Javascript

Testing Accessibility Features With Playwright

Jan 31, 2024

5 min read

Testing Accessibility Features With Playwright

In one of my previous posts, I mentioned the importance of having e2e tests to verify that your keyboard navigation works properly. I also suggested Playwright as a tool to write those tests.

I owe you a little tutorial on how to do that. And because keyboard navigation is not the only accessibility feature you should test and since Playwright has some nice built-in tools for accessibility testing, I will also show you how to test other aspects of your website.

What is Playwright?

Let's start with a short introduction for those who don't know Playwright yet. Playwright is an open-source automation library developed by Microsoft, designed to enable developers and testers to write scripts that can control a web browser's behavior. It is a Node.js library that provides a high-level API to control headless Chrome, Firefox, and WebKit with a single interface. This means you can write your tests once and run them in multiple browsers, ensuring cross-browser compatibility.

If you're new to Playwright, you can check out Dane's article, which nicely introduces the basics such as configuration or selectors, and presents some nice test examples.

Keyboard Accessibility Testing

Now, as promised, let's dive into keyboard accessibility testing with Playwright. As I already mentioned, keyboard navigation is one of the most important accessibility features to test, given that it can break anytime you add new functionality to your application and the problem can easily go unnoticed. It is also one of the easiest to test with Playwright because it provides a neat keyboard API that allows you to simulate keyboard input and verify that the correct elements are focused or activated.

Verifying Element Focus

To check which element is selected after a series of keyboard inputs, you can use the toBeFocused() method to check whether it is focused or not, like this:

await page.keyboard.press('Tab');
await page.keyboard.press('Tab');
await page.keyboard.press('Tab');

const textbox = page.getByRole('textbox');

// Verify that the textbox is focused
await expect(textbox).toBeFocused();

// Tab out of the textbox
await page.keyboard.press('Tab');

// And verify that the textbox is not focused
await expect(textbox).not.toBeFocused();

This code snippet simulates pressing the Tab key three times and then checks that an input is focused. It then presses the Tab key again, verifying that the input is no longer focused.

If you read my previous article, you might remember that I mentioned that many websites have a bug that prevents you from tabbing out of a textbox. This simple test can catch this bug and prevent headaches for your users.

Simulating Complex Keyboard Interactions

Playwright's keyboard class provides a keyboard.press() method to simulate pressing a key and releasing it immediately. It allows you to simulate pressing a single key, a combination of keys, or a key combination with a modifier key:

await page.keyboard.press('Shift+KeyA'); // Presses uppercase 'A'
await page.keyboard.press('Control+A'); // Select all text (on Windows/Linux)

You can find the full list of keys you can pass to the keyboard.press function on MDN.

If you need finer control over the keyboard, you can use the keyboard.down() and keyboard.up() methods to simulate pressing and releasing a key separately. One use case for this is to simulate pressing a key and holding it down for a certain amount of time, such as holding the Shift key to select multiple elements or lines of text:

// Press Shift and hold it down
await page.keyboard.down('Shift');

//Press the down arrow 5 times
for (let i = 0; i < 5; i++) {
  await page.keyboard.press('ArrowDown');
}

//Release the Shift key
await page.keyboard.up('Shift');

// and verify that the first 5 list items are selected
for (let i = 0; i < 5; i++) {
    // construct the selector for the ith list item
    const listItemSelector = `ul#myList > li:nth-child(${i + 1})`;

    // use the `toHaveClass` assertion to check if the item has the 'selected' class
    await expect(page.locator(listItemSelector)).toHaveClass(/.*selected.*/);
}

You can also use the keyboard.insertText() method to insert text into an element, but note that modifier keys do not affect this method (e.g. holding down the Shift key will not type the text uppercase) and it only dispatches the input event and does not emit the keydown, keyup or keypress events.

// press Tab to focus the textbox
await page.keyboard.press('Tab');
// insert text into the textbox
await page.keyboard.insertText('Hello World!');
// expect the textbox to contain the text
await expect(page.getByRole('textbox')).toHaveValue('Hello World!');

The keyboard API allows you to test keyboard input, keyboard shortcuts; and ensure that your application responds correctly to user input without a mouse. Although this might seem unnecessary, believe me when I say it is not. As I mentioned in my previous article, many applications try to implement keyboard navigation but contain a nasty bug that renders the effort useless. And it is worth spending some time writing a few simple e2e tests to avoid invalidating your efforts.

