Here's my dirty secret: I did not know nor care about web accessibility for the first 6 years of my web developer career. I added alt attributes to my <img>s, sure – but it didn't go much deeper.

I wanted to write more accessible web code, but it's always been more of a nice to have than a business priority. Plus, the accessible solutions I find online are not only all different, but they all also seem overly complex. As a result, my websites were only as accessible as my ability to duct tape pieces of 'web best practices'.

When I started my current job with a focus on web implementation of a design system, I had lots of catching up to do. Fortunately, my current employer prioritizes accessibility. I work with a team of in-house accessibility professionals and managed to really step up my A11Y game – not difficult since the starting point is somewhere below sea level.

On March 18th, the US Justice Department issued a new Web Accessibility Guidance. While the guide may not go far enough or is detailed enough, we are still moving one step closer to making web accessibility both the right thing to do and a legal requirement.

Here's is a list of web accessibility resources I would recommend to the 2012 version of myself – along with when and how to use each.

Screen Reader

Learning Web Accessibility without access to a screen reader is a bit like learning CSS without a rendering engine. You can read the CSS specifications and write CSS without feedback – at least in theory – but it'll surely slow your progress and deplete your motivation.

With Screen Readers, you can:

• Get instant feedback immediately on your website's UX.
• Develop empathy for assistive technology (AT) users through first-hand experience.
• Understand inter-screen readers' quirks and the gap between specifications and the implementations.

Humans are visually focused and so using a screen reader can at first feel slow. Work through the initial resistance. Use it on your everyday sites like Reddit and your daily news source, it will help you develop a basic understanding of what screen reader UX conventions are. When working with my own projects, I try to run through common user workflows with at least two screen readers to get a sense of the end-user experience.

For Windows users, there's the very popular – but paid – JAWs screen reader and the free alternative NVDA. There's also the Windows native reader Narrator, though I do not have experience with it. For Mac users, you can press command + F5 right now to bring up the VoiceOver app. For Linux users, there's GNOME's built-in Orca screen reader – not my personal favorite. I tend to use the ChromeVox / Screen Reader extensions instead. If you are looking for resources on how to use a screen reader, Deque University has some useful references.

Accessibility Plugins

Screen readers are important, but they aren't always the most time-efficient tools in a developer's toolbox. It can be especially slow when auditing an existing site. That's a job suited for Accessibility evaluation tools.

Accessibility plugins and extensions are the chainsaws of my toolkit, they are good for making the rough-cuts and giving me a high-level view of a website's accessibility status, along with any glaring accessibility violations. Once the extensions point out the major errors, we can fine-tune our solutions with the aid of a screen reader's feedback.

However, be aware that a tool telling you it cannot find accessibility violations does not equal the site is accessible. Automated accessibility evaluation for your site is not the same as a unit test for your code. Take WCAG success criterion 1.4.1 as an example:

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

A program cannot determine if only color is used to convey information – unless it's got human-level AGI. This point is important enough that it warrants repeating: Accessibility Evaluation tools alone are not enough.

I mostly use two Accessibility extensions regularly, the WAVE tool by WebAIM and the AXE Dev Tools by Deque Systems. The other beauty of accessibility plugins is it eases you into the world of specifications and guidelines, which brings us to our next topic.

The Specifications

Screen readers and accessibility tools mostly provide negative feedback. They are better at showing you accessibility violates than leading you to a good accessible experience. For good accessibility references, we have to go to the land of web guidelines and specifications.

Good web accessibility starts with the proper usage of semantic HTML. A screen reader can let you know when there's something wrong with your HTML.<div>s that look and behave like a button but isn't a <button> element? Your screen reader will let you know. The HTML living standard and the consistently helpful MDN HTML docs should be the first line of reference when implementing a new feature. ARIA, or Accessible Rich Internet Applications, is a set of tools that allow web authors to provide additional layers of semantic meaning to assistive technologies on top of what HTML offers.  

The acronym WCAG frequently comes up when working on web accessibility. It stands for the Web Content Accessibility Guideline and is published by the W3C. It's a set of accessibility guidelines and success criteria used to measure how accessible a website is – I already mentioned 1.4.1 in the previous section. Similar to the HTML standard and related documentation, it's not necessary to memorize all of WCAG. I take more of a piecemeal and reference approach, where I read up on sections related to what I am trying to do. Or when it is caught by the accessibility audit tools.

I cannot mention WCAG without mentioning the companion Understanding WCAG 2.1. Use it to move beyond the abstract and into concrete usage examples, techniques and scenarios. And as always, MDN is a web developer's best friend and has appropriate links to both publications.

Inclusive Components

Even with the right tools and references, it can feel overwhelming to 'do accessibility'. Short of working with an accessibility professional, the best mentorship I've gotten is from Heydon Pickering's book (and blog): Inclusive Components.

Heydon is a gifted writer who teaches you to think like an accessibility professional. You'll learn how he tackles common accessibility problems and patterns. The book also includes many references to WCAG and Aria roles to use as jumping-off points into exploring the guidelines – exploring with real use cases in mind.

A side note – I also want to recommend Heydon Pickering and Andy Bell's book Every Layout. It's a short yet comprehensive way of learning – or relearning – the fundamentals of web layout.

Accessibility Blogs

I saved the last spot for accessibility blogs. Not because they are the least useful, but because they are most useful with context provided by previous resources.

Quick sidebar, if you enjoyed reading this article so far, please share it with others. If you really enjoyed it and don't want to miss the next one, please follow me – it keeps me motivated to write more.

Let's go back to our initial problem of having too many examples. Let's say we are creating a sortable table component and come across an example from BU and one from Deque University.

We can first run the WAVE evaluation Chrome extension to get an overview of the two solutions. We see that the BU example is more of less an HTML table while the Deque example uses the grid aria-role.

Next, we turn on VoiceOver and try to use both tables via the keyboard. We immediately notice that the BU example's sortable table headers are not usable with keyboards while Deque's example is navigatable. This is better feedback than any amount of best practices will provide.

At this point, I can do a deeper dive of role="gridcell" from the Deque example and learn more about the role in both WAI-ARIA spec and its corresponding practice guide.

What all that said, here's a list of my favorite web accessibility blogs to keep up to date with industry trends and discover new use cases outside of my work:

• Adrian Roselli's blog – he happens to have a helpful post about accessible sortable tables.
• Sarah Fossheim's blog - I especially like the post detailing accessibility issues from the 2020 US election coverage.
• Sara Soueidan's blog – Check out her fancy accessible focus indicators.
• Scott Ohara's Blog – Scott's Accessible Components repo also deserves a shout-out.
• WebAIM's Blog – Helpful Industry news from WebAIM.

If I have accomplished anything with this post, I hope I convinced you to install a screen reader today. And if you already installed one – or if you have one that came with your operating system – learn a single new shortcut today (Deque reference link). I just learned that pressing x in NVDA when focused on a checkbox moves the visual cursor to the next one, neat!

If you liked this post, you may also be interested in learning more about whether we should be using multiple <h1> on a page in 2022. Is it accessible? Can you navigate correctly via landmarks?