At a glance
An HTML alternative should preserve the document’s important meaning and reader tasks, link clearly to the original PDF and identify the source version it represents. Review the exact alternative before publication and update both routes deliberately when the source changes. A PDF-to-HTML conversion alone does not approve either version.
The alternate format and source remain understandable as two views of a defined revision.
| Publication item | Example requirement | Verification |
|---|---|---|
| HTML alternative | Current policy, revision 3 | Text, tables and navigation reviewed |
| Original PDF | Retained download | Correct file and descriptive link |
| Source update | Revision 4 changes instructions | Re-review affected content |
| Reader feedback | Report a document barrier | Visible correction route |
Scroll sideways to see all columns. Use arrow keys when the table is focused.
Make the format choice clear
Use link text that says what the document is and which format opens. Readers should not have to infer that an icon-only link is a PDF or that an HTML alternative has a different revision. Include meaningful title, language and publication context.
Give the HTML real headings, lists, tables, links and descriptions where the content requires them. Preserve essential forms or interactions through a reviewed task path; a visual transcription of a form is not necessarily a usable way to submit it.
- Agree on the source revision and required reader tasks.
- Review the HTML meaning and interaction.
- Offer descriptive links to the appropriate formats.
- Bind approval to the exact output.
- Record how source changes and reader feedback will be handled.
Inspect fidelity and usability separately
Compare the source and HTML for omissions, changed numbers, lost qualifications and table relationships. Then test keyboard navigation, meaningful sequence, form behavior and a suitable assistive-technology workflow. Automated findings can support this work but do not replace it.
If the original visual layout matters, retain the original and describe the alternative honestly. A rebuilt PDF may have a different layout, while original-layout export can be unavailable for unsupported or unverified structures. Do not quietly substitute one output for another.
Maintain one understandable revision relationship
When the source changes, compare revisions and re-review affected output before updating the public mapping. Keep the prior publication record so feedback can be traced to the version the reader used. Ownership, review evidence and correction responsibilities belong in that record.
For search indexing, make each public route’s purpose clear and use canonical signals consistently with your intended indexable version. Canonicalization is not a document-identity or accessibility test. Private drafts and capability reports should not be exposed as public alternatives.
| Question | Required record |
|---|---|
| Which source? | Revision or digest |
| Which output? | Approved version |
| Which checks? | Scope, results and unresolved findings |
| Who owns updates? | Named responsible team |
| How can readers report a barrier? | Public correction route |
Scroll sideways to see all columns. Use arrow keys when the table is focused.
Sources and scope
Methods, worksheets and illustrative examples are DocAccessible editorial contributions. These references support the technical or product details described above. W3C techniques are informative guidance; they are not a certification scheme.
- DocAccessible remediation options
The different output paths and their review requirements.
- W3C: evaluating web accessibility
Automated tools and knowledgeable human evaluation serve different roles.
- Google Search Central: canonical URLs
Canonicalization is a search signal; it is not a file-identity test.
Written by the DocAccessible team under our editorial policy. Suggest a correction if a source or product detail needs updating.