When I was an intern I got my first accessibility audit back from a 3rd-party auditor. It listed out issues with the website I was working on and provided recommendations on how to make my code more accessible.  Then when it came to future features, I would copy-paste the same techniques to other parts of my code, but I wouldn't fully understanding why or when those techniques were needed.

Since then I've learned how much context I was missing around users and how they actually use and experience the web, part of that context being how to accurately test my work.  So let's talk about how we can check for accessibility!

Yay! Yes! Tools!  Gotta love it when you can just run testing software that tells you what's wrong with your code.  

 can be run by anyone and will scan a page and produce a list of code-level issues such as if an 

 tag, an invalid value has been passed to an ARIA attribute, and if an element has no programmatic text. There are also linters like the 

Automated testing tools are super easy to include into your development workflow and a quick way to learn about common issues and fixes.  However, while automated tools are great for correcting your implementations, they won't necessarily alert to when a feature needs some extra a11y love.  That's because automated tools don't necessarily know what it is that you're trying to achieve.  For example, there are certain ARIA attributes that a toggle button needs to be made accessible to all, but automated tools don't know that you're trying to build a toggle button, so it won't tell you what you're missing.  But 

 know.  And that's where manual testing comes in.

Manual testing is something we do all the time.  We interact with a feature or component and see if it does what we expect it to do.  But as mentioned in my post on 

the different ways people navigate the web

, there are so many different tools and methods that people use to interact with our websites and apps.  So 

 we should be testing our work with as many assistive technologies (ATs) as we can get our hands on, right?! Wrong. Since most ATs consume and make standard calls to the same accessibility APIs, we can usually say that if it works with one AT, it'll work for most others.  So we can easily cover most cases by testing with a few tools we likely already have at our disposal.

A lot of us are used to using a mouse to point and click our way through the web, but that's hard to do for users who have trouble seeing where elements are on a page, or even users who have difficulties with the minute movements a mouse can require.  Instead users should have the option to navigate solely with a keyboard.  When navigating with a keyboard, it's typical to scroll via Arrow keys, navigate to interactive elements using the Tab key (and Shift+Tab to reverse it), activate buttons with the Enter or Space keys (for link elements, only the Enter key is used), and use the Esc key to close menus, modals, etc.  The 

 is a great reference for how users expect to interact on a per component basis using a keyboard (and also a great place to view accessible versions of common components). During testing, you'll want to ask yourself the following:

Honestly, if at any point you're trying to use a keyboard and you get frustrated, it's a good indicator that your user will get frustrated as well. 

This is the most common tool used when navigating the web, but it's often overlooked how much we use the keyboard as well.  Most people without disabilities are hybrid users and will seamlessly switch between mouse and keyboard.  Just as there are those who only use keyboards, there are those who rely solely on "point and click" methodology.  

 is a popular speech recognition software that allows users to navigate via dictation, and the most preferred method of interaction is "saying and clicking" (check out this 

 if you need visualizations).  When, say, a quick search form in the header is only submittable by pressing the Enter key, it becomes harder for these users to perform the desired functionality.  We also want to keep in mind target size.  We don't all have the steady hand of a surgeon, so the general rule is to make sure that all interactive elements have a width of at least 44 pixels. Other than that, there aren't too many out of the ordinary things to test for with a mouse, but if you're looking for more rules like the keyboard list from earlier or you deal with crazy custom interactive components, you can check out the 

 section in the WCAG 2.1 for related rules.

Making sure that your website or app is resizable and customizable ensures that users with low vision can use your product.  Honestly this is a pretty big one considering people with low vision tend to be those who are older or even those who have lost their glasses to the sea while swimming at the beach after an earthquake...anyway, it's just to say that this helps more people than we think.  Users with uncorrectable low vision might use magnification software such as 

, which comes with a bunch of features like zooming in 200x, and enlarging text of webpages and apps.  We can check if our products will respond correctly in a few ways:

