Automated testing with tools like Axe DevTools will only flag a percentage of accessibility issues. You will need to perform some functional hands-on testing as well for full coverage.
The good news is that automated testing will flag the issues that are hardest to flag in functional testing. The functional testing is also very non-technical by and large. The most technical thing involved is inspecting elements with the browser’s developer tools. We have also a full functional testing guide you can use.
The following are assertions that need to be tested after an automated test (manual through the browser plugin or server-driven via the Accessibility Scanning with axe Monitor service, both use the same engine).
Typography
- Line height of 1.5 to 2 and not justified.
- No long blocks of ALL CAPS or italics
- No very small text (smaller than 16px for body text)
- No meaningful content generated via CSS
- Line length should be 30 characters or less, or the text can be changed to this column limit (by zooming the view or shrinking the viewport)
- Modality of text does not use color only (alerts, errors, link, emphasis)
Zoom
- Content readable and functional when view is zoomed 200%
- Any new asynchronous content updates (alerts, notifications, any changes to the display) need to show in the viewport as currently zoomed
Structure
- Content has visual and marked up structure
- Visual list is marked up as a list
- Visual headings marked up as headings
- Tables for tabular data have a caption, a header row with headers that have text and a scope=”col” attribute. If the first cell of a data row can be construed to be the title of the row, it also should be a header with a scope=”row”
- If any landmark or HTML5 structure is used, all of the content needs to be structured so that there is no content that is not enclosed in a landmark role of semantic HTML5 block.
Images
- If an image has visual meaning, the meaning should be expressed in text. True regardless of the format of the image. File, background, font icon, svg, canvas will all use different techniques.
- Alt text values are meaningful to the context and are a good replacement for the image
- No animated gifs
Links
- Are unique (in the link text and in the href value)
- Are specific
- Descriptive (with text) of what will happen if activated
- Identifiable from surrounding text without use of color only
- Have standalone meaning (do not reference directly or by position the visual context)
Controls and Forms
- Form field hints and field error messages are linked programmatically to the input
- Fieldsets have legends with logical text
- Radio and checkbox groups are enclosed in a fieldset, have a legend containing the prompt
- Any global instructions for a form need to be outside of it or if inside it, they need to be associated with the form programmatically
Other
- Content is not hidden from the screen reader by mistake (via CSS display:none of visibility:hidden)
- Conversely - items visually hidden are not “readable” by screen reader till they are visible
Controls
- Keyboard focus is visible
- Keyboard focus order is logical to the language declared (rtl, ltr, top to bottom, etc)
- Focusable elements need to be operable (exceptions if used for focus management)
- All controls need to be keyboard operable (native and non-native controls) - and respond to the keystrokes that type of control expects
- Label and control are visually proximate
- Controls do not change context without warning
- Click and keyboard targets are at least 44px by 44px
- Field hints and messages are programmatically associated with input
- There are no keyboard traps
- Control labels are unique and clearly describe what the control will do
- Content is not identified by location (‘click on button on left’)
Order
- Content is in same order visually and in the DOM
Language
- Plain language is used
- Control label language is correct
- Page language is set correctly
- Fragment language is set correctly
- Page and fragment language direction is set correctly
- Page or iframe title is appropriate
- Error messages address how to correct error
- First use of abbreviation or acronym is expanded
Well Formed
- Roles are appropriate to the intended use
- Widget instrumentation is correct. This field is too vast to capture in this document. axe will only catch:
- illegal descendants of a role
- absence of required descendants for a given role
- non existing roles (e.g., aria-label)
- No repeated attributes on same element
- No badly formed markup