There is no single accessibility expert. It’s a shared responsibility, and all developers have to leverage others’ knowledge to grow their understanding and manifestation of accessibility. By that same token, the main accessible frameworks that developers use can’t be taken as all encompassing. In the same way that developers wouldn’t create a new feature using only one tool, they should have multiple inputs to guide them through accessibility. The more robust developers’ accessibility checkers are, the better they’ll serve people with diverse needs. The author presents three ways for developers to avoid falling back on inadequate accessibility tools and guidelines and keep up with the shifting threshold for accessibility.
The U.S. General Services Administration recently released its Equity Action Plan, specifying a focus on accessibility beyond the bare minimum for all digital government services. This move from a federal agency signals to businesses that they’ll need to follow suit and strive for accessibility that exceeds basic inclusive changes.
But going above the bare minimum demands a different mindset from developers. Many of the people who are tasked with re-envisioning the bar for accessibility rely too heavily on a small set of tools that give them tunnel vision when building. React, Vue, and Svelte all have accessibility baked into them, but developers who use only what comes off the shelf risk becoming too singularly focused. Many tools prioritize the visual elements of accessibility because they’re the most noticeable, but what about users with auditory or mobility issues?
In the same way that developers wouldn’t create a new feature using only one tool, they should have multiple inputs to guide them through accessibility. The more robust developers’ accessibility checkers are, the better they’ll serve people with diverse needs.
I’ve worked in development for nearly a decade and have spent the past two years striving to make tools that help software designers and developers instill accessibility into their craft. Here’s how developers can avoid falling back on inadequate accessibility tools and guidelines and keep up with the shifting threshold for accessibility.
Mix and match your accessibility tools.
Each development platform has its own set of accessibility guidelines and requirements. For example, the accessibility (a11y) standards for the web are detailed in the Web Content Accessibility Guidelines (WCAG), Apple uses Human Interface Guidelines (HIG), and Android has its own set of guidelines. Web libraries like React and Vue have sections on best practices for accessibility, as do component-specific libraries like React Select and Vue Select.
But if developers just follow the accessibility parameters of the platform they’re building in, they’ll inevitably leave some accessibility gaps unfilled. Using just one set of guidelines is like expecting a table of contents to tell you the whole story.
The best way to avoid this problem is to mix and match tools and guidelines. If your framework leans more toward visual navigation, pair it with Google’s accessibility tree or Firefox’s Accessibility Inspector, which help developers understand how content is exposed to assistive technology. If your requirements are predominantly for people with audial impairments, try Orca’s screen reader for desktops like MATE, GNOME, and Unity. The Sonar GNU/Linux project is great for accommodating users with visual difficulties
There’s also a wealth of tools that developers can utilize to test accessibility across platforms. Linters are great to check code, while a11y add-ons can support writing accessible components into Storybook.
The more tools you use in tandem with your primary platform’s accessibility requirements, the more complete your picture of accessibility is. The tools don’t have to be purely development tools either — discussions on Reddit’s Web Accessibility community, Stack Overflow, and Slack’s accessibility channel can point you to the places that your original guidelines don’t cover.
Learn from localized accessibility legislation.
Developers have to take a global mentality when building products, and in turn, they have to acknowledge that accessibility adherence changes based on location. Accessibility is much more than translating text and copy-pasting from a framework that worked elsewhere.
What may be legally compliant or inclusive in one country is likely different in another. For example, the Accessibility for Ontarians with Disabilities Act (AODA) doesn’t have the same specifications as the European Standard for Digital Accessibility (EN301 549). And these types of legislation tend to go beyond the scope of popular technical frameworks like React, so developers can’t create compliant products by exclusively referring to those frameworks. For instance, the EN301 549 states that biometrics cannot be used as the only means for user identification. However, the WCAG — a staple set of guidelines in tech — have no such mention of biometrics.
Some locations will inevitably have stricter rules around accessibility, and developers have to apply these standards in their products across the board, even in countries that don’t ask for them. The maximum accessibility requirements you encounter should be the minimum you incorporate throughout all your work. It’s not only a moral duty, but a smart business decision. At some point, regulations are going to evolve, and what’s seen as strict now will become the norm later. Invoking a number of tools to include a more broad spread of accessibility from day one will help prevent companies from spending time and money fixing problems retroactively.
Uncover grey areas of standalone frameworks via user testing.
There isn’t a completion certification for accessibility. The more products or features you introduce, the more you’ll have to test and the further you’ll have to go beyond the tools you’re using to monitor your accessibility. Even if you aren’t actively releasing, there is always room for improvement, particularly for more complex elements like keyboard usage, focus, and landmarks.
Reviewing accessibility requires much more than downloading whole libraries you deem accessible and building from them. The building blocks may be accessible, but that doesn’t guarantee the end product will be. Developers have a responsibility to test the product as they construct it on both a granular scale and in its entirety. It has to be put in context, in lived experiences to confirm that it really is accessible.
Developers should repeatedly trial products and features in person or remotely with a diverse group of users of varying capabilities, ages, and backgrounds. At Stark, we test in person where possible, but otherwise use Zoom to conduct feedback sessions, ensuring captions, sign language interpretation, and other user needs are met. Fable is a brilliant platform to engage people with disabilities for user research and to highlight testing methods that reveal the gray areas of standalone frameworks. For us, user testing showed that frameworks don’t stop developers from having an incorrectly set up focus order for keyboard users. We only learned by speaking with people who use keyboard navigation for websites.
There is no single accessibility expert. It’s a shared responsibility, and all developers have to leverage others’ knowledge to grow their understanding and manifestation of accessibility. By that same token, the main accessible frameworks that developers use can’t be taken as all encompassing. They have to be used alongside other tools and testing to keep up with — and keep pushing for — a higher accessibility bar.
