More Accessible Products

Acknowledge and embrace human diversity

Consider gender identity and expression, sexual orientation, race, religion, first language, disability (permanent, temporary, contextual), and how these things can change over time.

Consider what's between the human and the UI

Think about input methods, browser, operating system, screen size and resolution, user preferences and choices, network connection (cost, speed, latency), age and condition of hardware, age of the person, experience level, assistive technology.

Think about options and preferences, not accessibility options.

Go off The Happy Path

Consider what’s messy, fragile, unpredictable. We already know that sometimes people will encounter problems with our products. That’s why we have error states and messages. We just need to widen this lens.

Make it more usable for more people

Accessibility is essential for some and useful for many. It’s not about lowering stands, but removing barriers. Say yes to users as much as possible.

Remove existing barriers

Check where a person’s ability might come into conflict with the product.

Avoid adding barriers

During design and development, consider where a person’s ability might come into conflict with the product.

Offer good motivations

• It’s good for us. It’s more meaningful work, aligning with our human-centered values. It helps us make more concise solutions that more simple and robust. It requires more creativity to find good solutions. It’s making the design vision work for a wide variety of people.
• It’s good for the business. It gives us more customers (from can’t use to can use for some people). It gives us happier customers (from good to great for some people). It helps us support user choice and preference. It gives us an edge over our competitors, and improves our brand perception and reputation. It’s a mark of high quality.
• It’s good for lowering legal risk. Some countries have legal requirements for accessibility. Some countries have anti-discrimination laws which can lead to litigation. Being seen as a brand that doesn’t care about inclusion, diversity, and accessibility is not a good look.

Be ready for objections

Have rebuttals and “but/and”s ready to deal with objections. Refer to how it affects us, the business, the legal risk.

• People with disabilities aren’t our target market. They’re only a small group of users anyway.
  • It’s absurd to discriminate based on disability. We don’t discriminate on other aspects of being a human.
  • Accessibility improvements help more than just people with disabilities.
  • Disability is a spectrum, not a binary. A disability can be permanent, temporary, or contextual.
  • People are living longer, so the aged population is increasing. Older people tend to benefit from accessibility and usability improvments.
  • If People with Disabilities can’t use the product as it is, of course they aren’t!
• It’s difficult. It takes too long. It’s easy to do ARIA wrong and make things worse. It’s only realistic / practical / possible on small projects. We don’t have support to do it.
  • It can be difficult at first, but it’s part of continuous professional development (like many other skills). It gets easier with practice.
  • It can be done bit by bit. Small changes add up. It’s mostly different work, not more work: making better choices earlier on.
• It’s boring. It’s not shiny or glamorous. It limits our creativity.
  • It’s a chance to be innovative.
  • It’s part of high quality, professional, work.
  • It gives us more, happier, customers.
• It’s a quick fix. We can quickly add accessibility things before the release. We can use an overlay. Automated tools are enough. It’s just about adding ARIA things to the code.
  • It works best when considered from the start. Finding and fixing issues at the end of the process is slow, frustrating, work. The earlier in the process we do it, the quicker and simpler it is.
  • Everyone has a part to play in making things more accessible.
• It’s ugly. Accessible can’t be beautiful.
  • Then we haven’t found the right solution yet!
  • It does provide more constraints, but that’s an opportunity for more creative solutions.
• Other things are higher priority.
• It’s third party software / someone else’s responsibility (even though it’s on our site)
• Other sites aren’t accessible, so why should we be?
• It’s time-consuming.
  • Counter “we don’t have time to cater to special needs” by focusing on the core human need.
  • Shift Left to improve efficiency. Doing the work earlier is much quicker than doing it later.

Celebrate good accessibility

Publicly praise and celebrate accessible work. Show the teams already making accessible work that it’s appreciated. Show the teams not making accessible work yet how it’s done, and the easy and difficult bits.

Think in semantic HTML

Plan to use the most semantically correct HTML for each piece of a page. For example: if an interactive element takes the user somewhere, it should be a link; if an interactive element performs an action, if should be a button. If something seems tricky or fiddly to make with HTML, review the design.

Understand the accessibility tree