Testing Other Accessibility Features

This article focuses mostly on keyboard accessibility, but I have good news! You can easily test other accessibility aspects with Playwright too! It conveniently integrates with the axe accessibility testing engine using the @axe-core/playwright package to run automated accessibility tests. These tests can catch various issues, such as poor color contrast, missing labels on UI controls, and duplicate IDs that can confuse assistive technologies.

Example Test for Entire Page Accessibility

Here's how you can scan your entire page for accessibility issues using Playwright:

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

test.describe('homepage', () => {
  test('should not have any automatically detectable accessibility issues', async ({ page }) => {
    await page.goto('https://your-site.com/');
    const accessibilityScanResults = await new AxeBuilder({ page }).analyze();
    expect(accessibilityScanResults.violations).toEqual([]);
  });
});

Scanning Specific Page Sections

You can also target specific parts of your page by using AxeBuilder.include() to focus the accessibility scan:

test('navigation menu should not have automatically detectable accessibility violations', async ({ page }) => {
  await page.goto('https://your-site.com/');
  await page.getByRole('button', { name: 'Navigation Menu' }).click();
  await page.locator('#navigation-menu-flyout').waitFor();
  const accessibilityScanResults = await new AxeBuilder({ page })
    .include('#navigation-menu-flyout')
    .analyze();
  expect(accessibilityScanResults.violations).toEqual([]);
});

Handling Known Accessibility Issues

When you have known accessibility issues that you cannot immediately fix, Playwright allows you to exclude certain elements from scans or disable specific rules:

const accessibilityScanResults = await new AxeBuilder({ page })
  .exclude('#element-with-known-issue')
  .analyze();

Reporting Accessibility Issues

If you want to report accessibility issues in your test results, you can use the testInfo.attach() method to attach the scan results to your test report:

