Skip to content

PATTERN Cited by 1 source

VPAT-driven a11y triage

Pattern

VPAT-driven a11y triage is the end-to-end engineering workflow that turns a third-party VPAT (Voluntary Product Accessibility Template) audit report into an a11y remediation backlog, resolves or legitimately closes each finding, and retains the outcomes as an organisational learning artifact. The pattern structures the VPAT output — typically a ticket-per-finding list keyed by WCAG criterion and severity — into four resolution buckets, each with a distinct engineering response.

See concepts/vpat-voluntary-product-accessibility-template for the audit artifact itself.

Four resolution buckets

1. Shovel-ready fixes — resolve immediately

Findings with obvious fixes at the widget or attribute level: colour contrast, missing contentDescription / alt text, missing form labels, basic ARIA errors on web. Assign out to the responsible team, no triage required.

From Slack's VPAT post: "we immediately assigned the obvious shovel-ready issues, such as those with color contrast and missing image labels, to the responsible teams for resolution."

2. Recurring themes — resolve at component-library layer

Cluster the remaining tickets by underlying cause. Multiple tickets often collapse to one root — e.g. several "error not announced" tickets across different screens collapse to one OutlinedTextField / SKBanner fix in the component library. Resolve at the component layer so every consumer picks up the correction for free.

Slack's 2025-11-19 post canonicalises this posture by repeatedly framing fixes at SK layer: "we modified OutlinedTextField...", "SKBanner for the error type was updated...", "we introduced a new SKListAccessibilityDelegate for SKListAdapter...". See patterns/accessibility-delegate-override-for-semantic-fix for the specific mechanism at Android component-library layer.

3. Platform-convention divergences — close with rationale

VPATs often apply WCAG mappings written for web to native platforms where the conventions differ. Cross-check against native first-party apps (Google apps on Android, Apple apps on iOS). If the platform convention is observably different and has user-experience rationale, close the ticket with a documented rationale citing platform convention.

Canonical examples from Slack: top-app-bar title not marked as heading (WCAG 1.3.1 — closed after testing Google apps); strikethrough not announced (WCAG 1.3.1 — closed after consulting blind community). See concepts/wcag-platform-applicability-gap.

Watch-out: this bucket is frequently abused as a way to avoid fixing bugs. The rationale must be cross-validated — observable in native first-party apps, backed by user research or community consultation, and documented in a form future auditors can reference.

4. Scope-bounded deferrals — explicit not-planned

Findings for WCAG criteria that don't meaningfully apply to the current product surface. Mark as not planned with a rationale tying the deferral to product scope.

Canonical example from Slack: WCAG 2.1.1 Keyboard Navigation (Level A) — Slack Android has no large-form-factor (tablet) support, which is the primary surface where keyboard nav matters. "We have decided to explore other solutions that align with recommended practices and standards." The deferral carries forward as an open commitment to revisit when the product surface expands.

Workflow

  1. Commission — third-party a11y vendor conducts audit, delivers ticket-per-finding report keyed by WCAG criterion and internal priority (P1/P2/P3).
  2. Bucket 1 assignment — shovel-ready fixes to responsible teams.
  3. Theme clustering — remaining tickets grouped by underlying cause.
  4. Design-team collaboration — ambiguous UX decisions (e.g. Edit mode vs always-visible drag handles) resolved with a11y-minded design partners.
  5. Community / user consultation — decisions about what assistive-tech users actually want (Slack's strikethrough decision) backed by consultation.
  6. Component-library fixes — themes resolved once at the component-library layer.
  7. Platform-applicability closures — cross-check against native first-party apps; close with rationale.
  8. Scope-bounded deferrals — explicit not-planned for out-of-surface criteria.
  9. Retrospective — publish learnings (what Slack's 2025-11-19 post is).
  10. Automated-regression coverage — fixed issues should ideally be covered by automated a11y tests (see concepts/automated-vs-manual-testing-complementarity; Slack's automated layer is [[sources/2025-01-07-slack-automated-accessibility-testing- at-slack|Axe-in-Playwright]]).

Composition with other patterns

Seen in

  • sources/2025-11-19-slack-android-vpat-journey — Slack's canonical retrospective on applying this triage workflow to the 2024 VPAT audit's Android findings; 8 themes (7 resolved, 1 deferred), with representatives of all four resolution buckets.
Last updated · 470 distilled / 1,213 read