A ‘learn as you do’ accessibility checklist

A good checklist, with a plan, should make itself obsolete.

I recently met with someone who is blind to learn how they experience digital experiences.

At times it was excruciating to watch.

Their screen reader ranted confusing, incomplete information, and the user couldn’t know everything that was on the page or how to navigate it properly.

An essential task, like paying a bill online, which is simple for many of us, was rendered impossible and resulted in the person receiving late payment notifications.

I asked them how they ‘saw’ the page in their mind, and it was then I truly understood how the digital world of seamless experiences that makes life so much easier for some of us can be an utter nightmare for those who use assistive technology, like screen-readers.

I realized that while there’s a lot to learn about UX accessibility, the main thing to know is that it is not about always having a checklist — it’s about designing for all people by default.

Because implementing accessibility should be about learning what’s necessary to design inclusively and why, so eventually we don’t need a checklist.

But understanding and implementing accessibility rules is hard! There’s a lot, it’s riddled with technicalities, and the tools we need are not fully baked into the design software we use. And accessibility isn’t an essential part of all design curriculums.

While the web is designed to work for all people, information and tools that designers need to design for accessibility are not very accessible!

Well, if you’re like me, the best way to learn is to make a plan, and start doing.

Learn as you do

Below is a learning to-do checklist I’m implementing with my team as a starting point:

• The requirements are grouped into sections for ease of design consideration
• Each item has a summary of what to do and why they need to be implemented and includes a reference to the specific WCAG 2.1AA requirement (and links to more information)
• The list does not include guidance that relates to development work only, to keep this as succinct as possible, but I’ve included a link at the end for more information for those interested

How this list was created

• As mentioned above, I met with a visually impaired user to watch and ask about their experience to gain first-hand empathy
• I completed the FREE edX Introduction to Web Accessibility course
• The A11Y Project is a community-driven effort to make digital accessibility easier. They have created a helpful, user-friendly, complete list of WCAG 2.1 AA requirements. I reviewed this to compile just the UX-related tasks (view the complete WCAG 2.1 AA list here)
• To make the checklist more user-friendly and learnable, I simplified information and added additional tips

Part of a bigger plan

Although I’ve been aware of accessibility for a long time, I am very late to learn how to implement it. The detail always seemed overwhelming and I just didn’t know where to start. And without a plan, I could easily put it off.

I’ve realised that some accessibility requirements can be baked into our style guide, making it much easier to embed into our workflow!

But this can take time, to bake in and flow changes to the digital product.

And the longer we take to start integrating accessibility into our default design requirements, the more legacy problems we are creating that we’ll have to back and fix.

Also, with the emergence of the ‘Internet of Things’ — all devices, appliances, lighting, and electronics connected and sharing information — we are seeing more multi-media interfaces appearing on fridges, cooking appliances, and dashboards. Problems with lack of accessibility will compound the longer we take to learn how to address them with other design considerations.

Here’s a plan:

1. Recruit users with varied abilities to view their experience of your product first hand, or at least watch this video or watch this video
2. Try using your keyboard without a mouse, you’ll need these shortcuts
3. With more empathy from the small insights above, get started — use the checklist below to start immediately implementing WCAG 2.1 AA requirements per project. Learn why as you do, so eventually, you don’t need a checklist
4. Commit to completing the FREE edX Introduction to Web Accessibility course to get a deeper understanding
5. Go through one or two sections of the list every week with your team to discuss how to add to your workflow, what tools to use, and if you can bake it into your style guide
6. In the background, use the WAVE assessment tool, or the list below as a guide to review your digital product to create a backlog to fix existing problems. To use WAVE, install the WAVE browser extension, load your URL in a new tab, click on the WAVE extension icon in your browser toolbar, and you’ll see a visual report of accessibility errors on your site.

A high-level explanation of UX considerations

