Assessment Checklist

This checklist includes an outline of how to cover everything that’s required in an accessibility audit of a project or product. An audit needs to cover the minimum of WCAG 2.0 AA:

  1. Perceivable
  2. Operable
  3. Understandable
  4. Robust

This checklist also includes new items from WCAG 2.1 AA. Review How to Meet WCAG (Quick Reference) for more details on each item.


Keyboard navigation without a screen reader running:

  • Visible focus style on desktop with keyboard (2.4.7 Focus Visible)

    Can a sighted, keyboard-only user see where they currently are on the page?

  • Focus order matches visual layout (1.3.2 Meaningful Sequence)

    Can a sighted, keyboard-only user comfortably move around the page elements in a predictable order?

  • No invisible tab-stops (2.4.3 Focus Order)

    When navigating with the keyboard or screen reader cursor, are there focusable points along the way which shouldn't be focusable?

  • No sudden changes of context when a control receives focus (3.2.1 On Focus)

    When navigating with the keyboard or screen reader cursor, does a modal window appear or focus suddenly switch to something else when a control gets focused?

  • Single letter shortcut keys can be remapped or disabled (2.1.4 Character Key Shortcuts)

    Custom shortcuts can wreak havoc for voice dictation users and keyboard-only users who accidentally activate a shortcut and lose their place – frustrating!


  • All img elements have an alt attribute (1.1.1 Non-text Content)

    With no alt present, screen readers announce the image file name and path.

  • Decorative images use empty values for alt attributes (1.1.1 Non-text Content)

    Does the image add value to the content? <img src="…" alt="">

  • Descriptive images have appropriate text alternatives (1.1.1 Non-text Content)

    Try to describe what's in the image to someone who has their eyes closed—help them paint a picture in their mind.

  • Complex images (charts, graphs, maps) have a separate text alternative (1.1.1 Non-text Content)

    Is there a plain text listing points on the map?

  • For images with embedded text, ensure the alt value equals the embedded text (1.1.1 Non-text Content)

    The "Shopify" logo image should have an alt value of, "Shopify".


  • svg elements have focusable="false" when a child of a focusable element (1.3.1 Info and Relationships)

    Avoids a bug in IE which creates duplicate announcement of focusable items.

  • svg elements feature aria-hidden="true" and role="presentation" when decorative (4.1.2 Name, Role, Value)

    Can sometimes create hidden tab-stops when navigating with screen reader cursor.

  • svg that feature use elements have whitespace between the svg and use tags (2.1.2 No Keyboard Trap)

    Currently a bug in Safari 10 which prevents Tab navigation.

  • img elements with an svg source includes the role="img" attribute (4.1.2 Name, Role, Value)

    Helps to convey image semantics correctly for VoiceOver/Safari on iOS.

