Six things you need to audit your site for accessibility

This article is part 2 of my series, how to do an accessibility audit. It will give you step-by-step instructions to test a complete website for accessibility compliance. It assumes that the website you are testing meets the following criteria:

• The website has a content management system
• The website consists of a set of templates and components that are reused across the site.

Auditors need the following information to complete a site-wide accessibility audit:

Six things accessibility auditors need:

(1) The auditor must be provided with a list of accessibility compliance levels to test. E.g. Web Content Accessibility Guidelines (WCAG) level A, AA, and/or AAA. Note that even the W3C doesn’t recommend trying to meet all criteria for AAA.

(2) The auditor requires a list of page links to test that include:

• Representative pages from every kind of template on the site
• Coverage of all components used across the site
• An optional percentage of extra pages to test as a sanity check (e.g. pick pages that are popular according to analytics testing reports)
• A list of “Happy Path” flows to test (e.g. sign in flow, purchase flow, etc.)

Typically I get this information from the technical team that maintains the site.

(3) The WCAG guidelines cover a range of criteria that includes page interactivity, visual design, and code. In some cases, some of this criteria would have been tested already during the design process. For example, contrast levels in the design may have already been tested in the design phase. The auditor needs to understand which criteria they will be checking.

In general, I recognize 4 main types of criteria that can be tested. Those pertaining to interactivity, design, code, and copy.

(4) The auditor must be provided with a list of device types to test the site. E.g. Is it a desktop-only audit, or should mobile devices be used for the audit? I have a POV on this that I will blog about soon.

(5) The auditor may use their tool(s) of choice to test the site, unless specific tools are specified. Some tools include:

• AChecker Web Accessibility CheckerOpens in a new window,
• WAVE Accessibility Evaluation ToolOpens in a new window,
• Direct link to WAVE accessibility toolbar for ChromeOpens in a new window
• Voiceover on a Mac for keyboard accessibility testing (press command+F5 on your Mac to start it)

(6) The auditor would benefit from familiarity with the following reference material to assist them in the audit process:

Helpful links:

• WCAG 2.0 Quick Reference
• WebAIM WCAG Checklist
• WebAIM accessible forms
• WebAIM accessible data tables

Accessible sites for reference (to see how it is done properly elsewhere):

• Government of Canada website
• Canadian National Institute for the Blind website
• Ramp up article: The top 5 most costly accessibility errors

WCAG Guideline Manual Test Cases

The table below lists WCAG guidelines that need manual tests and what those manual tests are for levels A and AA. I did not include AAA to save space. Let me know if you would like those in the comments and I’ll post them.

Audit Process:

For each of the pages provided to the auditor:

• Use an automated tool to highlight issues that can be caught by a machine.
• Perform the manual tests described in the table below.

For each of the “Happy Paths” provided:

• Attempt to go through the flows with just your keyboard
• Then go through the flows with your keyboard and a screen reader. Really listen to ensure that users who are not sighted are being given enough context to understand the experience.

Note: The letters beside some of the guidelines indicate what specialist must fix that issue. i=Information Architect, d=Designer, c=Copywriter, and no letter at all means Developer.

WCAG Manual Test Cases (levels A and AA):

Note: The letters beside some of the guidelines indicate what specialist must fix that issue. i=Information Architect, d=Designer, c=Copywriter, and no letter at all means Developer.

1.1.1-A-Non-text Content: Use automated tool to check for missing image alt attributes. Automated tools can also check for redundant alt attributes.

1.1.1-A-Non-text Content: Ensure that CSS background images are not be used for images that convey important information.
TOOL: Web developer toolbar
METHOD: Images > Outline All Images
— Validate that all images that convey important information have outlines.
(Background images will not be outlined).

