Introduction to digital accessibility

This is an opinionated introduction to accessibility. My goal is to keep this short, so I had to make hard decisions about what to include and what to leave out. There are a lot of great resources that I'm not listing here.

Words of encouragement

Don't let perfection get in the way of progress. Understanding accessibility takes time and practice. Start small now, and grow your skills over time.
You do not need to be an accessibility expert. Learn what you can and apply what you can. Ask questions and collaborate with others when you have questions.

Also, please be respectful as you advocate for accessibility to others, and remember that you didn't learn everything you know about accessibility overnight.

What is digital accessibility and who is it for?

Digital accessibility is about making the software we build accessible to people with disabilities. There are many disabilities, read the accessibility personas to start learning about them.

From a minimal compliance perspective: For software to be "accessible" it must be equally usable by someone with a disability as someone without a disability. Minimal compliance is usually measured by WCAG conformance. Thus, if an experience is equally unusable by everyone, it is still "accessible." We should not stop at minimal compliance.
From an inclusive design perspective: accessibility is about going beyond minimal compliance and providing good experiences for everyone. This is what we should strive for.

I am making this differentiation because many folks think that WCAG conformance is the end goal of digital accessibility. It is not.

What should I do if this is completely new to me?

If this is completely new to you, first read the accessibility personas. This will help you understand what accessibility is, who it is for, and how to test for it. Then, take a few moments to create a very small goal. Perhaps that goal is to test the next thing you build using a keyboard, or with the axe browser extension. Then iterate - keep setting new goals, and hold yourself accountable.

When should I think about digital accessibility in the software development life cycle?

An oversimplification of the software development lifecycle (SDLC) boils down to:

Design and planning.
Development.
Testing.
Release.
Repeat to make enhancements or fix bugs.

Additionally, mechanisms should be in place to monitor accessibility and detect regressions, both automatically and manually.

Example: recurring manual audits and automated checks built into the CI/CD pipeline.
Hint: integrating a tool into your automated testing pipeline is key. A quick win here will be linters like axe Linter.

Digital accessibility will be most successful if it is considered at each stage of the SDLC. The cost of fixing bugs grows significantly the later it is found in the SDLC. Thus, we need to consider accessibility as early as possible, especially in design and planning.

Where are accessibility bugs found?

Accessibility bugs can be found in:

Design. Examples: color contrast, use of color alone to convey information, etc.
Written content. Examples: alternative text for images, helpful error messages, etc.
Code. Examples: programmatically conveying the name, role, value, structure, and relationships of elements on the page.

Who needs to think about digital accessibility?

The short answer is everyone. Here are some examples:

Product owners, stakeholders, and leadership should make accessibility a clear priority and look for evidence that what is being built is accessible.
Designers need to test their designs for accessibility before handing them off for development. They can also document the expected user experiences of those designs for people with disabilities (this is often done with accessibility annotations).
Content writers need to author good alternative text for images, write helpful error messages, etc.
Whoever is writing development stories or tickets should make it clear what the requirements are for accessibility in the story itself. Accessibility acceptance criteria are very helpful here. For more information, read Collaborative planning, the forgotten step of accessible development.
Developers need to ensure that the code they write is accessible and meets expectations.
Testers need to verify that accessibility requirements have been met - this includes design, content, and dev requirements.

None of these roles individually need to be an accessibility expert. That would be unreasonable and inefficient. Instead, this should be a collaborative effort, with an atmosphere of experimentation and learning across roles. Collectively, the team should be able to work through most accessibility problems, but may still need to reach out to an expert from time to time.

Why should I care about digital accessibility?

There are several reasons:

For the people behind the screen. Humans are diverse, and we should account for that in our software.
For business potential. For example, it can be a significant way to differentiate your product from the competition and tap into the disposable income that people with disabilities hold.
For legal. Accessibility is a civil right.

What tools should I use?

There are a lot of tools for accessibility. The ones that I have listed here have proven to me to be the most accurate and helpful. That doesn't mean that you might find other tools valuable, but I wanted to give you a head start on what I know works well.

For Design:
- axe for Designers
- Stark
For Development and testing
- Axe - Axe from Deque Systems is a free and open-source automated accessibility scanning tool.
  - It comes in many forms that allow you to integrate it into all of the places you might want to test (manual testing, git pre-hook, CI/CD, E2E, etc.):
    - Browser extension
    - Open-source JavaScript library
    - Linter
    - etc.
  - The paid version also offers intelligent guided manual testing among many other helpful features.
- eslint-plugin-jsx-a11y
- Colour Contrast Analyser - The CCA tool from The Paciello Group is the best color contrast analyzer on the market. Download, install, and use it to grab different colors from your screen (or input colors manually).

Important: be sure to do manual testing too! Automated testing can not find all accessibility issues. For more help, read the accessibility personas.

What are some good courses and resources?