Code inspection


  • Page lang attribute set on the html element (3.1.1 Language of Page)

    Helps to ensure screen readers will pronounce content in the correct dialect.

  • Unique page title element text (2.4.2 Page Titled)

    This content is often the first piece of information announced, reassuring the user as to where they currently are.

  • Viewport zoom not disabled (1.4.4 Resize text)

    Do not do this: <meta name="viewport" content="… maximum-scale=1.0, user-scalable=no" />

  • Skip link is available and visible when focused (2.4.1 Bypass Blocks)

    Provides quick access to page content, skipping past repeated content such as the header or nav elements.

  • Landmark elements available, where appropriate (4.1.2 Name, Role, Value)

    Use header for header content, nav for navigation, main for primary content, etc. Helps to create quick navigation access.

  • Linear content flow; no tabindex attribute values in use other than 0 or -1 and no autofocus attribute (2.4.3 Focus Order)

    Are their positive tabindex values in use? What about autofocus ? These take power away from the user.

  • JavaScript events do not rely on keydown() (2.5.2 Pointer Cancellation)

    Use keyup() in order to allow users to "cancel" the event by swiping/mousing away, off of the control.


  • Headings for headings, in sequence (2.4.6 Headings or Labels)

    Do not use headings purely for design, rather, a logically ordered outline/content structure.


  • Lists for lists, ol , ul , and dl used appropriately (1.3.1 Info and Relationships)

    Is there a section of related content items displayed in a grid, or sibling a elements?

  • ul, ol elements with list-style: none includes the role="list" attribute (1.3.1 Info and Relationships)

    Helps to convey list semantics correctly for VoiceOver/Safari.


  • a for links (1.3.1 Info and Relationships)

    Use links for navigation; loading a new page or shifting keyboard focus from one element to another.

  • button for buttons (1.3.1 Info and Relationships)

    Use buttons to submit data or perform an on-screen action which does not shift keyboard focus.

  • Link purpose is clear and understandable (2.4.4 Link Purpose)

    Is it clear and understandable what the link is for or where the user will land from activating the link from its accessible name?

  • Links that open in a new window or external sites are indicated via icon and appropriate alt text (3.2.2 On Input)

    Helps both screen reader and sighted keyboard-only users that this will be the result of activating the element.

  • If there's .visually-hidden text or an aria-label attribute applied, ensure visible text is the first part of the hidden label (2.5.3 Label in Name)

    If not, voice dictation users will have difficulties calling out names of controls on the screen.

  • If multiple items on screen perform the same action, make sure they share the same name (3.2.4 Consistent Identification)

    Example, cards with multiple links (image, title, and "read more") may go to the same destination yet have different names–best to group into one focusable action item.


  • table for tabular data (1.3.1 Info and Relationships)

    Does this content look like a table? Use table .

  • th for headers (with appropriate scope attributes) (4.1.1 Parsing)

    scope="col" for column headers, scope="row" for row headers.


  • All form fields feature a label (3.2.2 On Input)

    Either via aria-label , .visuallyhidden element, floating label, or visible label (recommended.)

  • fieldset with legend used when appropriate (1.3.1 Info and Relationships)

    Does the label provide enough context for it to make sense on its own?

  • Fields use autocomplete attribute (1.3.5 Identify Input Purpose)

    Help people fill in form fields by using data stored in their browser.

  • Errors display in link list above the form (3.3.1 Error Identification)

    For large forms with many inputs , shift focus to error list heading, linking to each input in an error state.

  • Error text included within label or via aria-describedby (3.3.1 Error Identification)

    Wrapping the input and error text within the label helps to provide a large click/touch target and announced the error on focus .

  • Error state is not visually communicated via color alone (1.4.1 Use of Color)

    Users with color-blindness may not see the error state if color is the only indicator.

  • Update the title with the word, "Error" (1.3.1 Info and Relationships)

    The title content is often the first bit of content announced; this helps with current context.

  • Submission of legal or financial data must include review (3.3.4 Error Prevention (Legal, Financial, Data))

    People need to be able to give a final review before submitting data. Specifically for legal or financial (sensitive) data. Ex., Checkout's order review page.

  • Notifications, error messages, success messages, toasts, etc, are announce aloud (4.1.3 Status Messages)

    Critical information needs to be announced by screen readers via aria-live or equivalent role container, otherwise folks who can't see the screen may miss this information.



  • Media does not autoplay (1.4.2 Audio Control)

    Can be distracting, disruptive, or unexpected.

  • Controls are appropriately marked up (1.3.1 Info and Relationships)

    Check to ensure "toggle" state for buttons and range input for sliders.

  • Media can be paused on Space (2.1.1 Keyboard)

    Allow for a global pause function on any related video control or content container.


  • Closed captions are available (1.2.2 Captions)

    If someone can't hear the video, can they still get what they need?

  • Audio descriptions are available (1.2.5 Audio Description)

    If someone can't see the video, can they still get what they need to understand the content?


  • Transcript is available (1.1.1 Non-text Content)

    If someone can't hear the audio, provide a full transcript alternative.

  • Auto-playing audio can be paused (1.4.2 Audio Control)

    Allow the user to pause auto-playing audio.


  • Windows High Contrast on desktop, color inversion on mobile (1.4.1 Use of Color)

    Check for icons, borders, links, form fields, and text; is content still viewable? Can you distinguish elements from their backgrounds?

  • Increase text size on desktop to 200% (1.4.4 Resize text)

    Does increasing the text zoom cause content overlap? Is content still readable?

  • Increase text spacing on desktop (1.4.12: Text Spacing)

    Does increasing the text spacing cause content overlap? Is content still readable? (Bookmarklet)

  • Proximity (1.3.3 Sensory Characteristics)

    Use the straw test to ensure people who depend on screen zoom software can still easily discover all content.

  • Colour not the only indicator used to convey information (1.4.1 Use of Color)

    If everything was greyscale, could you still see where links are among body content?

  • Overly bright colors (1.4.1 Use of Color)

    People on the autistic spectrum may have difficulty with bright colors.

  • Layout is simple and consistent (1.4.10 Reflow)

    An overly complex layout can be confusing to use and follow