1.1.1c-A-Non-text Content: Check if the text alternative is appropriate (i.e. conveys information, not filenames, and images that should be ignored by assistive technology have null alt attributes (“”).

1.2.1-A-Audio-only and Video-only (Prerecorded): Validate that:
(1) A descriptive text transcript (including all relevant visual and
auditory clues and indicators) is provided for non-live, web-based audio
(audio podcasts, MP3 files, etc.) and
(2) A text or audio description is provided for
non-live, web-based video-only (e.g., video that has no audio track).

1.2.2-A-Captions (Prerecorded): Validate that synchronized captions exist for videos that include all dialogue and sound effects.

1.2.3-A-Audio Description or Media Alternative (Prerecorded): Validate that a descriptive text transcript OR audio description audio track is provided for non-live, web-based video.

1.2.4-AA-Captions (Live): Validate that synchronized captions are provided for all live multimedia that contains audio (audio-only broadcasts, web casts, video conferences, Flash animations, etc.)

1.2.5-AA-Audio Description (Prerecorded): Validate that audio descriptions are provided for all video content.
NOTE: Only required if the video conveys content visually that is not
available in the default audio track.

1.3.1-A-Info and Relationships: Use automated tool to check for failures (not warnings) about the document’s heading structure.

1.3.1-A-Info and Relationships: Use automated tool to check for input elements that are not associated with their labels.

1.3.1-A-Info and Relationships: 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).
TOOL: Web developer toolbar
METHOD: Outline > Outline Headings (you can also check off “Show Element Tag Names” to see the heading level)
— Validate that there is no heading on the page that has the APPEARANCE of a heading but no heading tag.

1.3.1-A-Info and Relationships: Validate that data tables are marked up using appropriate table markup (including specified IDs or headers for columns/rows).
RESOURCE: Creating Accessible Tables
TOOL: WAVE Toolbar
METHOD: Run a page-level test with WAVE.
— Refer to Details Tab > Structural Elements and ensure that all tables
on the page are reported.
— Ensure that a table caption is reported for each table.
— Ensure each heading in the table has a “col th” or a “row th”.
OR use the Web developer toolbar:
— Outline > Tables, table cells, table captions, with “Show Element
Tag Names” turned on.

1.3.1-A-Info and Relationships: Validate that layout tables do not use any attributes associated with data tables (e.g. scope and headers for columns/rows).
TOOL: Web Developer Toolbar
METHOD:
— This test is for LAYOUT TABLES ONLY (not for tabular data).
— Navigate to Outline > Tables in the toolbar to find layout tables, with
“Show Element Tag Names” turned on. This will display any tables on
the page and allow you to assess if they are layout tables.
— For layout tables, ensure that there are no data table attributes used
(e.g. scope and <th> tags). You will be able to see the tag used.

1.3.2-A-Meaningful Sequence: This test is for LAYOUT TABLES ONLY: Validate that an HTML layout table makes sense when linearized.
TOOL: Web Developer Toolbar, Lynx Viewer
METHOD:
— This test is for LAYOUT TABLES ONLY (not for tabular data).
— With the Web Developer Toolbar, navigate to Outline > Tables in the
toolbar to find layout tables, with “Show Element Tag Names” turned
on. This will display any tables on the page and allow you to assess if they
are layout tables.
— If there are layout tables, copy and paste the page URL and paste it into
the Lynx Viewer to see how the table looks when the content is linearized.

1.3.3c-A-Sensory Characteristics: Validate that instructions on the site do not depend on sensory characteristics like sight (e.g. “Click on the blue button to continue”) or sound (e.g., “A beeping sound indicates you may continue.”).

1.3.3-A-Sensory Characteristics: Look at controls on the page and validate that the instructions on how to use the controls do not relay on sensory characteristics like color, shape, size, etc. An example would be a button to toggle something ON or OFF that relies on color or position of the button to indicate current status. It shouldn’t rely on color or position, it should say ON or OFF.

1.4.1c-A-Use of Color: Validate that text alternatives include information conveyed by color differences.

1.4.1d-A-Use of Color: Validate that color alone is not used to distinguish links from surrounding text unless the luminance contrast between the link and the surrounding text is at least 3:1 and an additional differentiation (e.g., it becomes underlined) is provided when the link is hovered over or receives focus.

1.4.2-A-Audio Control: Validate that a mechanism is provided to stop, pause, mute, or adjust volume for audio that automatically plays on a page for more than 3 seconds.

1.4.3-AA-Contrast (Minimum): Validate that:
(1) Text and images of text have a contrast ratio of at least 4.5:1,
AND
(2) Large text (over 18 point or 14 point bold) has a contrast ratio of at
least 3:1

