General Accessiblity Principles
Accessible documents don't happen by accident. They are the result of deliberate decisions made throughout the authoring process — from how you structure a Word document to how you export it as a PDF. The principles on this page apply across every document type and every tool covered in this guide.
The practices on this page are grounded in the POUR principles covered in Why Accessibility Matters — Perceivable, Operable, Understandable, and Robust.
Start With Accessibility in Mind
The most effective place to address accessibility is at the beginning, before a document is created. Decisions made in the source document — in Microsoft Word, Excel, or PowerPoint — carry forward into the PDF when the document is exported correctly. This means that a well-structured source document will produce a well-structured PDF with significantly less remediation work required after the fact.
In contrast, a document built without accessibility in mind — using visual formatting instead of proper styles, manually created lists instead of actual list formatting, or images without alt text — will require extensive manual work in Adobe Acrobat to remediate, and some issues may not be fully resolvable after the fact.
The guidance in the Accessible Authoring pages of this guide is organized to help you build accessibility into documents from the start. If you are working with an existing document, the Adobe Acrobat pages cover remediation — but wherever possible, returning to the source document to fix issues is preferable to remediating the PDF directly.
Remediation Is Harder Than Prevention
Remediation takes more time, more effort, and more expertise than building accessibility in from the start — and for some issues, it is not fully possible at all.
Fixing an accessibility issue in a source document takes seconds. Fixing the same issue in Adobe Acrobat can take minutes — and for complex documents with many issues, the remediation time adds up quickly. Some issues that are trivial to address in Word (like properly nesting a heading or using actual list formatting) require significant manual tag manipulation in Acrobat.
More importantly, some issues cannot be fully resolved in Acrobat at all. Complex table structures, multi-column layouts, and certain reading order problems are difficult to remediate correctly after the fact and may require rebuilding sections of the document from the source.
The practical implication: the more accessible your source document is, the less time you will spend in Adobe Acrobat. If you are frequently spending significant time remediating PDFs, it is worth reviewing the source document practices that are generating those issues.
Use the Right Tool for Each Step
WVDE's document accessibility workflow relies on several tools:
- Microsoft Office (Word, Excel, PowerPoint) is where documents are authored. These applications include built-in accessibility features — heading styles, alt text, table structure, list formatting — that transfer to PDFs when documents are exported correctly. They also include built-in accessibility checkers that can identify common issues before a PDF is ever created.
- Adobe Acrobat Pro is where PDFs are verified and remediated. Acrobat's accessibility tools allow you to inspect tag structure, fix reading order, add or correct alt text, verify form field properties, and run full accessibility checks. Acrobat is a powerful remediation tool, but it works best on PDFs that were well-structured to begin with.
- Commonlook is an Adobe Acrobat plugin provided by Allyant that validates PDF accessibility against several standards, including WCAG 2.1 AA, and provides detailed structured reporting on failures and required corrections. Requests for individuals in departments that can make use of the Commonlook plugin can be made by reaching out to the Communications office.
No other tools are currently approved for document accessibility work at WVDE. If you have questions about tools or need assistance beyond what these applications provide, contact the Communications office.
Run Accessibility Checks Before Publishing
Both Microsoft Office and Adobe Acrobat include built-in accessibility checkers. These tools are not perfect — they catch many common issues but cannot identify everything, and some flags require human judgment rather than a straightforward fix. However, running these checks before publishing is a meaningful baseline step that catches the most common and most significant issues.
In Microsoft Office: Check for accessibility before exporting to PDF. In Word, Excel, and PowerPoint, go to Review > Check Accessibility. Address any errors before exporting. Any errors surfaced during authoring should be resolved prior to publishing or exporting to a PDF.
In Adobe Acrobat:
- After exporting, run a full accessibility check in Adobe Acrobat. Go to All Tools > Prepare for Accessibility > Check for Accessibility. Review all failures and address them before the document is uploaded to the website. Running the check early in the process may also tell you that making changes to your source file is appropriate
- If you have Commonlook installed, also run a check using the plugin:
- Menu -> Plugins -> Commonlook PDF Validator
- Once open, find Standards -> Accessibility -> WCAG 2.1 AA; clck full. The resulting table of results can be filtered by failures. Each failure can be identified in the document by clicking the individual row for the failure.
A document that passes the built-in checker is not guaranteed to be fully accessible — manual review, including reading order verification and screen reader testing, is still valuable for complex documents. But a document that fails the checker should not be published.
When You Need Help
Accessibility questions and complex remediation cases can be directed to the WVDE Communications office. Communications provides accessibility guidance and training for staff across the department.
For complex forms or documents with specialized layout needs, the Graphics department may be able to assist with document design.