Web Accessibility: Making the Web Accessible for All
Web Accessibility: Making the Web Accessible for All
A discussion of the importance of making web pages as accessible as possible, and how developers can easily do this with some HTML.
Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
The Significance of a Universal Design Approach
Inclusive or universal design ensures that the content of an application is easily recognized by screen readers (SR) upon which visually impaired people usually rely. Also, one can navigate through the content of a website using a keyboard alone, in a logical order. This is particularly helpful for people with mobility issues who may not be able to use a mouse. This is also useful for people who prefer to use a keyboard over a mouse. Similarly, providing closed captioning for video content is extremely useful for people with hearing-impairment. Again, this is also helpful for users who would prefer to view a video without sound, for example, while in a public place. This is especially helpful in creating social media content, where videos can be viewed in mute mode.
IMAGE 1: Snapshot of a video with closed captioning (CC), which helps people with hearing impairment to watch and understand video content.
Choosing color contrast and text ratios will help people with color blindness and would also offer better readability for other users.
So, web accessibility or universal design not only ensures inclusivity but also makes your application more usable and friendly. Additionally, from a business point of view, it increases your audience base, covering people who are disabled, elderly, or who are on the mend from a serious injury.
Making Your Application Accessible
So, how do we make our application accessible to disabled users?
Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making web content more accessible. While this list is quite overwhelming, below are a few points that I had worked on in a major client project.
- Use ARIA (Accessible Rich Internet Applications) roles, states, and properties on your HTML markup.
ARIA Roles help assistive technologies to better understand the semantics and suggest the purpose of an element. For example, the below div serves as an alert:
<div role = ”alert” > Please upgrade your browser! </div>
And the below content is only for presentation purposes and needs not be read by the screen reader.
<a href = “somepage.html” role = “presentation” > <img src =”thumbnail.jpg“ role = “presentation” alt = “thumbnail image“ /> </a>
ARIA Attributes start with prefix ‘aria-’ and can either be a state or a property.
States are bound to change as a result of user interactions with the element. For example, when we are emulating native interactive elements, such as a checkbox or a radio button with a ‘span’ or ‘div’ (which we generally do because of design requirements).
<span role = “checkbox“ aria-checked = “true“ tabindex = “0“ id = “simulatedcheckbox“> </span>
Properties such as ‘aria-label’ are used on a form label that is not visible on the page (because of design requirements) but must be read out by the screen reader in order to understand what input is required by the user.
- Alt Text: Images should have proper ‘alt text’ so that SR users can understand what the image is meant for. Also, if the image used is only for decorative purposes, there's no need to use alt text as this might just distract SR users from more important details.
- Skip Navigation: Allow the user to skip to the main content directly by providing a ‘skip navigation’ link at the top of the page.
- Keyboard Navigation: Page content should be accessible through the keyboard using keys, such as tab, arrow, and shift + tab. The tabbing order should be logical.
IMAGE 2: The above animation shows that when elements are re-ordered using CSS, the tabbing order remains the order in which these elements appear in the DOM and not the order in which they appear to the user. Logically the order should be the same as the visual order of elements.
- Tooltip: A tooltip is generally accessed through a mouse hover or click. It should also be expanded by using the keyboard. For example, on pressing the enter key when such content opens, it should also be read by the SR.
- Visible Focus: Ensure that the keyboard focus is indicated visually. For example, through a border around currently focused content.
- Scalability: Ensure that the text is scalable and the application remains usable when scaled up to the 200% zoom level.
- Contrast Ratio: Ensure that a contrast ratio of at least 4.5:1 exists between the text (and images of text) and the background behind the text. There are various tools available online to test contrast ratios.
IMAGE 3: Text written over the above image is not visible properly as portions of image do not have sufficient contrast with respect to the text.
IMAGE 4: On reducing the opacity of the image, the contrast has increased and hence text is more visible.
- Form Labels: Form inputs should have associated labels that help the SR user understand what input is required from them.
- Heading Order: Always use the correct order of headings. Use <h1> for the primary title of the page. Do not skip heading levels, otherwise, SR might think some content is missing. For example, in a page, after you have written the main heading in an <h1> tag, you should not use <h3> tags directly for a sub-heading just because it looks visually correct. Rather, use <h2> and control the visual appearance through CSS.
- Validation: Whenever possible, validate the information entered by the user. When an error is found, show the user where it happened and describe the error in a textual format.
Opinions expressed by DZone contributors are their own.