Policy For Accessability Testing Bot - Keep Published

Version 2

Quick Summary

This policy mandates the integration of an automated Accessibility Testing Bot into the CI/CD pipeline for all digital products to enforce WCAG 2.1 AA as a baseline standard. A key requirement is that the bot will automatically fail any build that introduces new high-severity accessibility violations, which must be remediated before code can be merged. While the bot serves as a first line of defense, it must be supplemented by manual testing and expert audits.

1. Purpose

This policy establishes the official guidelines for the integration, use, and management of the automated Accessibility Testing Bot. The purpose of this policy is to embed accessibility testing directly into the software development lifecycle (SDLC), ensuring our digital products are consistently evaluated against established accessibility standards. By automating baseline checks, we aim to proactively identify and remediate accessibility barriers, uphold our commitment to inclusivity, and reduce the risk associated with non-compliance to accessibility regulations.

2. Scope

This policy applies to all employees, contractors, and teams involved in the design, development, testing, and deployment of company-managed digital products, including but not limited to:

  • Websites and web applications
  • Mobile applications
  • Internal software and tools

This policy governs all new development and all major updates to existing digital products. It specifically pertains to any project with a source code repository and a Continuous Integration/Continuous Deployment (CI/CD) pipeline.

3. Policy Statement

The company mandates the use of the Accessibility Testing Bot as a foundational component of our quality assurance and development process. The following principles are central to this policy:

3.1 Mandatory Integration

The Accessibility Testing Bot must be integrated into the CI/CD pipeline for all projects within the scope of this policy. Scans must be configured to run automatically on code commits, pull requests, or builds to provide immediate feedback to developers.

3.2 Baseline Standard

All automated scans will be configured to test against the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standard, unless a higher standard is required by specific project or legal requirements. This serves as the minimum baseline for accessibility compliance.

3.3 Zero-Tolerance for New High-Severity Issues

Builds or pull requests that introduce new, high-severity or critical accessibility issues, as identified by the bot, must be configured to fail. These issues must be remediated by the developer before their code can be merged into the main branch. This "shift-left" approach prevents the accumulation of accessibility debt.

3.4 Remediation of Existing Issues

All teams are responsible for creating a backlog of existing accessibility issues identified by the bot upon its initial integration. These issues must be triaged, prioritized, and scheduled for remediation in subsequent development cycles, in collaboration with product managers and the accessibility team.

3.5 Acknowledgment of Limitations

Automated testing is a critical tool but does not replace the need for comprehensive accessibility auditing. The bot is recognized as a first line of defense to catch a significant percentage of common accessibility violations. It must be supplemented with regular manual testing and expert audits, especially for complex user interactions and workflows.

4. Procedures

4.1 Integration and Configuration

  1. Project Onboarding: Upon project initiation, the designated engineering lead is responsible for integrating the Accessibility Testing Bot into the project’s CI/CD pipeline, following the official documentation provided by the Engineering Tools team.
  2. Configuration: The bot must be configured to scan relevant code and components. The configuration file should specify the target WCAG standard and define which rules are active. Any modifications to the default rule set require documented approval from the Head of Accessibility or a designated equivalent.
  3. Dashboard Setup: Each team must ensure that scan results are being correctly reported to the central accessibility monitoring dashboard for visibility and tracking.

4.2 Issue Triage and Remediation Workflow

  1. Notification: The bot will automatically notify the developer or team via the CI/CD system (e.g., GitHub, GitLab) when an issue is detected.
  2. Validation: The developer must review the flagged issue to confirm it is a valid accessibility barrier.
  3. Remediation:
    • For new high-severity issues in a pull request, the developer must fix the issue before the code is merged.
    • For pre-existing issues, or new low/medium-severity issues, a ticket must be created in the team's project management tool (e.g., Jira). The ticket must include the issue description, its location, severity level, and a link to the bot's report.
  4. Verification: Once a fix is implemented, the code must be re-scanned by the bot to verify that the issue has been successfully resolved.

4.3 Exception and False Positive Handling

  • False Positives: If an issue is determined to be a false positive, it must be documented and suppressed within the bot’s configuration. The reason for the suppression must be clearly noted in the configuration file or an associated ticket.
  • Exception Requests: In rare circumstances where a high-severity issue cannot be immediately remediated without significant negative impact, a team lead may submit a formal exception request. The request must include a detailed justification, a risk assessment, and a proposed timeline for future remediation. Exceptions require approval from both the Head of Engineering and the Head of Accessibility.

5. Compliance

5.1 Monitoring and Auditing

The Accessibility Governance Team, in partnership with Engineering Leadership, is responsible for monitoring compliance with this policy. This will be achieved through:

  • Regular audits of the central accessibility monitoring dashboard to track issue trends, remediation rates, and overall product health.
  • Periodic reviews of project repositories to ensure the bot is properly integrated and configured.
  • Quarterly reports shared with leadership on the organization's accessibility posture.

5.2 Non-Compliance

Failure to adhere to this policy will be addressed through a standard escalation process:

  1. Initial Notification: The non-compliant team and their direct manager will receive a formal notification detailing the policy violation and required corrective actions.
  2. Escalation: If the violation is not addressed within the specified timeframe, the issue will be escalated to the relevant Director or VP-level leadership.
  3. Consequence: Persistent non-compliance may result in project deployment freezes, reallocation of resources, and may be factored into team and individual performance reviews.

5.3 Policy Review

This policy will be reviewed annually, or as needed, by the Accessibility Governance Team to ensure it remains effective, relevant, and aligned with industry best practices and evolving legal standards.