In this article, I want to share my previous experience with Web Accessibility, even these days I’m just working as a Back end developer but I think this part of the software development is very important to attend.
What is Web Accessibility?
Web accessibility or eAccessibility is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with physical disabilities, situational disabilities, and socio-economic restrictions on bandwidth and speed. When sites are correctly designed, developed, and edited, more users have equal access to information and functionality. [Wikipedia]
web accessibility means that EVERYONE can use a Website.
Accessibility is about EVERYONE.
Web Content Accessibility Guidelines
The Web Content Accessibility Guidelines (WCAG) are part of a series of web accessibility guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), the main international standards organization for the Internet.
They are a set of recommendations for making Web content more accessible, primarily for people with disabilities—but also for all user agents, including highly limited devices, such as mobile phones. WCAG 2.0, was published in December 2008 and became an ISO standard, ISO/IEC 40500:2012 in October 2012. WCAG 2.1 became a W3C Recommendation in June 2018. [Wikipedia]
Versions 2.1 and 2.2 only solved a tiny portion of the issues. The WCAG guidelines are still confusing, and the way the levels work is not ideal. They needed a complete overhaul, and in late 2016 a task force was put together to create a brand new version, WCAG 3.0.
Here’s more information, if you’re interested: Accessibility Guidelines 3.0
Benefits of an Accessible Website
- Increasing the market and the number of web audiences
- Ideal SEO
- Creating positive public relations
- You will be protected from discrimination and complications that the law imposes on programs that do not have these features
- Enhancing the website’s performance and usability
Web Accessibility Checklist
If you want to make sure that your website is accessible, accommodate your website with the below checklist:
- Images should have meaningful alternative text
- Links should be visually identifiable
- Use descriptive section headings
- Use correct semantic HTML element structure for your content
- Forms have descriptive labels
- Information should not depend on color, sound, shape, size, or visual location
- Text and background color should have sufficient contrast
- Content scales properly when zoomed/enlarged
- Use a descriptive title tag
- Support keyboard navigation
- Focus states should be visible for keyboard users
- Use correct HTML5 input types
- Content that automatically changes has the ability to be paused (Users must be able to pause movement on automatically changing content (carousels, slideshows, etc.))
- Limit or remove any flashing elements
- Users should be able to navigate content using a screen reader
- Allow keyboard users to skip navigation (Give keyboard users the ability to skip over all of the links, corporate icons, search bars, and other navigation elements and allow them to navigate to the beginning of the page content.)
- Offer multiple ways to find pages on your website (sitemap page, search function, main navigation)
- Avoid mouse-only interactions
- Set focus on modals, popovers, alerts, etc.
- The site should not time out unexpectedly
- Multimedia should have alternative ways to be consumed
- Ensure audio and video are not played automatically unless that is the expected behavior
- Use the HTML lang attribute
- Use understandable inputs labels
- Forms have helpful and accessible error and verification messages
- Make data available for graphs, charts, maps, SVGs, etc. through assistive technology
- Links should be descriptive and provide intent
- Table data is accessible to non-sighted users
- Use ARIA landmarks where applicable
- Decorative images should not be visible to screen readers
- Pages are understandable with no styles enabled
- Web page size should not exceed 500k
- HTML should be valid and error-free
You can follow the checklist details here:
- Accessibility checklist – webflow
- Web Accessibility Checklist
- Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0
Web accessibility topics to consider
As well as the checklist which I mentioned here, let’s discuss some important topics with examples.
Good Color Choices
It’s estimated that 4.5% of the global population experience color blindness (that’s 1 in 12 men and 1 in 200 women), 4% suffer from low vision (1 in 30 people), and 0.6% are blind (1 in 188 people). It’s easy to forget that we’re designing for this group of users since most designers don’t experience such problems.
uxbooth website
Here you will learn more about Good Typography, Forms, etc. Accessibility for Visual Design
Easy To Touch
The minimum size for choosing a button on a website page is around 44 to 48 pixels, which means when user wants to select or press a button on their phone touchscreen they should do that without any touch problem.
Keyboard Navigation
It is best to allow users to navigate between pages and sections of our websites with keyboard buttons and not disable keyboard navigation with CSS or JavaScript.
More information: Keyboard-navigable JavaScript widgets
The structure of HTML codes
In HTML codes, it’s better to follow a correct structure, for example, in nested content, when we have an h1 tag, we should first have an h2, and then an h3, etc.
To view your code structure, I recommend installing the HTML5 Outliner Chrome Extension.
Use the correct type of the lists in your codes, for example, if you have an un-order list use the ul tag, if you have an ordered list use ol tag, and if you have a descriptive list use dl tag.
by default, images are not accessible! if you want to have an accessible image you should add an alt attribute in your image HTML tag.
use the longdesc Attribute (longdesc Attribute) for images that need analysis or description data, or use aria-describedby for describing a section of the codes.
The aria-describedby attribute is used to indicate the IDs of the elements that describe the object. It is used to establish a relationship between widgets or groups and text that described them. This is very similar to aria-labelledby: a label describes the essence of an object, while a description provides more information that the user might need.
developer.mozilla.org
<button aria-describedby="trash-desc">Move to trash</button>
…
<p id="trash-desc">Items in the trash will be permanently removed after 30 days.</p>Skip Navigation Button
It must be possible for a user to access the content of the website regardless of how he enters the site, and no matter what tool he uses.
When a website has different images and content on each page, the “Skip to Main Content” button lets the user see the main content of the page. Assume that the user navigates different pages in a user panel with about 20 menu items. Using the keyboard, he/she has to press the Tab key 20 times on each page to reach the main content, which is very boring and annoying. It is very practical to place the button to access the content and the main part of the page for this reason.
here is an example for the old version of the sitepoint website.
If you are using the Abbreviation element, use the title attribute for it.
Using ARIA: Roles, states, and properties
ARIA defines semantics that can be applied to elements, with these divided into roles (defining a type of user interface element) and states and properties that are supported by a role. Authors must assign an ARIA role and the appropriate states and properties to an element during its life cycle unless the element already has appropriate ARIA semantics (via the use of an appropriate HTML element). The addition of ARIA semantics only exposes extra information to a browser’s accessibility API, and does not affect a page’s DOM.
for example:
<div id="saveChanges" tabindex="0" role="button" aria-pressed="false">Save</div>More Information:
ARIA states and properties
ARIA attributes enable modifying an element’s states and properties as defined in the accessibility tree.
Note: ARIA only modifies the accessibility tree, modifying how assistive technology presents the content to your users. ARIA doesn’t change anything about an element’s function or behavior. When not using semantic HTML elements for their intended purpose and default functionality, you must use JavaScript to manage behavior, focus, and ARIA states.
mozilla.org
Section 508 Amendment to the Rehabilitation Act of 1973
In 1998 the US Congress amended the Rehabilitation Act to require Federal agencies to make their electronic and information technology accessible to people with disabilities. Section 508 was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. The law applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. [Wikipedia]
Summary of Section 508 technical standards
- Software Applications and Operating Systems: includes accessibility to software, e.g. keyboard navigation & focus is supplied by a web browser.
- Web-based Intranet and Internet Information and Applications: assures accessibility to web content, e.g., text description for any visuals such that users of with a disability or users that need assistive technology such as screen readers and refreshable Braille displays, can access the content.
- Telecommunications Products: addresses accessibility for telecommunications products such as cell phones or voice mail systems. It includes addressing technology compatibility with hearing aids, assistive listening devices, and telecommunications devices for the deaf (TTYs).
- Videos or Multimedia Products: includes requirements for captioning and audio description of multimedia products such as training or informational multimedia productions.
- Self-Contained, Closed Products: products where end users cannot typically add or connect their own assistive technologies, such as information kiosks, copiers, and fax machines. This standard links to the other standards and generally requires that access features be built into these systems.
- Desktop and Portable Computers: discusses accessibility related to standardized ports, and mechanically operated controls such as keyboards and touch screens.
Web Accessibility Tests
There are several tools and websites available for checking whether your website is accessible:
- freedomscientific – Accessibility Testing Products
- NVDA for Windows OS
- Colour Contrast Analyser (CCA)
- Accessibility Developer Tools – Chrome Extension (Offered by: Google Accessibility)
- web.dev
- tenon.io – Accessibility as a Service
- tota11y
- a11yproject – Learn the fundamentals and principles behind the accessible design
- WAVE Web Accessibility Evaluation Tool
- Accessibility in Google Search
With the Wave website, I checked my personal blog’s accessibility and can see the list of issues and how to fix them and improve my blog’s accessibility.
