Author at Infinum

Automation Made Simple: Accessibility Testing with Playwright

Dino Vinković — Thu, 03 Apr 2025 11:43:46 +0000

With automation tools like Playwright, testing web accessibility doesn’t have to be tedious or time-consuming. Learn how to speed up your accessibility checks using Playwright and axe-core, and simplify the path to building more inclusive digital products.

Ensuring your web page is accessible to all users is becoming increasingly important for businesses. With regulatory pressures mounting and public awareness rising, brands and companies are looking to optimize their digital products to meet accessibility standards.

However, testing a web page for accessibility is a nuanced task, and certain aspects of it can be particularly time-consuming. Fortunately, there are a number of tools available to help testers check web accessibility thoroughly and efficiently, especially by leveraging test automation.

Not every team has the resources or bandwidth to build custom tools, but existing solutions can already achieve a great deal. In this article, we’ll explain how to conduct accessibility testing using Playwright, a very popular tool in the testing community. With just a few simple adjustments, Playwright can significantly speed up and enhance the efficiency of your testing process.

Why digital accessibility is important

A significant portion of the population faces challenges when accessing digital resources due to physical, cognitive, and sensory impairments. According to the World Health Organization, approximately 16% of the global population experiences significant disabilities.

If your app or website isn’t built with accessibility in mind, you risk excluding a considerable number of users – not only those with permanent disabilities but also individuals experiencing temporary or situational impairments, such as a broken arm or navigating a digital product in a noisy environment. Accessibility standards ultimately improve the user experience for everyone.

Beyond ethical considerations, accessibility is increasingly becoming a legal necessity. In the United States, the Americans with Disabilities Act mandates that public accommodations, including websites, must be accessible to individuals with disabilities. Similarly, the European Union’s European Accessibility Act and the Web Accessibility Directive establish clear guidelines for digital accessibility. Non-compliance can lead to significant legal consequences, including lawsuits, fines, and reputational harm.

What is accessibility testing?

Accessibility testing is the process of identifying barriers that may prevent users from fully interacting with a website or service. It ensures that people with disabilities can access and navigate the content just as easily as anyone else.

The testing is usually conducted through a combination of automated and manual accessibility checks. It evaluates several aspects, including visual design, interactive elements, content structure, navigation, and multimedia components.

Can accessibility testing be automated?

Accessibility testing can be automated to a certain extent. Automation tools can help us identify many common accessibility issues and provide reports that highlight areas needing improvement. These tools can check for issues like missing alt text, poor color contrast, improper heading structures, and missing ARIA attributes – areas frequently overlooked during development.

However, automated tools are limited to verifying basic accessibility compliance and cannot evaluate how intuitive or user-friendly an interface is. Human testing remains vital for uncovering issues such as confusing navigation, unintuitive layouts, or frustrating interactions, which are all essential if we want to ensure a truly inclusive user experience.

Automating accessibility testing with Plawright and axe-core

Playwright is an excellent starting point for teams interested in accessibility test automation. It is a widely used, open-source framework known for its ease of setup and strong community support. More importantly, it offers integration with axe-core, a powerful accessibility testing library created by Deque Systems. Axe-core helps testers efficiently detect violations of accessibility standards, such as the Web Content Accessibility Guidelines (WCAG), and provides insights on fixing any issues found.

Playwright and axe-core are a powerful combo – one that helps testers streamline accessibility checks, improving both efficiency and accuracy in their testing processes.

Initial setup

We’ll start by installing Playwright using npm.

npm init playwright@latest

You’ll be prompted to answer a few setup questions – feel free to go with the default options. TypeScript should be selected by default, but double-check that it is.

For full installation details, check the official Playwright documentation.

Next, add the additional packages needed for this implementation:

npm install @axe-core/playwright
npm install axe-html-reporter

Then, import the necessary modules in your test file:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
import { createHtmlReport } from 'axe-html-reporter';

Page inspection

Now, let’s walk through a practical example using todoMVC. To inspect a page for accessibility issues, we’ll use AxeBuilder from the axe-core/playwright package. The command new AxeBuilder({ page }).analyze() tells Axe to scan the current page and identify any violations according to established standards, and the results are stored in the accessibilityScanResults variable.

const accessibilityScanResults = await new AxeBuilder({ page }).analyze();

To focus the analysis on specific standards, you can refine the accessibility scan by using the withTags() method. For example, if you’re targeting the most common WCAG compliance levels (WCAG 2.0 and WCAG 2.1, levels A and AA), you can do so as follows:

const accessibilityScanResults = await new AxeBuilder({ page })
       .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])
       .analyze();

Assertion

After performing the scan, we need to verify whether any accessibility violations have occurred. You can achieve this by asserting that the violations array within the results is empty. If any violations are found, your test will fail, prompting you to address the identified issues:

expect(accessibilityScanResults.violations).toEqual([]);

Creating the report

To generate a readable summary of the accessibility scan, we’ll use the createHtmlReport function from the axe-html-reporter package. This function takes in the scan results we previously stored in accessibilityScanResults. We can also use options to configure the report name and output directory.