test('example with attachment', async ({ page }, testInfo) => {
  await page.goto('https://your-site.com/');

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

  await testInfo.attach('accessibility-scan-results', {
    body: JSON.stringify(accessibilityScanResults, null, 2),
    contentType: 'application/json'
  });

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

You can then use reporters to embed or link the scan results in your test output.

Conclusion

While your e2e tests should not serve as a replacement for manual testing and you should still check your app yourself to catch any issues that automated tests won't reveal, Playwright provides a convenient way to automate checks whether all of your website's accessibility features work as intended. It allows you to test keyboard navigation and other accessibility aspects such as color contrast or missing labels to make sure you aren't shipping a broken experience.

Testing accessibility with Playwright requires little effort, and in my opinion, is very much worth it. So, if you haven't done so yet, I encourage you to give it a try! And if you're still unconvinced, read about how I broke my hand to appreciate the importance of accessibility.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Jan Kaiser

Software engineer passionate about everything web-related. Particularly loves Angular, SCSS, TypeScript, soccer and dachshunds

@honzikec @honzikec

Does Replay Fix All Debugging Issues?

Rob Ocel and Adam Barrett talk with Jason Laster, CEO and co-founder of Replay. For those of you who are unfamiliar, Replay is an innovative browser development tool that is revolutionizing the way developers approach time travel debugging and bug fixing. This episode highlights all the reasons why Replay is such an amazing tool and all the problems it solves for developers. Jason shares the background on where the concept of time travel debugging came from, and how it actually works in Replay. The idea that you can capture a bug once and replay it as many times as needed enables developers to zoom in and identify the root cause of the issue. This approach saves infinite time, as you no longer have to rely on guesswork or spend hours reproducing bugs. Download this podcast episode here!...

Jan 5, 2024

1 min

ReactTesting

E2E Testing Basics with Playwright

End-to-end (E2E) testing is a crucial piece of the application testing puzzle. E2E testing generally refers to testing your application as an entire system as opposed to testing it in small isolated pieces like unit tests. This post introduces Playwright, a powerful E2E testing framework that offers APIs in several different programming languages. Before we dive in, let's take a high-level look at some of its most noteworthy features. - Component testing - This post is specifically about E2E tests but being able to test your components in isolation with the same framework is a really nice feature. - Incredible flexibility - Headless and headed test modes - Multiple browsers (Chromium, Firefox, WebKit), and mobile device testing environments - API is available in several different languages - Single-page and multi-page app testing - Project config supports running particular sets of tests against specific browsers and environments - Multiple browser contexts - Useful for testing multiple sessions or user accounts simultaneously - Parallel test execution - Runs tests in parallel by default - Test Generation - You can interact with your web app UI in the headed Playwright browser and have it generate selectors and test code for you. We won’t touch on it in this article, but you can learn more about it here - Debugging - Has built-in support for debugging Playwright in Practice In this post, we will reference a fictional web application with authentication that includes user login and profile setup flows to illustrate how you can use Playwright to test an application. Here is the directory structure for our tests: ` Playwright configuration playwright.config.ts is where you can specify various options and features for your testing setup. The projects option is where things get really interesting. You can use projects to configure different sets of tests to run on different browsers and devices. We can add tags to our test description to target particular tests for specific projects. For example, we can tag particular tests with @firefox and configure a project that only runs it against the Firefox browser. This might be useful for testing against regressions for a browser specific bug. We are also able to match against file names. In the project config below, we are ignoring tests with .mobile in the filename in all of our projects except the one that is mobile-specific. Here are some reference pages for some of the features, and config options covered here: - https://playwright.dev/docs/test-configuration - https://playwright.dev/docs/test-projects - https://playwright.dev/docs/running-tests ` The webServer option allows specifying a web server for server-rendered and API servers. You can provide a command to start the server, and Playwright will wait for it to be ready before running your tests. Artifacts and Fixtures In addition to the models and specs directories, we also have an artifacts directory and a fixtures directory. The artifacts directory is used to store any artifacts generated during tests, such as screenshots or videos. Playwright can automatically take screenshots or videos of test runs, and these will be saved in the artifacts directory. The fixtures directory, on the other hand, contains any static data that might be needed during tests, such as images or data files. For example, in our auth-flow tests, we use an avatar image stored in the fixtures directory to simulate a user uploading an avatar image during the profile setup process. Selectors and Basic Test Writing In Playwright, we use selectors to target and interact with specific elements on a page. Playwright supports a wide range of selector engines, including CSS, XPath, and text-based selectors. You can also create custom selectors to suit your specific testing needs. When writing tests, we typically use the page.locator() method to target a specific element using a selector. For instance, you can use CSS selectors to target elements by their class, ID, or attributes. Here's an example that demonstrates how to use selectors to interact with a simple login form: ` In this example, we used CSS selectors to target the email and password input fields and a text-based selector to locate the login button. We can call methods, such as fill() and click(), that simulate user interactions and verify that the application behaves as expected. If you want to learn more on this topic, check out the writing tests page of the documentation. Page Object Models One pattern that Playwright recommends in its documentation is called Page Object Models. A page object model is a design pattern for organizing tests in a way that makes them more maintainable and encapsulates reusable logic. The basic idea is to define a set of classes that represent the pages and components of your web application, and then use these classes in your tests to interact with the application. For testing our applications, auth flows we might add a auth-flow.ts file. We can define an AuthFlow class that represents the authentication flow of our web application. This class encapsulates all the logic for requesting magic links, creating user accounts, and clicking links in the email sent to the user. By defining this class, we can write more readable and maintainable tests that use the AuthFlow class to perform the necessary actions. We accept a page argument in our constructor. This is a special argument that is always available in the browser context of our tests. It allows us to interact with the page via selectors and other easy to use APIs. There is a dedicated page in the documentation for this special object. ` Specs Finally, let's take a look at the specs directory. This directory contains the actual test files that use the AuthFlow class to perform the authentication and profile setup flows. new-user.spec.ts For example, the new-user.spec.ts file contains a test that verifies that a new user can complete the authentication flow, and be successfully redirected. In this example, we use the test.describe.serial test annotation to run the tests one after the other, since the second (sign-out) test depends on the user being logged in. (By default, Playwright runs as many tests as it can in parallel). We use test.beforeAll to run setup code (creating a magic link and user account) and test.afterAll to run any cleanup at the end of the tests. One of the first things you’ll notice is the callback functions that we pass to the Playwright test methods like beforeAll get called with an object argument that includes things like browser and baseURL. The browser object provides an API to the actual browser that our tests are running in, and we can use it to create and open new pages like we do in the first couple of lines of the beforeAll below. ` profile-setup.spec.ts Next, we have a profile-setup.spec.ts file that contains a test that verifies that the profile setup form can be filled out and changes can be successfully saved. Tests similar to this will be pretty common in most web applications. Luckily Playwright’s API and selectors make it pretty easy. We are able to test form accessibility here by trying both clicking and tabbing to the next fields. ` sign-in.spec.ts And finally, we have a sign-in.spec.ts file that contains a test that verifies that the sign-in modal can be opened and a magic link can be sent. ` Once you get familiar with the API, and the tools that Playwright makes available to you, writing tests for your application becomes pretty easy… and dare I say… fun? Summary There is so much more that we can cover when it comes to Playwright because it’s such a fantastic and powerful tool. Hopefully, this served as a good introduction to help you get started writing some basic E2E tests for your application. We covered some good ground after the intro by looking at some of the configuration options Playwright provides, and then writing some example tests for a fictional authentication flow. Our page object model implementation provided a nice abstraction for working with our app’s authentication mechanisms. Please keep in mind that this is not a prescription for how you need to write or structure your tests. The specific setup in this post is more to serve as a guide and a way to introduce some of the features and ways to start writing some tests. The most important part is that you can meet your application testing goals, and enjoy your time building out your tests!...

May 5, 2023

6 mins

TestingJavaScript

Using HttpClient in Modern Angular Applications

Introduction With all the wonderful treats that the Angular team has given us during the recent "renaissance" era, many new developers are joining in on the fun. And one of the challenges they'll face at some point is how to call an API from your Angular application properly. Unfortunately, while searching for a guide on how to do this, they might stumble upon a lot of outdated information. Hence, this article should serve as a reliable guide on how to use the HttpClient in Angular >= 17. The Setup To make an HTTP request in Angular, you can take advantage of the HttpClient provided by the @angular/common/http package. To use it, you'll need to provide it. Here's how you can do that for the whole application using the bootstrapApplication function from @angular/platform-browser: ` With that, you should be good to go. You can now inject the HttpClient into any service or component in your application. Using HttpClient in Services Let's take a common example: You have a database object, say a Movie, and you want to implement CRUD operations on it. Typically, you'll want to create a service that provides methods for these operations. Let's call this service MovieService and create a skeleton for it with a method for getting all movies. ` Implementing the Method using HttpClient Let's assume we have a GraphQL API for our movies. We can implement our getAllMovies using HttpClient to make a request to fetch all movies. First, we will need to define a new type to represent the response from the API. This is especially important when you are using GraphQL, which may return a specific structure, such as: ` When working with a real API, you'll likely use some code generator to generate the types for the response from the GraphQL schema. But for the sake of this example, we'll create an interface to represent the response manually: ` Now, we can implement the getAllMovies method using HttpClient: ` > Note: The post method is used here because we are sending a request body. If you are making a GET request (e.g. to a REST API), you can use the get method instead. The getAllMovies method returns an Observable of MoviesListResponse. In this example, I have typed it explicitly to make it obvious at first glance, but you could also omit the type annotation, and TypeScript should infer it. > Note: While I'm excited about signals as much as the next guy, making HTTP requests is one of the typical async operations for which RxJS Observables are a perfect fit, making a great argument for RxJS still having a solid place in Angular alongside signals. Using the Service in a Component Now that we have our MovieService set up, we can use it as a component to fetch and display all movies. But first, let's create a Movie interface to represent the structure of a movie. Trust me, this will prevent many potential headaches down the line. Although using any at the beginning and implementing the types later is a valid approach in some cases, using data fetched from an API without validating the type will inevitably lead to bugs that are difficult to solve. ` Now, we can start implementing our standalone MoviesComponent: ` In this component, we are calling the getAllMovies method from the MovieService in the constructor to fetch all movies and assign them to the movies property which we will use to display the movies in the template. ` In this case, placing our code inside the constructor is safe because it doesn’t depend on any @Input(). If it were, our code would fail because the inputs aren’t initialized at time of instantiation. That's why it is sometimes recommended to place logic in ngOnInit instead. You could also put this call in an arbitrary method that is called e.g. on a button click. Another way to handle the subscription is to use the async pipe in the template. This way, Angular will automatically subscribe and unsubscribe from the observable for you and you won't have to assign the response to a property in the component. Due to the structure of the returned data, however, we'll need to use the RxJS map operator to extract the movies from the response. ` > Note using the pipe method to chain the map operator to the observable returned by getAllMovies. This is a common pattern when working with RxJS observables introduced in RxJs 5.5. If you see code that uses the map operator directly on the observable and wonder why it isn't working for you, it's likely using an older version of RxJS. Now, we can simply apply the async pipe in the template to subscribe to the observable and display the movies: ` Conclusion HttpClient in Angular is pretty straightforward, but with all the changes to RxJS and Angular in the past few years, it can pose a significant challenge if you're not super-experienced with those technologies and stumble upon outdated resources. Following this article, you should hopefully be able to implement your service using HttpClient to make requests to an API in your modern Angular application and avoid the struggle of copying outdated code snippets....

Mar 27, 2024

4 mins

AngularJavaScript

How to Make Coding Both Your Hobby and Profession with Jason Lengsdorf @ CityJS Conf 2024

Join us backstage at CityJS Conf for this conversation with Jason Lengsdorf. In this discussion, we explore strategies for reducing stress and anxiety among engineers, ensuring they maintain relevance in the dynamic world of coding. Jason emphasizes the importance of self-assurance and the role of play in fostering continual engagement with evolving technologies. Moreover, we get a sneak peek into Jason's latest venture, "Web Lunch," a platform where he converses with developers who have found harmony between their careers and personal satisfaction. Coding isn't just a job; it's a passion and a lifestyle. Jason highlights the significance of pursuing work that excites and challenges us, echoing the sentiment that coding can be both a career and a hobby. By infusing enjoyment and creativity into our coding endeavors, we can shape our professional trajectories in alignment with our values and interests. This approach not only minimizes regret but also maximizes happiness and fulfillment in our careers. Central to our discussion is the pivotal role of effective leadership in creating a supportive and encouraging work environment. Leaders who prioritize the well-being and happiness of their team members foster a culture of collaboration and empowerment. Through mentorship, guidance, and opportunities for growth, these leaders enable developers to align their personal goals with organizational objectives, leading to increased job satisfaction and professional fulfillment. Adaptability is key to sustained success in software engineering. Jason emphasizes the value of remaining open-minded and continuously learning, even when it means stepping out of our comfort zones. Embracing discomfort is an integral part of personal growth, allowing us to overcome obstacles and unlock our full potential. By nurturing a spirit of curiosity and adaptability, developers can navigate the complexities of their careers with resilience and enthusiasm....

Apr 25, 2024

2 mins

JavaScriptMentorship

Testing Accessibility Features With Playwright

Testing Accessibility Features With Playwright

What is Playwright?

Keyboard Accessibility Testing

Verifying Element Focus

Simulating Complex Keyboard Interactions

Testing Other Accessibility Features

Example Test for Entire Page Accessibility

Scanning Specific Page Sections

Handling Known Accessibility Issues

Reporting Accessibility Issues

Conclusion

Jan Kaiser

You might also like

Does Replay Fix All Debugging Issues?

E2E Testing Basics with Playwright

Using HttpClient in Modern Angular Applications

How to Make Coding Both Your Hobby and Profession with Jason Lengsdorf @ CityJS Conf 2024

You might also like

Does Replay Fix All Debugging Issues?

E2E Testing Basics with Playwright

Using HttpClient in Modern Angular Applications

How to Make Coding Both Your Hobby and Profession with Jason Lengsdorf @ CityJS Conf 2024

Testing Accessibility Features With Playwright

What is Playwright?

Keyboard Accessibility Testing

Verifying Element Focus

Simulating Complex Keyboard Interactions

Testing Other Accessibility Features

Example Test for Entire Page Accessibility

Scanning Specific Page Sections

Handling Known Accessibility Issues

Reporting Accessibility Issues

Conclusion

Jan Kaiser

Does Replay Fix All ​​Debugging Issues?

E2E Testing Basics with Playwright

Using HttpClient in Modern Angular Applications

How to Make Coding Both Your Hobby and Profession with Jason Lengsdorf @ CityJS Conf 2024

Does Replay Fix All ​​Debugging Issues?

E2E Testing Basics with Playwright

Using HttpClient in Modern Angular Applications

How to Make Coding Both Your Hobby and Profession with Jason Lengsdorf @ CityJS Conf 2024

Does Replay Fix All Debugging Issues?

Does Replay Fix All Debugging Issues?