7 Things that Turn good Accessibility into Great Accessibility
The difference between good and great is a chasm the size of the Grand Canyon
— Rob Light, Creative Artists Agency (speaking about Dua Lipa)
This article is the other end of the spectrum from the article I wrote last week entitled “10 things that indicate designers have no clue about accessibility”
Almost 98 % of the top million web pages are completely inaccessible, with almost 60 accessibility violations per page on average. So it is easy to find crappy pages to dump on because only 2 % of web pages on the internet are doing either a good job or a great job. Here are the elements that differentiate the good pages from the great pages.
Good accessibility is about compliance, GREAT accessibility is about empathy
People running great accessibility programs don’t stop when the desired WCAG standard is reached. Here are a few examples:
Does the product stop accessibility improvements when AA is met, or follow AAA guidelines that really should have been AA guidelines, such as touch target size?
Has color contrast been evaluated exactly as required in WCAG 1.4.3? Or was color contrast made accessible for everyone, and in objects beyond just text? Great accessibility checks color contrast in unimpaired vision and color blindness modes, as well as checking the contrast of keyboard focus indicators and activatable icons.
Are the employee-facing websites, docs, and apps as accessible as the public-facing websites, docs, and apps?
Does the website copy use “premium language” like savor instead of taste, purchase instead of buy, conversation instead of talk?
Great accessibility managers empathize with their end users with disabilities, which means they want to do it right, not just comply with the regulations.
Good accessibility looks at the product, GREAT accessibility looks at the entire user experience
Customers don’t buy products, customers buy experiences. How many times have you sworn you would never buy something from a company again because of a bad sales or customer support experience? Accessibility to people with disabilities is generally as important (if not more so) than sales or support. However, if you don’t personally need accessibility or know someone who does, you may not realize how important it is.
Experiences include the reality of the user interacting with the product, as well as anything adjacent to that product use. Core adjacent product services that are essential to the overall user experience include documentation, training, customer support, and surveys. When adjacent product services are at least nominally accessible, chances are the product is too, because adjacent services are typically the last car on the digital accessibility journey train.
If the company sells tangible products and not just software, physical accessibility counts too. Also, product packaging should be an accessibility consideration.
Microsoft Xbox does this well. Possibly the best out there.
Google/Fitbit does not do this well. I am giving them a pass for another 15 months since the accessibility issues were all Fitbit’s fault. Google only recently acquired the Fitbit accessibility mess.
Good products do user research, GREAT products incorporate accessibility feedback from people with disabilities
Ever heard the phrase “Nothing about us, without us, is for us”? That phrase was coined as part of the protests that resulted in the passage of the Americans with Disabilities Act. Doing user research with people with disabilities is a sign of great accessibility.
Great accessibility managers never, ever assume they understand the impact of a product decision on individuals with disabilities, even if it is a disability they have first-hand experience with. They ask. They ask respectfully. And they ask several people because not everyone experiences an identical disability in the same way.
Good accessibility has a well-defined QA process, GREAT accessibility executes that process using testers with disabilities
Testing is considered one of the most important software development phases, encompassing up to 40–70 percent of project schedules. Testing aims to verify whether software:
1) meets design/specification requirements;
2) works as expected, and;
3) satisfies the stakeholders’ needs.
Because “stakeholders” can always include people with disabilities, software testing plans must include accessibility. Using testers with disabilities is essential to determine what is expected and satisfies the stakeholder needs from the accessibility perspective. Similar to the “nothing about us without us” argument above.
GREAT accessibility uses accessible design systems
It is becoming more common for software to be built using a collection of reusable components known as design systems. Using a design system provides a quick start to the website or mobile app development.
Think about a design system as the software version of Legos:
- All the pieces fit together;
- With the pieces, you can build anything you want.
VMware’s open-source, web-based design system is called Clarity. The Clarity Design System is not only used for VMware products but is also used by a huge number of organizations outside of VMware.
When using a design system, it is even more important that it is built using accessibility-friendly options, because design systems provide building blocks that are consumed by other software. One design system accessibility defect will show up in every single component of the implemented website/app. That could be thousands of places.
There are a few other accessible open-source design systems besides Clarity: Lightning (Salesforce), Spectrum (Adobe), and Carbon (IBM) come to mind. But there are not that many.
If you are building your own design system or component library, make sure the components are accessible and expose the ARIA properties that must be set by developers as they are implementing to maintain an accessible end product.
If you have chosen to use an open-source design system that is NOT accessible, do the world a favor and contribute it back after you’ve made it accessible. Just like Paypal did with Bootstrap. That’s what companies with great accessibility do.
GREAT accessibility is included as a product release gate
“Release gates” are final checks that are reviewed as part of making a go/no-go release decision for a product. When accessibility is at the release gate, it sets the expectation from the beginning that only accessible software will be released. Establishing release gates typically also involves establishing an exceptions process where a large number of people with a fair amount of power will be exposed to bad accessibility decisions if a product team requests a release without closing the accessibility release gate.
Good accessibility managers speak at accessibility events, GREAT accessibility managers speak at UI/UX/Design events
I still attend a couple of large, almost obligatory, annual accessibility conferences. However, I find at those, I am largely preaching to the choir. If I’m speaking about accessibility at a general UI/UX/design conference, I’m preaching accessibility to the heathens. Which do you think has a larger impact on building a more accessible world? Converting the heathens, of course.
Getting from good accessibility to great accessibility costs time and money. Perhaps the hardest part is it requires obtaining commitment and establishing a shared vision with other stakeholders outside of the accessibility team. However, ask someone who uses assistive technology what great accessibility means to them. For the most part, their answer will distill down to “priceless” and can be as meaningful as:
the difference between being on SSI and having a decent-paying job
the difference between full independence and partial (or full) dependence on others
And then ask yourself again whether you are willing to make the leap from good accessibility to great accessibility.