Over the years, I have reviewed the accessibility of a number of sites. This document outlines ten common accessibility issues I have encountered which could result in a site’s failure to fully comply with WCAG 2.0. The document includes links to some of the WCAG 2 advisory Sufficient Techniques provided by the W3C for addressing each issue.

Please note: This is not intended to be a complete list of all possible accessibility problems and the order of the items is of no significance. For full details about WCAG 2.0 go to the “Web Content Accessibility Guidelines” W3C Recommendation 11 December 2008.

Page content

1. Failure to include text alternatives for images
2. Use of CAPTCHA
3. Failure to provide adequate alternatives for other inaccessible content
4. Failure to use HTML header elements appropriately
5. Failure to explicitly associate form inputs with their labels (or use the input title attribute)
6. Failure to ensure sufficient difference between foreground (text) colour and background colour
7. Failure to identify data tables with Summary or Caption
8. Failure to mark-up data tables correctly
9. Failure to ensure sites can be used without the mouse
10. Use of onChange event handlers with select menus

1. Failure to include text alternatives for images

The need to provide equivalent text alternatives for all non-text content is the first accessibility requirement of WCAG 2.
1.1.1 Non-text content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose (except for a few specified situations). (Level A)
WCAG 2.0 Success Criteria 1.1.1

In practice, this Success Criterion most often relates to the use of the image alt attribute for images that are necessary to understand and/or use a site and a null or empty alt (alt=””) for images that are used for layout or decorative purposes.

1.1: Selected Sufficient Techniques

A: If short description can serve the same purpose and present the same information:

• Use alt attributes on img elements (Technique H37)

B: If a short description can not serve the same purpose and present the same information as the non-text content (e.g. a chart or diagram):

• Provide short text alternatives (e.g. alt attribute) AND one of the following techniques for the long description:
• Long description for non-text content using longdesc (Technique G92).
• Long description in text near the non-text content (Technique G74).
• Long description in another location with a link to it that is immediately adjacent to the non-text content (Technique G73).

1.2: Note on use of CSS background images

CSS background images should not be used for important items like navigation elements or headings since they will not be displayed when a site is accessed with a device that is unable to display images. Use of background images in this way is a recognised WCAG 2 failure.

• Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information (Failure F3).

2. Use of CAPTCHA

CAPTCHA stands for “Completely Automated Public Turing test to Tell Computers and Humans Apart”.

The most common example of CAPTCHA is distorted images of text used as part of a login or registration process. Since this form of CAPTCHA uses randomly generated images without text alternatives they are inherently inaccessible to screen reader users and other people who are unable to access images on the page.

The need to provide an alternative for CAPTCHA is one of the specific exceptions in Success Criteria 1.1.1
1.1.1 Non-text content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose (except for a few specified situations). (Level A)

• CAPTCHA: If the purpose non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.

2.1: Selected Sufficient Techniques

When non-text content is a CAPTCHA, two things need to be done:

• Provide a text alternative (e.g. image alt attribute) that describes the purpose of the CAPTCHA (Technique G143).

AND

• Ensure the Web Page contains another CAPTCHA with the same purpose using a different modality (Technique G144). Very often the other modality is audio, but the audio should be discernable and understandable by general web users (i.e. not too distorted).

3. Failure to provide adequate alternative for other inaccessible content

Many websites use proprietary (non-W3C) formats which may not be accessible. PDF and Flash are two commonly used formats that can cause problems for screen reader users.

When PDF and Flash content is prepared well it can be accessible to many assistive technology users, but since some assistive technologies may not be able to access even well made PDF and Flash material it is advisable to provide an accessible HTML alternative.

Web content producers should make PDF and Flash material as accessible as possible because assistive technology support for these formats is improving all the time and it is expected that well made material will be accessible to nearly all assistive technology users in the near future.

At this time, some jurisdictions do not consider PDF and/or Flash to be “accessibility-supported” technologies. For example in Australia, various government authorities stipulate an accessible alternative needs to be provided for PDF material.

There is a lot of advice on the web to help developers make accessible PDF material. A good starting point is the Adobe article “Workflow for creating Accessible PDFs“.

The W3C Techniques document contains a large number of techniques for improving the accessibility of Flash material (Flash Techniques for WCAG 2.0). There are detailed descriptions and examples for each technique.

4. Failure to use HTML Header elements appropriately

The ‘h1’ header element should be used for the main heading(s) of the page. Subsequent headers (h2, h3 etc) should be used to identify and present different sections and sub-sections of the page.
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
WCAG 2.0 Success Criteria 1.3.1

The failure to use header elements appropriately reduces the accessibility of sites since it makes it hard for screen reader users to understand the structure of information presented on the page. Appropriate header elements also allow screen reader users to easily navigate to different sections of the page.

4.1: Sufficient Technique

• Using H1-H6 to identify headings (Technique H42)

5. Failure to explicitly associate form inputs with their labels (or use the input title attribute)

Screen reader users, and others who are unable to perceive the visual presentation of the information on the page, need to be able to identify the purpose of form inputs (controls).

