As part of the Design Thinking workshop, I bring up the importance of thinking about what is at stake for people with disabilities who can’t use our applications.

This doesn’t only apply to things like online banking or medical sites. No matter what type of content your site includes, interaction and content issues need to be addressed. It might be through development or design, or even at the broader product level. It’s important to test and review your work objectively.

You can also apply this approach to websites you didn’t build– especially when they belong to organizations or products you love.

The website for Seattle-based nonprofit radio station KEXP is one example I used in a live workshop.

I love music and consider KEXP to be an international treasure, but their site has some pretty rough accessibility issues.

As part of a live workshop, I did an accessibility review of 

 with some of the same manual testing and DevTools inspection techniques I use all the time in my work. While I inspected the site, I kept a running commentary on both of the technical and human sides of the accessibility equation.

9 minute long video to testingaccessibility.com

 and it’s available to watch now with captions and a full transcript.

Like other sites, I’ve submitted issues I found to KEXP in the past but they haven’t been fixed yet. When providing feedback I gave suggestions on how to fix the problems their importance for disabled listeners. I know they have limited resources… but it’s still a shame.

Sometimes there’s a tendency for people to make excuses for an organization because “they’re a nonprofit” or “it’s just a music website” but the reality is these types of issues are present in all kinds of websites all across the internet. Inaccessibility really gets old when you’re trying to browse the web and take part in a cultured society along with everyone else.

The steps I take in the video are a great starting point for manual accessibility testing. I encourage you to follow my lead and go test one of your favorite sites. Reach out to them with what you find. Who knows–with encouragement, maybe they’ll take steps toward a more accessible web. (I’ve seen it happen before, and I will again!)

Watch as Marcy Sutton uses manual testing and DevTools to identify accessibility issues as part of a live Testing Accessibility workshop.

I love music and consider the radio station KEXP to be an international treasure, but their site has some pretty rough accessibility issues. Watch me do some live testing on their site using some of the same manual testing and DevTools techniques I use in my work.

Watch my Live Accessibility Review of KEXP.org

I’ve gotten a few questions about whether Testing Accessibility could be useful for accessibility certification training, such as the IAAP Web Accessibility Specialist (WAS) certification. To answer the question in a central place, I wanted to share some thoughts on this including my own approach to accessibility certification.

First and foremost, Testing Accessibility was not created as a training resource for certification specifically. There are other training offerings which could meet this need but I haven’t reviewed them myself. I have instead focused on creating general accessibility training based on my years of experience as a software engineer, public speaker, and workshop trainer specializing in web accessibility.

The topics covered in Testing Accessibility include things that have come up repeatedly in my career that I felt people learning about accessibility should know. There is likely some overlap with curricula intended for certification training but this would be more coincidental than intentional.

And here’s why: I am not accessibility certified by choice. These certs became available long after I’d worked in the field as an accessibility engineer, so personally I didn’t feel like it was necessary to advance in my career. I’ve worked in the field long enough that I haven’t needed to–and my trainings and talks have also counted toward IAAP continuing education credit in the past.

There are many opinions surrounding accessibility certification. This 

I had to laugh today.
I was told I was not an expert in #accessibility. I'd be fine with someone's opinion but WHY they had that opinion that left me baffled.
Their take: not being CPACC/WAS certified must mean I couldn't pass the exam. Therefore shouldn't give #a11y advice.

I am with Julianna on this one, in that certification is not a requirement to be an expert or to give accessibility advice. It can certainly help, but it isn’t a requirement.

Still, certification can provide a pathway to learn more about accessibility in ways that can advance one’s career and it can be a good move for some. Certification also shouldn’t be discounted as a valuable tool for folks in underrepresented groups who might benefit from credentials and the associated experience.

The choice of whether to get certified for accessibility is a personal one–and ultimately, it’s up to each of us to decide. My goal as a trainer is to teach you how to level up with accessibility in development, design, and the related people skills so collectively we can make the web a more accessible place. If certification also fits into your path, I say go for it since we need all the help we can get from individuals like yourself when it comes to accessibility.

How does training from the Testing Accessibility workshops compare to IAAP Web Accessibility Specialist (WAS) certification? 

People have asked Testing Accessibility could be useful for accessibility certification training, such as the IAAP Web Accessibility Specialist (WAS) certification. To answer the question in a central place, I wanted to share some thoughts on this including my own approach to accessibility certification.

Thoughts on Accessibility Certification

Screen readers are among the most misunderstood topics I’ve encountered in my work.

Who uses screen readers, which ones they use, and how screen readers work all have their own misconceptions. There is even the misconception that screen readers are the only important thing 

Let’s try to clear things up a bit with some help from 

In addition to hosting an accessibility-focused 

, WebAIM has been regularly conducting screen reader user surveys since 2009. The information I share comes from my industry experience as well as the data from 

The first thing to address is the question of who screen reader users are. While it does track that screen reader users tend to be blind or otherwise visually-impaired, it is a generalization to say that it’s 

 that demographic. The WebAIM numbers show that almost 14% of respondents did not select blindness or low vision/visually-impaired when filling out the survey. It’s true that the survey showed 80% reporting these options, but still, 14% isn’t nothing.


I am often asked if screen reader testing with VoiceOver is good enough.

This is one of those questions where I think that any step toward a more accessible web is a good one, so I think testing with VoiceOver is good to do. In the Testing Accessibility workshops we use VoiceOver a number of times.

That said, if posing “Is VoiceOver good enough?” as a yes or no question, my answer is no.

WebAIM’s survey numbers clear up this misconception.

