Auditors often see agencies submit "clean" PDFs that fail during manual reviews. The gap between automated scan results and actual compliance is significant. With the DOJ's Title II deadline set for April 26, 2027, for state and local governments with populations over 50,000, the number of documents under scrutiny is rising rapidly. Here's what auditors are asking when they see discrepancies between tool reports and screen reader results.
Can You Trust a PAC 2024 or Adobe Scan for Compliance?
No. Automated checkers like PAC 2024 or Adobe's Accessibility Checker identify structural issues such as missing tags and blank titles. They're quick and consistent, but they can't assess meaning. For instance, alt text labeled as "image" or "chart.jpg" passes the scan but provides no useful information to screen reader users. Similarly, while checkers confirm the presence of tags, they can't ensure that the reading order is logical. A two-column layout might look fine visually but read incoherently when a screen reader jumps between columns.
Your scan result is just a starting point. It indicates whether the document has a basic structure, not whether it supports real-world use.
Common Mistakes That Pass Automated Checks but Fail Manual Review
Fake headings are a frequent issue. Text formatted in bold and larger font may look like a heading, but without an H1, H2, or H3 tag, it's invisible to navigation. Screen reader users rely on headings to navigate documents efficiently. A document with visual headings but no semantic tags forces users to read linearly. Check the Tags panel in Adobe Acrobat to ensure headings are correctly tagged. If not, your document fails WCAG 2.1 Level A under Success Criterion 1.3.1 (Info and Relationships), even if your automated scan shows green.
This issue is common in policy memos, annual reports, and public notices, where documents may look correct on screen but lack proper tagging.
Ensuring Form Fields Are Usable
Test forms with a screen reader. A form may look complete visually but announce "edit field, blank" without context. Each field needs a programmatically associated label or tooltip. Labels must be specific enough to distinguish between similar fields. For example, if you have multiple date fields, each should have a distinct label.
Include required formatting in the label. If a phone number must be entered as (XXX)XXX-XXXX, specify that. Don't rely on placeholder text, which disappears once typing begins.
Tab order is also crucial. Fields might be labeled correctly but navigate illogically. A permit application that jumps from a name field to a signature line and back isn't usable, even if every field has a label.
Are Tables Really Fine?
Your checker confirms a <Table> tag exists, but it doesn't verify that header cells are correctly identified or that merged cells are handled properly. A budget table might have a visible structure, but if header cells aren't tagged and associated with data cells, a screen reader can't convey which column or row a number belongs to.
Automated checkers often miss these issues. Manual audits catch the gap between structural presence and correct semantic use. Review the tag tree directly. Confirm <TH> tags are in place and scoped correctly. Test with NVDA or JAWS to hear how the table reads. If you can't determine which department a budget figure belongs to when listening, neither can your users.
Handling Decorative Images
Mark decorative images as artifacts. Agency seals, decorative dividers, and watermarks should not be announced by a screen reader. If left as regular tagged images, they add unnecessary noise.
Conversely, meaningful images often lack alt text or have unhelpful descriptions. A chart showing budget allocations described only as "chart.jpg" fails the user. Decide whether an image is decorative or informational. Mark decorative images as artifacts and provide meaningful alt text for informative images.
Catching Reading Order Problems
Use a screen reader to test a sample of your documents. NVDA, JAWS, or VoiceOver will reveal how the document reads aloud. Government reports and newsletters often have complex layouts that make sense visually but not when read in tag order.
A screen reader might read across a two-column layout or interrupt a paragraph with a sidebar. This results in a document that's technically tagged but incomprehensible when read aloud. This is common in press releases and newsletters where design is complex.
Review the tag tree directly. Reorder tags to match the logical reading sequence, not the visual layout.
Checking Document Metadata
Yes, always check metadata. Auditors look for it every time. Common issues include missing language attributes and generic filenames like "Doc4_final_v2.pdf" instead of descriptive titles.
These are quick fixes but often flagged in audits. Set the language attribute in document properties and replace filenames with meaningful titles.
Next Steps
Incorporate manual review alongside automated scanning. Use automated checks as a starting point. Spot-check with a screen reader on a sample of documents, especially forms and data-heavy reports. Review the tag tree for headings, tables, and reading order rather than relying on visual appearance.
Standardize processes for tagging, alt text, and metadata across teams and document types. The mistakes above are easy to fix but easy to miss when some tags are in place. The difference between a document that passes a checker and one that works for users is the step you take between scanning and publishing.
