Accessibility Governance Risk And Deferment

Core Workflow

1. Front Stage (Release & Attestation):

   • Product Owners (PO) must include accessibility details in the Test Completion Report (TCR).
   • POs must file a release request in ServiceNow and complete an Accessibility Attestation.
   • Documentation: Teams must attach an "Accessibility Attestation Spreadsheet" to the ServiceNow form. This spreadsheet must include details of current release defects, a comprehensive archive of all logged defects, and high-level metrics.
   • Attestation Content: Summary of total issues, count of unresolved issues by severity, and a remediation plan for partially compliant products.
   • Release Policy: Do not block product release due to accessibility issues. Ensure the product is released but the accessibility effort is recorded.

2. Severity Ratings System: Use the following 4-tier scale strictly when categorizing defects:

   • 1 - Critical: Issues causing complete barriers for user groups, making essential functions unusable. No workarounds. (e.g., form cannot be submitted via keyboard).
   • 2 - High: Issues significantly affecting access to essential info/functionality. Substantial hurdles, complex workarounds. (e.g., missing alt text for important images).
   • 3 - Medium: Issues impeding access to non-critical info/functionality. Inconvenience or delay. (e.g., insufficient contrast for non-essential text).
   • 4 - Low: Issues affecting ease/convenience but not core functionality. Minor issues. (e.g., missing alt text for decorative images).

3. Back Stage (Audit & Governance):

   • Verify the accessibility attestation details in ServiceNow and the attached spreadsheet.
   • Conduct "Sample checks" or "Sample audits" to validate claims.
   • Compliance Determination:
     • Sufficiently Accessible: No Critical (1) or High (2) severity bugs found. Mark as accessible. Educate team to fix Medium/Low bugs.
     • Non-Accessible: Critical (1) or High (2) severity bugs found. Mark as Non-compliant.

4. Risk Management (Archer):

   • For Non-compliant products, create a "risk" in the Risk Management System (Archer).
   • Raise a "finding" explaining the risk.
   • Assign risk ownership to the Product Owner.
   • Create "Action items" in Archer outlining steps for the PO to take.
   • Coordinate additional accessibility training for the PO's team.

5. Deferment & Exception Evaluation: Evaluate requests for "Accessibility Deferment" or exceptions against the following strict criteria:

   • When Deferment is Valid: Technical limitations preventing immediate compliance; Legal/regulatory conflict; Project started before ACoE/framework establishment; Third-party dependency with no timeline for compliance.
   • When Deferment is Not Needed: Product has no human-facing interface; Special-purpose software where no users have identified disabilities affected; Internal research use where no team members have identified disabilities affected (must consult ACoE).
   • Rejection Criteria (Do Not Approve): Lack of genuine effort; Budgetary convenience; Prioritizing aesthetics/convenience over inclusion; Recurring or preventable issues; Absence of a clear resolution plan.

Anti-Patterns

• Do not block the release pipeline for accessibility issues; focus on recording and post-release remediation.
• Do not invent new severity levels or tools outside the specified list.
• Do not suggest email submission; use ServiceNow only.
• Do not alter the specific definitions of the severity ratings.
• Do not approve deferments based solely on tight deadlines unless they fall under "Technical limitations" or "Changed standards/practices".
• Do not ignore the "Recurring or preventable issues" rule when evaluating exceptions.

Triggers

• Execute ACoE accessibility process
• Evaluate accessibility deferment request
• Manage accessibility compliance risk
• Review accessibility attestation and TCR
• Assess accessibility compliance exception