Accessibility Governance for Data Products

Accessibility in a data product is not achieved once; it is maintained. Grids, charts and dashboards change every sprint, component libraries upgrade, new teams join, and each change can quietly break what worked. The patterns elsewhere on this site describe how to build accessible data interfaces; this topic describes how organisations keep them accessible — through requirements that make accessibility testable, records that make gaps visible, processes that respond quickly when things break, and research that reveals whether real people can do their work.

The users affected are every disabled user of the product, because governance determines whether fixes happen at all and how fast regressions are repaired. Inside the organisation, it affects product owners (who write requirements), engineers and QA (who build and test), design system teams (who own shared components), sales and legal (who rely on conformance reports) and leadership (who fund the work). The failure this topic prevents is the common cycle: a big accessibility push before a contract, a year of gradual decay, another push.

This topic belongs to testing & auditing accessible data interfaces.

WCAG criteria in scope

Governance covers all of WCAG 2.2 A and AA in principle. In data products, a handful dominate requirements, debt and regressions:

Criterion	Level	Why it dominates in data products
1.1.1 Non-text Content	A	Charts and visual indicators
1.3.1 Info and Relationships	A	Table and grid structure
1.4.1 Use of Color	A	Status colours, series, highlights
2.1.1 Keyboard	A	Custom grids, drag interactions
2.4.3 Focus Order	A	Focus loss after updates
2.5.7 Dragging Movements	AA	Column reorder, brushing, layouts
4.1.2 Name, Role, Value	A	Icon buttons, custom widgets
4.1.3 Status Messages	AA	Sorting, filtering, background jobs

Prerequisites

Working knowledge of the patterns your product uses, across accessible data tables & grid systems and core ARIA & keyboard navigation for data UIs.
A testing baseline: automated accessibility testing pipelines and manual accessibility audits.
A component library or design system, ideally with documented accessibility contracts — see accessible data component libraries.

Each step produces input for the next; skipping one breaks the loop.

ARIA & HTML spec reference

Governance artefacts reference specifications rather than implement them. Keep these references consistent across criteria, debt entries, bug reports and ACRs:

Reference	Use in governance
WCAG 2.2 success criteria numbers	Every criterion, debt entry and ACR row
WAI-ARIA 1.2 / Authoring Practices patterns	Expected behaviour in acceptance criteria
HTML-AAM / Core-AAM	Evidence in browser bug reports
EN 301 549 clauses	Non-web documents (exports) and software in EU procurement
Section 508	US federal procurement

Step-by-step implementation

Step 1 — Acceptance criteria

Given focus on the "Amount" header, when Enter is pressed, then rows sort ascending and "Sorted by Amount, ascending" is announced

See writing accessibility acceptance criteria for data grids.

Step 2 — Debt register

- id: GRID-014; criteria: ["2.5.7"]; severity: blocker; workaround: "Columns menu"

See tracking accessibility debt in component libraries.

Step 3 — Regression triage

Reproduce → assess impact → find cause → respond → add test

See accessibility regression triage for data UIs.

Step 4 — Research

participants: 6; screen_readers: [NVDA, JAWS, VoiceOver]; tasks: [T1, T2, T3]

See usability testing with screen reader users.

Step 5 — Conformance reporting

1.1.1 — Partially Supports — Charts provide summaries and tables; Network map lacks an alternative (fix in 7.4).

See VPAT and ACR for data-heavy products.

Step 6 — Report progress

A one-page summary per release: open blockers and majors, regressions and time to fix, study findings addressed, ACR changes.

Shared responsibilities, each with a clear owner.

Keyboard interaction contract

Governance does not define key bindings, but it should make sure every product’s grids follow the same contract so users learn it once. Keep one documented contract in the design system and reference it in acceptance criteria:

Key	Contract	Where enforced
Tab	One stop per grid	Acceptance criteria; Tab stop tests
Arrows	Cell or row navigation	Component tests
Enter / Space	Activate, sort, select	Acceptance criteria
Escape	Cancel or close one layer	Component tests
Shift+F10	Row context menu	Component tests

Governance decides which combinations the product commits to supporting, and says so in the ACR:

Combination	Support commitment	Test frequency
NVDA + Firefox, NVDA + Chrome	Supported	Every release candidate
JAWS + Chrome	Supported	Every release candidate
VoiceOver + Safari (macOS)	Supported	Every release candidate
VoiceOver + Safari (iOS)	Supported for mobile flows	Monthly
TalkBack + Chrome	Supported for mobile flows	Monthly
Narrator + Edge	Best effort	Quarterly

Edge cases & failure modes

1. Accessibility as a final-sprint task

Diagnosis: criteria added at the end, never tested. Fix: criteria in refinement; QA tests them like functional criteria.

2. Invisible debt

Diagnosis: known gaps live in people’s heads. Fix: a register with component docs generated from it.

3. Regressions in the backlog

Diagnosis: blocking regressions wait weeks. Fix: incident-style triage.

4. Optimistic ACRs

Diagnosis: “Supports” everywhere; buyers find failures. Fix: honest partial support with remarks.

5. No real users

Diagnosis: decisions based only on audits. Fix: regular studies with screen reader users.

Writing accessibility acceptance criteria for data grids

Concrete Given/When/Then criteria for keyboard, announcements and visuals, mapped to WCAG and to test methods, drawn from a shared library. See writing accessibility acceptance criteria for data grids.

Then focus remains on the "Amount" header

VPAT and ACR for data-heavy products

Scope, evaluation methods, honest conformance levels and remarks that name features, workarounds and plans — dated and reviewed each release. See VPAT and ACR for data-heavy products.

