Accessibility Checklist for User Documentation

This checklist supports documentation teams in ensuring that user-facing content is accessible to all users, including those using assistive technologies. It can be applied during content creation, review, and pre-publication.

Scope

Applies to:

• All user documentation (guides, tutorials, help pages).
• PDF, HTML, and Markdown outputs.
• Docusaurus-based sites and static documentation.

Checklist items

ID	Area	Requirement	Check method	Applies to
A1	Headings	Use proper heading hierarchy (#/H1, ##/H2, ###/H3) in logical order.	Markdown/Docusaurus output.	All docs.
A2	Images	All images include descriptive alt text.	Manual review or linter.	All embedded images.
A3	Links	Use meaningful link text (avoid "click here", "read more").	Manual or link scanner.	All links.
A4	Tables	Tables include headers and logical structure.	Markdown structure, visual test.	Data or layout tables.
A5	Lists	Use semantic lists (-, *, or 1.) instead of manual indents.	Markdown validation.	Instructional content.
A6	Color Contrast	Ensure sufficient contrast between text and background.	Contrast checker.	Web output, images.
A7	PDFs	Exported PDFs have tagged structure, alt text, and selectable text.	PDF reader with accessibility mode.	Exported documentation.

Best practices

• Avoid using color alone to convey meaning.
• Use descriptive headings and consistent terminology.
• Avoid jargon or explain it in context.
• Test documentation with screen readers (e.g., NVDA, VoiceOver).
• Use plugins for a11y enhancements.

RACI

Role	Responsibility
Technical Writer	R (executes)
Accessibility Expert	C (consults)
QA Tester	C (validates)
Product Owners	I (informed)
Documentation Owner	A (approves)

Tailoring

• Adjust based on the delivery format (web vs PDF).
• Include additional items for compliance (e.g., EN 301 549, Section 508) if required.
• Use automated tools where available, but always include manual review.