Ten Common Accessibility Problems

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:

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

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

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).

9 comments;

  1. Thanks, Roger. This is almost like my own checklist in many ways. The onChange and other inline event handlers really have no place in HTML any longer; it’s rather easy, and more maintainable, to code them in a separate, dedicated script file. These old techniques are still so prevalent that it makes the habits hard to break for some developers.

    Bruce brings up a good point regarding table summaries. I’ve been watching the HTML5 spec grow and the WHATWG discussions around the summary attribute brought up some valid points. I think if you explain the data in a text summary prior to the table that would be sufficient for most folks, but what about screen readers and other assistive technologies which rely on the summary? Maybe a suitable solution would be to use some scripting and DOM magic to grab the summary, place it back on the page above the table and style it accordingly? The only downside to this approach is that some screen readers may read the summary twice, but we’ve never encountered this ourselves.

    Thanks again. It’s very nice to see accessibility discussions becoming active again.

  2. This is a very nice collection of issues.
    I often hear that there is too much to accessibility. If web designers would only take these ten recommendations and would design with these in mind from now on, the internet could be much more accessible.

  3. Thanks Bruce, Billee and Tom for your comments.
    With regard to summary and caption, the one big advantage they have over using a heading and/or paragraph before the table is that summary and caption are explicitly associated with the table. For pages containing just a single data table it might not be a big issue, but if you have a page with multiple data tables the use of summary and/or caption will allow screen reader users to use a keyboard shortcut to jump from table to table, and each table will be identified when it is encountered. If the table is identified by a only preceding heading or paragraph the user will have to back to find this information. I usually tell people they should try to use summary and caption, but if not both at least one should be used.
    When it comes to summary, the content of the summary is really for screen reader users and should provide a quick overview of the table, and its aim and content, that is similar to what a sighted person would get from a quick look. As such, the wording might not be the same as what you would use in a piece of text on the page before the table.

  4. I don’t know about most of the list, but I do know what bugs me most often and it is pretty simple. For an elderly audience, be sure to (1) enable word wrap so that enlarged copy stays on the screen, and (2) enable the viewer’s choice of font style and size as set in his browser so he can use a bolder font. Old eyes tend to need high contrast and enlarging the copy isn’t enough for many of us. We need a bold font. This need applies to email as well.

    ===gm===

  5. How will #4 work with the new HTML5 elements? My understanding is that proper HTML5 will only use h1 elements along with nesting of sectioning content in order to determine the true level of the heading.

    I discussed this at length with people in the WhatWG IRC channel and the outcome was that future browsers will change the default styling of h1 elements to match their nesting and it doesn’t really matter since most people will override their styles with CSS anyway. Older screen readers that have no knowledge of HTML5 will surely be confused by all the h1 elements.

  6. It may be just an ESL problem on my part but I am confused by your use of “header” and “heading” interchangeably, especially since “header” is a common page component that is also made official in the HTML5 header element. The concept however is perfectly clear.

  7. G F Mueden, if resizing and reflowing text is a continual problem for you, an application in development called Zone Clipper might be just what you need. Read more about it at http://tinyurl.com/26ul564 and stay on the lookout for its general availability. If you can see well enough to figure out the location on the Web page of the text you want to read, Zone Clipper lets you copy that block of text and reformat it to meet your specific needs. It’s a cool tool, and I hope it’s widely available soon.

    Michelangelo, it is not just an ESL problem. Because both “header” and “heading” are essential components of any Web page, it would help if more of us used the terminology carefully. Most often the slip-up is as occurred here — using “header” when “heading” is meant. But it can really get confusing. If I were to say, “For these headers, use heading 2” in one breath and then say, “Be sure to enter the title in the page header,” I wouldn’t expect anyone to know whether my second sentence meant to be sure to populate the “Title” tag in the header region of the page or to be sure to enter the title as a heading 1 in the body region of the page.

  8. Like Steve, I’m wondering about the potential confusion that might arise when HTML5 header elements are marked up with h1 headings. One can always match the heading level to the structure of the document by using and h2 or h3 in the header element, but that doesn’t completely resolve the question. Since HTML5 sectioned content (e.g. a section or article element) can be picked up as a discrete section and placed elsewhere or syndicated, the headings used may not match the logical outline of the destination either. I’m watching with great interest to see how HTML5 headers are handled by screen readers and other devices.

Leave a Reply to G F Mueden Cancel reply

Your email address will not be published. Required fields are marked *

*
*