• Colour contrast — Color contrast changes for people with impaired vision and colour blindness, sometimes rendering words and content ineligible or invisible. We need to ensure our brand palettes have passed an accessibility test, and then keep an eye on new designs using contrast-checking plugins. Also, not all palettes work for all levels of vision abilities, and colours carry different meanings to different cultures, so it’s best to not rely on colour alone to convey interactivity or other information to users.
• Adaptable content layout — Ensure your digital product can be viewed without distortion when orientated to horizontal vie, or when zoomed in for easier reading
• Consistent use of headings — Define heading styles and usage (h1, H2, H3, etc) so you always use the same heading style with the same information hierarchy on every page to create a consistency that is easy to follow for users of assistive technologies.
• Form errors — Display a summary of errors at the top of the form and link to relative input fields; use more than one cue to communicate errors, warnings, success, and important information (e.g. color+wording); provide suggestions of solution.
• Image descriptions — Ensure all images have descriptive text (‘alt’ text) so its meaning in context can be communicated via other forms, such as large print, braille, speech.
• Interactive elements and their instructions — Use more than one cue to communicate interactivity, keep instructions for interaction elements close to their related elements, and avoid or clearly identify links that open in a new tab or window
• Touch — Ensure all touchpoints have a minimum width and height of 44px, ensure sufficient space between interactive items, and don’t use horizontal scrolling
• Page titles — Ensure the page title that appears in a web search result page matches the title displayed once the website is loaded. A difference can be confusing for disabled users and for users who might wonder whether the URL they just clicked was correct. Also, keep page titles succinct and one that identifies the site it belongs to, with the important and unique information first
• Media & Animation (Audio & Video) — Minimize blinking animations and don’t use flashing, don’t autoplay, and ensure video captions and audio transcripts are available

Here’s the ‘learn as you do’ UX checklist for WCAG 2.1 AA

Considerations are grouped into relatable sections and have included links to the official requirement detail, as well as tools.

Colour

Colour contrast changes for people with impaired vision and colour blindness, sometimes rendering words and content ineligible or invisible. We need to ensure our brand palettes have passed an accessibility test, and then keep an eye on new designs using contrast-checking plugins. Check the contrast of your colours next to, and on top of each other.

Also, not all palettes work for all levels of vision abilities, and colours carry different meanings to different cultures, so it’s best to not rely on colour alone to convey interactivity or other information to users.

1. Check the contrast for all text
   Normal-sized text (Up to 23px/18px bold) should have a contrast ratio of 4.5:1.
   Large-sized text (24px/18.5px bold and larger) should have a contrast ratio of 3:1.
   Text that overlaps images or video should also be eligible (see ratios above)
   1.4.3 CONTRAST
2. Check the contrast for non-text elements, like icons, borders, etc.
   These should have a contrast ratio of 3.0:1.
   1.4.11 NON-TEXT CONTRAST
3. Check your content in Accessibility Display Modes.
   Activate modes such as Windows High Contrast or Inverted Colors to check the overall contrast and legibility of page elements like icons, borders, links, etc.
   1.4.1 USE OF COLOR

Tools

• Enter colours into the WebAIM: Contrast Checker to check contrast at various font sizes
• Check your design work as you go with plugins like Cluse for sketch and A11y — Color Contrast Checker for Figma
• Assess your website with the WAVE browser extension

Adaptable content layout

Ensure your digital product can be viewed without distortion when orientated to horizontal view, or when zoomed in for easier reading.

1. Design for responsiveness to accommodate a clean view at all zoom levels.
   When a person zooms in to over 300% (using either the mobile operating system or the browser settings), the layout should reflow into one column to allow them to easily view content and not have to scroll sideways to read.
   1.4.10 REFLOW
2. Ensure the site can be rotated to any orientation for tablet and mobile.
   1.3.4 ORIENTATION

Tool — Click the View tab in your browser and click Zoom in — use the Zoom Text Only option is offered.

Consistent use of headings

Heading elements (h1, h2, h3, etc.) not only break up the page visually but also help communicate the meaning of a page or view to people using assistive technology by communicating a consistent structure of pages. Screen readers read the header copy and the header type (h1, h2, etc.) to the user. Define heading styles and usage (H1, H2, H3, etc) in your style guide so you always use the same heading style with the same information hierarchy on every page to create a consistency that is easy to follow for users of assistive technologies.

1. Use heading elements to introduce content and create an overall consistent page structure, not for just visual design.
   Every page should have at least one heading.
