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.
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.

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.

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.

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.

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.
Updated about 2 months ago