When I perform accessibility testing for clients, I work in the same sequence that the Manual Accessibility Testing module is ordered in:

Make sure things are rendered in the browser as expected.

Try navigating the site with only my keyboard, taking note of what does and doesn't work.

Scan the page with various developer tools (

Test specifically for color contrast, including a spin through Windows High Contrast Mode.

Take note of how screen readers behave on Mac, Windows, and mobile devices.

Zoom in and out and watch for how content reacts.

Once I've got a list of things that need addressed from the user side of things, I start in on the code. I often start conversations with Creative/Design teams as well to prevent accessibility issues earlier in the software development lifecycle.

As I dive in to fix accessibility problems with code, I prioritize them based on user impact and the Web Content Accessibility Guidelines. I aim to fix things one viewport size at a time, though it's important to double check that changes in one place don't have an effect on others. This is where Automated Testing comes in, but that's a topic for another day.

A repeatable process for manually testing accessibility on a site using DevTools and the the browser.

My Accessibility Testing Order of Operations

Like most areas of web development, testing for accessibility can benefit from automation.

There are several different types of tests you can write, each with their own time and place to be most useful. Today we'll talk about the role of Unit Tests when testing accessibility.

Unit tests are concerned with small, isolated pieces of functionality that don't rely on things like API calls or other external services.

Often unit tests for accessibility will make sure that accessibility information makes it into the right place in a component for digesting in screen readers, or test internal interaction APIs.


Here's an example from Testing Accessibility that uses Jest and Testing Library to see if a button within a custom dropdown is properly labeled:

It's possible to make browser-based DOM assertions with unit tests, though the capabilities depend on the library you use.

One popular choice that I like to use is Testing Library because of the available queries and interaction events.

Here's another example with Testing Library that will fail if the dropdown button isn't a real button, but a div instead:


I like this toolset because your tests become a contract for accessible user interface components. If a button regresses into a non-focusable DIV like our above example, the test will fail since DIVs aren't reachable or operable by keyboard.

While there's a lot more that we can do with unit testing–I'll go into more depth in the full Testing Accessibility workshop series–there are plenty of scenarios that benefit from different, less isolated techniques.

Jest and Testing Library can be used to write unit tests that ensure accessibility information makes it into the right place in our components.

Unit Testing for Accessibility

One of the foundations of web development is writing an accessible, semantic structure in your pages and components. This is important for multiple reasons, primarily for exposing accessibility information for people using screen readers and other assistive technology.

Semantic structure has a cool benefit of making your page content more machine readable, and both HTML and ARIA have big parts to play in that.

What is programmatic accessibility information?

In Testing Accessibility, one of the areas we’ll dive into is programmatic accessibility information. Another way to phrase this is “programmatically determinable”.

According to our trusted resource the Web Content Accessibility Guidelines, 

Determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities.

​Determined in a markup language [such as HTML] from elements and attributes that are accessed directly by commonly available assistive technology.

Here is an example of programmatically determinable information in a page:

In the above example, the language of the page is set to English on the HTML element. When a screen reader reads the page aloud, the pronunciation changes when it gets to “Français” and “Español”. This is possible because of the programmatic information provided by the 

 attributes on the HTML tag and individual language links.

By using semantic HTML elements and attributes as well as ARIA roles, states, and properties, information can be easily extracted and presented in multiple ways. This includes screen reading software, voice navigation, and more. How cool is that??

Learn the rules of ARIA (Accessible Rich Internet Applications)

With budding knowledge of a tool like ARIA, it is imperative that I also teach you the rules of how and when to use it. This is because incorrect usage can make a page less accessible than if there was no ARIA at all.

I fell into this trap myself, early in my career! I used ARIA attributes that were poorly supported at the time and missed required attributes on related elements.

In Testing Accessibility, you'll learn the building blocks of ARIA and you’ll be more successful at plumbing accessibility information through HTML to Accessibility APIs and assistive technologies.

Programmatically determinable accessibility information benefits screen reader and other assistive technology users.



Programmatic Accessibility and the Rules of ARIA

One of my favorite parts of accessible web development is coding of interactive components. In a nutshell, any action a user can take with a mouse needs to be possible somehow using a keyboard and screen reader.

There are conventions to lean on as we code accessible interactions, such as managing keyboard focus and binding the Escape key with JavaScript as we manipulate components on the screen.

How screen readers overlap with keyboard access

If you only pay attention to JavaScript event mechanics and not the screen reading experience, even the most keyboard-accessible component will render as hot garbage!

While keyboard support is a foundational part of developing accessible interactions, it’s also important to know how ARIA factors in. Will a blind screen reader user know your toggle button has a menu associated with it, and whether it’s open or closed?

Here is a toggle button that could function fine with JavaScript but leave screen reader users confused about its state or purpose:

 function could effectively expose or hide the neighboring list of links for keyboard functionality. However, it has no initial accessibility information to indicate its state or hint at the presence of an associated element.

By including a couple of well-supported ARIA attributes as well as keyboard focus management, this little dropdown could be much more usable all-around:

We can use JavaScript to set aria-expanded to true when the dropdown opens so its state will be communicated in a screen reader. We can also send focus to the first link in the dropdown list when it opens, and bind the Escape key to close it and restore focus back to the toggle button.


This is just one example of the techniques you'll learn in the full Testing Accessibility workshop series!

We can use JavaScript to set aria-expanded to true when the dropdown opens so its state will be communicated in a screen reader

The Overlap of Screen Readers and Keyboard

It’s unfortunate how common it is for a web application to have a poor experience when using the keyboard.

Fortunately for us, there’s a quick way to gauge how keyboard-ready our websites and applications are:

It sounds deceptively simple, but it’s an incredibly useful way to audit an application to see how usable it is.

Once the page I’m testing has loaded, I’ll hit Tab and see what happens.

Does a skip link appear? Am I taken to a place on the page that makes sense? Can I do the same operations as mouse users?

If an element is highlighted, how is the color contrast? Using a tool like Colour Contrast Analyzer helps make sure it's acceptable.

What can be most telling is if nothing seems to happen at all.

As I Tab, I’ll look at the status bar in the lower left corner of my browser to see if link addresses are displayed. It’s very common for navigation menus to be visually hidden, but still have their menu items reachable with the keyboard when closed. This is problematic as it creates a poor experience.

When a menu isn’t visible, its interactive contents need to be hidden from keyboard and screen reader users with CSS 

 or a similar technique so that it isn’t reachable either. This sets up more of a 1-to-1 experience for mouse users and keyboard users alike. There are some other nuances around choosing proper semantic elements to ensure the menu can be understood and operated with screen readers, but ensuring individual items aren’t reachable via Tab when inactive is a big step in the right direction.

The Tab key is a quick way to gauge how keyboard-ready your websites and applications are.

My First Step in Manual Testing

As the joke goes, three of the hardest things in computer science are naming things and off-by-one errors. 🥁

While it can be tricky sometimes to think of good names for variables and components, there are some other considerations to take into account when it comes to accessible naming for identifying components in Assistive Technologies like screen readers.

One of the most important things you can do is use semantic HTML elements in your markup. Instead of going with 

s for everything, choose an element that includes an implicit role and behavior that matches your purpose. For example, 

 can give you an idea of what they do from reading their tag names. Similarly, using 

 instead of styling a different element provides accessibility information and functionality in the browser for “free” without using ARIA (Accessible Rich Internet Applications).

Just like “when all you have is a hammer, everything looks like a nail,” ARIA is a powerful tool that’s not always the right one to use. It can also sometimes make a real mess of a web application if not used correctly. It’s best to use ARIA for the components you create that are more complex than the available semantic elements alone, along with testing in Assistive Technologies to ensure a positive user experience.

There are many aspects of ARIA that can be safely and routinely utilized. Name and role are common, and there are also more specialized attributes. For example, in the workshop demo app I use the 

 state to inform screen readers that the custom mega menu component is opened or closed.

In Testing Accessibility, we get deeper into the “when” and “how” of ARIA best practices including hands-on practice coding and  writing real-world tests.

Use semantic HTML elements in your markup that include implicit roles and behavior that match your purpose.

The Importance of Accessible Naming

I saw a tweet recently from Heydon Pickering that offered commentary on a web development topic someone made on Reddit.

“Switch between two pages on the client side within a multi page website?”

“I have no idea but I feel like it should be easy. Trivial. Perhaps even built into browsers themselves. You could have an HTML element specifically for it. One starting with ‘a’ perhaps, so it is easy to find.”

While it is a bit snarky, it made me chuckle. There’s definitely truth to Heydon’s sentiment.

When you build a web application that uses client-side routing, you’re taking control of navigation away from HTML and the browser and giving it to a JavaScript component. This has implications for accessibility.

Screen readers rely on events like page title changes to announce that navigation has occurred. Since a JavaScript-rendered page change won’t refresh like a traditional HTML page, screen readers won’t automatically read out a title or document summary like they normally would.

If for some reason you must use client-side routing, using a library like React Helmet (or similar scripting functionality) to make changes to the document 

 when navigating with a JavaScript library helps in this regard. This can also give us something to write automated tests for, such as “it updated the page title” with Cypress.

Focus management for keyboard users is another problem. When a navigation event occurs, JavaScript can’t exactly recreate the HTML page refresh experience, which resets focus to the top of a page along with configurable screen reader announcements. Focus could be moved to the new content with JavaScript for keyboard ergonomics-sake. I did some research on this topic, which is often referenced by library authors and spec writers but the situation is still a bit of a mess.

If client-side routing libraries try to guess for us and move focus to the same place for every situation, it can lead to a sub-par experience. This is why libraries have largely punted on addressing accessibility in client-side routing. To solve this, we need routing APIs that allow us tap into navigation events and handle focus management and announcements gracefully.

I ran into this recently while building out the Mega Nav component for the Testing Accessibility demo application. When testing menu interactivity and navigation, I found that client-side navigation with Reach Router wasn’t properly resetting the menu state while simultaneously jumping focus too far down the page automatically. Adding some code to reset menu state was an easy enough fix, but APIs for managing focus left more to be desired. In this case, using the trusty <a> tag instead of a special <Link> component allowed the browser to take care of both issues itself.

While it depends on the type of application you’re building, my general suggestion for the moment is to let pages refresh if you can. Doing this ensures that the focus point is reset, and that Assistive Technology users aren’t left wondering if anything happened. This practice will still play nicely with the dynamic updates from React Helmet, too.

There are a lot of accessibility wins we can get for free from the HTML elements we choose and the browsers the render them. It’s just a matter of knowing what to look for.

Client side routing takes control of navigation away from HTML and the browser and gives it to a JavaScript component. This has implications for accessibility.

The Implications of Client-Side Routing

The Test-Driven Development process has a certain beauty in its simplicity:

Write a (failing) test. Write some code to make it pass. Ensure the test passes, then repeat for the next requirement.

Think about how the small pieces of your applications should behave for accessibility, then write tests to make sure they do.

 This helps keep us on track and saves us from breaking things later.

As the developer tooling ecosystem has evolved over the years, we are now able to write tests that go beyond business logic and into accessible user outcomes.

Testing Library is a fantastic tool for a web developer to become familiar with.

Using the Jest framework and utilities provided by Testing Library, we can write tests that ensure that elements are not only rendered to the DOM, but also that they properly 

support keyboards and Assistive Technologies

hitting the Tab key is my first accessibility test

With a little help from Testing Library’s 

 packages, we can write a test that renders a 

 component, and makes sure that it has focus after the Tab key is pressed.

 statement, we’d write something like this:

, we can be confident that the user will be able to tab over to the search button.

Another useful tool for testing at the component level is 

With this tool, we are able to write similar tests to our example above, but with the same API and add-on ecosystem that Cypress uses for integration & end-to-end testing. In addition, components are rendered to a real browser and include a UI for debugging test behavior.

No matter which of these tools you use, the TDD process for your accessible components is the same:

Write tests describing the behavior that fails accessibility requirements. 

Make the tests pass by fixing the accessibility problems in the component. To validate your approach, make sure to cross-check in a browser (and screen reader, where applicable). This will make your tests more solid and worthwhile.

Check that hidden items aren’t reachable by keyboard when they shouldn’t be, such as inside of a closed menu

Component props passed in for accessible names or other text content output the correct markup

Menus can be toggled open and closed with the keyboard

ARIA states and labels update when a combobox component is opened and items filtered

Accessibility-focused Test Driven Development

I got my first full-time development job at a Seattle design firm as the only in-house dev in 2009. I landed at a really cool boutique creative firm but software quality wasn’t the focus of what we built. As long as it looked amazing and told a compelling brand story, that was what they cared about. I was still super new to development and learned by copying the structure of other people’s stuff to figure out how it worked. This was back in the Flash and ActionScript days, with a lot of learning by “throwing code at it to see what sticks”. Needless to say, I didn’t know anything about accessibility.

My first real accessibility-focused work came a couple years later in 2011 when working at an agency who specialized in working with well-known companies and brands.

 over the accessibility of their website. And if Target was being held accountable, any agencies they hired were obligated as well.

This happened to be the first client account I was asked to lead.

I was super pumped for the opportunity and dove right in.

Back then, the dev tooling ecosystem wasn’t nearly as good as it is now. Some of the lessons were hard won as I learned about accessibility for the first time on the job. I was able to take what I learned about building accessible web applications that fulfilled legal & contractual requirements for Target and apply them to other projects, too. (It turns out companies like being confident in avoiding lawsuits!)

By far the thing that made accessibility really “click” for me was the connection I made with Target’s accessibility QA team.

As a developer it’s nice to be able to talk to someone who is testing your code to determine if it works or not. It becomes more profound when the person testing is directly impacted when it doesn’t work.

My buddy Steve from Target’s QA team was blind and used a screen reader to interact with web pages.

It’s one thing to write semantic markup that passes basic tests and “sounds okay” when announced in a screen reader. But being able to ask someone who relies on Assistive Technology for their honest perspective will have a way bigger impact.

Looking back, this was a pivotal moment in my accessibility journey.

We weren’t only making sites that fulfilled requirements for conformance. We were instead making sites that disabled people could use, including Target’s customers as well as Steve and his colleagues.

We weren’t only making sites that fulfilled requirements for conformance. We were instead making sites that disabled people could use.

What's your Accessibility Origin Story? Here's Mine.

As a whole, the current state of accessibility on the web still isn’t great.

New people continue to enter the industry as new technologies emerge. It’s vital that we teach best accessibility practices so that the applications of the future are accessible from the start.

If you’re an engineer tasked with making decisions about what technologies to use for a project, you need to do your due diligence. What are the constraints that come with a certain choice? What are its accessibility implications?

Of course, we don’t always have the luxury of working on greenfield projects (

I’ve consulted with a team that used HTML Canvas for a project that provided very limited options in terms of accessibility. It’s possible the team could have chosen a better solution when the project was greenfield, but we had to work with what we had.

No matter where you are in the state of your application, pair with colleagues to look closely at the source code of any frameworks or libraries you’re considering using. Look for markup anti-patterns like missing input labels or click events on divs. If you see these— run away! Or at least validate there is a documented, accessible way of doing things.

If the library you’re looking at provides a demo site or components, you may be able to manually test their examples from your browser to ensure they’re accessible before you get started.

Throughout the Testing Accessibility series, you will deepen your knowledge of accessibility and improving user experience outcomes. Writing semantic markup from scratch, coding interactivity that supports Assistive Technology, identifying & remediating issues… so much more.

But beyond that, you’ll come away with a deeper understanding of how to navigate trade-offs behind the architectural decisions you make. You’ll also learn how to communicate the importance of accessibility to stakeholders and other teams.

Accessibility has been important and it will continue to be important.

Now’s the best time to make it a focus.

As new people enter the industry. It’s vital that we teach best accessibility practices so that the applications of the future are accessible from the start.

Now is the Best Time to Start

There’s a continuum in accessibility testing:

At “Point A” there are no tests at all. No manual process, no automated test suite… nothing.


Then over at “Point B” is an application that’s got just the right amount of tests and process to validate the right things at the right time.


Let’s explore how you can get to point “B” no matter where you’re starting from.


As I’ve shared before, the very first step I take towards accessibility testing is to hit the Tab key.


Does your interactive application behave the way you expect? If the answer is no, you’ve got more to uncover. But you’ve now inched closer to our goal state and all you needed was a keyboard!


There are several testing tools that are must-haves on the journey.


Central to a number of accessibility tools is axe-core, a library I worked on at one point in my career (more on that some other time).

, which can catch issues in your code before you push them.

 powered by Axe that allow you to test all or part of any web page. I like the browser extension because you don’t have to be a developer to use it— anyone technical or curious enough to use a program like Excel is going to be able to run these tests.

If you’re building a web application with a JavaScript library like React or Vue, consider adding 

 to your project. This allows you to render your components in isolation from the rest of the app. You can render a button, a menu that uses those buttons, a page that includes that menu, and everything in between. Each Storybook Component Story you create can also be passed props to put it into a specific state. This is really nice for testing interactions with components like modals that might require a series of clicks to expose in the deployed app. Storybook also offers an 

 that checks for issues using (you guessed it) axe-core.


With some manual accessibility testing in place, let’s jump ahead to the halfway between point A and point B.


This is where the testing process gets more code heavy.

We’ll start with the introduction of unit testing. With this approach, you’ll want to make sure that the smallest individual parts of your code perform as expected.


To show how small a unit can be, the popular testing tool 

 provides an example in their docs that tests that two plus two is four.

But what does that have to do with accessibility?

Jest can be used to test the DOM with the help of 

 and its additional framework-specific libraries. We use 

 in the Testing Accessibility workshops but many libraries and tools are supported. This means we can not only ensure that components are rendered, but that they include proper ARIA attributes or accessibility-focused functionality we could check for in a browser.

 is a powerful tool that runs integration & end-to-end tests in a real browser instance. These types of tests are focused on making sure our different components play nicely together.


Cypress lets us mimic the way a user would click, type, and otherwise flow through our application at a higher level. Using Cypress, we can assert that many accessibility requirements function as we expect. There’s also a “Component Testing” flavor of Cypress that can be used similarly to Jest and Testing Library but with the same API as the full-featured Cypress. You’ll get hands-on experience with both in the Automated Testing workshop.


Our last step to reach the target is to introduce Continuous Integration (CI) into the mix. This is where we set up our automated test suites to run every time code is pushed. If a test doesn’t pass, the code isn’t pushed and we don’t deploy an inaccessible application to production. There are several different options for setting up CI but we use 

 in the Testing Accessibility workshops.


With robust functional tests and CI in place, you can potentially move from “no testing at all” over to a fully tested application. You now have some pointers on how to set your team up for accessibility success!

Of course, there’s a lot of nuance and practice that I’ve glossed over for now that you can explore deeper in the Testing Accessibility workshops. But there’s plenty of reading you can do from here.

Remember that accessibility isn’t just making sure that your markup includes the proper elements and attributes and roles. It’s more than having tests that pass, too. (”Testing the right thing” is a whole topic on its own!)


Throughout the software development lifecycle, you have to make sure to ask yourself “What impact does this have on people with disabilities?” Continuously challenge your biases while testing both your assumptions and your code.

Accessibility isn’t just adding markup with the proper elements and roles or having tests that pass. (”Testing the right thing” is a whole topic on its own)

Where are you on the accessibility testing continuum?

Most people would agree that identifying and fixing issues before they make their way to production is a better process than receiving complaints from Twitter (or worse— 

If you’re reading this, you recognize the importance of accessibility and the role that testing has in ensuring our applications are usable by all.

But there’s often still a struggle when it comes to accessibility testing.

One of the common sticking points I’ve seen is developers not being sure where testing would be most effective when their organizations largely don’t support it or care.

Here’s my advice on a process for prioritizing an area of your application to test.

. These are the things that would be really bad if they broke in production.

Write out the steps that a user would take to do a thing if they were using a mouse. Then do the same process for users interacting with the keyboard.

How does the user interact with the application–what actions can they take? What new data appears? What navigation takes place?

From there, turn these steps into a manual testing process that can be followed regardless of the team someone is on. This has the added benefit of getting other people in an organization involved & invested in the result.

Does the keyboard allow the user to move through a flow as expected? Do accessibility browser extensions report as expected?

Using a screen reader might be a bit ambitious for a new tester, as there is definitely a learning curve as it relates to user expectations. But it’s still worth considering.

Once you’re confident that multiple people on your team will be able to contribute to manual accessibility testing, move on to implementing automated tests.

For each step of a user flow, take stock of the individual components and elements involved.

Write unit test assertions against interactive controls, including inputs and buttons, to ensure they include proper labels and are operable per the 

. Check out the many useful techniques available for unit testing & integration testing for simulating user events like key presses and clicks.

While building a repeatable process in the “real world” isn’t always straightforward to implement, this general approach is my go-to as a first introduction to an accessibility testing flow.

We go deeper into the nuances around implementing testing processes and how to determine what to test when in the Testing Accessibility workshops.

One of the common sticking points I’ve seen is developers not being sure where testing would be most effective

Alleviating a common testing struggle

Despite having the bulk of my career focused on accessibility, I still don’t feel like an expert some of the time.


This isn’t me trying to be modest. Instead, it’s more of a reflection of how large the field of accessibility really is and how there will always be more to learn and discover.


If you’ve attended my workshops in the past, you might have noticed that I always say “testing” instead of “auditing”.

While it might seem like an exercise in semantics (pun intended), there is an intentional difference between the two that is worth pointing out.


My passion for accessibility grew out of my interest in web development.

I’m a web developer and trainer with an expertise in accessibility.


I test and develop user interfaces but I don’t produce accessibility audits for a living. (I also chose not to get an accessibility certification as I have enough experience in the field to not require it.)


To help clarify, let’s play a game of word association. The word “audit” can carry financial or tax related connotations. If someone is getting audited, there’s going to be a lot of paperwork that will be picked through very carefully.


There’s a lot of crossover between the techniques, tools, and resources involved in determining the accessibility of a web application. 

Accessibility Articles