12 manual tests for accessibility compliance you should do now

It is important to design and develop websites with accessibility in mind. It is a common misconception that tools can be used to determine if a website is compliant with accessibility guidelines. This article will describe at a high level which guidelines cannot be tested with an automated tool, and require manual testing.

How do you measure web accessibility compliance?

Accessibility compliance levels have been defined by the World Wide Web Consortium (W3C) in their Web Content Accessibility Guidelines (WCAG) version 2.0. The guidelines define criteria that describe three levels of compliance:

  1. Level A: These guidelines are considered "must-haves" for accessibility compliance.
  2. Level AA: These are defined as "should have" features.
  3. Level AAA: These are defined as "nice to have" features.

How is web accessibility compliance enforced?

Two US laws exist pertaining to web accessibility:

  1. Section 508 of the United States Workforce Rehabilitation Act of 1973 contains a series of guidelines for United States Federal Government agencies. These are separate from the W#C's WCAG guidelines.
  2. The American Disabilities Act (ADA), Titles II and III encourage state and local government websites, as well as the websites of private entities, respectively, meet WCAG 2.0 to level AA. A proposed official rulemaking for this has been proposed for 2018 that would potentially make compliance mandatory.

Is there a tool that can quickly measure compliance for my website?

Automated tools can measure a website's compliance with certain guidelines. These include the WAVE toolbar and AChecker. Using these tools can help you find trouble areas on your site. But you must also do manual tests to be sure that your website is accessible. Some accessibility guidelines require a human's judgement in order to be measured.

Using tools alone to test for accessibility compliance results in a false sense of security.Click To Tweet

I have listed these guidelines below, along with the associated manual test for each guideline. Use an automated tool on your website in addition to these manual tests to see if your website is accessible. The most critical one to try is guideline 2.1.1, which states that all functionality must work with the keyboard alone.

There are twelve manual tests to measure level A compliance, 3 for level AA compliance, and two for level AAA compliance.

WCAG Guidelines that need manual tests

WCAG Guideline Manual Test Description
1.1.1 All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. (Level A) CSS background images should not be used for images that convey important information. This is because you can't put alternate text on a CSS background image. Right-click on an image to view source, and if there is no <img alt="" /> tag, then it is probably a CSS background image.
1.3.1 Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A) Validate that changes in text presentation are not used to convey information without using appropriate markup (e.g. text styled as a heading but not marked up with heading tags), and that layout tables do not use any attributes associated with data tables (e.g. IDs and headers for columns/rows, or E.g. Use of <th> tag, "summary" attribute, etc. for a LAYOUT table).
1.3.2 When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A) Validate that an HTML layout table makes sense when linearized, i.e. when the table is read from top to bottom, left to right.
1.3.3 Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. (Level A) Validate that a graphical symbol alone is not used to convey information. For example, an empty shopping cart icon vs. a shopping cart icon with an item in it, with no text alternative to indicate the cart's status.
2.1.1 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) Validate that all critical user flows are achievable through keyboard alone.

Validate that all remaining content is accessible through keyboard alone.

2.1.2 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) Validate that there are no keyboard traps (interactions you can get into with your keyboard, but can't get out of). These would be most likely to occur in overlays and other interactive elements on the page such as video players or image galleries.
2.4.1 A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A) Validate that a link is provided to skip navigation and other page elements that are repeated across web pages OR that a page has proper heading structure.

Make sure it actually works to use the "skip navigation" link by tabbing to it, hitting "Enter" with your keyboard to follow the link. Ensure that the content area moves into focus, then tab again and ensure that the tab focus continues to be in the content area.

Note: A developer can provide the skip navigation link as a hidden anchor link, but it's helpful for keyboard users not using a screen reader if the link becomes visible on focus, or is always visible.

2.4.3 If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A) Validate that navigation order of links, form elements, etc. is logical and intuitive. Do this by tabbing through all elements. If the focus area does not move in a sensible way from in the reading order from top to bottom, there is an issue.
2.4.4 The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A) Validate that the purpose of each link (or form image button or image map hotspot) can be determined from the link text alone, OR from the link text and its context, by doing the following:

(1) Locate content needed to understand how link text describes the purpose of the link, and (2) Check whether the content is contained in the same sentence, paragraph, list item, or table cell, or in the preceding heading.

Validate that links (or form image buttons) with the same text labels that go to different locations are readily distinguishable (i.e. not in the same context in the markup).

Note: If the design makes it difficult to include the link text IN CONTEXT in the markup, then the content should be updated. 

3.2.1 When any component receives focus, it does not initiate a change of context. (Level A) Validate that when any page element receives focus, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user. (E.g. Opening a new window when the page is loaded, or using a script to remove focus when focus is received).
3.2.2 Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A) Validate that when a user inputs information or interacts with a control, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user unless the user is informed of the change ahead of time. (E.g. Automatic submission of a form and presentation of new content without a warning, or launching some action upon selection of a radio button, check box, or select list).
3.3.1 If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A) Validate that required form elements or form elements that require a specific format, value, or length provide this information within the element's label. The information should be present between the <label> tags in the markup. Validate that form validation errors are presented in an efficient, intuitive, and accessible manner. I.e., form errors should receive keyboard focus and be read out by the screen reader.
1.4.4 Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA) Validate that text can be resized up to 200% and remain legible. Test this in Firefox: View > Zoom > Zoom text only, then ctrl+ on your keyboard to increase the font size on your screen.
2.4.7 Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA) Validate that it is visually apparent which page element has the current keyboard focus (i.e., as you tab through the page, you can see where you are). Note: This may need an associated design.
3.1.2 The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA) Validate that the language of page content that is in a different language is identified using the lang attribute (e.g.,
<blockquote lang="es">).
2.2.4 Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency. (Level AAA) Validate that there are no meta redirects with time limits, that there are no meta refreshes with a time out.

Validate that interruptions (alerts, page updates, etc.) can be postponed or suppressed by the user.

2.2.5 When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. (Level AAA) Validate that if an authentication session expires, the user can re-authenticate and continue the activity without losing any data from the current page.

2 thoughts on “12 manual tests for accessibility compliance you should do now

  1. Re 2.1.2 Keyboard Trap - sometimes it's actually sensible to trap and cycle focus in an overlay until the user has interacted with the overlay or dismissed it.

    As you have also mentioned, this is primarily about media players and flash content (if anyone still uses that).

    Reply
    1. lsnrae

      Thanks for your comment, Graham. I know what you're referring to here. If someone opens a modal window or overlay as you note, the keyboard focus should stay within that component until they close it. However, the fact that they can close it and escape means that it is not a "trap." The guideline indicates that there should never be a trap (i.e. once my keyboard focus is placed within a component or element, I am unable to leave).

      Reply

Leave a Reply

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