Part of my job is to assess if websites are usable for people with disabilities. Over the past year I have audited many large-scale web experiences across various industries. I've helped three airlines in China and Canada and some Canadian retailers. I've assisted some US educational institutions.
Through these audits I have identified the top 5 most costly website accessibility issues. These are the ones that have the most detrimental effect for users, and that will take the most time to fix later.
It takes time to conduct a full accessibility audit. Instead, start by reviewing these five issues. If you fix these on your website, you will ensure a baseline of compliance that you can continue to enhance.
Most costly accessibility issue #5:
Guideline 1.1: Text Alternatives: Provide text alternatives for any non-text content.
All non-text content (like images or video) needs a text alternative that describes the non-text content. Images on a website need alternative text described in an alt attribute. It looks like this in the code:
<img src="myimage.jpg" alt="Descriptive text for my image" />
Some general rules for creating alt attributes:
- All images need alt attributes.
- Decorative images need empty alt attributes.
- All other imagery needs a descriptive alt attribute.
- For the most part, don’t bother using title attributes.
- You can't place an alt attribute on a CSS background image. Images that need to be described should be marked up with an <img> tag.
What happens if you do not use an alt attribute on an image? If your site’s imagery does not have an alt attribute, the assistive device will read the path to the image. This is annoying for non-sighted users, and usually doesn't help them understand the image content.
This guideline is easy to test with automated tools like the WebAIM Chrome browser extension. Install this in your Chrome browser. Test each page to see if there are alt attributes missing on your site’s imagery by clicking on the button in the toolbar.
Familiarize yourself with the rules for applying alt attributes here: WebAIM > Articles > Alternate Text, and here: The Paciello Group: HTML5 Accessibility Chops: title attribute use and abuse.
Most costly accessibility issue #4:
Guideline 1.3: Create content that can be presented in different ways without losing information or structure.
- Use semantic markup to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc.
- Use tables for tabular data. Where necessary, associate data cells with their headers. Use data table captions and summaries where appropriate. Read more about accessible data tables.
- Note for the integration team: Table captions, summaries, and IDs and headers should be exposed to a CMS authoring tool.
Why does heading structure matter?
Assistive devices have the ability to navigate web pages by structure. A user visiting the site using such a device can navigate the site in various ways. They may choose to navigate through a list of the headings to understand what content is available on a page.
Elements styled to look like headings will not appear as headings for these users. Heading tags must be used for users to benefit from this feature of their assistive device.
<h1>Main headline text</h1>
Do NOT do this:
<p class="heading">Main headline text</p>
It can be tempting to assign styles to heading levels based on the design style guide (see figures 1 and 2). When you do this, sometimes you will need to skip heading levels on a page to meet the design requirements. This breaks accessibility guidelines (see figure 3).
You can avoid this issue can by implementing the CSS styles for headings the following way.
- Keep heading css styles separate from heading structure in html. For example, create separate heading level css classes, e.g. .primaryHeading, .secondaryHeading, etc. with properties defined in CSS.
- In this way, you can apply any style to any heading level, and place headings on the page in the expected order.
In this way, we can apply heading levels independent of style (see figure 4). This method meets both the design requirements and accessibility guidelines.
Most costly accessibility issue #3:
Guideline 2.1: Make all functionality available from a keyboard
This is another one that is easy to test during development. Developers are already tasked with testing their work across various browsers and devices. Developers should simply tab through each page with their keyboard as they are developing.
Talk to the developers on your team about navigating a site with the keyboard alone. Ask them to try it on one of the pages they recently developed. Warn them in advance about common problem functionalities like modal windows or flyout menus. Items that show or hide content when the user clicks on them with the mouse pointer need to also work when the user tabs through with their keyboard.
Most costly accessibility issue #2:
I bet the forms do not work for users of assistive devices on your website.
So much depends on form design. Forms are not meant to be fancy. A form's main purpose is to function as intended -- to capture and submit information. Encourage designers to create simple forms that observe the following best practices:
- The full form label is included with the field (hint: Do not rely on placeholder text)
- The form label is ideally above the form field. This way it will fit easily into a narrow area (e.g. a mobile device).
- Required fields are indicated with an asterisk.
- Browser default controls are the easiest to ensure accessibility compliance.
Developers need to ensure that form fields are programmatically associated with their labels. This is a simple exercise that is too often missed. Test it by tabbing through the fields of your form with a screen reader enabled. Screen readers will not read out form field names if the fields are not associated with their labels. The impact will be that the user will not know what information they should enter in the field. Read this excellent article on form accessibility.
<input id="name" type="text" name="textfield">
Most costly accessibility issue #1:
3.2.2 On Input: When the user submits a form without filling out all fields they will get an error.
When a user fills out a form the wrong way and attempts to submit it, errors preventing form submission are commonly bypassed by the screen reader. Often the error will appear in red text, but non-sighted users will not see it. The user gets no feedback about what they did wrong so cannot fix the issue. It slams the door in the face of a user of assistive devices.
This can be easily fixed during design phase. The error message for each field should appear next to or immediately below that field's label in the design. In the code, the error message should be placed within the label itself. When an error is generated, focus should be programmatically placed on that field. The screen reader will automatically read out the field's label followed by the error message.
Using this method, the user's experience will improve. Let's say the user forgot to provide their email address, and try to submit the form. The keyboard focus will immediately be set on the email field, and the error message will be appended to the label. The user will hear "Email address. Please provide your email address." The email address field will have focus, so they will be able to immediately start typing their email address. Then they can tab through the rest of the form and click "submit" again.
The bottom line:
All web experiences deserve a thorough accessibility review, but starting with these 5 tactics will ensure a baseline of accessibility compliance on your pages.
Let me know what accessibility unit tests you use in your work.