Accessibility is not a “best practice”, it’s an imperative. It’s not about building niche features for niche audiences, it’s about ensuring that everyone can perceive, understand, and engage with your product.

Here are a few principles that can help you deliver:

1. It’s not a question of whether or not to build an accessible product: that much is not negotiable. It’s more of a question to what degree you need to invest. If you really don’t know, start with A, the lowest level, do some user testing with real people, and iterate your way to AA.
2. If you don’t design for accessibility, you won’t implement accessible software. This demands awareness and collaboration at all levels of the team, not just from the developers.
3. You don’t need to be an expert in accessibility to start building more inclusive experiences. Many teams I’ve worked with are afraid to just get started because it sounds like it will take a lot of effort and expertise. What matters is creating a culture of continuous improvement.

Choosing the right target level

There are three levels of conformance that the Web Content Accessibility Guidelines (WCAG) discusses: from least to most strict, they are A, AA, and AAA.

AAA doesn’t mean 100% accessible for all people all the time — that’s not a realistic goal. Even so, most pages don’t need to conform to AAA in order to be considered usable for most people. The guidelines actually recommend against conformance to AAA for entire websites as a general rule because it’s not possible to satisfy all the criteria simultaneously for some content.

As for the other levels: depending on where you live, A may not be sufficient to comply with the law; AA is the sweet spot for most applications. (I’m not a legal professional — please do your due diligence.)

Organizations in certain industries (like government or healthcare) tend to demand a higher level of conformance, which leads to clear requirements in user stories and more rigorous testing. For organizations or locales which don’t have an obvious mandate and don’t know their own requirements, I currently recommend level A as the default for their applications. The bar is fairly low for A, which will make it less overwhelming as a starting goal, and helps to put good habits in place that will make getting to AA easier. The goal should be to get to AA eventually.

Taking action as a team

Unfortunately, when a clear mandate is absent, accessibility tends to get completely de-prioritized, because the requirements may not be immediately obvious. It’s often seen as having comparatively little value next to delivering other features, even by well-meaning people. This is a pitfall to be avoided: accessibility isn’t a standalone feature, it’s an intrinsic part of all features.

What does it look like to actually design for accessibility? I have some suggestions for how different roles can contribute.

Product Strategists

Add specific acceptance criteria for accessibility in user stories. (Not just a catch-all “do accessibility”!) This quick reference is very useful for understanding the guidelines, and you can even filter for the standards you are trying to meet. That should give you a sense of what kind of requirements you can start to write in your stories and will help everyone learn what actually needs to be done.

Experience Designers

Pair with developers to find appropriate solutions. A common example I use is drag-and-drop: if a designer asks me to build a drag-and-drop interaction without a way to achieve the same goal via the keyboard, I give them that feedback before I write a single line of code. I provide input on the feasibility of the proposed interaction design or we co-sketch alternatives. The inclusive components project is a great resource for sourcing common patterns.

Use design tools to your advantage. Look for ways to include accessibility checks in your design tools, such as Sketch Cluse contrast checker, Stark, Figma accessibility plugins, and a wide variety of browser extensions. These plugins can help simulate different types of color-blindness, highlight contrast issues, and more.

Organize task-based user testing with people with varying disabilities (i.e., visual, auditory, motor, and cognitive disabilities); those learnings should be shared back with the rest of the team in order to improve the product. Even better if the team can observe (or watch a recording) — having had the chance to do this myself, I can definitely say it’s an excellent opportunity to build empathy with the people you’re trying to serve.

Developers

I talk about this topic a lot, so if you’re looking for some more detail you can certainly check my prior art. :) At a high level, there are two things I’d emphasize:

Automate whatever checks are possible to automate. You can use a tool like Pa11y or Lighthouse, which will run automated checks against your HTML and CSS and tell you if you’ve missed things like alt attributes on your images, or if you have poor color contrast. There may be Javascript linter plugins (here’s a plugin for React) that will serve similar purposes and can be complementary to setting up accessibility tests. These tools catch issues which would be very time-consuming and tedious to do manually all the time.

It’s also possible to write unit tests for keyboard navigation in Javascript. For example, you could write a test for pressing the enter key while focused on a button, in addition to one for clicking it.

Use semantic HTML as much as possible. A huge number of issues on the web today would be solved if we used <button> instead of <div> when we want the behavior of a button. (Seriously, folks, stop doing this!!!) However, these types of issues are more likely to be caught via manual review than via automated testing, so...

Quality Analysts

Conduct manual reviews. The reality is not every accessibility issue can be caught with automation. You will need to do some manual testing with the keyboard and with a screen reader (e.g., VoiceOver on Mac) to ensure the WCAG guidelines are met. If you have access to someone who regularly makes use of a screen reader, that’s ideal, but that shouldn’t stop the team from gaining familiarity with how screen readers work. Note that different screen readers have slightly different behaviors, so it’s important to understand which ones your users are relying on. Tota11y is another favorite tool that can help educate team members about accessibility issues while doing manual reviews.

You know enough to get started today

I, too, once had the feeling that implementing accessibility sounded really hard and ambiguous, until I realized that most people already have the skills they need to resolve the vast majority of accessibility issues. I make it my personal mission to demystify this topic for the teams that I work with, and eagerly look for opportunities to learn more. If you’re on a team that doesn’t have the first clue what to do when it comes to designing for accessibility, I hope the tactics I’ve described can help you to take action and start your learning journey.