Impact of rule engine customization

Understand how customizing the BrowserStack Accessibility Testing rule engine affects scan coverage, severity, compliance mapping, and reporting across dashboards.

Customizing the rule engine lets you tailor accessibility checks to your organization’s standards. You can enable or disable rules and adjust severities of specific rules. These changes directly impact issue counts, accessibility scores, compliance claims, and trend comparability.

Prerequisites

• Owner and Admin permissions to create and apply organization or project-level rule sets.
• Familiarity with WCAG versions and conformance levels (for example, WCAG 2.2 AA).
• Clarity on how your teams consume results in dashboards, APIs, and CI.
• You need to update the extension to use this feature in Workflow Analyzer.

Key impacts

The following are the key impacts of customiuzing the rule engine:

• Issue counts and score: Disabling rules reduces reported issues and can inflate scores. Changing the severity of rules affects the accessibility score.
• Cross-tool impact: When the rule engine is customized at the org level, users cannot make individual customizations in Workflow Analyzer, Website Scanner, or Automated tests.
• Organizational scope: Any change to rule customization changes the scope for the entire organization. Reverting to the original settings can be done only at the organizational level.
• Compliance mapping: Claims such as “WCAG 2.2 AA compliant” must reflect your configured scope. Disabling core rules can invalidate compliance assertions.
• Trends and baselines: Historical comparisons may not be apples-to-apples after changes. Establish new baselines or annotate change dates.
• Dashboards and APIs: Build summaries, issue breakdowns, and API responses reflect your active rule set at scan time.

Why customize

• Align to policy: Match checks to internal standards or regulatory scope.
• Reduce noise: Deprioritize rules that are non-applicable and focus on meaningful issues.
• Phased adoption: Gradually raise the bar by tightening rules over time.

What you can customize

• Enable or disable rules: Control whether a rule contributes to issues.
• Override severity: Change rule severity (for example, Serious → Critical) to affect prioritization and score impact.

Best practices

The following are a few best practices for customizing the rule engine:

• Version rule sets: Use semantic names (for example, Org-Standard v1.1) and keep a changelog.
• Pilot first: Validate before org-wide rollout.
• Review after engine updates: Reassess customizations when the rule engine is upgraded.
• Document governance: Record owners, review cadence, and approval steps.
• Annotate reports: Note rule-set changes in dashboards for future readers.

Rollback and audit

• Revert to a previous version of the rule set if a change introduces noise or hides critical issues.
• Maintain an audit trail of what changed, who approved it, and when it was applied.

Related links

• Severity of rules
• Rule repository
• Diagnose inconsistencies in issue counts
• Accessibility score calculation