WCAG: How to implement web accessibility & establish an organizational-adaptive strategy

What does it take to improve the accessibility of applications? What difficulties prevent organizations from achieving that goal? How can these problems be solved and make interfaces disability friendly?

Many organizations dodge the accessibility-related dues during development, especially if never practiced before, and are still unfamiliar with its craftsmanship. It might also seem inconsequential to the design pattern we typically practice or even extraneous to users we assume are non-disabled. We commonly perceive such duties as enriching rather than a necessity, which results in web content accessibility guidelines (WCAG) remaining overlooked until they fade off in the backlog.

To overcome apparent violations, organizations can educate teams, recruit in-house experts, and even get 3rd party services to support repair processes. However, the latter won't stick unless carried out forever, as proper compliance to WCAG requires ongoing care and is not a one-time refurbishment.

Failing to apply WCAG and not meet its success criteria will likely result in broken interfaces for some users. In addition to blocking target audience from using services and consequently, damaging revenue increases, failing to comply with the standard is a human rights violation that exposes an organization to lawsuits.

Hence, we need a strategy to instill a set of mind, focus on the joint actions teams need to take, set up workflows, and plan gradual steps to become accessible.

Suggested strategies

Consider a11y practices as an integral part of development. Put it right next to design, code, testing, security vulnerabilities, business logic, and more.

Let's spread out what we found as quick and most effective workflows.

Separation of concerns

At Vonage, we strategically maintain a tailor-maid library (Vivid) where organization-wide engineers can enjoy the benefits of UI-based components built from the ground up also to meet WCAG success criteria.
Benefits:

1. Battery charged
   Integrating the library across Vonage products makes it easy to handle violations in a single codebase and continuously improve it to fit required standards.

2. Flexibility
   Components can be easily adjusted and enhanced to an even more compelling user experience by the consuming authors (devs). Plus, on its own, a11y related API may help authors better understand how to craft a11y practices.

In practice

Let say, for example, we default a banner component role to 'status' with a redundant aria-live attribute set to polite (To maximize compatibility when using this role). This indicates that the screen reader should wait until the user is idle before presenting updates to the user.

However, we can modify the above attributes (role and aria-live) to fit contextually. So if the information is critical, we could still alter the banner's role to 'alert', telling assistive technologies to interrupt other processes and provide users with immediate notification.

As a result, Consuming authors can seamlessly concentrate on their products' progress rather than deep dive into a11y practices, as we separate the concern of eligible a11y from the other development concerns by "outsourcing" them.

Some organizations practice an even more isolated codebase dedicated to a11y; see adobe's react-aria.

Ready-made

If setting up a dedicated team isn't a reasonable choice in your organization, a practical alternative would be to adopt a reliable 3rd party OSS that satisfies the required criteria. The Vivid team also gained a significant head-start by partially subclassing the material web components library under its hood.

Prioritize

Choosing how we handle defects in-house is bound to business needs. Priorities can alter, but here's a suggestion to start -

1. Issues picked up by free crawlers and found using automated tools are often easy to handle and fix to protect the organization from lawsuits and improve sites' ranking
2. Legal implications pages (e.g., privacy policy, nutritional information, GDRP pages)
3. High traffic pages (e.g., homepage, landing/login/campaign pages)

As for a gradual increase, WCAG defines three levels of conformance (A, AA, AAA) an organization may adopt. Most countries' laws require UX to comply with at least the first level (A). Nonetheless, we can cherry-pick on specific features, go the extra mile, and opt-in to higher levels.

Level 1

Essential tasks with high user impact, normally with the least investment. Completing these tasks addresses many of the top concerns of people with disabilities.

Level 2

You should complete these tasks in addition to the first level to address the next-most important issues that may keep certain users from fully using your product.

Level 3

Completing all three levels achieves compliance with the A and AA criteria of the Web Content Accessibility Guidelines (WCAG).

—IBM, pace of completion

Product teams should include accessibility targets in each release. As they do, each team member takes on specific tasks to ensure they set up the product for success. This process set regularly will outcome in improved, sustainable accessibility.

Remember, every feature you make more accessible improves the experience for some users. You don’t have to solve it all at once to improve.

Tooling

A reasonable starting point is to have automated tools, such as tests, linters, browser addons, and IDE plugins to first aid with reporting identified violations and help get up and ready to brief in on good-first-issues.
Here are a few of the standard tools out there -

• Deque's Axe
• Microsoft accessibility insights
• Wave
• Site improve (big pile of services)
• Pope.tech
• Assistive labs (Like BrowserStack for screen readers)

Note that "off the shelf" automated tools pick up < 40% of the errors and are superficial (e.g., color contrast, inputs associated with labels, and more). Furthermore, compliance does not equal a genuinely accessible site. We must manually test and review.

Services

If feasible and resources apply, get 3rd party services to review applications by actual users, some even with relevant disabilities, which will provide actual "field" data on UX failures.

• Deque
• Level Access
• Audioeye
• Vision Australia Digital Access
• Digital Accessibility Centre (DAC)

There are dozen paid services to choose from, but the ones that seem most genuine to me are those with real disabled users.
Disclosure: I ran into DAC reference following gov. uk's insightful success story about getting an accessibility audit.

...We had our autocomplete tested by the Digital Accessibility Centre (DAC). They are one of several companies who specialise in accessibility testing and auditing. The majority of DAC's testers have access needs.They are expert users but they depend on services being accessible in their day-to-day lives.
DAC invited us to their offices in Neath to watch them put the autocomplete through its paces...

Communicate

Provide an accessibility statement to:

• Show your users that you care about accessibility and about them
• Provide them with information about the accessibility of your content
• Demonstrate commitment to accessibility, and to social responsibility

—w3c, web accessibility initiative

Start with
Minimal accessibility statement
Complete accessibility statement

Or generate with
https://www.w3.org/WAI/planning/statements/generator/#create
https://www.accessibilitystatementgenerator.com

Keep an open channel for users' feedback - a wide range of disability types and assistive tools may fail in play with the applications' UI. The following article section hints at how diverse it gets.

Summary

To serve all users, we need to continuously operate on a full spectrum of disabilities UX flaws.

Applying and maintaining a11y in your app(s) is a practice much like tests and security. You need to not only apply a11y but also set up the mechanisms that will allow you to maintain it.

Head start with an a11y-ready UI library. If resources apply, establish a dedicated team solely operating on UI, semantics, and accessible components.

In our experience, you will soon find out there’s no “one-fits-all” and you’ll need to start handling feedback - either from customers or from the business side. This is when you’ll need to prioritize.

Feedbacks are like feature requests or bugs. They need to be maintained and tested to ensure they don’t break (regression is bad for business). Here automated tests come into play - either 3rd party tools or tools you build that are dedicated to your UI (using tools like Cypress).

Eventually, when you do the best you can do on your own and feel you need another push to get to a new level - get the help of experts.

Just like any other task, you’ll need to set the gradual steps to comply with web content accessibility guidelines. It will be a joint effort of teams involved in UI development with set up workflows and a roadmap plan (also known as Epic on Jira).

Remember, every feature you make more accessible improves the experience for some users. You don't have to solve it all at once to improve.

I encourage everyone who are starting to learn about the topic to initiate action in your organizational environment.

Please raise any questions, arguments, concerns in the comments. I would love to hear back.

Thank you for reading 🤍

And special thanks to Yonatan Kra for his helpful, thorough review.