Accessibility testing overview

When it comes to quality engineering, there are additional dimensions that are key to building a great user experience. Accessibility is a core part of quality - ensuring that all users have equitable access to your application. In many ways, accessibility also lends itself to improved testability.

Mabl allows you to combine your accessibility testing and functional testing in one place, simplifying tool sprawl and providing a unified platform for testing and reporting. Learn more about mabl's accessibility reporting dashboard here.

Use cases

You can use the accessibility testing capabilities in mabl to achieve the following:

  • Create accessibility checks against a specific page or element within your app
  • Add these checks at any point in the testing process to validate additional states of your app
  • Fail a test run based on the severity of accessibility violations
  • View comprehensive reports for each check alongside your functional testing results
  • Fully incorporate accessibility checks into existing tests and execute them throughout the development lifecycle

🚧

Access

Accessibility testing is currently available for all new Growth and Enterprise customers that close after June 1st, 2022 as well as all active trials. Customers that signed before June 1st will need to upgrade to gain access.

Your workflow

At a high level, you will typically take the following steps when working with accessibility checks in mabl:

  • Create a new test or edit an existing one
  • Get your application into the desired state
  • Insert an accessibility check step from the "Add step" menu
  • Specify the page or element to check and any relevant configuration rules
  • Save the test
  • Run the test and view the full report from the test results page

Testing setup

Creating accessibility checks within a test is as simple as adding the "Accessibility" step type. Based on your needs, the check can be targeted against a specific element or the entire page.

These checks can also be tailored based on the tags or rules that are most relevant to your team, whether that's WCAG 2.1 Level A & AA, best practice rules, and more. To provide increased configuration, rules can be disabled as well.

You also have the option to fail the step based on the severity of the violations, quickly providing insight into critical violations that may warrant additional investigation.

586586

Creating accessibility checks in the Trainer

Once an accessibility check has been successfully created, these checks will run like any other step in mabl. The output of the check can be viewed at the step level in the test results. This includes a summary of all violations, checks that are incomplete or inapplicable, and passing checks.

14121412

Accessibility results in the mabl app

Each check includes a summary of the rule, impact, failure details (if applicable), element information, and additional help resources.

656656

Detailed violation results

Rules, tags, and configuration

Accessibility checks in mabl provide the option to specify the rules and tags that are used. Without any changes on your part, accessibility checks will use the default configuration from axe-core. This configuration will use all rules outlined here, except for rules with the "experimental" tag. As of May 2022, it would include all rules for WCAG 2.0 (levels A, AA, AAA), all rules for WCAG 2.1 (levels A, AA, AAA), as well as the Best Practices rules.

586586

Advanced settings

You also have the ability to specify rules and tags. For example, if your organization was working towards WCAG 2.0 Level AA compliance, you can specifically use the wcag2aa tag.

Note: The tags only include the specific rules for that accessibility standard and not any rules in less strict standards. If you wanted a check to cover rules from WCAG 2.0 Level AA compliance and WCAG 2.0 Level A compliance, you would need to list both tags (e.g. "wcag2a, wcag2aa") in the accessibility check.

For additional information on the axe-core tags listed below, please refer to this resource.

Tag Name

Accessibility Standard

wcag2a

WCAG 2.0 Level A

wcag2aa

WCAG 2.0 Level AA

wcag2aaa

WCAG 2.0 Level AAA

wcag21aa

WCAG 2.1 Level AA

best-practice

Common accessibility best practices

wcag***

WCAG success criterion. For example, wcag111 maps to SC 1.1.1

ACT

W3C approved Accessibility Conformance Testing rules

section508

Old Section 508 rules

section508.*.*

Requirement in old Section 508

experimental

Cutting-edge rules, disabled by default

Rules allow you to further tailor results based on what is most important to your organization. For example, perhaps your team is aiming to ensure that all images have alternate text by using the area-alt rule ID. See the full list of rule descriptions here for additional information.

📘

Limitations

  • Accessibility checks are only available for Chrome and Edge on the Unified runner.
  • Accessibility check results are not available during trainer replay at this time
  • Minimal information on accessibility checks can be viewed during local runs. For complete results, the test must be executed in the cloud.

Accessibility Reporting

In addition to running accessibility checks against your application, mabl also provides comprehensive reporting on accessibility violations. Learn more about the reporting dashboard here.


Did this page help you?