Test-level rule configuration

Define specific rule sets for individual tests or groups of tests within your build.

You may not want to apply the same accessibility checks to all tests in your build. Some tests can cover workflows at different stages of remediation, while others can have temporary waivers or region-specific compliance requirements. With test-level rule configuration, you can apply different rule sets to different tests within the same build, giving you granular control over accessibility testing.

Use cases

Test-level rule configuration helps you:

• Incremental remediation: Relax specific rules for legacy flows while enforcing strict checks on newly developed features, enabling gradual accessibility improvements without blocking CI.
• Region-specific compliance: Apply stricter rule sets to tests covering regions with higher accessibility standards while maintaining baseline checks elsewhere.
• Focused testing: Exclude rules that don’t apply to specific workflows. For example, exclude color-contrast checks from tests for a dark mode feature where contrast is intentionally low.
• Test suite organization: Group tests by accessibility compliance level and apply appropriate rule sets to each group.

How to configure

Add the accessibilityTestProfiles section under accessibilityOptions in your test configuration file. Specify each profile with a combination of the following parameters based on your targeting needs:

For valid rule IDs and category names, see Accessibility rule mapping.

Basic configuration

The following configuration demonstrates exclusions added at the build level directly in the accessibilityOptions section and at the test-level exclusions in the nested accessibilityTestProfiles section.
The test-level profile uses testName to target a specific test with an exact name match.

The following table summarizes the rules excluded for each test in the build based on the above configuration:

Wildcard patterns

The following configuration demonstrates exclusions added at the build level directly in the accessibilityOptions section and at the test-level exclusions in the nested accessibilityTestProfiles section.
The test-level profile uses testName for exact name matches and testNamePattern with wildcard (*) to target multiple tests.

The following table summarizes the rules excluded for each test in the build based on the above configuration with wildcard patterns:

Example

The following example demonstrates how a test-level configuration with multiple profiles is applied to a test case.

Configuration

The following configuration defines build-level exclusions in the accessibilityOptions section as well as multiple test profiles with both exact and wildcard matches in the nested accessibilityTestProfiles section:

accessibilityOptions: {                     
  excludeRule: ["imageview-element-label", "non-text-contrast"], // Build-level exclusions
  accessibilityTestProfiles: [              // Test-level exclusions
    {
      testName: "Login Test",               // Exact name match
      excludeRule: ["duplicate-accessibility-label"]
    },
    {
      testNamePattern: "Login *",           // Wildcard match
      excludeRule: ["readable-text-spacing"]
    }
  ]
}

Result

For this configuration, BrowserStack App Accessibility applies the following exclusions:

• Build-level exclusions (imageview-element-label, non-text-contrast) apply to all tests in the build.
• The duplicate-accessibility-label rule is excluded only for the test named “Login Test”.
• The readable-text-spacing rule is excluded for any test whose name starts with “Login “.

Test-level resolution

When the test named “Login Test” runs, BrowserStack App Accessibility determines the applicable exclusions as follows:

1. Build-level exclusions always apply. As a result, imageview-element-label and non-text-contrast are excluded.
2. The test name exactly matches testName: "Login Test". As a result, duplicate-accessibility-label is excluded.
3. The test name also matches the wildcard pattern "Login *". As a result, readable-text-spacing is excluded.

Final exclusions for “Login Test”:

• imageview-element-label
• non-text-contrast
• duplicate-accessibility-label
• readable-text-spacing

Troubleshooting

• Rule ID and Rule Category mismatch: In your configuration, ensure that you specify rule IDs and categories that match exactly with the valid IDs and categories defined by BrowserStack. If you specify an invalid rule ID or category name, the system logs a warning but continues execution. For valid rule IDs and category names, see Accessibility rule mapping.
• Test name mismatch: Test names are case-sensitive. Ensure the testName or testNamePattern matches exactly how the test name appears in your test framework.
• No tests matched: If a profile doesn’t match any tests, it’s silently ignored. Check your test naming and wildcard patterns.
• Category vs rule precedence: If you exclude both a rule category and individual rules from that category, the category exclusion takes precedence, and all rules in the category are excluded.

Next steps

• After each test runs with its specific rule set, you can view which rules were executed and excluded for each test in the App Accessibility test report.

• For more configuration options, see Configuration options.