2. Use only one H1 element per page or view.
   Use the H1 element to communicate the key purpose of the page or view. The H1 element on a page should be unique to that page.
3. Keep headings in a complete and logical order from the top of the page.
   For example, an h3 element should not appear on a page before the first h2 element. And don’t jump headings, skipping from an h1 to an h3 element without an h2 in between. Use CSS classes if you must skip levels for visual requirements.

2.4.6 HEADINGS OR LABELS

Tools to assess heading use on a page: HeadingsMap browser extension, or WAVE extension for a more complete accessibility assessment

Form errors

Display a summary of errors at the top of the form and link to relative input fields; use more than one cue to communicate errors, warnings, success, and important information (e.g. color+wording); provide suggestions of solution.

1. Display input error messages above a form and relate to the specific fields.
   While we often display input error messages next to the input field with the error, this can be hard to read and digest longer forms for users of assisted technology. Displaying a summary of the errors above the form gives these users a high-level understanding of all issues and should link or direct them to the corresponding fields needing correction.
   3.3.1 ERROR IDENTIFICATION
2. Use more than colour to communicate errors, warnings, success, and important message
   E.g. Use color+wording, as colour may not be distinguishable for people with impaired vision, colour blindness, or different cultural understandings.
   1.4.1 USE OF COLOR

Image descriptions

If you upload images or supply images to your development team, provide them ‘alt attributes’ (alt-text) — this is a short and simple description of the images for people who may not be able to view them. Missing alt-text forces screen readers to describe the image by its file name instead, which usually communicates the image’s content incorrectly.

Ensure all eligible images have descriptive text (‘alt’ text) so its meaning in context can be communicated via other forms, such as large print, braille, speech.

1. Complex images of data, etc. — describe the purpose of the graphic and all visible information, in context with the page content. Also, supply a plain text version on the page.
2. Images containing important text — ensure the alt description includes the image’s text.
3. For decorative images — you don’t need to supply alt copy (developers will add ‘null’ instead)
4. Linked images — explain their function, where they will link to, etc.

Tips for writing alt copy:

• Be specific, and describe it in context how it relates to the other content
• Never start with “Image of …” or “Picture of …”
• Use SEO keywords but sparingly
• Include any text that’s embedded in the image
• Don’t be repetitive
• Don’t add alt text to ‘decorative’ images, life ‘lifestyle’ images, etc.

Click here for the full article about alt copy tips

Related requirement: 1.1.1 NON-TEXT CONTENT

Interactive elements and their instructions

Use more than one cue to communicate interactivity; keep instructions for interaction elements close to their related elements; and avoid or clearly identify links that open in a new tab or window.

1. Make links clearly recognizable as links
   Use commonly understood methods of communicating linked content, such as underlined text and accent colours. But don’t use colour alone, as it may not be distinguishable for people with impaired vision, colour blindness, or different cultural understandings.
   1.4.1 USE OF COLOR
2. Avoid, or clearly identify links that open in a new tab or window.
   While avoiding links that open in a new tab or window are technically not required for compliance, they are often noted as an area of frustration for users of assistive technology. For example, if these links aren’t clearly communicated, people won’t understand why the “back” button no longer works as expected. If the experience does require a link that navigates users to a new tab or window, ensure this behaviour is communicated clearly before users need to activate the link. Here are some tips.
   G201: GIVING USERS ADVANCED WARNING WHEN OPENING A NEW WINDOW
3. Double-check that good proximity between content is maintained.
   Interactive elements should remain close to their instructions. Keep this in mind for desktop views, as screen width can widen the page and separate interactive elements, like checkboxes, right-aligned on a page with instructions that are left-aligned.
4. Use a combination of cues to communicate an instruction
   Use a combination of cues to communicate an instruction, and make sure you don’t use just visual (“to the right”) or just audio (“after the tone”).
   1.3.3 SENSORY CHARACTERISTICS

Touch

Ensure all touchpoints have a minimum width and height of 44px, ensure sufficient space between interactive items, and don’t use horizontal scrolling.

