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.

📘

Access

Accessibility checks are available for users on Growth and Enterprise plans.

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

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.

📘

Page checks vs. element checks

Use page-level checks to understand the overall accessibility of your app. Use element-level checks when you have different accessibility standards for specific elements.

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.

586

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.

1412

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.

656

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.

586

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 NameAccessibility Standard
wcag2aWCAG 2.0 Level A
wcag2aaWCAG 2.0 Level AA
wcag2aaaWCAG 2.0 Level AAA
wcag21aaWCAG 2.1 Level AA
best-practiceCommon accessibility best practices
wcag***WCAG success criterion. For example, wcag111 maps to SC 1.1.1
ACTW3C approved Accessibility Conformance Testing rules
section508Old Section 508 rules
section508.*.*Requirement in old Section 508
experimentalCutting-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 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.