11 New Year’s resolutions for accessibility in 2022

These are in no particular order, but many of them transcend web accessibility and can make you a better person. You may not be able to implement some of these because it’s not within your power. However, you can still advocate for it or at least support your accessibility co-workers (assuming you have them).

1. Integrate accessibility early into your process

Accessibility is not window dressing, nor is it the sprinkles on the cake. Accessibility is a primary ingredient, or should be. The underlying cause of most accessibility issues springs from a mindset. That mindset is developing a product for users that are just like the developer. That’s a bad mindset, not just from an accessibility point of view.

When you are in the planning stages, bring in QA and the accessibility personnel. Hopefully, you’re listening to System Administrators (SAs) and Database Administrators (DBAs) in the planning stages as well. If the SAs or DBAs say something can’t be done or are making recommendations, you adjust as necessary. Give similar deference to QA and accessibility personnel, which brings us to the next resolution.

2. Recognize QA and accessibility personnel as part of the team

Yes, the team, not just your team. Stop thinking of QA and accessibility personnel as the “QA team” and “accessibility folks”. Stop thinking of yourself as part of the “dev team” or “design team”. You’re all on the same frickin’ team! You are all trying to deliver a functional, available, reliable, accessible, secure, and usable product.

Lose the silo mentality in 2022. You’re a professional. Stop making the workplace like a high school clique-fest.

Thinking of making a design change? Bring in QA and the accessibility personnel. Ask, listen, follow through, follow up, and repeat. Be prepared to be shot down, which brings us to the next resolution.

3. Be willing to admit when you are wrong and accept correction

This is one of those resolutions that transcend accessibility.

Your ego can be an ally when it matters, but that’s rarely the case when you’re part of a team. Recognize that your ego can be a hinderance to you, the product, and the team.

If you debate your case, do it in good faith. Recognize that your “opponent” is also trying to deliver an excellent product or service.

When you are wrong, admit it. Don’t grovel or feel guilty. You don’t even have to say “I’m wrong.” In fact, it’s better to say “You’re right.” and/or “I hadn’t thought about it that way.”

This doesn’t mean that QA or accessibility personnel are always right. On many teams, they have been shot down even when they are right. If you are wrong and you don’t understand why you’re wrong, then little is gained. Ask others to educate you on the matter.

One step beyond this: be willing to admit the way you’ve thought about something has been wrong this whole time. This is more difficult and requires more humility than admitting you’ve been wrong about a single point.

4. Lose the excuses

Reign in your thoughts when you start thinking:

• “That’s how I’ve/we’ve always done it.”

• “This accessibility issue is too expensive to fix.”

• “What do they know? They’re not developers.”

• “We can’t make that change. It’ll make the site look like crap.”

• “The automated accessibility testing tool said there were no errors.” (LOL!)

• “Our process is already too bloated to include accessibility.”

• “We don’t have time to address these accessibility issues.”

I won’t expound on these because that all stem from deprioritizing accessibility. I’d imagine if there was a functionality issue, you’d make the time and you’d make the effort. For the many millions of users that have a disability, an accessibility issue is a functionality issue.

5. Treat severe accessibility defects as show-stoppers

Some accessibility issues are worse than others. If you look at WCAG 3.0’s Working Draft, there are Critical Errors — which, if committed, would result in an overall failing compliance score. That would certainly qualify as a show-stopper.

When you say things like, “We’ll address it after the release. We’ve got a deadline,” what you’re actually saying is “Accessibility is not that important.” And, be honest, you know that if you wait until after the release, it’ll be put off again until after the following release.

If your proposed product didn’t function for 10% of your potential users, would you be okay deploying it? That’s what accessibility defects do: they break your product for a significant number of users. The defects don’t make it inconvenient, they break it. That’s a show-stopper. Treat it like one.

Otherwise, you’re user stories, as Attila Vágó says in his article It’s Not Only An Accessibility Bug — It’s A Blocker! begin this way:

“[W]hen user who doesn’t use keyboards, assistive devices, has zero vision loss, dyslexia, motor impairment, cognitive, vestibular disorders, any other impairment or otherwise unable to use their device in a traditional manner, goes to log in…”

6. Decrease your dependence on third party libraries

I know it’s easy to turn to a UI framework or other third party library. After all, you figure “someone else has done all the hard work, why should I repeat it?” Yes, they’ve made a framework that looks nice and appears easy to implement.

Trust me when I say that the vast majority of them have not done the hard work of ensuring the frameworks are accessible. Even if you adopted one and determined that you would pour through it to ensure that it was accessible, you’d spend just as much time (likely more) building what you’d need from scratch.

Furthermore, you will constantly have to upgrade the libraries, which can be time-expensive.

Consider it a challenge. Build the site with no CSS or JavaScipt at the beginning. Add CSS and JavaScript as appropriate, keeping in mind the role of each.

And, for the love of Pete, please don’t ever entertain accessibility overlays! These elixir salemen are selling a shady bill of goods and many companies that are using them are being sued to Kingdom Come.

7. Use Semantic HTML

