Hello! This is a (work in progress) map to MAP (More Accessible Products): a product that everyone can use, regardless of the technology they're using or any disabilities they might have.
The MAP is made up of 9 ideas. Each idea has a set of actions.
-
Idea 1: Think non-binary
- Acknowledge and embrace human diversity
- Consider what's between the human and the UI
- Go off The Happy Path
-
Idea 2: Avoid barriers to access
- Make it more usable for more people
- Remove existing barriers
- Avoid adding barriers
-
Idea 3: Understand the pros and cons
- Offer good motivations
- Be ready for objections
- Celebrate good accessibility
-
Idea 4: Know the technology
- Think in semantic HTML
- Understand the accessibility tree
- Understand ARIA
-
Idea 5: Follow the Standards
- Remember the Priority of Constituencies
- Know the Standards
- Know the big names
-
Idea 6: Shift Left
- Choose accessibility as a priority
- Check for common omissions
- Offer feedback to the previous step
-
Idea 7: Design Accessibly
- Design in layers
- Add annotations to designs
- Use standard controls where possible
- Think about customisation
-
Idea 8: Develop Accessibly
- Write semantic HTML
- Do Static Analysis
- Write Automated Tests
- Do Code Reviews
- Use the Design System carefully
-
Idea 9: Test Accessibly
- Test with the keyboard
- Test with browser extensions
- Test with Screen Readers
- Do an audit
Idea 1: Think non-binary
Think more broadly, in a more human-centered way. This helps us understand the wide range of human experience, that abilities exist on a spectrum, and that things seldom go as planned.
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.
Go off The Happy Path
Consider what’s messy, fragile, unpredictable.
Idea 2: Avoid barriers to access
Think about where barriers might occur when a person’s ability comes into contact with the product. Consider Auditory, Cognitive, Physical and Vision aspects. Consider more than one aspect at a time. Fewer barriers to access make our products more usable for more people.
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.
Idea 3: Understand the pros and cons
Sell the idea and understand the difficulties. People are at different levels of understanding and caring: meet them where they are and talk to them in their terms and language.
Offer good motivations
Use the hierarchy of motivating change:
- Intrinsic motivation (enlighten, inspire)
- Feels like: the right thing to do; the smart thing to do; making a difference; helping people.
- From seeing the real world benefits to people.
- Extrinsic motivation (rewards)
- Helps, but focuses on the practitioner, not beneficiaries.
- Can result in doing it just for the reward.
- External control (guilt, punishment)
- Sets a low bar. Can result in doing the minimum amount of work necessary and othering the beneficaries.
Some common motivations
- Shipping with a11y bugs is similar to shipping with…
- Lorem Ipsum text in the UI
- Buttons and links that aren’t hooked up
- Empty buttons and links
- Pages with no headings
- Invisible text
- Only allowing mouse-based input of text
- Blank / placeholder images
- Remediation on large projects is difficult and costly. The way to approach this is to shift left and address problems earlier, when they’re cheaper to fix.
- It’s exciting
- It’s an exciting challenge, working within stronger constraints. It requires more creativity to find good solutions. -It gets easier
- “It doesn’t have to be perfect. Just a little bit better than yesterday.” - Leonie Watson
- Set up a tiny test for people to do, so they can see the problem, feel it.
- Get buy-in with a small, high-value, example.
- Do small bits at first: five minute piggybacks on top of other things.
- Continuous learning is part of our job
- It gets easier with practice
- It’s Agile: continuous attention to technical excellence and good design
- It’s a mark of quality
- It’s not doing more work, it’s doing the same work differently.
- Get an edge over our competitors
- More meaningful work, using your skills for good
- Have more, happier, customers
- It’s human-centered
- Tim Berners-Lee, W3C Director and inventor of the World Wide Web, said “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” That sounds important!
- Support use choice. Don’t want to!
- Better brand perception and reputation
- A disability can be permanent, temporary, or contextual.
- Disability is a spectrum, not a binary
- Have the confidence and kindness to be a little boring or simple
- Helps us design for reality as it is
- Essential for some, useful for all.
- Best case: from can’t use to can use. Worst case: from easy to easier.
- It’s a mark of high quality
- It’s good usability
- Making a difference; helping people.
- It’s simpler
- Plain old semantic HTML gives you lots of a11y for free.
- More robust UI, which breaks less often
- Simpler UI, which is more maintainable and easier to debug
- Make a choice to replace one small bit of existing work with an a11y tasks, as an experiment
- It’s the law
- Avoid lawsuits
- Flip it to see how absurd it is
Be ready for objections
Have rebuttals and “but/and”s ready to deal with oppositions.
Some common objections
- Other things are higher priority.
- It’s boring, it’s not shiny or glamorous.
- It’s difficult. It’s easy to do ARIA wrong and make things worse.
- It’s takes too long.
- People with disabilities are not our target market.
- Only affects a small group of users.
- We don’t have support to do it.
- It’s only realistic / practical / possible on small projects.
- We can quickly add accessibility before the release.
- We can use an overlay.
- Web accessibility is just a developer’s responsibility.
- Automated tools are enough.
- Compliance is enough.
- It’s all about ARIA.
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.
Idea 4: Know the technology
Have at least a high-level of understanding of what makes up a web page, and how assistive technology reads a web page. This helps us to understand the feasibility of design choices.
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.
Idea 5: Follow the Standards
Know what standards to follow and where to look for guidance. Understand that compliance with the standards is the minimum. Our goal is usable and accessible.
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.
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.
Idea 6: Shift Left
Make more accessible decisions earlier in the process. It’s quicker and simpler to make things accessible earlier, compared to adding on accessibility at the end or fixing accessibility bugs later.
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 are 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.
Idea 7: Design Accessibly
Design accessible products that work well for a wide variety of people, technologies, and abilities.
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
Use standard controls where possible. Give a rationale for deviations from standards.
Think about customisation
Think about customisation. Options, not accessibility options.
Idea 8: Develop Accessibly
Build accessible products that work well for a wide variety of people, technologies, and abilities.
Write semantic HTML
Use the most appropriate HTML element for thing.
Understand ARIA and is sparingly and carefully.
Do Static Analysis
Include accessibility linting.
Write Automated Tests
Add accessibility-related tests in our unit, integration, and end-to-end tests.
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.
Idea 9: Test Accessibly
Ensure high quality, usability, and accessibility.
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 structure
- Check interactions
- Check that the alt text of images conveys the content and function of the image
- Check form error handling
- Check that the order of content make sense
Do an audit
- Check the page title.
- Check the page headings.
- Test with the keyboard.
- Test zoomed in to 400%.
- Run the aXe browser extension.
- Run the ARC toolkit browser extension (Chrome only).
- Do the assessment option of the Microsoft Accessibility Insights browser extension (Chrome only).
- Check if some common AAA SC have been met
- Test with a screen reader.
- Do a final read-through of the WCAG SC.