const reportHTML = createHtmlReport({
    results: accessibilityScanResults,
    options: {
        outputDir: reportDir,
        reportFileName: reportName,
    },
});

Note that createHtmlReport returns an HTML string – it doesn’t create a file by itself. To write the report to disk, we’ll use Node’s fs module:

if (!fs.existsSync(`${reportDir}${reportName}`)) {
       fs.mkdirSync(`${reportDir}${reportName}`, { recursive: true });
     }
     fs.writeFileSync(`${reportDir}${reportName}`, reportHTML);

Parametrizing the test

Testing a single page is a good start, but broader coverage requires more. Let’s modify our test to run against multiple pages by creating an array of objects containing URL/name pairs. The URL field tells Playwright which page to check, and the name field isn’t required, but helps us generate more descriptive report names:

const urlsToCheck = [
    {
        url: 'https://todomvc.com/examples/react/dist/',
        name: 'reactPage',
    },
    {
        url: 'https://todomvc.com/examples/angular/dist/browser/#/all',
        name: 'angularPage',
    },
    {
        url: 'https://todomvc.com/examples/javascript-es6/dist/',
        name: 'jsPage',
    },
];

Next, we’ll loop through each URL in our test using forEach:

test.describe('Accessibility', () => {
 urlsToCheck.forEach(({ url, name }) => {
   test(`should check: ${url}`, async ({ page }, testInfo) => {
…

This setup generates a separate, clearly labeled report for each tested page.

The full example

Here’s how the complete test script comes together. This is a simple example that shows how easy it is to get started with accessibility test automation using Playwright and axe-core:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
import { createHtmlReport } from 'axe-html-reporter';
import fs from 'fs';

const reportDir = 'reports/a11y/';

const urlsToCheck = [
    {
        url: 'https://todomvc.com/examples/react/dist/',
        name: 'reactPage',
    },
    {
        url: 'https://todomvc.com/examples/angular/dist/browser/#/all',
        name: 'angularPage',
    },
    {
        url: 'https://todomvc.com/examples/javascript-es6/dist/',
        name: 'jsPage',
    },
];

test.describe('Accessibility', () => {
    urlsToCheck.forEach(({ url, name }) => {
        test(`should check: ${url}`, async ({ page }, testInfo) => {
            const reportName = `${name}.html`;

            await page.goto(url);

            // Scan the page and save results to accessibilityScanResults
            const accessibilityScanResults = await new AxeBuilder({ page }).analyze();

            // Create HTML report
            const reportHTML = createHtmlReport({
                results: accessibilityScanResults,
                options: {
                    outputDir: reportDir,
                    reportFileName: reportName,
                },
            });

            // Save HTML report to a file
            if (!fs.existsSync(`${reportDir}${reportName}`)) {
                fs.mkdirSync(`${reportDir}${reportName}`, { recursive: true });
            }
            fs.writeFileSync(`${reportDir}${reportName}`, reportHTML);

            // Assert no violations detected
            expect(accessibilityScanResults.violations).toEqual([]);
        });
    });
});

Report

The reports generated by axe-core are clear, detailed, and practical. They highlight each accessibility violation, categorize its severity, and point to the relevant WCAG guideline. For every issue, you’ll see the specific DOM element affected and get actionable suggestions on how to fix it.

What’s especially helpful is that each issue comes with documentation links, allowing testers and developers to learn more about the problem and why it matters – making it easier to address issues effectively and build more inclusive products.

Make accessibility testing work for you

Digital accessibility is no longer a nice-to-have – it’s becoming increasingly relevant for businesses looking to provide equal access for all users and reduce legal and reputational risks. However, evaluating accessibility manually can be time-consuming and prone to human error. Test automation can be a great asset for testers, and tools like Playwright and axe-core make it easy to catch many common accessibility issues early in the development process.

As our example shows, setting up automated tests doesn’t require complex custom solutions – just a few lines of code and the right tools. Still, we need to bear in mind that automation isn’t a silver bullet. Automated tests are powerful allies, not replacements for human judgment. Experienced testers use these tools to boost efficiency and consistency, while still applying manual testing to assess usability, context, and the overall user experience.

Ultimately, the best approach combines speed with empathy – automating what you can and thoughtfully testing what you can’t.

The post Automation Made Simple: Accessibility Testing with Playwright appeared first on Infinum.

FAQ about QA

Dino Vinković — Fri, 10 Sep 2021 14:30:00 +0000

People who have never worked in software testing might lead you to believe that a software tester just does the same thing over and over again until they find a bug… or lose their sanity, whichever comes first. If you are interested in Software Testing, otherwise called Quality Assurance, leave out the random articles and Reddit threads and read on to see what the job really entails.

Stumbling upon the wrong kind of information can be misleading and even put you off. First of all, isn’t the definition of insanity “doing the same thing over and over again, but expecting different results”? Well, we don’t want testers to go insane, and we do want them to do the job right.

There is actually a lot of variety in software testing. Working in the field requires a broad range of skills and at the same time opens the door to acquiring new ones.

What education do you need to become a tester?

An interesting thing about QA is that in most cases it doesn’t matter which school you attended or what kind of degree you hold. In fact, you could be a geography professor and bring in a particular skill set that would make a great addition to the team. Of course, if your end goal is to get a job that requires certain engineering skills, then you will probably need a degree in engineering or relevant experience.

There are, however, some certifications available. You might even hear that getting one or more of them will help you get noticed. From my experience, there is more than enough material online to prepare you for the interview and even your first months on the job. For example, this handy source of information.

What to look for in a job?

As new technologies keep popping up, we have to continuously build up our knowledge. That’s why it is important to look for a company that continually invests in the education of its employees. It can be especially helpful when you are just starting out and need some guidance.

Coming to a new workplace, there is a lot of information to digest. In that situation, having a mentor is a huge advantage as they can introduce you to the company culture, help you get started and explain the specifics of the project(s) you’ll be working on.

Both these factors fit in nicely with a good work-life balance. You might feel that you have to learn 24/7 to keep up with everything, so it is important to look for a company that is mindful of your health and well-being.

When to start applying for jobs?

The answer is simple – right now. There’s no point in waiting. Even if you don’t land a job immediately, going to interviews is still a great experience. It gives you an insight into the skills and knowledge the employers are looking for. That will give you a better idea of what to focus on.

With all the information out there, you might be inclined to think that you have to know everything before you even start applying for jobs. Being prepared for an interview is definitely a plus, but don’t waste your time going through a multitude of tutorials trying to learn everything. Projects can vary substantially when it comes to technology and the tools being used. It might turn out that you won’t need to use most of what you learned, at least for a while.

As with most jobs, you learn best by doing. With time you will become better at dissecting what to work on, depending on your interests or the skills you want to acquire.

What’s with all those titles?

Looking for a software testing position, you will come across a myriad of titles, such as Software Tester, Quality Assurance, Quality Assurance Engineer, Manual QA, Software Development Engineer in Test, and so on. It can be confusing, especially when you run into two job openings with the exact same titles but quite different job descriptions.

Don’t let fancy titles fool you or scare you off. Read the job posting carefully or better yet, email the employer or recruiter and ask what you want to know.

What exactly a software tester does could vary from company to company. It might be because of different technologies the company is using, a specific field of work, or there might be various QA roles present.

Software testers that do manual tests mimic the way a regular user would use an app. Of course, they go into much more detail and really try hard to catch all the defects you don’t want users to see, from typos to app crashes.

Testers who work on automation usually have slightly different job titles, something on the lines of Test Automation Engineer. Those types of testers focus more on using their coding skills to write automated tests.

It’s more likely that you will be testing apps both manually and with the help of certain tools that don’t necessarily require coding skills. The tools help as they speed up your performance but they can’t tell you how an app feels overall, it’s something you can only learn with manual testing.

So, you landed your first QA job, what’s next?

There are so many things to learn in the beginning that it might all seem overwhelming. Don’t worry, a beginner isn’t expected to know everything before their first day. However, there are a couple of essentials you really should be aware of.

One of the most important skills is writing a good bug report. The person reading the report should be able to understand it without having to figure out what you were trying to say. Also, you want to be able to understand the report yourself once the issue is fixed. This is especially important if a bug is fixed after a longer period of time and you forget some of the details. This blog post is a good resource for writing a good bug report.

Writing good, reusable test cases is another important skill to have. If you’ve gone on a googling quest to see what a test case looks like, you’ve probably come across different versions. The reason is that every team adapts their test case structure to their needs. The point is to simply write solid test cases that you can use over and over again. Writing tests that you’ll use only once or keep updating them day in and day out is a waste of time you could have spent actually testing.

You should probably also have an idea about what testing is and how it is done. There are dozens and dozens of testing methods and techniques you should know and use in your job. For starters, take a look at our QA handbook to find out what and how to test.

How to improve your skills further?

With new developments constantly coming up, you should always strive to be updated. Reading blogs is a good way to start. You could also invest some time to research new tools and new technologies. Maybe you’ll discover a tool to help you test more efficiently.

Investing time in learning a programming language can be beneficial for multiple reasons. You’ll understand developers better, especially when they use a lot of technical jargon. With basic coding skills, you’ll be able to use the tools that require some coding. Maybe you’ll even find out that you enjoy programming as much as testing and decide to move on towards test automation.

If you are more of a creative type, take a design course. That way you’ll learn
how designers do what they do and get a better understanding of user experience.

Learning about other aspects of software development will help you understand the development process better and make you a better tester overall.

It’s both the journey and the destination

Hopefully, you now have a slightly better idea of what software testing is about and what awaits you at the beginning of your QA journey.

It is a very versatile field and no, you won’t just be doing the same thing over and over again. You will, however, use different testing methods and techniques with a specific goal in mind. And yes, you will use a lot of different tools over time.

If you ever decide to shake things up, you’ll have a solid background and enough mojo to move onto development, design, or project management. The possibilities are endless.

The post FAQ about QA appeared first on Infinum.