Accessibility Compliance Checklists

Checklist for WCAG 2.0 AA compliance of web sites and web applications

WCAG2.0 AA Standard

Compliance with standard

Text Alternatives 1.1.1

Provide alt attributes for meaningful images. An alt attribute is a short description of an image that a screen reader can “read” to the user.

Pre-recorded Media. 1.2.1, 1.2.2, 1.2.3, and 1.2.5

Provide transcripts and synchronized captions for all media with audio content. Also provide an audio description for videos with content that is not described in the audio, for example, charts that appear on the screen but are not described in the audio.

Live-Streamed Media. 1.2.4.

Use real-time captioning for all live-streamed media with audio content.

Good Code 1.3.1,1.3.2, 2.4.3, and 4.1.1

Use good semantic structure and syntax to enable the user to access all information and navigate the page in a logical manner.

Sensory Characteristics 1.3.3

Do not provide instructions that refer solely to visual location or orientation, such as “the blue box on the top left,” or solely use sound, color, or other sensory characteristics.

Use of Color 1.4.1

Do not rely on color to convey meaning. Color-blind users may have trouble with a website if color is used to convey important information. Required fields should not be indicated only with color.

Audio Control 1.4.2

Provide a way for users to control audio independent of the computer audio setting. A screen reader user may not be able to hear the screen reader over the audio the application is generating.

Contrast 1.4.3

Ensure appropriate color contrast so that content can be read by people with visual impairments. 

Resize Text 1.4.4

Define text using em, not pt or px, to ensure it is resizeable.

Images of Text 1.4.5

Do not create graphics that look like text, instead use text and style it with CSS.

Keyboard 2.1.1 and Bypass Blocks 2.4.1

Make sure all website functionality is available via keyboard navigation. Also, provide a means for users to skip over repetitive sections of the site.

No Keyboard Trap 2.1.2

Ensure there are no keyboard traps. This occurs when the user can get to a certain point with the keyboard, but then can’t access the rest of the website.

Timing Adjustable 2.2.1

Provide sufficient time for users to respond to timed content and provide users the ability to extend the time if necessary.

Pause, Stop, Hide 2.2.2

Enable the user to control the movement, blinking, or scrolling of any content.

Flashes 2.3.1

Ensure content and multimedia do not flicker at a rate known to induce seizures among optically sensitive users.

Page Title 2.4.2

Provide a title for each web page that describes its topic or purpose to ensure the user knows what page they’re on.

Focus Order 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.

Link Purpose 2.4.4

Make the purpose of links clear

Use descriptive text for links, and not “click here,” or “read more,” and identify links to PDFs, Word documents, Excel spreadsheets etc.

Multiple Ways 2.4.5

Provide multiple ways for the user to locate content, such as a navigation bar, search, and sitemap.

Headings and Labels 2.4.6

Use headings appropriately to convey content hierarchy.

Visible Focus 2.4.7

Provide a visual indicator of where the cursor is.

Page Language 3.1.1

Declare the language, using the language tag, that the website is written in. If there are multiple languages on a page, it is crucial to indicate when the language changes and then when it reverts to the original language.

Language of Phrases 3.1.2

Use language tags around foreign words so that the screen reader uses the correct speech synthesizer.

On Focus 3.2.1 and On Input 3.2.2

Give the user a choice before changing context, such as when a link will open a new browser window or when to submit a form.

Consistent Navigation 3.2.3 and Consistent Identification 3.2.4

Use consistent navigation and identification cues throughout the site. For example, use the same iconography, text cues, templates, and navigational elements.

Error Identification 3.3.1 and Error Suggestion 3.3.3

Provide meaningful error messages that describe the appropriate solution.

Labels 3.3.2

Associate all form elements with a label tag.

Error Prevention 3.3.4

Provide the user an opportunity to confirm information they have entered for impactful transactions, such as legal and financial transactions. For example, “Do you want to transfer $5000?”

Name, Role, Value 4.1.2

Ensure all technologies, including assistive technologies, can determine what an element is and does. Screen reader software must be able to determine, for example, if an element is a menu and if it is expanded or collapsed; or if a magnifying- glass icon launches search or zoom functionality.

Checklist for mobile applications

Color

  • Colour contrast must comply with WCAG 2.0 AA level requirements:
    Contrast ratio of 4.5:1 for normal text (less than 18 point or 14 point bold.)
  • Contrast ratio of 3:1 for large text (at least 18 point or 14 point bold.)
    Information conveyed via colour MUST be also available by other means too (underlined text for links, etc.)

Visibility

  • Content hiding techniques such as zero opacity, z-index order and off-screen placement must not be used exclusively to handle visibility. Everything other than the currently visible screen MUST be truly invisible (especially relevant for single page apps with multiple cards):
  • USE the hidden attribute or visibility or display style properties.
  • Unless absolutely unavoidable, aria-hidden attribute SHOULD NOT be used.

Focus

  • All activatable elements MUST be focusable:
  • Standard controls such as links, buttons, and form fields are focusable by default.
  • Non-standard controls MUST have an appropriate ARIA Role assigned to them, such as button, link, or checkbox.
  • Focus should be handled in a logical order and consistent manner.

