Building an accessible document policy

Remediation projects end; publishing does not. Without a policy that assigns standards, roles and gates, a remediated site drifts back to inaccessible within a couple of budget cycles. This guide is an outline of the document policy itself — the sections it needs, what each should say, and how to make it stick.

Why do we need a document policy at all?

Because the failure mode is organizational, not technical. Documents are published by dozens of people across departments, each with their own templates and habits. A policy converts "accessibility is everyone's job" into specific defaults, named owners and a gate — the three things that survive staff turnover.

• The drift problem after remediation projects
• Policy vs. training: defaults beat reminders
• What auditors and complainants ask to see first

What scope and standards should the policy set?

State plainly what is covered — every document published to any public-facing property, including the LMS and social attachments — and the standard it must meet: WCAG 2.1 AA, with PDF/UA as the target profile for PDFs. Name the exceptions process rather than leaving exceptions to imagination.

• Covered properties and document formats
• WCAG 2.1 AA / PDF/UA as the named standards
• How a document gets an exception, and who signs it

Who owns what under the policy?

Give every covered property a named publishing owner, make authors responsible for using accessible templates, a coordinator responsible for the program, and leadership responsible for resourcing it. The policy should also name who answers accessibility feedback and within what time.

• Author, owner, coordinator, leadership: the four roles
• The feedback channel and response clock
• Procurement's role: no new inaccessible document sources

What workflow gates make the policy real?

Two gates carry most of the weight: templates (documents start accessible) and a publish check (documents cannot go live failing machine checks). Add a remediation path for third-party and legacy documents, and a monitoring loop that catches whatever slips past both gates.

• Approved accessible templates per document type
• The automated publish gate and its failure behavior
• Handling third-party documents you must post
• Monitoring as the safety net, with owner notifications

How do we measure whether the policy works?

Track the inflow, not just the stock: share of newly published documents passing checks, time from detection to fix for failures, backlog trend, and feedback response times. Publish a short annual summary — measurement that nobody sees changes nothing.

• The four metrics that matter
• Dashboards from monitoring data
• Annual review and policy revision cadence

How does DocoMatic support a document policy?

DocoMatic operationalizes the gates: it monitors your domains continuously, checks and remediates new documents as they appear, and gives the coordinator the metrics the policy commits to — pass rates, fix times and evidence per document — without building any of that in-house.

• Continuous monitoring as the enforcement layer
• Automatic remediation of gate failures
• Reporting aligned to the policy's metrics