1.4.4-AA-Resize text: Validate that text can be resized up to 200% and remain legible.
TOOL: Firefox browser
METHOD:
— With the page open in Firefox, navigate to View > Zoom > Zoom Text
Only.
— Use command+ (command key and plus sign) to increase the size of the text until it is around 200% bigger. See if the layout breaks so much that you can’t read the text anymore. It doesn’t matter if the layout breaks a bit as long as the text is still legible.

1.4.4-AA-Resize text: Validate that form controls resize along with visually rendered text.
TOOL: Firefox browser
METHOD:
— With the page open in Firefox, navigate to View > Zoom > Zoom Text
Only.
— Use command+ (command key and plus sign) to increase the size of the text until it is around 200% bigger. See if the form controls also grow in size along with the text.

1.4.5-AA-Images of Text: For Images of text: Validate that the image is a logo and has appropriate alt attribute. Or, validate that the image can be customized (i.e. increased in size without losing legibility)

2.1.1-A-Keyboard: Automated tools can detect the presence of possible javascript jump menus. Would require a manual test to ensure that the jump menu is in fact inaccessible (i.e. triggers a new page on change without activating with a button). Tools can also detect the presence of device-dependent event handlers.

2.1.1-A-Keyboard:
(1) Validate that all critical user flows are achievable through keyboard alone. (2) Validate that all remaining content is accessible through keyboard alone.
TOOL: Keyboard and/or Screen Reader
METHOD: If using a screen reader, ensure you are using the compatiblebrowser for your screen reader of choice.
— If using Safari and Voiceover,
configure Safari so that you can tab through all elements, not just forms:
Safari > Preferences > Advanced > Accessibility > Press Tab to
highlight each item on a webpage.

2.1.2-A-No Keyboard Trap: Validate that there are no keyboard traps. These would be most likely to occur in overlays and other interactive elements on the page such as video players or image galleries.
— Note that all keyboard traps will probably be found when investigating
guideline 2.1.1

2.2.1-A-Timing Adjustable: Automated tools can detect use of <meta http-equiv=”refresh”> tags and will add this to a report.

2.2.1i-A-Timing Adjustable: Validate that if a page or application has a time limit, the user is given options to turn off, adjust, or extend that time limit.

2.2.2-A-Pause, Stop, Hide: Auotmated tools can detect use of the <blink> tag and <marquee> element, and <meta http-equiv=”refresh”> tags

2.2.2i-A-Pause, Stop, Hide: Validate that:
(1) Automatically moving, blinking, or scrolling content that lasts longer
than 5 seconds can be paused, stopped, or hidden by the user, i.e. HAS
CONTROLS, and
(2) Automatically updating content (e.g., automatically redirecting
or refreshing a page, a news ticker, AJAX updated field, a notification
alert, etc.) can be paused, stopped, or hidden by the user or the user can
manually control the timing of the updates.

2.3.1-A-Three Flashes or Below Threshold: Validate that no page content flashes more than 3 times per second unless that flashing content is sufficiently small and the flashes are of low contrast and do not contain too much red.

2.4.1-A-Bypass Blocks: Validate that a link is provided to skip navigation and other page elements that are repeated across web pages OR a page has proper heading structure.
TOOL: Keyboard.
METHOD:
— Tab into the page and make sure there is a skip navigation link before the
global navigation menu (and anywhere else where it says in the wireframes
that one should be)
— Tab into the “skip navigation” link. Hit Enter on your keyboard.
The page should scroll the content area into view. Hit tab again to make sure
that the tab focus is now in the content area.

2.4.1-A-Bypass Blocks: Automated tool can validate that frames are appropriately titled & skip links are not broken.

2.4.2-A-Page Titled: Validate that the web page has a descriptive and informative page title.

2.4.3-A-Focus Order: Validate that navigation order of links, form elements, etc. is logical and intuitive.

2.4.4c-A-Link Purpose (In Context): Automated tool can validate if links contain text, or if there are redundant links (adjacent links that go to the same place), or if linked images are missing alt text.

2.4.4-A-Link Purpose (In Context): 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:
TOOL: Web inspector
METHOD:
(1) Locate content needed to understand how link text describes the purpose
of the link.
(2) Check whether the content is contained in the same sentence, paragraph,
list item, or table cell, or in the preceding heading.

