The Hard Thing About Digital Accessibility

When it comes to accessible development, enteprises are caught between a rock and a hard place.

The Rock: Enterprises face mounting pressure to make their websites and mobile apps accessible to differently-abled people.

The Hard Place: The lack of scalable enterprise-grade development and testing tools, methodology, lack of support in common web development frameworks, lack of knowledge and best practices in development teams to facilitate the accessibility endeavor.

Enterprise-Grade Automation Tools Are Lacking

The existing solutions in the industry revolve around syntax analysis rule-sets that cap issue detection at 20% (depending on the complexity and dynamic elements of the page). Essentially, they find errors like color contrast, missing alt-text, missing HTML attributes, etc. which are important, but not nearly enough for proper accessibility. Given that much of functional and semantic information is sometimes hidden from HTML syntax (making it invisible to syntax analysis — we’ll talk about this more later) — it’s easy to see why today’s accessibility automation tools really struggle.

Accessibility is Not Baked Into the Infrastructure

In addition to the lack of automation, there are no guardrails built into HTML development frameworks to prevent developers from making accessibility mistakes. Of the available web development framework — React, Bootstrap, Angular etc. — none encourage developers to pick the correct accessible UI components (ie: drop-downs, radio buttons, checkboxes, etc.) or to use ARIA tags when they define custom components using divs/spans with CSS and Javascript. This creates a difficult situation for assistive technologies like screen readers.

Accessibility is a Complex Field

Since some of the accessibility requirements are not clearly defined, it’s hard to develop a set of functional requirements that a developer can relate to and test their code against. The WCAG 2.1 A and AA specifications may sometimes seem arbitrary and open to interpretation. Consider the following:

• 1.3.1 Success Criterion which says “Info and Relationships” and is explained as: “Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text”. This was so vague that the WAI felt that they needed to clarify the terms “structure”, “relationship”.
• When trying to balance design and accessibility implementation requirements, complying with the 1.4.3 Contrast (Minimum) or 1.4.11 Non-text Contrast guidelines means really taking a shot in the dark.

Manual Accessibility Testing is Hard

Manual accessibility testing requires deep knowledge of accessibility guidelines, how to operate assistive technologies, and a certain level of expertise in HTML and web technologies. In most enterprises the process is as follows: a PS (professional services) firm comes in and, with a screen reader like JAWS/NVDA and a keyboard (separate flows), painstakingly checks navigation, interaction, flow, focus management, orientation, semantics, noise, and alternative content etc.. Yes, all of this is done manually.

The PS firm then documents all the issues for developers to fix and trains the development team on how to fix them, but when they try, the testing process is so complicated and difficult that it goes back to the PS firm/manual accessibility QA team. This is, to say the least, annoying and tedious for developers — and generally suboptimal for the development process.

Adapting Accessibility to the rapid pace of CI/CD

Accessibility isn’t a once-and-done project. It needs to be maintained for every major release of the website/web application. Development teams are rapidly adopting continuous integration/deployment. Adding an accessibility manual audit is something that clearly flies contrary to the concept of releasing/deploying fast. With weak testing automation tools and no working knowledge in dev, accessibility testing becomes a boat anchor for development teams.

The industry needs better automation — now is the right time

We believe that the right set of technologies (computer vision, multi-modal AI models combining images, the DOM, interactions, etc.) are getting commoditized to a point where it is possible to build a generic solution to the accessibility problem. Something that can take care of the 80–95% of the testing that is currently done manually — enabling developers to integrate this into their day-to-day development process.