7. Accessibility criteria and enforcement

Local snapshot only. The workspace page is authoritative.

7.1 Baseline and scope

FY27 PDS component work targets WCAG 2.0 Levels A and AA, consistent with the FY27 developer ticket. FY28 will consider a higher WCAG 2.1 A/AA baseline. Any change to the stated baseline requires a recorded governance decision and the applicable design, engineering, and QA/accessibility gates.
PDS accessibility applies to the component’s supplied semantics, interaction, defaults, and documented consumer responsibilities. Product teams remain accountable for page-level focus order, journey flows, content alternatives, form behavior, composition, and end-to-end accessibility of the assembled product.
A PDS component status is not certification of the consuming application.

7.2 FY27 assurance model

FY27 has no embedded or standing QA. Before Beta, the assigned developer and Design Ops Product Designer must produce or review the applicable evidence for:

• automated accessibility checks such as axe or the approved equivalent;
• keyboard-only operation;
• focus order, movement, restoration, and visibility;
• semantic markup;
• programmatic names, roles, states, values, errors, and status messages;
• contrast and non-color cues;
• zoom, reflow, and text spacing;
• high-contrast or forced-colors behavior where supported;
• motion preferences when the component moves or animates;
• disclosed known limitations.
  Automated checks never substitute for manual evidence. A component cannot become Stable when its applicable qualified manual checks have not been completed. In that case it remains Beta or lower with the unmet gate visible.
  An inner-source contributor supplies the accessibility evidence required by the assigned item and corrects findings within the approved scope. Contributor authorship is not accessibility approval: the accountable design, engineering, and borrowed QA/SDET roles retain their existing evidence and go/no-go authority.
  Borrowed QA/SDET may be scheduled for defined consultation, test execution, and sign-off. QA/SDET owns only the evidence it performs and cannot approve by absence. FY28 intends to establish dedicated accessibility-capable QA ownership for the manual test matrix, regression evidence, and the QA portion of maturity and major-change gates.
  These controls adapt the combined automated/manual approach documented by GOV.UK, Primer, and Carbon. (GOV.UK, Primer, Carbon)

PROPOSED accessibility evidence record schema

The governing document requires an accessibility record without specifying its schema. A per-component record, proposed:

component: pds-alert
version_tested: 1.2.0
target_criteria: "WCAG 2.0 A/AA"
test_date: 2026-08-10
environments:
  browsers: [Chrome, Edge, Safari]
  assistive_technologies: [NVDA, VoiceOver]   # only what was actually run
automated:
  tool: axe-core
  result: pass
  date: 2026-08-10
manual:
  keyboard_only: pass
  focus_order: pass
  semantic_markup: pass
  contrast: pass
  screen_reader: not_performed        # gaps are disclosed, not omitted
defects:
  - id: A11Y-DEF-014
    severity: serious                  # see Section 7.3 taxonomy
    description: "Accessible name missing when Alert wraps a link"
    status: open
reviewer: <name>
residual_limitations:
  - "Manual screen-reader pass not yet performed — Beta only, not Stable"
consumer_responsibilities:
  - "Consumers must supply their own alt text for any icon slot content"
lifecycle_decision_supported: "Beta promotion, 2026-08-14"

7.3 Component/product responsibility boundary

Every Beta and Stable component page separates:

• PDS guarantees: supplied semantics, component-level keyboard behavior, tested states, supported configuration, and known limitations;
• consumer responsibilities: accessible labels and content, composition, page-level focus, validation, localization, and end-to-end task testing.
  Extended components remain product-team owned. Their record must include an owner, automated-check results, keyboard and semantic review, known limitations, and available product-specific manual evidence. An Extended component cannot become Core Beta or Stable until the applicable PDS evidence and domain gates pass.

7.4 Applicable fr-CA accessibility and localization checks

Flexible sizing and content accommodation are universal component-quality requirements. French is not treated as an exceptional layout condition.
Additional fr-CA checks apply when a component contains built-in strings, accessible names, descriptions/messages, or locale-sensitive formatting:

1. Built-in strings: Every built-in visible string, instruction, error, and status message has an approved fr-CA resource. Locale switching produces the French resource without missing keys, unintended English fallback, or translation-breaking concatenation.
2. Accessible names: Every control exposes the intended French programmatic name. When a visible French label exists, its text is included in or matches the accessible name. Localized descriptions, states, errors, and status announcements remain correctly associated.
3. Language exposure: French content or a language change is programmatically identified so assistive technology can apply the appropriate pronunciation rules.
4. Localized formatting: Dates, times, numbers, currency, percentages, and other locale-sensitive values use locale-aware fr-CA data and produce the approved output rather than a hard-coded English/Canadian format.
5. Manual assistive-technology check: When applicable, a supported screen reader announces the localized name, role, state/value, instructions, errors, and status messages correctly in the French context.
   Components without applicable built-in or locale-sensitive behavior record the checks as not applicable; they still pass the universal flexibility and ordinary accessibility gates.

7.5 Accessibility evidence

Every applicable accessibility gate must link to the evidence actually reviewed by the accountable domain owner. An unavailable or undefined evidence record is not a pass. The authoritative record format, required fields, reviewer qualifications, refresh trigger, and retention policy remain open.
Open — pending Core team: borrowed-QA scheduling. Decide how FY27 QA/accessibility consultation is requested, prioritized, scheduled, and protected; which components or changes receive scarce manual review; required lead time; and what happens when the requested capacity is unavailable.
Open — pending Core team: accessibility evidence record. Decide the authoritative storage location and required schema, including whether it must record component/version, target criteria, test date, environments, assistive technologies, automated results, manual checks, defects, evidence links, reviewer, residual limitations, consumer responsibilities, and the lifecycle decision supported. Also decide reviewer qualifications, refresh triggers, and retention rules.
Open — pending Core team: accessibility defect consequences. Define the defect-severity taxonomy and its effect on Alpha, Beta, Stable, release urgency, support, deprecation, and consumer notification. Until that rule is approved, a failed required gate or undisclosed material limitation cannot be treated as Stable.