Conformance Level: Partially Supports

Tracking accessibility debt in component libraries

One entry per issue, severity by user impact, linked products and workarounds, conformance status in docs and a burn-down for leadership. See tracking accessibility debt in component libraries.

severity: blocker

Accessibility regression triage for data UIs

Reproduce with the reported AT, assess impact, find the cause with tree diffs or bisecting, respond quickly, add a test. See accessibility regression triage for data UIs.

console.log(diff(good.yaml, bad.yaml));

Five to eight compensated daily users, realistic tasks, remote sessions with audio, synthesis by task and severity. See usability testing with screen reader users.

participants: 6

Cross-cutting concerns

Ownership. Shared responsibility without named owners becomes no one’s responsibility. Name owners for the criteria library, the debt register, triage and the ACR.

Metrics that matter. Count blockers and majors open, median time to fix regressions, criteria coverage on stories, and task success in studies. Avoid vanity metrics like “number of axe rules passing”.

Training. Governance depends on people who can write criteria, rate severity and diagnose issues. Short, regular training — with the inspection tools and the patterns on this site — keeps skills spread across teams.

Procurement and legal. Contracts increasingly include accessibility clauses. Keep legal and sales informed through the ACR and the debt register so commitments match reality.

Four quarters to move from ad hoc pushes to a sustained practice.

Worked example: from audit panic to steady practice

A data analytics company faced a failed accessibility review during a large public-sector deal. Previous efforts had been one-off audits before big contracts. This time, leadership funded governance rather than a sprint: a criteria library of 40 grid and chart statements, a debt register seeded from the audit (67 entries, 9 blockers), a regression triage process using the incident tooling, two usability studies a year with screen reader users, and a rewritten ACR with honest remarks. Twelve months later, blockers were at zero, median time to fix regressions had fallen from five weeks to three days, and the next procurement review passed with a remediation plan for the remaining majors.

Who is affected, and how

Group	Without governance	With governance
Disabled users	Fixes come and go	Steady improvement; fast regression fixes
Product owners	Surprise failures late	Requirements up front
Engineers	Speculative fixes	Clear criteria and evidence
Sales and legal	Unreliable claims	Honest, defensible reports
Leadership	Periodic crises	Measurable progress

Common mistakes

Project thinking. A push before a deal, then nothing until the next one.
Audits without follow-through. Findings delivered as a PDF and never turned into tracked work.
Compliance without users. Conformance reports with no evidence that real users can complete tasks.
Everyone and no one owns it. Responsibilities spread so thin that nothing moves.
Metrics that flatter. Counting passing automated rules instead of open blockers and time to fix.

Getting started in one quarter

Week 1: name owners for criteria, debt and triage. Weeks 2–3: write a criteria library for the three most-used grid patterns and add them to refinement templates. Weeks 4–6: seed the debt register from the latest audit and existing tickets, rate severity, publish component status. Weeks 7–8: agree the regression triage process with the incident team. Weeks 9–12: run a first small usability study and review the ACR against everything learned. By the end of the quarter, accessibility is part of how the product is built rather than something added afterwards.

Design system integration

The design system is governance’s strongest lever: component-level acceptance criteria, conformance status, debt entries and ARIA snapshot templates live with each component and reach every product that uses it. Publish them in documentation, generate reports from them, and treat component accessibility regressions as release blockers for the design system itself.

Testing checklist

Process

Every interactive story has accessibility acceptance criteria.
A debt register exists with owners, severity and workarounds.
Regressions follow a triage process and leave tests behind.

Evidence

Usability studies with screen reader users run at least twice a year.
The ACR is dated, based on testing, and reviewed each release.

Reporting

Leadership receives a burn-down and regression metrics each release.

FAQ

Where should a team start with governance?

With acceptance criteria for new stories and a debt register for known issues. Both are cheap and change behaviour quickly.

Does governance require an accessibility team?

It helps to have specialists, but most of the practices work with trained product teams and a small central function.

How do we justify the cost?

Procurement requirements, legal risk and — most directly — the cost of repeated crisis remediation compared with steady practice.

Should accessibility block releases?

New blockers and blocking regressions should. Known debt with workarounds and plans usually should not.

How do we keep criteria from becoming boilerplate?

Keep them specific to the story’s interactions and require a test method for each one.

How often should we audit?

At least annually by specialists, plus continuous automated testing and per-release smoke tests.

Who signs the ACR?

Someone with authority over product and legal claims, after review by whoever tested the product.

What is the most common governance failure?

Treating accessibility as a project with an end date instead of a quality attribute maintained like performance or security.

How does governance interact with agile delivery?

It fits inside it: criteria in refinement, tests in the definition of done, debt in the backlog with severity, triage alongside incident management, and studies on the research calendar. No separate process is needed.

What should we measure first?

Open blockers and median time to fix accessibility regressions. Both are easy to count and directly reflect users’ experience.

How do we involve disabled employees?

Invite them, compensate their time as expert input, and never make them the only testers or the default sign-off. Their perspective is valuable; the responsibility belongs to the whole team.

Does an accessibility statement on the website count as governance?

It is a useful public commitment, but only if it reflects the ACR and the debt register. A statement without the practices behind it is marketing.

Manual accessibility audits — periodic expert review
Automated accessibility testing pipelines — continuous checks
Accessibility tree & API inspection — diagnosis tools
Design system tokens & component contracts — governance in components
Accessible data component libraries — where shared fixes live

← Back to Testing & Auditing Accessible Data Interfaces