2.4.4-A-Link Purpose (In Context): Validate that links (or form image buttons) with the same text that go to different locations are readily distinguishable (i.e. not in the same context in the markup; not in the same paragraph, list item, etc.
TOOL: Web inspector
METHOD:
(1) Locate links that have the same text.
(2) Check whether the links are contained in the same sentence, paragraph,
list item, or table cell, or in the preceding heading. If they are, that is a
problem.

2.4.4-A-Link Purpose (In Context): Validate that null alt is not used for images where images are the only content in a link.
TOOL: WAVE toolbar. The WAVE toolbar will tell you if there are empty links on the page.

2.4.5-AA-Multiple Ways: Validate that at least two of the following are available: a list of related pages, table of contents, site map, site search, or list of all available web pages.

2.4.6-AA-Headings and Labels: Automated tools can advise if there are missing a missing <h1> primary heading level.

2.4.6c-AA-Headings and Labels: Validate that page headings and labels for form and interactive controls are informative. Avoid duplicating heading (e.g., “More Details”) or label text (e.g., “First Name”) unless the structure provides adequate differentiation between them.

2.4.7-AA-Focus Visible: 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).
TOOL: Keyboard.

3.1.1-A-Language of Page: Validate that the language of the page is identified using the HTML lang attribute (<html lang=”en”>, for example). Can be validated with an automated tool.

3.1.2-AA-Language of Parts: Validate that the language of page content that is in a different language is identified using the lang attribute (e.g., <blockquote lang=”es”>).

3.2.1-A-On Focus: 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).
— For example, links that open in a new window or a popup window should have an icon that warns the user they are special.

3.2.2-A-On Input: Automated tools can detect when interactions on the page launch new windows. You still need to validate that the instance is missing an warning to assess that it is breaking the guideline.

3.2.2-A-On Input: 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.2.3-AA-Consistent Navigation: Validate that navigation links that are repeated on web pages do not change order when navigating through the site.

3.2.4-AA-Consistent Identification: Validate that elements that have the same functionality across multiple web pages are consistently identified. For example, a search box at the top of the site should always be labeled the same way.

3.3.1-A-Error Identification: Validate that required form elements or form elements that require a specific format, value, or length provide this information within the element’s label.
TOOLS: Web inspector, Screen reader
— The required field indicator (or “optional” indicator) should be
visually close to the text label for that field. Check the code to ensure it
is within the label tag.
— When that field receives keyboard focus, a screen reader should announce
the required field indicator, e.g. “Name *” would be read,
“Name star”

3.3.1-A-Error Identification: Validate that form validation errors are presented in an efficient, intuitive, and accessible manner.
RESOURCES: Creating Accessible Forms
TOOLS: Screen reader
METHOD:
— Fill out the form with your keyboard and leave some fields blank or fill
them out wrong purposefully.
— When the form is submitted, the first field that has an error should
receive keyboard focus, and that error should be read out by the screen
reader.
— As you tab through the rest of the form, any field with an error should
read the error out.

3.3.2-A-Labels or Instructions: Automated tool can validate if label text is empty.

3.3.2i-A-Labels or Instructions: Validate that sufficient labels, cues, and instructions for required interactive elements are provided via instructions, examples, properly positioned form labels, and/or fieldsets/legends. An example of a failure would be not including a text label for a set of phone number fields.

3.3.3-AA-Error Suggestion: Validate that if an input error is detected (via client-side or server-side validation), suggestions are provided for fixing the input in a timely and accessible manner.

3.3.4-AA-Error Prevention (Legal, Financial, Data): Validate that if the user can change or delete legal, financial, or test data, the changes/deletions can be reversed, verified, or confirmed.

4.1.1-A-Parsing: Check pages with the W3C Validator, paying close attention to errors in markup syntax, duplicate IDs, etc.

4.1.2-A-Name, Role, Value: Validate that markup is used in a way that facilitates accessibility. This includes following the HTML/XHTML specifications and using forms, form labels, frame titles, etc. appropriately.
TOOLS:
W3C Validator
METHOD: Run a validation test and go through the results with a front end developer to assess which of the issues need to be fixed (the validator throws many false negatives).