2021 accessibility predictions

Yeah, machine learning and personalization made the list, but I also have a couple of other thoughts.

It’s time for the annual “Year-End” accessibility predictions.

Machine Learning

Machine learning is going to continue to be exceptionally important to the advancement of accessibility. The challenges of scaling accessibility in a world where only 30 % of the tests are automated are well documented in this note from the W3C titled Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them.

TL;DR — Software *used* to be monolithic. One major release every 12–18 months, and a few minor releases focused on specific areas. That is no longer the case.

SaaS can release hundreds of times per week.

Native apps releases happen weekly-ish (more often if needed)

Improved accessibility test automation is essential to avoid accessibility regressions

With the world going to SaaS and native app in droves, accessibility can’t live successfully in a world where 70 % of the tests are manual. It’s not enough to GET software accessible; you have to KEEP software accessible. Machine learning will allow us to crush the 30/70 split between automated and manual testing. Image processing, natural language processing, pattern recognition, and supervised and unsupervised learning will be essential to shifting that percentage towards the automated side. That way, the tests can be run with every, single check-in preventing good accessibility from being replaced with broken accessibility.

My accessibility dream is a world that any check-in that breaks an automatic test is rejected. Something like this:

When we can automate more accessibility tests with a high accuracy level, we can tie them into the CI/CD pipeline. Code updates can be blocked if more accessibility tests fail than from the last check-in, preventing achieved accessibility from deteriorating.

• High levels of accuracy, in turn, require taking into account how ARIA might be overriding an issue that is broken in the native HTML. False positives caused by performing HTML analysis alone will negate the value of automated testing.
• Shifting defect discovery to earlier in the process is better, faster, and cheaper for everyone. It is also necessary to move accessibility from reactive to proactive.

(now a shameless plug for Crest, if you have already heard about this new fantastic tool, skip to the next section)

VMware’s Crest machine learning-based open-source automated accessibility extension to WAVE now checks for video captions/subtitles and podcast transcripts automatically and keyboard function, focus indicators, focus contrast, and heading relevance. The Crest team has identified and is planning to implement 26 more tests currently only manually testable that we think we can automate before the end of 2021. Stay tuned!

Personalization

Personalization is a curb cut. It is a better experience for people without disabilities and a massive improvement for people with disabilities. Why?

1. Personalization means less interaction — it takes people who use assistive technology three to five times (on average) as long to complete an operation than people without disabilities. Not having to turn on close captioning every time you enter a site means you are saving that interaction and operating faster no matter what your ability status is.
2. Personalization means less user frustration — knowing what works for your particular situation and then having to re-establish it every single freaking time you log in is highly frustrating to users. If I had a nickel for every time I have thought, “why do I have to hit the Ctrl-+ button over and over again, why can’t it remember I like it set to 200 %,” I would be sipping a cocktail outside of Turtle Bay.

Eventually, organizations will start to get the memo on the importance of personalization. It is taking longer than I thought it would, though. Who would have thought that something as apparent as personalization would take so long to achieve acceptance by organizations whose success is measured by gaining and retaining happy customers?

2021 will be the year non-accessibility professionals realize that accessibility is a program, not a project.

So this prediction is my secret sauce, the one I haven’t heard anyone else discussing. There have been several significant accessibility milestones in the last 15 years:

• 2006 — WCAG 1.0
• 2008 — WCAG 2.0
• 2018 — WCAG 2.1
• mid-2021 — WCAG 2.2
• 2022 — WCAG 3.0 and the EAA

Note the spacing between updates. WCAG 1.0 was somewhat incomplete. Most consider WCAG 2.0 in 2008 to be the first complete accessibility standard. And then ten years passed without an update. Followed by three updates in four years (2.1, 2.2, and 3.0), two of which are pending. Then add in the European Accessibility Act for good measure if you work for a global company.

Most software professionals who are NOT accessibility subject matter experts only know about 2.0 and 2.1 (if they know anything about accessibility at all), and they know that ten years passed between these two releases. If this is what they think is the regular W3C accessibility update cadence, they are in for a rude awakening. WCAG 2.2 will come out two years after 2.1, and 3.0 (AKA “Project Silver”), which will significantly change how accessibility is measured, comes out less than two years later.

This “update WCAG every two years” approach is more likely to be the future cadence. WCAG 3.0 will be such a significant update that 3.1, though not yet started, is all but guaranteed, and it won’t likely be ten years after 3.0.

• Accessibility is and should be thought of as a continuous process improvement program.
• Your organization is guaranteed to fail if it only thinks about accessibility before release.
• Accessibility standards are evolving as more people perform research on things like cognitive disabilities and neurodiverse conditions.
• Accessibility standards also evolve as new technologies for gaming and VR/XR are released.

Accessibility is a program, not a project. Also, accessibility needs to be considered throughout the product life cycle. If people don’t understand that now, the WCAG 2.2 update in 2021 and the planned 3.0 update in 2022 may enlighten them.

“Accessibility is a program. Not a project” leads to my final prediction, which is:

More frequent application of Maturity modeling to organizations trying to improve their accessibility programs.

With the fear of litigation driving many (especially retail) accessibility programs, it is not surprising that many organizations slow down or even stop work on accessibility programs once the case has been dropped.

This approach creates accessibility regression — because accessibility was viewed from the lens of a project (make the litigation go away) and not a program. Many companies are learning this difficult lesson as they are being sued multiple times by different litigants as their accessibility backslides.

Getting a product accessible and *keeping* it accessible requires exercising two different sets of corporate muscles.

• Muscle set #1: Getting a product accessible focuses mostly on people involved directly in the Software Development Life Cycle
• Muscle set #2: Keeping a product accessible requires participation from stakeholders in the entire organization — Communications, Training, Support, HR, D&I, and Policy, just to name a few

Maturity modeling (MM) is a way of measuring your entire organization to see how well each of these categories (“dimensions” in MM-speak). MM findings can identify:

• Which dimensions are doing better than others?
• What policies and documentation (“artifacts” in MM-speak) are missing.
• The changes that are necessary to achieve the next level of accessibility improvements.

I will do a deep-dive on accessibility maturity modeling in a future article.