Colour contrast

  • Normal sized text and icons (1.4.3 Contrast)

    AA requires contrast ratio of 4.5:1 .

  • Large text and icons (1.4.3 Contrast)

    AA requires contrast ratio of 3.0:1 .

  • Icons (1.4.11 Non-text Contrast)

    AA requires contrast ratio of 3.0:1 .

  • Input element borders (text input, radio buttons, checkboxes…) (1.4.11 Non-text Contrast)

    AA requires contrast ratio of 3.0:1 .

  • Embedded or overlapping text on images/video (1.4.3 Contrast)

    Is text still readable in all images and video scenes/frames?

  • Custom ::selection colors (1.4.3 Contrast)

    Text selection can happen by accident. Can it still be read?

See Color Contrast for more details.


  • Written in plain language and does not use figures of speech (3.1.2 Language of Parts)

    Recommended to write content at an 8th grade reading level

  • button , a , and label element content is unique and descriptive (1.3.1 Info and Relationships)

    "Click here" and "Read more" are just not helpful, especially when navigating by only buttons or links.

  • Text is left aligned for left-to-right regions and right aligned for right-to-left regions (1.4.12 Text Spacing)

    Centered or justified text can be difficult to read for people with Dyslexia

  • At least two methods are made available to navigate and locate content (2.4.5 Multiple Ways)

    Examples include; primary/secondary/tertiary navigation, search mechanism, site map, breadcrumb, etc.


  • Allows for any orientation (1.3.4 Orientation)

    Does the site only allow portrait orientation on a hand-held device?

  • No horizontal scrolling (1.4.10 Reflow)

    Requiring someone to scroll horizontally can be difficult for some, irritating for all.

  • Controls and link icons can be activated with ease (2.5.5 Target Size)

    Not required for all clickable elements, but good to make sure things like hamburger menu controls, social icons, gallery viewers, and other touch controls are usable.

  • Sufficient space between clickable items in order to provide a scroll area (2.4.1 Bypass Blocks)

    Some people who experience hand tremors have a very difficult time scrolling past clickable items which feature zero spacing.

  • Any gesture based functionality has an optional method requiring no gesture (2.5.1 Pointer Gestures)

    It can be difficult or painful for some folks to use gestures such as swipe or multi-finger input. Make sure to provide an alternative, such as a single button which serves the same function.

Dynamic components

  • Dynamic components such as Carousels , Predictive search , Modal windows , Tabs , etc, are marked up accordingly, provide appropriate context, and include expected keyboard functionality

    Refer to the WAI-ARIA Authoring Practices guide for more details.

  • Any content appearing on hover or focus needs to be dismissable, hoverable, and persistent (1.4.13 Content on Hover or Focus)

    Think tooltips or anything that appears on hover; can it be dismissed via Esc ? Does it persist for zoom users to mouse around and read the content?

  • Session timeout warnings (2.2.1 Timing Adjustable))

    Is there a timeout for the current activity? Let people know this ahead of time, and with significant notice before the timer runs out. (Not having a timeout at all is best.)

Assistive Technology and Testing Tools

The following are various pieces of assistive technology to test with during an audit.


The keyboard is the most basic assistive technology. Use the Tab key to move between focusable items.

Watch for:

  • Focus indicator – do you know where the cursor currently resides?
  • Focus order – are items in a top-to-bottom, left-to-right order?

More details can be found on the Keyboard accessibility best practices post.

Screen readers

Use the most recent versions of operating systems, browsers, and screen readers during assessment.


  • JAWS with Internet Explorer/Edge on Windows
  • NVDA with Firefox on Windows
  • VoiceOver with Safari on macOS


Automated testing

Run automated accessibility testing tools as a last resort in order to catch things which may have been missed when manually testing.


Text-only Zoom

There are some Chrome browser extensions you could use to test text-only zoom, but what’s recommended is to use the built-in text zoom functionality with Firefox. Here’s how to accomplish this:

  1. Load the website in question with Firefox
  2. Ensure text zoom is enabled by going to "View", select "Zoom", and select "Zoom Text Only"
  3. Adjust the text size to 200% using the Cmd/Ctrl and + keys, and view the page content

Review the Text Zoom post for more details.

Straw Test

Use the Straw Test to simulate a highly zoomed interface in order to reveal proximity issues.

Voice Activation

There are two primary/popular methods to test with voice dictation software:

Automated testing tools

Run each of the following to ensure a solid test result as each tool has its own set of testing methods—results may vary.