The Equity Action Plan was released by the U.S. General Services Administration. The move from a federal agency signals to businesses that they need to strive for accessibility that surpasses basic inclusive changes.
Developers have a different mindset when it comes to going above the bare minimum. 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. Developers who only use what comes off the shelf risk becoming too focused on accessibility. Many tools prioritize the visual elements of accessibility because they are the most noticeable, but what about users with 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 better accessibility checkers, the better they will serve people with diverse needs.
I have worked in development for over a decade and have spent the past two years trying to make tools that help software designers and developers instill accessibility into their craft. Developers can keep up with the shifting threshold for accessibility by avoiding falling back on inadequate accessibility tools and guidelines.
Each platform has its own accessibility guidelines. The Web Content Accessibility Guidelines (WCAG) are used by Apple, and the Human Interface Guidelines (HIG) are used by Android. Component-specific libraries like React Select and Vue Select have sections on best practices for accessibility.
If developers just follow the accessibility parameters of the platform they are building in, they will inevitably leave some accessibility gaps unfilled. It's like expecting a table of contents when you use just one set of guidelines.
The best way to avoid this problem is to mix and match tools. If your framework leans more towards visual navigation, you should pair it with a accessibility tree or accessibility inspector. Orca's screen reader can be used on desktop computers like MATE, GNOME, and Unity. Users with visual difficulties can be accommodated by the Sonar project.
There are a lot of tools that developers can use to test accessibility. Adding a11y add-ons can support writing components accessible into Storybook, while linters are great to check code.
The more tools you use, the more complete your picture of accessibility is. You can find the places that your original guidelines don't if you use the tools that don't have to be solely development tools.
When building products, developers have to take a global mentality and acknowledge that accessibility adherence changes based on location. A framework that worked elsewhere is not the same as accessibility.
It is likely that what is legal in one country is not legal in another. The European Standard for Digital accessibility has the same specifications as the AODA. These types of legislation tend to go beyond the scope of popular technical frameworks, so developers can create compliant products by only referring to those frameworks. According to the EN301 499, the only way to identify a person is by using other means. The set of guidelines in tech called the WCAG have no mention of fingerprints.
Even in countries that don't ask for accessibility standards, developers have to apply them in their products even if they don't ask for them. The minimum accessibility requirements you should include are the ones you encounter the most. It is a smart business decision. At some point, regulations are going to evolve, and what is seen as strict now will become the norm later. A more broad spread of accessibility from day one will help prevent companies from spending time and money fixing problems retroactively.
There is no completion certification for accessibility. The more products you introduce, the more you have to test and the more you have to monitor your accessibility. Even if you are not actively releasing, there is always room for improvement for more complex elements.
You need more than just libraries to review accessibility. The building blocks may be accessible, but that doesn't mean the end product will be. The developers have a responsibility to test the product as they build it on a scale and in its entirety. It needs to be put in context to confirm that it is accessible.
Developers should trial their products and features with a diverse group of users. At Stark, we use Zoom to conduct feedback sessions and ensure that the needs of our users are met. Fable is a great platform to engage people with disabilities for user research and to highlight testing methods that reveal the gray areas of frameworks. User testing shows that frameworks don't stop developers from setting up focus orders for keyboard users. We spoke with people who use keyboard navigation for websites.
There isn't a single accessibility expert. It's a shared responsibility, and all developers have to use others' knowledge to grow their understanding of accessibility. The main accessible frameworks that developers use can't be taken as a whole. They have to be used with other tools and testing to push for a higher accessibility bar.
All Rights Reserved © 2024
