I received a question from someone who was working through the Design Thinking & People Skills workshop and had a question about one of the challenges.

Note: this article has been updated for further clarification in regards to contrast ratios.

In the workshop, learners are presented with a screenshot of a form and asked to identify potential issues.

Here’s the Subscribe form from the challenge in question:

Here’s the explanation that was included as part of the original solution:

Even though the contrast ratio for the blue submit button fails to meet 4.5:1, it actually does pass WCAG for non-text contrast (at least 3:1). Keep in mind there is a different success criterion for user interface components and graphical objects than static text.

I received an emailed question prompted by this challenge:

While the word “subscribe” doesn’t pass AA as large or regular text, the solution says that text must meet 4.5:1, but I think without knowing the text size, we wouldn’t know if it should meet 3:1 or 4.5:1 (it looks like that text might be big enough to be “large”). I was also wondering if it’s true that text on a button doesn’t have to meet the 4.5:1 standard just because the button is a UI element? Or am I just misreading?

The person who sent me the email is right about font size being a factor in the “Subscribe” heading text and contrast ratios:

If the text is 18pt / 24 px or larger, it will count as “

” and only need to meet 3:1. Because our example comes from a design asset, we can’t exactly check the font size and verify. But we can provide advice to our design team about contrast requirements: for headings to pass 3:1, they need to be at least 24 px (or 19px bold, rounding up from 18.666px / 14pt). Since this heading has a ratio of 2.3:1, it doesn’t pass either 3:1 or 4.5:1.

For the submit button, it is indeed a user interface component. But the background color only needs to meet 3:1. As you pointed out, the text does need to meet 4.5:1 if the font size is less than 24px (18pt) or 19px bold. The font size wasn’t specified in this case either, so it was a bit ambiguous.

I’ll admit this is a case where WCAG can be confusing–at least it was for me. The Non-Text Contrast criterion (1.4.11) does mention leveraging the rationale for “large-text contrast” in Contrast minimum (1.4.3), which has the 3:1 ratio. But it wasn’t immediately clear that text inside of a user interface component would fall under the different success criterion. I suppose the answer should be obvious from the name: “non-text” applies to backgrounds, icons, and graphics. Text inside components has the other, previously established requirement that factors in font size and bolding. (But then there are also icon fonts, to make things more confusing.)

My original rationale was that the blue submit button is a single control, sitting on its own line with padding and a background color. Similar to headings, I reasoned that these components would stand out at a 3:1 ratio for all of their parts. However, a contrast ratio of 4.5:1 for the text inside of a button component would be more visible to people with low vision or an issue with color perception. It is also a requirement according to WCAG for smaller font sizes.

I think we can agree that the original contrast failed ratio requirements, regardless of how it gets updated. When coming up with a solution, it can help to talk through interpretations of WCAG as a team to make sure you have it right, as it’s easy to get mixed up.

WCAG is also a starting point when it comes to accessibility. Getting feedback from people with disabilities on design systems and pattern libraries with UI components is another great approach, as it’s typically an earlier part of the software development lifecycle.

I appreciate receiving questions like these, as well as the nudges to clarify further!

It’s always good to double-check and make sure things are accurate and we’re all on the same page.

Clarifying WCAG guidelines for color contrast and font size using an example from the Design Thinking & People Skills workshop from Testing Accessibility.

The Design Thinking & People Skills workshop has a challenge related to WCAG guidelines for contrast and font sizes. This article clarifies the solution in response to a learner's question.

Clarifying Color Contrast & Font Size Guidelines

workshops, it’s impactful to write UI tests from the perspective of users who only use the keyboard.

 tools you’re likely already familiar with, as shown in this example lifted from the course:

Adding more tests like this will help ensure your UI remains keyboard accessible as it continues to evolve.

But What About My Existing Click-based Tests?

Most of your existing tests will already be interacting with elements via 

. These tests may end up duplicating some of the setup and assertion code from your keyboard-only tests.

Over time, this could make the tests more difficult to maintain and extend.

So How Can I Cut Down on the Duplication?

One idea would be to factor out those duplicated pieces into shared code. But that could also make the tests harder to read and reason about.

A different idea comes from noticing that tests will mostly come in pairs. For every test like

Fill out the form, then find and click the submit button

Fill out the form, then navigate to the submit button using the keyboard and press Enter

Consolidate each matching pair of tests into a single, click-based test

Create a way to automatically replace clicks with equivalent keyboard actions (without modifying test code)

Run the test suite once in “click-based mode” and again in “keyboard-based mode”

That way, the setup and assertion code is only written once.

A “Keyboard Testing Library” To Tackle The Problem

Trying to implement that idea is how the 

 method on the library’s sole export ( 

Starting from the currently focused element, it performs a 

 through the DOM’s keyboard accessible elements. It uses 

 for pressing the tab, shift+tab, and arrow keys to systematically move between these elements.

If it finds the target element, it will stop and activate it. It uses 

If it can’t find the target element, it will throw an error.

Rewriting the example from the introduction, the calls to 

keyboardOnlyUserEvent.navigateToAndPressEnter


To enable switching between being click-based and keyboard-based, 

 depending on the presence of an environment variable:

This enables the test suite to run once without the environment variable set, executing the click-based versions of the tests. When it’s run again with the environment variable set, the keyboard-based versions of the tests will be executed.

Now every time someone writes a new click-based test, it will automatically be transformed into a keyboard-based test as well.

A huge caveat is that I have only gotten to try this out on some toy examples so far. So it’s still unclear to me if it will work smoothly in most cases.

With that in mind, my guess is that it will be best suited to component library tests, and least well suited to full page tests.

I originally thought of this idea at some point after hearing Marcy share her approach to the topic (now covered in the Testing Accessibility workshop series). Many thanks to her for that!

And thank you dear reader for coming this far! I hope this has been a helpful use of your time and spoons.

keyboard-testing-library by Grunet is an extension to Testing Library that allows you to reduce duplication when writing accessibility unit tests.

In this guest post, Grunet introduces keyboard-testing-library as a solution to cut down on duplicated code in your accessibility tests.

Bringing Together Keyboard-only and Click-based UI Tests with keyboard-testing-library

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 and despite the efforts of many of us in the industry, the current state of accessibility on the web still isn’t great.

New people continue to enter the industry as new technologies emerge. To get real for a second, we still risk history repeating itself where accessibility is not prioritized. Therefore, it’s vital that we teach best accessibility practices so that the applications of the future are accessible from the start.

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

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

I consulted with a team this past year 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. So I made accessibility recommendations based on the technology in use while focusing on user experience.

No matter where you are in the state of your application, pair with colleagues to look closely at the source code and documentation of any frameworks or libraries you’re considering. Look for markup anti-patterns like missing input labels or click events on divs. If you see these—consider running away! Or at least validate there is an 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. If you can improve things with further tinkering, that can provide some confidence without a huge investment.

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.

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

Accessibility Articles

Clarifying Color Contrast & Font Size Guidelines

Bringing Together Keyboard-only and Click-based UI Tests with keyboard-testing-library

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