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:
- Perceivable
- Operable
- Understandable
- 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
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!
Images
-
All
img
elements have analt
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
-
svg
elements havefocusable="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 featurearia-hidden="true"
androle="presentation"
when decorative (4.1.2 Name, Role, Value)Can sometimes create hidden tab-stops when navigating with screen reader cursor.
-
svg
that featureuse
elements have whitespace between thesvg
anduse
tags (2.1.2 No Keyboard Trap)Currently a bug in Safari 10 which prevents
Tab
navigation. -
img
elements with ansvg
source includes therole="img"
attribute (4.1.2 Name, Role, Value)Helps to convey image semantics correctly for VoiceOver/Safari on iOS.
Code inspection
Global
-
Page
lang
attribute set on thehtml
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
ornav
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 than0
or-1
and noautofocus
attribute (2.4.3 Focus Order)Are their positive
tabindex
values in use? What aboutautofocus
? 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
-
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
-
Lists for lists,
ol
,ul
, anddl
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 withlist-style: none
includes therole="list"
attribute (1.3.1 Info and Relationships)Helps to convey list semantics correctly for VoiceOver/Safari.
Controls
-
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 anaria-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.
Tables
-
table
for tabular data (1.3.1 Info and Relationships)Does this content look like a table? Use
table
. -
th
for headers (with appropriatescope
attributes) (4.1.1 Parsing)scope="col"
for column headers,scope="row"
for row headers.
Forms
-
All form fields feature a
label
(3.2.2 On Input)Either via
aria-label
,.visuallyhidden
element, floating label, or visible label (recommended.) -
fieldset
withlegend
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 eachinput
in an error state. -
Error text included within
label
or viaaria-describedby
(3.3.1 Error Identification)Wrapping the
input
and error text within thelabel
helps to provide a large click/touch target and announced the error onfocus
. -
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 equivalentrole
container, otherwise folks who can't see the screen may miss this information.
Validation
-
Validate generated HTML (4.1.1 Parsing)
Ensure valid HTML for a consistent experience across browsers + AT.
Media
-
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.
Video
-
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?
Audio
-
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.
Appearance
-
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
Animation
-
Animations should be subtle and not overly flashy (2.3.1 Three Flashes or Below Threshold)
Flashy animation can be an irritant or possibly cause seizures.
-
Background video imagery has a mechanism to pause the video (2.2.2 Pause, Stop, Hide)
Text over background video can be difficult to read as the video serves as a distraction.
-
Animations obey the
prefers-reduced-motion
media query (2.3.3 Animation from Interactions)If someone enables the "Reduce motion" feature in their operating system settings, the animation does not commence.
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.
Content
-
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
, andlabel
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.
Mobile/Touch
-
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.
Keyboard
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.
Desktop
- JAWS with Internet Explorer/Edge on Windows
- NVDA with Firefox on Windows
- VoiceOver with Safari on macOS
Mobile
Automated testing
Run automated accessibility testing tools as a last resort in order to catch things which may have been missed when manually testing.
Zoom
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:
- Load the website in question with Firefox
- Ensure text zoom is enabled by going to "View", select "Zoom", and select "Zoom Text Only"
- 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.
- Lighthouse by Google
- aXe by Deque
- Accessibility Insights by Microsoft
- WAVE by WebAIM