Accessibility work can become confusing when a future standard changes direction. W3C’s latest WCAG 3 update is important for document teams, but it is not a new compliance deadline and it is not a finished checklist to apply to PDFs today.
What W3C changed
On 25 September 2026, W3C explained a new direction for the draft W3C Accessibility Guidelines 3. The proposal uses one conformance level based on core requirements, plus supplemental requirements, assertions and recommended practices. It also introduces tags for physical harm, risk, barriers and friction, with reporting tiers intended to show progress towards and beyond conformance.
This matters beyond ordinary web pages. W3C says the work generally applies to apps, software, documents and other digital content. Its WCAG 3 introduction says the draft has a broader scope covering content, apps, tools and publishing. That makes it relevant to teams producing reports, application forms, course materials and other PDFs.
The limitation is just as important as the announcement. W3C describes WCAG 3 as incomplete, says substantial changes are expected, and does not expect a finished standard for a few more years. It also says the best preparation is to meet WCAG 2.2 success criteria now. WCAG 2 will not disappear when WCAG 3 is finalized.
Five useful PDF checks today
1. Start with a structured source. Use real headings, lists, table headers and meaningful link text in Word, Google Docs or the authoring application. A visually large line is not automatically a heading, and exporting cannot reliably repair a poorly structured source. 2. Review reading order and keyboard order. Check that page content follows a sensible sequence for a screen reader and that interactive controls can be reached without a mouse. Columns, floating text boxes and decorative sidebars need particular attention. 3. Describe meaning, not decoration. Give informative images useful alternative text. Mark purely decorative artwork appropriately. For charts and complex diagrams, provide the information in an equivalent explanation rather than repeating a filename. 4. Do not confuse OCR with accessibility. OCR can make text in a scan searchable, but it does not prove that headings, tables, language, reading order or form labels are correct. Recognition errors also need human review. 5. Test the saved PDF people will receive. Reopen the final file, zoom it, use keyboard navigation and inspect it with relevant accessibility-checking and assistive-technology tools. Include disabled users in testing when the document or service has meaningful consequences.
Where FileStation fits—and where it does not
FileStation can help with limited preparation tasks: use PDF OCR for clear English scans, then follow the guide to OCR, reading order and accessible student documents. These tools can support a review, but FileStation does not certify WCAG conformance, repair every PDF tag or replace specialist testing.
The most useful lesson from the draft is not to wait for a new scoring system. Preserve structure at the source, test the actual PDF with people and tools, and document the issues you find. That work remains valuable even while WCAG 3 continues to change.
Primary sources: W3C, “Crafting WCAG 3 for more accessible user experiences” (25 September 2026) and the W3C WCAG 3 Introduction, updated 25 September 2026.