Never miss an A11y bug

Web accessibility (A11y) is crucial for creating inclusive applications that serve all users, regardless of their abilities. The term “A11y” (pronounced “a-double-one-y”) stands for accessibility. Web accessibility is covered by the Americans with Disabilities Act (ADA) and generally should meet the Web Content Accessibility Guidelines (WCAG) standards. Non-compliance can present legal risk and inhibit potential users from accessing your services.

While accessibility is often associated with supporting users with visual or cognitive impairments, its benefits extend far beyond that. Many accessibility features, like keyboard navigation or high-contrast modes, benefit all users, not just those with disabilities. For example, color contrast, alternative descriptions, and the ability to resize charts without breaking layouts are good product design basics. At Opto, this becomes especially important as we aid financial advisors in exploring and explaining a wide variety of complex financial concepts.

Yet many developers struggle with implementing and maintaining accessibility effectively, often overlooking or missing issues altogether. As a frontend developer, I’ve faced this challenge over and over again. How do we not only build accessible websites but also maintain accessibility standards as teams iterate and add features?

The challenge

Traditional accessibility testing often involves manual checks or sporadic audits, which can be:

  • Time-consuming and error-prone
  • Easy to overlook during rapid development cycles
  • Difficult to scale

At Opto, we’re building financial technology solutions that scale across a growing number of advisors and their clients. As we rapidly iterate on features and expand our platform, we need testing approaches that can keep pace with our development velocity. Automation isn’t just a nice-to-have, it’s essential for maintaining quality as we grow.

Enter Playwright Axe plugin

When I discovered the Playwright Axe plugin, I was immediately excited by its potential. By integrating accessibility testing directly into our CI pipeline, we could catch issues before they reached production, freeing up developers to focus on building features rather than performing manual accessibility checks.

The implementation is straightforward - Playwright waits for page render, then scans for accessibility violations based on your configuration.

const runAccessibilityTest = async (
  page: Page,
  path: string,
  waitForTestId: string,
) => {
  await page.goto(path);
  await page.waitForLoadState("load");
  await page.getByTestId(waitForTestId).waitFor();

  const axe = new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa"])
    .include("body");

  const accessibilityScanResults = await axe.analyze();

  const contrastViolations = accessibilityScanResults.violations.filter(
    (violation) => violation.id === "color-contrast",
  );

  return contrastViolations;
};

test(`${name} should not have any color contrast issues`, async ({ page }) => {
  const violations = await runAccessibilityTest(page, path, waitForTestId);
  expect(violations, `Accessibility violations found on ${path}`).toEqual([]);
});

This code above checks for color contrast issues, but the plugin can be configured to test for any WCAG 2.2 criteria. The test will fail if accessibility issues are found, preventing regressions from reaching production code.

I should note that this method isn’t completely a “set it and forget it” solution. In addition to the time invested upfront configuring the CI pipeline, getting the app in a good “starting” state, and deciding which accessibility rules to enforce, there is maintenance required to keep the pages/features playwright checks up to date. For example, when new pages or different states of pages are added, the tests need to be updated to make sure those pages or versions of them are scanned in the tests.

That being said, I believe the tradeoff is worth it. By integrating the Playwright Axe plugin into the CI pipeline, developers can focus primarily on other tasks and have more confidence that their changes meet a high standard when it comes to accessibility.

Impact at Opto

Since implementing automated accessibility testing, we’ve been able to identify accessibility issues as soon as they’re introduced. A recent example illustrates this perfectly: when we updated the link colors on one of our pages, our testing system immediately flagged a contrast issue.

The “Calculation details” link, styled in a light green, failed the color contrast check with this error:

image of contrast failing

Description: Elements must meet minimum color contrast ratio thresholds

Violation:

  • Button element with color #0aa086 on background #fafbfc
  • Current contrast ratio: 3.17
  • Required contrast ratio: 4.5:1
  • Font size: 14px
  • Font weight: normal

By adjusting to a darker green shade, we resolved the contrast issue, making the text more readable for all users.

image of contrast passing Note: The content herein is provided for informational and illustrative purposes only and does not purport to represent actual performance or hypothetical performance of a specific manager, client, account, strategy or asset class.

Looking ahead, we’re expanding our automated testing to cover more WCAG criteria and implementing as many checks as possible directly in our component library. This proactive approach will help us catch accessibility issues earlier in the development process. Our goal is to make accessibility not just a requirement, but a fundamental part of our development DNA at Opto.

For disclaimers, visit https://www.optoinvest.com/disclaimers.