Text Equivalents

  • Text equivalent MUST be provided for every non-strictly presentational non-text element within the app.
  • Use alt and title where appropriate (see Steve Faulkner's post about Using the HTML title attribute for a good guide.)
  • If the above attributes are not applicable, use appropriate ARIA Properties such as aria-label, aria-labelledby, or aria-describedby.
  • Images of text MUST be avoided.

Form controls

  • All form controls MUST have labels (<label> elements) for the benefit of screen reader users.

State

  • Standard controls such as radio buttons and checkboxes are handled by the operating system. However, for other custom controls state changes must be provided via ARIA States such as aria-checked, aria-disabled, aria-selected, aria-expanded, and aria-pressed.

Other

  • An app title MUST be provided.
  • Headings MUST not break hierarchical structure.
  • ARIA Landmark Roles SHOULD be used to describe an app or document structure, such as banner, complementary, contentinfo, main, navigation, search.
  • Touch event handlers MUST only be triggered on the touched event.
  • Touch targets MUST be large enough for the user to interact with (see the BBC Mobile Accessibility Guidelines for useful touch target size guidelines.)

 

 

 

 

 

 

 

 

 

Checklist for ePub texts

EPub accessibility hinges on:

  4.4.1 Page Navigation

  • ePub must provide a page list and page break indicators to allow users in mixed print-digital environments to coordinate their positions.  See Daisy for details of acceptable techniques

4.4.2 Media Overlays Playback

  • ePub provides media overlays for an accessible playback experience for anyone who benefits from having text and audio synchronized.
  • The most basic Media Overlay Documents indicate the text to highlight and the audio clip that corresponds to the text
  • Advanced Media Overlay documents include  structure and semantics to Media Overlay Documents to allow Reading Systems to present more usable experiences by:
    • providing users  the ability to skip past secondary content 
    • helping users escape from deeply nested structures
    • allowing users to navigate through the sections of the publication without having to go to the table of contents.

Checklist for Microsoft Office Documents and Powerpoint

MS Word provides you with some tools to check accessibility automatically. But you should also perform the functional tests below.

Office 2016

  • Windows: File > Info > Check for Issues > Check Accessibility
  • Mac: Tools > Check Accessibility

Office 365

  1. Go to Ribbon Review tab
  2. From the Accessibility section, choose Check Accessibility

Checklist

Media

Meaningful images have alternative text. Video has captions.

Test images:
Word 2016:
select image, select Format > Picture > Layout & Properties tab > Alt Text and ensure that both the title and description duplicate in text the meaning of the image.

Office 365: select image, pick Picture in ribbon, select Alt Text tab  and ensure that both the title and description duplicate in text the meaning of the image.

Color

Do not rely on color to convey meaning.

Test: visual check

Contrast

Ensure appropriate color contrast so that content can be read by people with visual impairments.  Contrast ratio is the same as required in web pages (see above)

Test: visual check

Structure

Document has logical structure using headings.

Test (for Word): insert a table of contents (see below). If the TOC seems right and reflects the visual structure of the document, headings were probably used correctly

Tables

Tables have logical structure

Test: TODO

Index

Long documents have a table of contents

Test (for Word): there is a TOC present in the document at the beginning if the document goes over 4 pages.

Checklist for Google Docs

You will need to test on a copy of the document, as some of the tests are going to affect the content of the document itself, or are not possible unless you have editing rights. To do so File > Make a copy. 

Google Docs does not have an accessibility checker. You can however save it as a web page and then use a web based accessibility checker. 

Note: only do this if the document is not confidential!

  1. Menu: File > Publish to the Web, then click the Publish button. 
  2. Copy the link provided to you
  3. Go to: https://wave.webaim.org/ and paste the link
  4. You will be provided with a report

Checklist

Media

Images have alternative text.

Test: right click on image. Select Alt Text.  Ensure that both the title and description duplicate in text the meaning of the image

Contrast

Ensure appropriate color contrast so that content can be read by people with visual impairments.  Contrast ratio is the same as required in web pages (see above)

Test: visual check

Tables

Tables are very simple in nature and first row has column heading text

Test:  visually determine that the first row has text that would logically be headings. Visually determine that table is simple in nature - no column or row spans, no nested tables.

Structure

Document has logical structure using headings (1 through 6 for Docs)

Test on a Doc copy: insert a table of contents (Insert > Table of Contents). If the TOC seems right and reflects the visual structure of the document, headings were probably used correctly

Index

Long documents have a table of contents

Test: there is a TOC present in the document at the beginning if the document goes over 4 pages.

Checklist for Google Slides

Google slides are very hard to make accessible. But the requirements below will help.

Media

Images have alternative text.

Test: right click on image. Select Alt Text.  Ensure that both the title and description duplicate in text the meaning of the image

Contrast

Theme with good contrast  between foreground and background.

Structure

Slides all use predefined layouts. If a custom text block is added, it must have an  alternative text as if it were an image 

Each slide has a title, and where meaningful, a subtitle

Tabs

Tab order (navigate using tab) follows reading order

Tables

Tables are very simple in nature and first row has column heading text

Test:  visually determine that the first row has text that would logically be headings. Visually determine that table is simple in nature - no column or row spans, no nested tables.

Good practice

There are copious speaker notes. These will be read by screen readers and will help immensely.