Know how the accessibility tree is built from the DOM (the Document Object Model, the tree that the browser builds from the HTML of the page). Each element in the accessibility tree has a name, a role, a value, and a state.

Understand ARIA

• Know the Rules of ARIA. Use HTML if we can, and add any ARIA carefully.
• Have a handle on ARIA attributes. Know which ones we can get from the HTML, and which ones needs to be added.
• Check new ideas and patterns against the ARIA Patterns for ideas for best practice.

Remember the Priority of Constituencies

Put our users first. The Priority of Constituencies says: “difficulties to the user should be given more weight than difficulties to implementors.”

Know the Standards

The standards set the minimum (acceptable accessibility), we set the maximum.

• WAI ARIA Authoring Practices
• WCAG POUR
• WCAG Success Criteria

Know the big names

Be familiar with a handful of big names in the industry. They provide useful tools and resources for using and learning.

• MDN: HTML: A good basis for accessibility; HTML elements reference.
• Deque: axe; Deque university.
• WebAIM: WebAIM Million; Articles.
• TPGi: ARC toolkit; Blog.
• Microsoft: Inclusive Design; Accessibility Insights.

Choose accessibility as a priority

Be clear on your list of priorities, and choose to put accessibility high up that list.

Log accessibility tickets as bugs. Treat those bugs as technical debt. Track the number of tickets and the cycle time.

Check for common omissions

Before we start designing, we think about:

• Page titles and headings
• Colours and use of colour
• Text alternatives for non-text content
• Error states and messages

Offer feedback to the previous step

When issues are spotted, offer feedback to the previous step. Testing back to Development back to Design back to Product.

Design in layers

• Do a text-only design
  • Clarify the order and content
• Do an HTML-only design (no presentation, no layout)
  • Clarify the order and content, the single function of each interactive element
• Go off The Happy Path
  • Try and break it. Then fix it.

Add annotations to designs

• Heading levels
• ARIA Landmarks
• Accessible names for form elements without a visible name
• Accessible name for each group of controls, visible or not
• Alt text for every image and icon
• Show keyboard interactions. Follow ARIA patterns. Give a rationale for deviations from the standards.

Use standard controls where possible

Give a rationale for deviations from standards.

Write semantic HTML

Use the most appropriate HTML element for thing.

Understand ARIA and use it sparingly and carefully.

Do Static Analysis

Include accessibility linting.

• axe Accessibility Linter for VS Code
• eslint-plugin-jsx-a11y for the command line

Write Automated Tests

Add accessibility-related tests in our unit, integration, and end-to-end tests.

• For unit and some integration tests use jest-axe
• For End-to-End tests, use cypress-axe or axe-playwright

Do Code Reviews

Explicitly include accessibility in code reviews.

Check that new Pull Requests are “axe clean” (there are no errors flagged by a11y automated tests).

Use the Design System carefully

A good Design System helps nudge us towards more accessible choices. Watch when combining components that the end result is still accessible (even small combinations like groups of radio buttons). Check the accessible names of things.

Test with the keyboard

• Can you interact with every element on the page?
• Can you see where you are on the page? Look for a visible :focus indicator as you navigate.
• Can you use functionality (like tooltips) that you usually see on :hover?

Test with browser extensions

• Run the aXe browser extension. This is a good tool to run first since its philosophy of ‘zero false positives’ means the list of errors is usually short.
• Run the ARC toolkit browser extension (Chrome only). This is a good tool to run next since it will flag more errors, and provides an easy way of inspecting the accessibility of semantic structures such as headings, landmarks, links, buttons, form controls, and alt text. In particular, check that:
  • link text describes the destination of the link;
  • button text describes the action that will happen;
  • alt text conveys the content and function of each image.
• Do the assessment option of the Microsoft Accessibility Insights browser extension (Chrome only). This is a good tool to use next because it offers good coverage of the WCAG SC (Success Criteria). It’s a reasonably lengthy process, but gets faster with practice.

Test with Screen Readers

• Check how the page sounds. Check the structure, interactions, error handling, and order of the content.
• Check the text alternatives for non-text content.

Do an audit

Do a thorough test of the page as a whole. It helps to have an established list of steps for doing audits.

This will include some things we’ve already done. An audit is the final check that everything’s as it should be.