Deque University (paid) - I may be biased, but this is perhaps the best resource available. It is chock full of expert advice and perfect for self-learning. It covers everything from fundamentals to web accessibility (basics and advanced), QA testing, Program management, PDF and document accessibility, and even mobile application accessibility. It's fairly inexpensive and worth every penny.
Deque University (free screen reader reference guides) - Deque University also provides many free resources, one of which is the screen reader keyboard shortcuts and gestures. These documents are (in my opinion) critical when learning how to use a screen reader.
W3C Web Accessibility Initiative (WAI) - The WAI should be one of the first places you look for accessibility information. They have top-notch resources on fundamentals, policy, tutorials, testing, etc.
Introduction to Web Accessibility - edX course on accessibility from the W3C WAI

Additionally, check out these resources:

What are some good checklists?

I need to start this with a disclaimer. Accessibility is not a checklist. Everyone always asks me for a checklist, which is why I'm including this list. Everything that is in WCAG 2.x should be on the checklist. As much as you or I might want it to be simpler than that, it just isn't. Remember that WCAG is a minimum requirement and doesn't cover everything. You should do acceptance testing and research with people with disabilities. Checklists are most effective when used in planning. That being said, you might find the following helpful.

WCAG Quick Ref.
WAI: Easy Checks - A First Review of Web Accessibility - a great first check for accessibility.
Accessibility Heuristics from Deque - this is a great "checklist" that is especially useful when reviewing designs.
Deque University (free) checklist. Links to courses require a subscription, but this is still helpful without a subscription. This is a great resource because it ties each checkpoint to a specific WCAG SC or marks it as a best practice.
Deque University (paid) - also includes various checklists for different team roles and provides a detailed testing methodology for WCAG 2.x.

What are the standards?

Standards can be complex and hard to read and therefore are often only referenced as a last resort. I'd argue that they should be consulted first. They are the most authoritative source of how things should work. Some browsers, screen readers, and assistive technology don't always provide full support for the standard, but more often than not, they trend in the direction of support. To provide the absolute best experience for users, you will need to code to the standards (for forward compatibility), and shim any significant gaps in support (for example, that prevent access) in a way that is also forwards compatible.

WCAG Quick Ref - A dynamic and easy-to-read list of WCAG success criteria (SC). WCAG is the international standard for digital accessibility, so understanding the requirements outlined in this standard is critical to meet conformance. The actual standards can be very hard to read and overwhelming, so the Quick Reference provides another way to quickly glean information. Filter by WCAG version (2.0 or 2.1), level (A, AA, or AAA), and various tags, techniques, and technologies. It also provides links to the understanding documents for each SC and links to relevant techniques.
Understanding WCAG 2.1 - The success criteria in WCAG can often be vague or otherwise hard to understand. This is where the 'Understanding' documents come in. These documents detail each SC, discuss examples, describe the intent of the SC, and dive into how meeting the SC benefits people with disabilities. If you ever have a question about an SC - go here first.
HTML - HTML is often overlooked, but it is critical for a developer to understand what is and what is not possible in HTML. The semantics (name, role, value, states, and properties) provided by HTML elements and attributes are what make screen readers possible. For example, <button disabled>submit</button> is announced something like "Button, submit, disabled". Additionally, there are rules about how elements can be nested and what attributes are allowed under different circumstances. Assistive technologies like screen readers have much better support for HTML than ARIA, so reach for HTML first.
Using ARIA - The attributes provided by the Accessible Rich Internet Applications (ARIA) standards are often overused, misunderstood, and implemented in such a way that actually worsens the user experience for people with disabilities. This 'standard' (it's more of a note) explains when to use and not use ARIA. This is a must-read.
ARIA Authoring Practices - ARIA is designed to be malleable and flexible so that developers can make wacky and innovative designs accessible when there isn't a native way to build the design (or example, if an HTML element doesn't exist). This document details some common patterns that ARIA can help with and attempts to standardize them. It provides details on expected keyboard interactions and working examples. Check here first if you have to reach for ARIA. **Warning: ** The patterns here are opinionated and sometimes more theoretical than practical. Always test what you build with assistive technologies to make sure it works as expected.
ARIA in HTML - You can't just mix ARIA with HTML willy-nilly. To guarantee the best possible support with assistive technologies like screen readers, you should also adhere to the restrictions defined in this document. This document describes which ARIA roles and attributes are allowed on different HTML elements. Tools like axe test against these requirements.
ARIA 1.2 - If all else fails and you need to roll your own, or if you need to fix something and can't correct the HTML due to silly business constraints, reach for ARIA. However, just like HTML, there are rules around when and where you can use various roles and attributes. Read this before writing any ARIA.
Accessible Name and Description Computation 1.1 - this standard describes how accessible names and descriptions are computed in various scenarios. This isn't something you will likely need to memorize as a developer, but is a fun deep dive and may help you understand why a screen reader is conveying a specific name or description in certain circumstances.
HTML AAM - The HTML Accessibility API Mappings describe how browsers should translate various HTML elements and attributes to system accessibility APIs for consumption by assistive technologies like screen readers. This isn't something most developers need to know about but can be a fun read if you want a deep dive into how your code is translated into a screen reader experience. Note that there are other AAM documents, such as the Core AAM, which focuses on ARIA mappings.

More resources

This is more or less a dumping ground for more reading and resources:

mfairchild365/a11y-resources