Your Accessibility Claims Are Wrong, Unless…

Now that it is a market differentiator to talk about accessibility in projects, that’s all many do — talk about it. In a sea of pop-dev noise, “accessibility” can be claimed with little risk someone will challenge it. If someone does, the response is often a fine balance between silence and accusations.

I offer some approaches you can and should take before you set expectations about the accessibility of your thing — code or article or talk or whatever.

Stop

I am breaking this up into content creators and their backers. Content creators may write articles, make demos, deliver talks, host podcasts, and plenty more. Their backers may be tech companies, dev sites, industry events, or even browser makers.

For Content Creators

If you are discussing or creating a new pattern or library or technology or talk or article or whatever:

1. Don’t assert anything about how it works with assistive technology.
2. Don’t assert anything about its accessibility.

Be honest and say that you don’t know. It’s ok not to know, so admit it freely. Reader beware and all that.

For Organizations Backing Those Content Creators

If you are backing that content creator:

1. Get them (paid) support, training, or an expert to test with or coach them on assistive technology.
2. Ensure your your content creators are frank about the (lack of) accessibility considerations and make it a visible and standard clause in everything they create.

Otherwise you risk leaving them hanging when they publish problematic content, making them feel like they are standing alone in the cold. Never mind how that affects your brand.

Unless…

Unless you (or the designated editors) ask a few questions:

1. Assistive technology (AT) questions:
   • Are you a daily user of AT?
   • Are you involving daily users of AT?
   • Do you already use AT for testing?
   • Do you know how to use the AT?
   • Do you have a daily user of AT involved?
   • Are you aware there is AT besides screen readers?
   • Do you consider system settings to be AT?
2. Accessibility questions:
   • Do you mean WCAG (and if so, which SCs)?
   • Do you mean ADA?
   • Do you mean Section 504?
   • Do you mean Section 508?
   • Do you mean ACAA?
   • Do you mean CVAA?
   • Do you mean ACA?
   • Do you mean AODA?
   • Do you mean EN 301 549?
   • Do you mean “works with a specific AT”?
   • Do you mean usable by everyone regardless of ability?

For the AT questions, the more “no”s you had the less likely you should make any assertions about how your thing works in AT.

For the accessibility definition questions, readers may believe the thing you wrote conforms with all those laws or guidelines (and many more). Also, one of those was a red herring that I hope you caught as soon as you saw it.

Resources

For more information on what it means for something to be accessible, head over to the W3C’s Web Accessibility Initiative and dive in. For the red herring I referenced, it was the ADA.

For AT, I am going to focus on screen readers since it is where I see the most alarmingly wrong information from “expert” developers promoting their thing. Consider that ARIA is useful only for screen readers and ARIA mis-use is a multiplier of bad for screen reader users.

Screen Readers

Get some screen readers. Plural. Ideally you will cover JAWS, NVDA, VoiceOver on macOS, TalkBack, and VoiceOver on iOS. Don’t use solely VoiceOver; it is more opinionated and does not always reflect what the majority of screen reader users experience.

• Windows
  • Download the free NVDA screen reader (but please donate to support it). Pair it with Firefox.
    • Browse Mode
  • Download JAWS and use it in 40 minute increments for free. Pair it with Chrome.
    • JAWS Hotkeys
  • Use Narrator (it is built in, though not a first choice for most users). Pair it with Edge.
    • Narrator keyboard commands and touch gestures
• For macOS
  • Use VoiceOver (it is built in). Pair it with Safari.
    • Use VoiceOver to browse webpages on Mac
    • VoiceOver Command Charts
• For Android
  • Use TalkBack (it is built in). Pair it with Chrome and maybe Firefox.
    • Use TalkBack gestures
    • Use TalkBack to browse the web with Chrome
    • Use TalkBack keyboard shortcuts
• For iOS / iPadOS
  • Use VoiceOver (it is built in). Pair it with Safari.
    • Learn VoiceOver gestures on iPhone
    • Use VoiceOver on iPhone with an Apple external keyboard
    • Learn VoiceOver gestures on iPad
    • Use VoiceOver on iPad with an Apple external keyboard
• For Ubuntu
  • Use Orca. Pair it with Firefox.
    • Reading Documents and Web Pages
    • Reading Commands
    • Structural Navigation Commands
• For ChromeOS
  • Use ChromeVox (but only use ChromeVox in this scenario, not as a plug-in for Chrome on Windows or macOS).

