Practice Real-World Testing Scenarios for QA: Challenge 4

Hi! The 4th challenge is ready: accessibility testing. For me, it's important to design websites for all people with and without disabilities.

The WHO estimates that 1.3 billion people – about 16% of the global population have some significant disability, and this number is increasing.

The latest WebAIM data reveal that nearly 96% of the world's top public websites launch with critical accessibility failures. Today, ignoring these bugs is a legal violation. Governments worldwide, reinforced measures such as the European Accessibility Act (EAA), now strictly mandate that public-facing digital products comply with the Web Content Accessibility Guidelines (WCAG).

If your website is open to the public and is under US, it may fall under the Americans with Disabilities Act (ADA) — and noncompliance can be expensive. In 2025, over 8,600 ADA website lawsuits were filed in the U.S. One of the most notable recent cases: online retailer Fashion Nova agreed to a $5.15 million class-action settlement (Alcazar v. Fashion Nova) — and ironically, the site set up to manage the settlement claims was itself inaccessible to screen reader users.

In one of my projects, an EdTech platform, we need to ensure the website is WCAG 2.2-compliant. It was challenging because there were several bugs and the external audits were outside the company and sometimes we didn't have a clear action to fix it. I helped with one requirement: adding patterns to charts so people with color blindness can understand them without relying solely on color.

I did the same on the website to practice testing: https://abi-testing-dojo-demo.azurewebsites.net/login

I added patterns to the charts
I added a table with chart data and with keyboard navigation you can see the details of the info in the chart

2 courses that I think are helpful to design and develop accessible websites a

How To Design for Accessibility: for UX Designers (WCAG 2.2)

Learn Accessible Web Design

You can read my previous article, where I explained different tools that help you test whether a page is accessible.

Tools for accessibility testing

So for this challenge, you need to perform the next testing:

1) Manual testing

Close your eyes and, using a screen reader (NVDA or VoiceOver (macOS)), navigate to the website. Then, moving only with TAB, ENTER, and arrow keys, reach the charts and select another option in the menu for example users and create a new user.
Repeat the same without closing your eyes but now check if the selected option is clearly visible. Many people with motor disabilities don't use a keyboard or mouse — they rely on assistive tech like switch devices, eye-tracking, or voice control. All of these depend on the same thing: the browser's focus system, the one you're testing with Tab. If focus order is broken, it locks out anyone using alternative input methods.

2) Test with a browser extension

Although a browser extension can't find all bugs, it helps to discover the current accessibility errors on your website. There are various extensions and companies, such as BrowserStack, [TestMu]((https://www.testmuai.com/lp/accessibility-automation) and Cypress offer products to scan your page and generate reports with the accessibility bugs.

Test the website in grayscale — if you can't tell what's happening without color, neither can they.

You can use, Accessibility insights to see how to test color by turning the website grayscale.

Another extension that I think are useful:

3) Integrate accessibility into your end-to-end tests

There are different npm packages and tools to integrate accessibility into your automated tests.

For Cypress, one interesting free plugin is Wick-ally

I created one for Playwright Snap-ally. With this plugin, you can check the accessibility bugs in your web site and create the bugs on Azure DevOps.

Running accessibility testing in your CI/CD pipeline can help ensure that no new bugs are introduced. Still, it doesn't replace manual testing, since it only catches the same 30-40% of issues automatically on every commit.

Also, you can create an AI skill to check a website's accessibility and include feedback on how to fix the issues.