Only 6.5% of survey respondents report VoiceOver as their primary screen reader. Compare this to 30.7% with the free 

 for Windows (which we also use in the workshops). The most popular primary screen reader is 

, a commercial product with various license options.

But just because only 6.5% say VoiceOver is their primary doesn’t mean you should ignore it. When WebAIM changes the question from “primary screen reader” to “commonly used screen reader,” the number jumps to 41.3%.

The numbers for mobile tell a different story, though. Over 70% of survey respondents report using VoiceOver on iOS devices as their primary mobile screen reader!


Finally, there’s a misconception of how a screen reader is actually used. You don’t need to make every piece of content keyboard-interactive to read it aloud.

Screen readers offer the user the ability to quickly move around the page to find content they’re interested in— provided that the developers wrote proper markup.

The WebAIM survey results show importance of proper heading levels. Over 67% use headings as their primary means of navigating a page, and over 85% view them as at least “somewhat” useful.

One survey result I found surprising (along with the authors, based on their comments) was about navigating using landmarks/regions on pages. More people responded with “seldom”, or “never” than “whenever they’re available” or “often”. The authors note that the use of landmarks for navigation has been steadily declining over the years. They posit that this is either because screen readers are getting better at using other mechanisms, or that developers aren’t using them properly or frequently enough. Landmarks can play a role in meeting 

WCAG criteria related to identifying & grouping content

 and are considered to be a best practice in the accessibility community. I use them in my work, as well as in the Testing Accessibility workshops.

Screen readers can seem a bit mysterious or confusing, but like anything else it takes a bit of learning and practice. I started to become more comfortable with screen readers by iteratively testing as I made changes and referencing command cheat sheets. Check what the screen reader says before a change, make the change, test again.

This is the approach we take throughout the Testing Accessibility workshops. We go beyond the basics of landmarks and heading levels, and move into more complex interactions with components like date pickers. You won’t only build experience in structuring your application to best support a screen reader, but you’ll build compassion through experiencing an overzealous screen reader.

You’ll also learn the benefit of working with people who rely on screen readers full time. Because what might seem like a poor experience to you could be absolutely fine to someone else with a vision disability. Or the other way around: what seems acceptable to you could be a hot mess to a person who relies on Assistive Technology. It’s all about learning and keeping an open mind!

Who uses screen readers, which ones they use, and how screen readers work all have their own misconceptions. 

Screen Reader Myths and Misconceptions

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.


An accessibility audit is a similar sort of thing. When someone audits a web application, they are looking for every single violation of the Web Content Accessibility Guidelines or other standards. Any violations are classified and compiled into an in-depth report or spreadsheet, which can then be used in legal proceedings should the need arise.


Who does the fixing, or “remediation” as we say, might change depending on the situation. Sometimes an internal development team will be responsible for remediation — also known as implementation. Other times the company who performed the audit will take care of remediation as well.


There are several “Web Accessibility Audit Service Providers” that are a quick search away. I also can’t stress enough how important it is to prioritize accessibility companies that are owned and operated by people with disabilities.


When it comes to increasing accessibility adoption in the tech industry, we need all the help we can get. The testing approach that I follow and teach allows for anyone to make an impact– not only those with a precise attention to detail meeting the needs of a professional audit. My goal is to teach you a process that prevents common accessibility issues from making it to production. With the number of inaccessible sites and apps out there, I believe we can improve the state of the digital world with collective curiosity and effort.


As long as you’re thinking about user impact for disability and acting on accessibility with the belief that it matters, you’re on the right track. Regular testing uncovers low hanging fruit that can be quick to fix as well the more nuanced issues. You might also try getting through to colleagues by embracing more candid descriptions of how horrible an inaccessible interaction is. “Hot garbage for a person with limited mobility” comes to mind! 😜


There’s a lot of crossover between the techniques, tools, and resources involved in determining the accessibility of a web application. In Testing Accessibility, you’ll learn my favorites and how I use them in my consulting work, along with techniques for remediating the issues you identify. We’ll also explore the psychology of winning over stakeholders, as often the friction preventing accessibility from being successful stems from people rather than code.


Whether your organization chooses to engage with a third party auditing service or invest in bringing the skillset in-house, at the end of the day you’re taking another step toward an accessible web.


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

It's not just semantics! There's a difference between testing and auditing.

Accessibility Testing vs. Accessibility Auditing

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

Being prepared might help you get buy-in to focus on testing.

Alleviating a common testing struggle

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)

How to get from "Nothing" to "Just Right"

Where are you on the accessibility testing continuum?

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

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.

My story about what made the importance of accessibility "click".

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

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 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

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 start with 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.

 region apart from another (because you'll likely have multiple), include an 

 attribute to specify the purpose of that particular landmark.

These attributes create something called an 

 for an element that is relevant in Assistive Technologies. Other elements that need accessible names exposed include links, form controls with labels, and buttons. This also applies to icon buttons, which aren't fully functional when only a visual icon is present. What does that vague, custom icon represent? Who knows!?

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

Accessibility Articles

Watch my Live Accessibility Review of KEXP.org

Thoughts on Accessibility Certification

Screen Reader Myths and Misconceptions

Accessibility Testing vs. Accessibility Auditing

Alleviating a common testing struggle

Where are you on the accessibility testing continuum?

Now is the Best Time to Start

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

Accessibility-focused Test Driven Development

The Implications of Client-Side Routing

The Importance of Accessible Naming

My First Step in Manual Testing

The Overlap of Screen Readers and Keyboard

Programmatic Accessibility and the Rules of ARIA

Unit Testing for Accessibility

My Accessibility Testing Order of Operations