With most HTML forms, the aim or purpose of each input is identified with a text label that is presented using the HTML “label” element with a “for” attribute that has the same value as the “id” attribute for the associated input. The use of matching attributes enables screen readers to associate the label with the input. Each “id” attribute should be unique.

When it is not possible to provide an explicitly associated label, WCAG 2.0 allows the input title attribute to be used to identify the aim or purpose of the input.

5.1: Sufficient Techniques

• Using label elements to associate text labels with form controls (Technique H44)
• Using the title attribute to identify form controls when the label element cannot be used (Technique H65)

6. Failure to ensure sufficient difference between foreground (text) colour and background colour

There are two Success Criteria relating to the colour contrast ratio between foreground (text) and background colours, one at Level AA and the other at Level AAA. And, unlike WCAG 1.0 exceptions are made for differences in text size and the purpose of the text.
1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no contrast requirement.

(Success Criteria 1.4.5 Contrast (Enhanced), which is at Level AAA, requires a contrast ratio of 7:1 and 4.5:1 for large-scale text)

6.1: Sufficient Techniques for S.C. 1.4.3

A: text is less than 18 point if not bold and less than 14 point if bold

• Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text (Technique G18).
• Not specifying background color, not specifying text color, and not using technology features that change those defaults (Technique G148).
• Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast (Technique G174).

B: text is as least 18 point if not bold and at least 14 point if bold

• Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text (Technique G145).
• Not specifying background color, not specifying text color, and not using technology features that change those defaults (Technique G148).
• Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast (Technique G174).

6.2: Note on the use of CSS to provide a background colour

The use of a CSS image to provide background colour for navigation elements or headings can cause problems when the text colour is specified using CSS and no CSS background colour with sufficient contrast is provided for the text.

• Failure of Success Criterion 1.4.3, 1.4.6 and 1.4.8 due to specifying foreground colours without specifying background colours or vice versa (Failure F24).

7. Failure to identify data tables with Summary or Caption

WCAG 2.0 requires data tables to be presented in a way that allows the tables as a whole to be easily identified by assistive technologies.
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
WCAG 2.0 Success Criteria 1.3.1

WCAG 2.0 suggests the “summary” attribute of the table element and/or the “caption” element can be used to identify data tables. The “summary” attribute is probably the more commonly used method. The content of the “summary” attribute is not displayed on the screen however it is read by screen readers. The “caption” element is displayed as the table heading, and is explicitly associated with the content of the table.

7.1 Sufficient Techniques

• Using caption elements to associate data table captions with data tables (Technique H39).
• Using the summary attribute of the table element to give an overview of data tables (Technique H73).

8. Failure to mark-up data tables correctly

Unlike WCAG 1.0, no distinction is made between ‘simple’ and ‘complex’ data tables in WCAG 2.0. With all data tables, users need to be able to associate the information presented in each data cell with the relevant row and column headers.

With simple data tables, which have only one level of row and/or column headings, appropriate table markup is all that is required to allow screen reader users to access the information contained in the table. Appropriate markup for simple tables means using the TH element for the row and column headers and the TD element for the data cells.

However, screen readers can only access one level of row and/or column headers that use the TH element. With data tables that have more than one level of row and/or column headers it is necessary to also use the ID and HEADERS attributes and/or the SCOPE attribute.

Wherever possible, simple data tables should be used since they are easier to mark-up and most screen reader users find even well constructed complex data tables with multiple levels of headers, more difficult than simple tables to use.

8.1 Sufficient Techniques

• Using table markup to present tabular information (Technique H51)
• Using id and headers attributes to associate data cells with header cells in data tables (Technique H43)
• Using the scope attribute to associate header cells and data cells in data tables (Technique H63)

9. Failure to ensure sites can be used without the mouse

Not all web users are able to use a mouse so it is important to ensure site pages can also be used with the keyboard. There are two Success Criteria directly related to this issue:
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. (Level A)
WCAG 2.0 Success Criteria 2.1.1

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)
WCAG 2.0 Success Criteria 2.1.2

9.1 Selected Sufficient Techniques

• Ensuring keyboard control by using HTML form controls and links (Technique H91).
• Providing keyboard-triggered event handlers (Technique G90).
• Ensuring that users are not trapped in content (Technique G21).

10. Use of onChange event handlers with select menus

The use of JavaScript on websites is generally accessible since most assistive technologies can now support appropriately used JavaScript. However not all screen readers support all JavaScript “event handlers”, which trigger certain actions when an event occurs.

For scripts that do more than just change the visual appearance of an element, the W3C advises content developers to use event triggers that are device-independent, since many people with disabilities are unable to use a computer mouse.

Some web pages contain form inputs which present options in a drop-down menu that the user can select from. Those forms that use the “onChange” (device-dependent) event handler to trigger JavaScript functions based on a selection from within a ‘select’ element can present accessibility problems for the users of keyboards and some other input devices.

10.1 Selected Sufficient Techniques

• Providing a submit button to initiate a change of context (Technique G80) by using submit buttons (Technique H32).

See also:

• Failure of Success Criterion 3.2.2 due to launching a new window without prior warning when the status of a radio button, check box or select list is changed (Failure F37).