Get started with accessibility: A primer based on experience

Accessibility is my passion (and increasingly my expertise). It has been since my time at the short-lived start up Editorially, where accessibility was a priority in the building of the application. Ethan Marcotte, co-founder, built the front end with it in mind, and everyone on the team cared about accessibility. Thanks to the entire team’s efforts, we received an email from a person who used assistive technology thanking us for making a product they could use. That email stayed with me.

From that moment, making the web usable for all people in all circumstances became a focus of my professional development. I’m still learning, and accessibility is a constantly evolving field. Still, I’ve developed some insights and methods along my journey and want to share them with you now. If you do even a little bit of the following, you’re doing more than most.

What is accessibility?

First, a definition: to me, accessibility is making it so anyone can access the content and information in your site or application no matter how they’re trying to get it and no matter who they are.

Accessibility is much bigger than screen readers, although they’re certainly a part of it. It’s also about all the other ways in which your content could be difficult for someone to see and consume. Color combinations and contrast are one part of it. Ability to use a keyboard is another. Can the user stop motion that bothers them or induces illness? Are animations at a speed that won’t create problems for some users? How fast is the web connection, and does your site work when it’s slow?

The Gov.uk team has a great post that outlines their take on accessibility, and I love how they talk about excluding no one. As you learn more about accessibility, you keep realizing that not everyone approaches the web the way you do. And that’s what’s at the heart of this work: the less you assume about your users, the better.

Accessibility is a team effort

Because different aspects of accessibility work fall under the purview of different team members, it helps to have everyone working toward that goal.

Last winter I worked on a team where accessibility was a top priority from management on down. That meant design was thinking about it. Developers were thinking about it. We had the application tested for accessibility. Every team member cared, and if they didn’t know how to do something, they asked for help. The application may not have been perfect upon launch, but it was so much better than it would’ve been had the entire team not cared.

Other times I’ve worked with teams where I had to cajole others into caring about things like color or Javascript usage, sometimes with little success. On those projects, my nagging efforts made only a small dent, but even that dent was better than nothing.

If you are in a position to do so, you can start making dents, too. Slowly get your team on board by asking questions. Help them learn or become aware of the needs of others. This will only strengthen the team’s work and skills over time, making accessibility a natural and normal part of their thought process.

Questions to ask to get more accessible

I have a bunch of questions that I ask to push myself—and team members—to think differently, to stop assumptions. I will never be able to use the web exactly the same way as someone with different abilities, but these questions at least help me start thinking about others’ contexts.

What are the different ways in which people will be using the site or application?

They may be on high-speed connections on a big desktop monitor, or maybe they’re using Voice Over on their iOS device. Maybe they’re on an older Android device with a slower connection. Maybe they have a large monitor, but a slower connection and the monitor is not the best quality, so color contrast matters. You get the idea.

There are many ways a person may be accessing your application, and I’ve found it helpful to make a list of different combinations I might incorporate into my testing.

Are there limitations inherent in the tools the team is using, making it harder to make the site accessible?

If you’re using a framework, does that make it easier or harder to do the necessary accessibility work in the code? Is anyone actively working to make the framework more accessible? There are so many wonderful people in our community who have put hours and hours into making commonly used JavaScript frameworks—such as React or Angular—more accessible. The same goes for the CMS and its output, looking into how these things inherently work will help you understand the work that needs to be done.

Has any user research been done that would be helpful as I work?

Previous user research can be helpful, but I don’t assume that every user is the same or that the research has sussed out all the possible ways a person may come to the application. What’s most important to me as I work is not to assume.

Accessibility considerations

Whenever I’m starting something new or evaluating an existing project, I look for the following elements first:

• Semantic HTML. Is the final production code good clean HTML? No matter how you’re getting there, either via a CMS or using a framework, the output should be semantic and valid so you can ensure a good document outline.
• ARIA. Is ARIA being used properly? This means using it for major landmarks but also not using it too much. I like the checklist at the A11Y Project as a good starting point.
• Keyboard navigation. Can the site be navigated with only the keyboard? People shouldn’t have to use a mouse to get around, and the order and flow should make sense.
• Color. Is the color contrast good enough for all users, and can a person with color blindness still get all the information from the site?
• Performance. While this isn’t always lumped into accessibility, I think it’s an accessibility issue because people on slow connections should also be able to get to your site and use it.

I’ll go into each of these in more depth in upcoming posts, but this should give you something to think about.

Test your work

A lot of what I’ve learned has been through testing my work to see how it operates in various circumstances. Testing reveals a great deal about how others use the web, as well as how you can improve your work.

Just as there isn’t infinite time to test in every browser, there probably isn’t infinite time to test in every assistive tech/device combination. Pick a few to start. Get used to what it’s like to use your site with, for example, VoiceOver on your iOS device or on your Mac. If you have a windows machine, NVDA is free. You can install that and test away. For keyboard users, try using your site without a mouse. Can you do it? Where are the hangups, and what could be improved? If you’re using a lot of color, be sure and test it in grayscale in addition to one of the screen reader tools.

If you want to learn more about how screen readers interact with browsers and pairings, people write about that.

Resources

Speaking of great resources, here are some places where I’ve learned a lot over the years.

First up is the WebAIM email discussion list. I know, email is so last decade, but it’s oh so good for following conversations about how to do tricky and hard things in the accessibility world. What I love about this list is that there are several users on it who use assistive technology when browsing the web, and their feedback and ideas are invaluable. What we assume when we do our work may not be true, and I’ve been set straight many a time when reading through responses on this list.

Next up, keep up with Heydon Pickering’s site, Inclusive Components. His articles take one component and break it down with a lot of examples and ideas for how to make something accessible. What I really love about them is that they show many ways to do a thing, so you can decide what works best for your situation and your site. There may be a better way—or you may have limitations that Pickering doesn’t—but there are lots of ideas here.

Then do some in-depth reading. These three books have helped me understand accessibility more deeply, and they’re all written by authors with deep knowledge on the subject:

Accessibility for Everyone by Laura Kalbag is a quick read and wonderful introduction to the subject. Laura tackles both design and code and does so in a compact book that is packed with good information.

Inclusive Design Patterns by Heydon Pickering is, much like his site, a look at various patterns and how to make them accessible, it’s a great resource and complement to his site.

A Web for Everyone by Sarah Horton and  Whitney Queensbery takes you through design and UX to ensure that your flows work for everyone. This is focused more on design and usability, but the book includes interviews with users at the end of each chapter, which I loved. It also introduced me to a lot of people who are working in the accessibility world that I wasn’t aware of.

That feels like a lot, but accessibility is important and is too often tacked on to the end of a project or, even worse, retrofitted after the threat of a lawsuit. Once accessibility becomes part of how you build for the web, it doesn’t take you any longer. It merely changes your approach.

While changes to workflow can be difficult after years of always doing it one way, it’s worth it. It’s worth it when a user writes you an email to tell you you’ve done it. Maybe you didn’t do it perfectly, but they were able to use your application. This is why we do the work—because everyone deserves to be able to use the web and access it easily.

Do you want help thinking through accessibility more deeply? I’m available for continuing consultation or workshops with your team, get in touch!

Many thanks to Ethan Marcotte for tech editing this piece and to Meghan Seawell for helping my words shine with her editing skills.