Scaling Accessibility

In an enterprise software world, accessibility isn’t always about testing a handful of simple websites with homogeneous data and predictable release cycles. Sometimes accessibility has to scale.

A presentation based on the topic at the center of this article was submitted to CSUN 2020. If you are interested in hearing more, please email the conference chair and express your interest ! If you are associated with a conference where you think this topic is a good fit, please leave a comment with submission instructions. Thanks !

In an any cloud, any app, any device world, adding “any users” (what I like to call “the fourth any”) complicates things immensely. Before organizations can claim “any users” they have to first be accessible.

Why is scaling accessibility important ?

Technology is moving from individuals being tied to hardware and projects being tied to monolithic software releases to a cloud-based and app-based world. The average smartphone user spends 2 hours and 15 minutes each day using apps. Research shows that there are between 60 and 90 apps installed on the average smartphone, of which 30 get used every month.

Most apps *plan* to update weekly, though frequently “life intervenes”.

• Find a critical security/privacy issue? Release a new version of theapp.
• Apple updates to iOS 13 and the app needs a few tweaks to optimize? Release a new version of the app.

In the app world, there are few constraints other than customer satisfaction around how often the organization releases a new version of the app.

The release cycle cadence for SaaS (aka “the cloud”) is not much different than that for apps. One of the significant benefits of Software as a Service is that because updating software is easy, it is done fairly frequently. However, WCAG wasn’t defined with that release cadence in mind. Unlike the “one major release per year” monolithic release model, SaaS uses a CI/CD (Continuous Integration / Continuous Delivery) pipeline as a best practice for development teams to implement and deliver product updates more frequently and reliably to its customer base. CD/CD isn’t implemented just through a tool choice though (nothing is that easy) it also requires a development philosophy, a set of operating principles, and collection of practices to enable an environment where software releases can be fast, furious, and operationally reliable.

6 Principles of Scaling Accessibility

Principle 1: Use an accessible design system

The first step to an accessible product is using an accessible design system.

• Every time a developer codes a UI component from scratch (for example an accordion or modal dialog box), the developer is introducing the possibility that something about that component either a) might not be accessible or b) might be inconsistent with the style guide.
• Every time there is more than one person independently creating accordions or dialog boxes from scratch not only are you introducing the possibility of inaccessibility, and deviation from the style guide, you are all but guaranteeing different coding practices, which increases the maintenance and testing effort.

Clarity is the accessibility open source design system authored and maintained by VMware which has been downloaded over a million times this year alone.

Principle 2: Have a style guide contain “accessibility guardrails” to prevent implementation issues

When creating a large SaaS system or app, chances are the organization has some type of formal or informal style guide that tells developers what fonts to use (and when), what buttons should look like. That is where the accessibility guardrails should be located. Keeping accessibility in a completely independent chapter or a single line saying “implement this using WCAG guidelines” is a guarantee that the information will never be reviewed, and something will be done in an inaccessible manner. Guardrails that provide developers options to choose from a closed set within a list of “do’s” and “don’ts” is the best that can be done to insure that people don’t interpret the guidelines in whatever way suits them.

Principle 3: Be able to quickly identify changes that impact users of assistive technology

People in accessibility (testers and users with disabilities) have a fairly narrow focus. Changes that impact behind the scenes security, data processing, or performance optimization usually do not impact assistive technology use. The kinds of changes that DO impact users with disabilities are:

• visual changes (i.e. new field, deleted link, header change, change in focus indicator). Visual changes can be tracked by using a label/tag in whatever system is being used to track defects or new behavior implementations.
• the addition of ARIA to augment a component’s announcement from what is visually displayed (i.e. visually display “click here”, announce “click here for more information about accessible playgrounds”). Changes in ARIA code can be detected when checkins take place.
• multimedia / motion changes (addition of captions, animated .GIFs). This is usually handled at the content level, see Principle 5 below.

Principle 4: Get automated smoke tests up and running as efficiently as possible

Unit tests that can be run in an automated manner are at the core of the CI part of CI/CD packages. Software can be validated as frequently as each individual code checkin, and developers can be alerted or the code can be rejected if the change fails any of the automated tests. Accessibility unit tests are therefore an essential component to this process. Given that only somewhere around 30 % of accessibility guidelines support automated code analysis tests, that can be a significant challenge.

The steps to determine which test cases should be part of the “smoke suite” are:

1. Separate the “every day / happy path” use cases from “this hardly ever happens” use cases.
2. Figure out what is most likely to break, and prioritize that testing first.
3. Once the test process and code is debugged, tie them in to the CI/CD pipeline.
4. If a new change causes a test to fail, reject that checkin
5. Flag the developer requesting the checkin.
6. If a handful of developers get the majority of the rejections (which is usually the case) that is a “training opportunity”.

Principle 5: Block the content management system from adding inaccessible content

It isn’t enough to have an accessible infrastructure, the software also needs accessible content. And as quickly as code can change, content can change faster. Plus it is likely that the organization’s content managers will have far less accessibility experience than the developers.

Some of the accessibility related items that are easy to prevent from occurring from the CMS are:

1. Don’t allow graphics to be loaded without alt-text, or someone checking a box that says the graphic is “decorative” (with a definition of what a decorative graphic really is)
2. Don’t allow videos to be uploaded without captioning files
3. Don’t allow videos to be uploaded without links to accessible described audio, or a box checked that says “described audio not required” — again with a definition of what requires DA and what does not.

Principle 6: Identify your VPAT cadence and tie it to your release cadence

How often is the organization going to do end-to-end testing of the product including manual tests and update VPATs and ACRs? The greater of “every release with new major functionality” or at least 2–3 times a year seems to work for most people.

Conclusion

Keeping products accessible in a rapid deployment SaaS / app environment is a challenge most accessibility managers will be presented with eventually. Scale forces us to fully assess internal accessibility processes and procedures and figure out how to implement each one in a way that doesn’t adversely impact the speed necessary to efficiently scale the enterprise software release cycles, while also not compromising on accessibility quality. Scaling accessibility helps us build robust products that not only meets users current needs, but also meets future user needs without the need for a massive product redesign or code refactoring.