Keyboard shortcuts are necessary to use a desktop screen reader well (don’t rely on hitting the Tab↹ key over and over). For mobile screen readers, learn the gestures versus swiping right repeatedly. Keep in mind mobile screen reader users often use keyboards too.

• Basic screen reader commands for accessibility testing by Léonie Watson.
• Understanding screen reader interaction modes by Léonie Watson.
• Browsing with a desktop screen reader by Henny Swan.
• Browsing with a mobile screen reader by Henny Swan.
• Screen Reader / Browser Combinations from the WebAIM 2021 screen reader user survey.

Note I did not touch on pairing with Braille displays (that was a pun). As you go down that path there will be more to learn, including how content may be truncated to fit a Braille display.

Added 28 November 2022: Sara Soueidan has posted an excerpt from her forthcoming Practical Accessibility course that goes into far more detail than I do above, including for macOS users who do not have a Windows machine (though you should get your boss/client to just buy you one, they are cheap): Setting up a screen reader testing environment on your computer

Other AT

There is plenty of other assistive technology. The boring keyboard is the most common one, though it does not always look like the one mounted to your laptop (or have the same number of keys).

Do you know how Space and Enter↵ behave differently when pressing a native <button>? If not, then probably test those scenarios for your fancy custom button widget.

Centre for Accessibility Australia has a nifty resource for using the accessibility features built into your OS or device. Read through it. Try them all out. Try them out on your thing. Ask users of those settings to try your thing. Lather, rinse, repeat.

• Browsing with a keyboard by Henny Swan.
  • Enable Full Keyboard Access (FKA) on macOS from Apple Support.
  • Enable Tab support in desktop Safari from Apple Support.
  • Enable FKA on iOS from Apple Support.
  • Enable FKA on iPadOS from Apple Support.
• Browsing with screen magnification by Henny Swan.
• Browsing with speech recognition by Henny Swan.
• Designing for people who use a mouse, video, by Henny Swan.

Best Practices

Validate your stuff. I know that is trickier with custom elements and fancy frameworks, but just using the W3C HTML Nu Checker could keep you from easy mistakes like typos.

Remember that if you start building features for assorted user preferences, everything related to accessibility still applies. For example, if you make a dark mode it still has to honor WCAG contrast minimums.

Other system settings aren’t necessarily AT, but not honoring them can be disabling for many. For example, Windows High Contrast Mode (AKA Contrast Themes or forced-colors mode). You don’t choose the colors, the users do from a limited palette. Which you should not override. But for which you may need to account in what elements you choose.

Show Your Work

Don’t assert the thing works in screen readers (for example) and leave it at that. Tell me which screen readers (plural). Tell me which versions of those screen readers on which operating systems with which browsers and which versions of those browsers.

Tell me how you tested it, which commands, which interaction mode (sticking with screen readers here), what was announced, where they differed.

Better yet, make a video. A human captioned video. That does not autoplay. Showing AT with standard commands. And no mouse (still using screen readers as my example). Most screen readers have a speech viewer or log which is a good start. Beware that those logs often do not fully represent what is announced.

For an extreme example of both approaches, see the Results section in my post Accessible Description Exposure. It includes announcements, how I navigated, videos, and even screen shots of the elements lists. This way users have steps to recreate it.

Though that may be overkill for most. You could get by with something like, “Only VoiceOver on macOS announced the thing; JAWS, NVDA, and TalkBack ignored it no matter how I navigated.” Obviously include details on your testing kit somewhere so folks understand which versions of which screen readers with which browsers.

Do not rely on the output of the accessibility inspector in your browser dev tools. What is exposed there may be different than what is exposed in the OS accessibility APIs and thus exposed to users.

And, for the love of His Noodly Appendage, do not use “a11y” in your long-form writing. Write it out.

Wrap-up

To try to distill this into the main takeaways:

• For content creators, these resources I shared can help you level up your work. This may make it easier for your thing to gain traction when you demonstrate its accessibility chops
• For organizations backing those content creators, if your accessibility reviewers don’t already know the resources I reference, they may need more support. If you don’t have accessibility reviewers, get some.
• For accessibility practitioners (not mentioned until now, but hopefully reading and maybe correcting me), don’t do free labor. Get paid for your knowledge and skill.
• For the resources I linked, they will get stale as new versions of things come out. So, you know, do some legwork and find the most recent versions of them as needed.

Each day articles and talks and demos are shoved into our timelines, making us feel like we are falling behind. If you want to make a thing, maybe these resources can help calm that feeling by boosting your work quality in ways most do not properly consider — the accessibility of it.