No one likes to be told they’ve been doing it wrong. I remember when I first started experimenting with HTML back in 19(cough)(cough), I was doing it all wrong. My elements had all caps because that’s what the book said and half of my elements didn’t have a closing tag because the brower was (and still is) forgiving on the rendering for the able-bodied.

But now, we (should) know better. We know that HTML elements have a purpose, and it’s not style, nor function — it’s content and structure. A <p> or paragraph element, for example, is not for adding vertical white space before and after the opening and closing tags. It’s meant to contain text… namely, a paragraph.

We’ve abused how forgiving browsers are with rendering HTML. We sloppily throw together some HTML in our IDE of choice, save, refresh the browser, return to the markup, add a series of line breaks (<br /> ) to increase the vertical space between sections, add unnecessarily inline styling, save again, refresh again, and presto! — we’re happy with how it looks. Now deploy!

But read what Jason Knight states in his article Semantic Markup Probably Doesn’t Mean What You Think!:

Oh, but it LOOKS fine to you… well lah-dee-huffing-dah for YOU! It’s not about you, it’s about the people visiting your site. It’s called accessibility, and by using HTML properly you get that quickly, simply, and easily. You ignore proper semantics and you’re just making the page harder to use for someone, somewhere, at some time!

HTML elements provide a structure that can be read by assistive technology. When you use the elements incorrectly, you can make your content unreadable for those using assistive technology.

When QA finds a bug, we developers often say in jest “it works fine on my machine.” We chuckle because we all know that’s a ridiculous thing to say. Not all machines are the same, nor the configurations. How then can we justify sincerely saying exactly the same thing with our markup?

8. Get familiar with WCAG 2.2 (and WCAG 3.0)

WCAG 2.2 could be finalized in a matter of weeks and there are new Success Criteria that we should know. Here’s the current (and likely final) list:

• Accessible Authentication

• Accessible Authentication (No Exception) (this criterion is only available in the Editor’s Draft)

• Dragging Movements

• Consistent Help

• Page Break Navigation

• Focus Appearance (Minimum)

• Focus Appearance (Enhanced)

• Visible Controls

• Target Size (Minimum)

• Redundant Entry

If you’re a developer, read up on these and see if your product meets these new standards. If you’re the accessibility expert, familiarize yourself enough with these so that you can communicate the need in language the developer can understand. WCAG criteria are notoriously confusing. Educate and guide your team.

As for WCAG 3.0, it’s certainly a good idea to be familiar with it. For the individual guidelines, I’d recommend accessibility personnel read, process, and make recommendations for changes. Communicate the bigger picture of WCAG 3.0 to your team — that standards will be geared towards needs, changes to the standards will be more frequent, the bare minimum likely won’t cut it, and holistic testing will be part of the testing process.

9. Hire or consult with someone that uses assistive technologies

With holistic tests coming in WCAG 3.0, it only makes sense to seek out those that use assistive technologies (AT) and get their feedback on your product.

When you are able-bodied, and you’re using a screen reader to consume the same page over and over again, you get fatigued (or, at least, I do).

There’s no substitute for a real user that relies solely on AT to consume a website. Befriend them, buy them coffee, or (better yet) hire them as part of your team. Once WCAG 3.0 comes out, this will probably be a common thing. Get a head start by doing it this year.

10. Seek accessibility instead of compliance

Accessibility — not compliance — should be the goal. Here’s a hint to find out which one you’re seeking:

You’re looking for a color for your text. So, you go to one of several color contrast calculator pages and enter the color value of your background. Then you enter in a color you really like for the text. It tells you the color contrast isn’t high enough. If you inch the color value ever closer to compliance until it reaches that magic 4.5 ratio, you’re after compliance.

If we were all angels, we wouldn’t need laws. Laws cannot make you care about your fellow man and accessibility standards cannot make you care about those that consume the web differently than you. That has to be a choice. Make that choice in 2022.

11. Cross-train

There’s no reason any developer should be ignorant in terms of web accessibility. The information is out there, available at your fingertips. I received virtually no formal web development education or training. I say that not to toot my horn, but to demonstrate that web has all the educational material you need.

Likewise, if you are the accessibility expert, you should have at least a beginner’s-level understanding of web development. You want to be able to communicate the need, but you also should be able to look at the markup, see what went wrong, and offer practical solutions.

Conclusion

You could sum up everything this article with one short sentense: Take accessibility seriously.

I don’t guilt anyone into an accessibility mindset (at least, not on purpose), nor do I scare them with litigation stories. You should want an accessible web because it’s the right thing to do. That mindset can’t be forced with guilt, fear, or pressure. It’s a choice and I hope you’ll make that choice in 2022.

Happy New Year to you!

Recommended links

Featured articles

• It’s Not Only An Accessibility Bug — It’s A Blocker! by Attila Vágó
• Why accessibility overlays hurt more than help by Denis Boudreau
• More lawsuits filed against companies using accessibility plugin/overlays by Sheri Byrne-Haber, CPACC
• Semantic Markup Probably Doesn’t Mean What You Think! by Jason Knight

My articles mentioned

• WCAG 3.0: What you need to know about the future of accessibility standards
• Communicating accessibility as needs to be met and not rules to be followed
• Stop your scare tactics with accessibility lawsuits — use honey, not vinegar