1. Do not use horizontal scrolling.
   Some people who experience motor control issues may find scrolling difficult.
   1.4.10 REFLOW
2. Ensure sufficient space between interactive items for ease of vertical scrolling on touch screens.
   Scrolling via touch on pages with lots of interactive elements (video, tool-tips, etc.) and little spacing can be difficult for all of us, but especially for people with motor control issues like hand tremors.
   2.4.1 BYPASS BLOCKS
3. Ensure interactive elements have a minimum width and height of 44px for ease of interaction.
   This does not include in-line text, and in cases where the size of the target is determined by the user’s interface/settings and is not modified by the author of the digital product
   2.5.5 TARGET SIZE

Page Titles

Ensure the page title that appears in a web search result page matches the title displayed once the website is loaded. A difference can be confusing for disabled users and for users who might wonder whether the URL they just clicked was correct. Also, keep page titles succinct and one that identifies the site it belongs to.

1. Ensure the page title matches what displays on web search results
2. Keep page titles succinct and one that identifies the site it belongs to, , with the important and unique information first. Examples:

• Home page — <Home page title>
• Subpage — <Subpage name>|<Home page title>

Media & Animation (Audio, Video, Slideshows, etc.)

Minimize blinking animations and don’t use flashing, don’t autoplay, and ensure video captions and audio transcripts are available.

1. Ensure any media does not autoplay.
   Autoplay media can be unexpected and disruptive, especially for cognitive disabilities like ADHD, and vestibular (inner ear/balance) and seizure disorders.
   1.4.2 AUDIO CONTROL
2. Minimize blinking animations and don’t use flashing.
   Blinking, strobing, and flashing animations can trigger seizures (whether moving automatically or when triggered by the user).
   As a guide: Blinking animation at speeds of less than 3 per second can be allowed for a short time as long as it stops (or can be stopped); Flashing is blinking more than 3 per second, or large and bright.
   2.3.1 THREE FLASHES OR BELOW THRESHOLD
3. Animated media must not auto-play for more than five seconds
4. Confirm the presence of video captions for hearing impaired
   1.2.2 CAPTIONS
5. Confirm transcripts for audio content are available for hearing impaired
   1.1.1 NON-TEXT CONTENT
6. Provide user controls to pause background video.
   Background video can be distracting, especially if placed behind the content.
   2.2.2 PAUSE, STOP, HIDE
7. All media should also have alt text.

Tool — Identify Seizure Risks with the PEAT tool (Windows only)

Copy

Ensure your language is clear and without slang or jargon, minimal abbreviations (or alternative text); your text links, buttons, and labels make sense on their own; and your copy is left or right-aligned according to language.

1. Use plain language and avoid language-specific slang/idioms, exclusionary jargon, and complicated metaphors.
   Think in terms of writing for an 8th-grade reading level, or for someone whose first language is different from the default language of your digital experience.
   3.1.5 READING LEVEL
2. Make sure that buttons, text links, and labels are unique and clearly describe what will happen when clicked/tapped.
   Accessibility tools for users can allow them to navigate via a list of all links on a page, so don’t use simplified language like “click here” or “read more”, or anything that doesn’t make sense when read out of context.
   1.3.1 INFO AND RELATIONSHIPS
3. Left-align or right-align text according to how the language is read (Left-to-right or right-to-left)
   And avoid centred-aligned or justified text as it can be hard to read.
   1.4.8 VISUAL PRESENTATION

That’s it!

I hope it helps.

Learn as you implement so the checklist becomes a broader understanding of the human spectrum and a default part of your design thinking.

Feel free to suggest any improvements or corrections!

Click here for more development guidance.

More from Damien…

Explore Damien’s two design innovation labs:

• Life-centred Design Lab — expanding human-centred design to include nature and invisible communities
• Future Scouting — Designing life-centred, values-driven future tech products with speculative design

Get practical with tools and courses:

• Life-centred Design Books and Toolkits
• Life-centred Design Courses
• Life-centred Design Innovation Cards

Follow Damien on Medium for more fringe design thinking and experiments.

The Life-centred Design Lab supports creatives, educators, government, and businesses to do less…

Future Scouting Design Guide