Originally posted on a11ywithlindsey.com
Hi friends! It’s been a hot minute since I wrote a blog post. If you follow me on Twitter, you know that I took a very strategic break in March to work on getting ahead of things. So now I am up and running, and I asked some followers what they wanted me to write next.
It sounded like people were curious about my web accessibility testing approach! So I’m going to walk you through my thought process, what I test for, how early I check, and how I test. It's like having my web accessibility testing checklist in your back pocket.
Getting started
My web accessibility testing process begins before I even start writing code. Hopefully, I wasn’t siloed away from the designer and had input in design decisions. Even if I didn’t have input, I start looking at the design and how I can ensure that everything is accessible.
I take a look at the design and assess any potential accessibility issues. For example, if I am looking at the design of my site below:
I’ll start mentally thinking about how I will lay this out in the markup.
- The "Blog" page title will be an
<h1> - The date will be a
<time> - The blog post titles will have
<h2>links - All the blog teasers will be inside of a
<main>tag
I won’t go further into how I interpret a design because that could be a long post on its own. But thinking through semantic markup is an essential part of my process, and I didn’t want to neglect it. Starting with a good HTML foundation helps tremendously with the testing process.
Running the site through Wave
While I am working, I usually run my website through the WebAIM Wave tool. I will take a peek at it every time I build something new. Using the Wave tool extension works well on my local environments when I want to get a sense of where my issues are. Through this exercise, I learned that I have some redundant links.
Redundant links are something I should address as a web accessibility blogger. I should have fixed this before, but I am leaving it here for the sake of transparency and learning. I may have corrected this by the time I have posted, but the screenshots will still be here.
As you can see here, I have 0 errors (yay) and 18 alerts for redundant links. Alerts are a lower priority than errors, but because I don’t have any errors, I am going to focus on fixing those. What I would do here is create a pull request and fix those up. The thing I enjoy about the Wave tool is that it tells you why it’s important and how to fix the issue.
Some people also use the Lighthouse tools on Google Chrome! I love Lighthouse too, but I tend to use those on live sites as an accessibility auditing tool versus testing as I am building.
Assess the contrast
The Wave tool that I mentioned above has a contrast checker.
Usually, I have already tested the color combinations that the designer gave me. However, when I receive a style guide with a few colors, sometimes I will implement it without double checking. We are all guilty of this sometimes because we are human. When I first launched this site, there was a contrast issue I missed. On the color of the date element it used to be #D73C13, and now it’s #C03711. I didn’t follow my designer’s suggestions and put the original color on my background, which is #F3E9EA.
Someone kindly pointed out to me that I had some color contrast issues. Once I stopped feeling embarrassed, I used WebAIM's contrast checker to assess it. I fixed this quickly by using the “Lightness” input to make the vermillion darker. I adjusted the color until I received passing marks on the contrast checker.
Tab through my site
I always click on the URL of the browser and press the tab key. We want to ensure that we are still aware of where the focus is. We want to be able to access controls to help us view content. We want to be mindful of anything that requires any interaction.
Here are some examples of problems I've dealt with
- Having a closed hamburger menu and being able to tab to the links inside it. This situation is confusing for a keyboard user as they are not confident what links they are focusing on.
- In desktop view, a user is unable to open a hamburger menu with their keyboard.
- Going to an e-commerce site and seeing a “Related Item” slideshow and being unable to use the arrows.
- Using the "Login" button that pops up a modal, and the focus is still "behind" the modal and cannot reach the form.
Approaching these challenges is a great way to improve your JavaScript skills! I learned a ton about JavaScript this way. I needed the tabIndex property to be -1 when the links were non-visible. Furthermore, I will use an event listener to toggle the tabIndex to 0 when we toggle open a menu. We can also ensure that the product slider arrows are buttons so that they work on click events! I talk about using semantic buttons in my previous post about 3 Simple Tips to Improve Keyboard Accessibility. If you want to see a demo of this and have an Egghead PRO account, I demonstrate this in my
Use Semantic HTML to Improve Hamburger Menu Accessibility lesson.
Screenreader testing
Screen reader testing is the trickiest part for me. I am visually-abled, hence do not truly understand how hard it can be.
However, running through a screen reader has been key to helping me find issues I didn’t realize existed. Recently I found a problem in a bar chart data visualization where I had a number formatted “110k.” I feel like this would be better read as “110 thousand.”
Something I still am working on is learning how to use a screen reader better. I use primarily VoiceOver, which is the screen reader for Mac. I've been using Web Aim's VoiceOver guide to help me improve my screen reader usage. I usually keep it up while I am testing in case I forget a command. One major thing to remember is that most guides say "VO" as a shortcut. "VO" is the equivalent to control + option on your Mac.
Conclusion
This post is getting a bit long because I wanted to ensure that I go through what I do on my personal projects. I want to do a follow-up post about Continuous Integration, all the testing libraries, and how I use react-testing-library for my integration tests. The reality is that most of us are working on teams and we need some automation built into the workflow. That post is coming soon! Stay tuned!
Feel free to let me know what you think on Twitter. If you're interested in hearing more content from me subscribe to my newsletter (unsubscribe, anytime)
Top comments (10)
This is amazing; thank you.
It's one thing to hear from an accessibility expert, "Here are the top 5 things you should build in."
But it's another great way to remember when you hear from an accessibility expert, "Here are the top 5 things I dummy-check when I'm building."
Haha of course! I am human, abled and imperfect. I need to ensure that I am following best practices as well!
I didn't know Wave was such a useful tool for finding accessibility issues for sites running locally, I'll definitely be using that more in the future!
I have found lots of bugs just by trying to do the same basic tasks with only a keyboard, which was helpful and surprising since they seem obvious the second I find them. Thankfully like many a11y issues, the fixes weren't that tough and were mostly adjustments to the DOM and semantic HTML elements. ...Except for modal focus issues, those still haunt my dreams.
Great piece, and I think some in-depth looks at testing for keyboard and screen reader usage would be some great follow-ups. I'd especially be interested in the Screen Reader one, since despite testing with it many times I get the feeling there's many ways to use it I'm overlooking.
Thank you, Max! That's a great idea!
Yeah, I actually might want to partner with a screen reader user for that to make sure I know how they actually navigate it. I don't want to make so many assumptions as someone who is able bodied.
Yeah, I've often done the same when it comes to screen reader testing. I'm still unfamiliar with it in many ways, so there's likely different approaches or tricks to using it I don't know of but should likely take into account.
I think Smashing Magazine had an article with footage of a regular screen reader user, but I've never gotten around to watching it unfortunately. Here's the link: smashingmagazine.com/2019/02/acces...
Oh, this is a good thing for me to read! Thank you!
This is great. I am always happy to find new tools. Do you use axe as well? It seems like the wave tool you mentioned covers a lot of the same errors from what I can tell. :thinking_face:
If I recall correctly, aXe is built into Google Chrome Lighthouse! So by default, yes. I have an emotional attachment to Wave because it was the first tool I used and also really helped me learn accessibility!
Something that I really want to explore in a future post is an evaluation of the automated testing tools. I believe that aXe has a CLI tool that I want to try out!
Excellent post Lindsey, very approachable and practical.
Thank you, Kyle!