tl;dr Resize your browser window, zoom in 200%, and resize your text.  That's it.  That's how you test.  If anything looks wonky or unreadable, then it probably needs some fixing!

Okay.  So if you need one take away from this blog, it should be that you should 

 on your website.  It'll cover keyboard functionality and text-to-[insert preferred sense here] accessibility, which will pretty much cover 90% of your issues (I put a random percentile in there for the drama.  Please don't quote me!).

A screen reader is software a user can use to translate written text on a page to audible speech.  But it's not just the visible written text that it can announce.  If a website or app is marked up correctly, screen readers will announce 3 important pieces of information:

If you're testing with a screen reader and you don't hear those three things (save for exceptions noted earlier), then it's a good indication that you have an accessibility issue to log.  A lot of the success criteria of the WCAG relate to these three pieces of information being accessible, and if it works with one screen reader, it's likely to work with a majority of other ATs.

If you're on a Mac, the Voice Over screen reader is already installed and you can start using it right away.  For Windows or other OS's, popular screen readers are JAWS (subscription based) and NVDA (free and open-sourced). When using one of these screen readers, it's important to make sure you're testing with proper screen reader/browser pairings.   Based on the most recent 

, you should test your desktop sites with at least one of the following:

Just as Voice Over is available on Macs out of the box, it's also available on iPhones, and even most Androids come with preinstalled with TalkBack:

You'll want to test with the most popular pairings to determine if any bugs are implementation issues or compatibility issues, as it's often the case to report a bug with the AT for compatibility issues instead of trying to find a workaround on your end.

I would say that what we've covered so far will catch most accessibility issues.  If you're doing dedicated accessibility testing, there are a few other methods you could use to get more coverage.

This is actually a pretty big thing to test for, but I'm putting it in this section because it only applies to when you have animations, videos, or movement in general on your website or app.  Users with certain cognitive disabilities may have trouble using a product that has distracting movement and content on the site, and those who use a screen reader will have difficulty hearing if there's any audio content that plays automatically.  To help with this, pretty much all 

operating systems come with a way to reduce or turn off motion on their device

, and if implemented correctly, will also apply to websites and apps.

When it comes to animations, videos, and audio, make sure to check the following:

Windows users have a control setting called "High Contrast Mode" that enables them to set a sort of theme for their display.  They have the ability to decide what the color of their background, buttons, links, static text, selected text, and disabled elements.  This setting helps users with low vision and photosensitivity by allowing them to choose their own color scheme and set contrast levels of their preference.  Since essentially this mode overrides the CSS of apps and websites, it's useful to check to make sure that no meaningful content is loss.  

 is a subscription based testing tool that emulates many of the popular software-based ATs, and it has a good description of 

Phew!  That was a lot, and maybe even more information than you wanted.  But I swear: understanding what the issues are and how to reproduce them will help you understand the best approach towards fixing them.  Or even just helps you know what to search for.  Like "how to reduce motion based on user settings," ya know?  But if not, I'll talk about the most common accessibility issues on websites and how to fix them in another post.  For now, thanks for reading!

* You might be wondering if you should care about an AAA guideline when often websites only try to meet AA guidelines.  The answer is "yes," though they are more often considered as "best practices" to help provide an even better experience for users.  It might be helpful to think of conformance levels in this way: A = minimum needed to unblock users from using your site; AA = minimum needed to prevent users from rage quitting your site; AAA = minimum needed to provide a decent experience for users. It should be noted that it's near impossible to meet all AAA guidelines, as some actually may conflict with legacy systems, modern designs, and security practices.  So it's best to consider them as "best practice" and do what you can.

** I know y'all are itchin' to see some code and learn how to implement this, but that'll be in another post.  Look at how much text is already on this page!!

Learn about the tools you can use to check if a website is accessible to a variety of users

#testing.

How to Test for Web Accessibility