Starting a new accessibility remediation project?

Marie Kondo’ing the project first will get you to your goal faster.

Yay, you finally convinced someone to prioritize remediating an inaccessible website.

What could possibly go wrong? </snark>

There are approaches and prioritization that will make your end goal of an accessible website easier and cheaper.

1. Consider a do-over

Do you want to fix what is there, or are you better off building something new and accessible from scratch? The answer depends on a couple of things:

A. How extensive is the necessary remediation?

B. Was the site scheduled for an update anyway?

If the answer to “A” is “tons” and the answer to B was “yes” or “maybe,” even “hadn’t thought about that, sounds like a good idea,” then you might want to consider starting over. Then you can make accessibility part of the MVP of a website or mobile app redesign, rather than trying to jam accessibility retroactively into the old design.

This is *especially* true if the remediation requires adding responsive support so that magnification works correctly. Start over. It’s usually much easier, believe me. It’s very, very hard to put responsive breakpoints into a design that was created without them in mind.

In addition to the “what is easier,” question, there may be tax benefits to rebuilding. Fixing bugs is generally considered an operating cost because it’s a “repair,” building something new may be capitalizable. Check with your accountant, don’t trust me. I know enough about accounting to be dangerous, nothing more.

2. Figure out what you can get rid of

If that page, document, or behavior isn’t sparking happiness, delete it. Then it doesn’t have to be remediated, which will make the overall project faster and easier.

Do you really need 20 years’ worth of SEC filings when 3 to 5 years (or less, just point them to the SEC site) will probably do?
Do you really need a page showing some event that took place 3 years ago?

Hold up every page and download, and if there is no joy, get rid of it.

Look at your analytics to see what your highest trafficked pages are to make this decision. If you don’t have any, it is totally worthwhile to install them, wait for a month, and then act on the data.

3. The order in which you tackle remediation is important to your users

If you decide to proceed with remediation rather than a do-over, you should implement the easiest, most impactful accessibility guidelines first. Because I’ve done this several times, I’ve created a mental list of my preferred order of remediation task execution.

A. Start with keyboard access

Keyboard access is the basis for almost all assistive technology (“AT”).

If it doesn’t work with the keyboard…
…nothing involving assistive technology will function correctly.

Use your personas (if you have them) to focus on the highest priority user paths.
Consider creating personas (if you don’t have them).
Your last choice should be going to your software testing workflows (if you don’t have personas and aren’t going to create them)

If you don’t have any of these things, you are going to have to figure out how you know when you have done “enough” testing, which can be difficult.

Check all keyboard operation-related behavior simultaneously, including focus order, indicator pattern, and contrast while in the “neighborhood.” The success criteria you should be reviewing in this step include:

B. Color choices and alt-text

Colors don’t take long to fix, but they take forever to decide, because of the collateral and trademark implications. Also, the people fixing the colors will be different folks than fixing the keyboard access. Don’t forget to check contrast for people with red/green color blindness. I use CoBliS for this, but there are plenty of plugins available for common design tools.

In reviewing alt-text, you need to look at every single non-text element in the site and decide “what information is the RIGHT amount of information to provide about this graphic.” I wrote an entire article on how to answer this question.

Both color and alt-text likely use different groups of people than keyboard access, so there is a high likelihood you can accomplish these concurrently. The success criteria you should be reviewing in this step include:

C. Accessible multimedia

This includes:

Making sure you have video captioning and podcast transcripts, which are always required for people with hearing loss but are used by other non-disabled groups. Have tens of thousands of pages that need to be checked? VMware’s Crest machine learning-based automated accessibility extension to WAVE now checks for video captions/subtitles and podcast transcripts automatically.
Assessing videos for the need for descriptive audio. Not all videos need descriptive audio, but if they do, you either need to provide it or replace the video.

These are easy, quick, cheap wins and most likely utilize different people than either A or B. The success criteria you should be reviewing in this step include:

D. Header structure

People with print disabilities who use screen readers desperately need good, and consistent, header structure to quickly navigate through text to find exactly what they want and skip through what they don’t want.

E. Fix the easy problems that make your website a less than joyful experience

I know absolutely no one (regardless of their ability status) who appreciates any of the following:

Inaccessible CAPTCHAs. Those are always blockers. At a minimum, replace them with Google I am not a Robot reCAPTCHA v3. Even if you have accessible CAPTCHAs, ask yourself the question “could I use honeypots instead?”
Infinite scrolling. Dump it. There is no way to make this accessible.
Parallax. Again, no way to make it accessible. Here’s an accessibility hint: if you make your visitors feel like they are going to puke, chances are they won’t become customers.
Excessive motion and automatically moving carousels. They cause the same issues as parallax. Unless you are going to personalize motion choices, get rid of it.
Missing “skip to content” link. Keyboard-only users don’t like having to press the tab button 57 times to get to the center of your page.
Timeout behavior. Do you provide enough warning? Can people easily recover from it? Review, and update as needed.

F. Make all your forms and error messages accessible.

There are nine guidelines concerning form construction and error handling, almost 20 % of WCAG 2.1 Level AA. They include:

If you make all your feedback, forms, and error message compliant, you’ve just knocked out almost 20 % of the guidelines, and it’s an important 20 %. Focus on just the form content itself, templates come in the next step.

G. Remediate all HTML page templates

Once you think you are done making your page templates compliant, you need to test them manually in extreme detail using a combination of different:

Browsers
Operating systems
Assistive Technology
Hardware

Remember, any accessibility bug in your templates will show up on every page that template is used. This is going to be a LOT of places, possibly thousands. Also, make sure at least some of the people testing the templates are native users of assistive technology.

H. Run LINT or some LINT-like tool

Speaking as a former VP of engineering operations for a large .com, people don’t like keeping their code up to date as the underlying frameworks change. The home-building equivalent of this is being in charge of plumbing when the glamorous jobs are in interior decorating or architecture. Replacing deprecated functionality with newer behavior is essential to being WCAG compliant because when Java or SQL or some other tool puts up a code-level error message, a user with a disability especially a screen reader user will have no idea what is going on and how to recover from it. That is why the WCAG 4.1.1: Parsing guideline is so important.

H. Finally, remediate the rest of your content and behavior.

Consider grouping your WCAG guidelines to test related behavior at the same time to get through it more efficiently.

4. Don’t wait for a “Big Bang,” release incrementally

If you go with the approach above, push out each step into production after it has been completed and validated. Don’t wait until you get to the last step and then push it all out at once. You aren’t building a freeway overpass; we’re talking about software here. If you missed something or it could have been done better, it’s easy to update. Trust me, when you start making accessibility improvements word gets around. I think it was all of 48 business hours before I started fielding questions from people about VMware’s first largely accessible releases with Fusion, Player, and Workstation. We didn’t do a single announcement or press release, our users figured it out and started clamoring for more.