Acrobat’s built-in accessibility checker is a useful tool for finding some accessibility errors. But it can only detect some potential accessibility issues. Find out why Acrobat’s accessibility checker isn’t enough for checking the accessibility of your documents.
Many organizations and their designers check their PDFs for accessibility with the Acrobat accessibility checker, thinking that if they pass the checker, that means they are accessible. Unfortunately, the Acrobat accessibility checker, even though it’s so named, cannot detect most accessibility issues. So passing does not mean a document is accessible.
If you’ve been relying on Acrobat’s accessibility checker to test your accessible PDFs, your documents may not actually be fully accessible. In fact, they could have major accessibility and usability issues.
The Acrobat accessibility checker is useful for testing certain accessibility issues and troubleshooting your PDFs in the accessibility process, so you can go back to your source file and address many of the issues if needed.
But you still need to do manual checks and screen reader testing. Depending on the content, there may also be work to do in the PDF that cannot be done in the source file.
What the Acrobat Accessibility Checker Can Check
There are some accessibility issues that the Acrobat checker can detect.
Presence of tags
The Acrobat accessibility checker can tell if a PDF contains tags, which are the foundation of an accessible PDF. Tags are needed to convey the content of a document to assistive technology.
The checker will try to determine if the document is an image-only PDF, such as a scanned image. If it seems like the document contains text but there are no fonts used in the PDF, then it will flag it.
Set document language
It can tell you if the primary document language has been set. This is especially useful if you have a document in a language other than what the screen reader user normally has set. They can switch to another language pack if needed to make sure the language is voiced properly.
Set document title
The Acrobat accessibility checker can tell you if there is a document title.
Presence of bookmarks
It can tell if the document has bookmarks, which helps some users get to different parts of the document quickly. They appear on the lefthand side in their own panel.
If the document has at least 21 pages but doesn’t have bookmarks that are parallel to the document structure, then Acrobat flags it.
No skipped heading levels
Another issue the Acrobat accessibility checker can check is the hierarchy of headings.
For example, if a document has a heading that has been formatted as an H2 and the next heading has been formatted as an H4, it will flag that as an issue, because a heading level has been skipped.
Proper list structure
It can check to see if lists are tagged properly.
Presence of Alt-text
When it comes to Alt-text for images, the Acrobat accessibility checker can tell if images have Alt-text.
Presence of table headers
It can tell if tables have header rows designated or not.
What the Acrobat Accessibility Checker Cannot Check
There are many important things that require manual checking to ensure accessibility and usability in a document. The Acrobat checker can only do automated checks, not manual checks. Those must be done by a person.
While the Acrobat accessibility checker can check for tags, it cannot tell if the correct tag has been used.
The way that sighted users understand content can be different from how someone using a screen reader understands that content. So the use of improper tags causes confusion to users of screen readers.
There might be content set as paragraphs that should be inside a list. There might be headings that really should be paragraphs or vice versa.
Not only that but the source programs, such as InDesign, don’t provide all the options there are. That means some things must be tagged manually.
Proper document language
The checker cannot tell if the document language has been set correctly.
Good document title
While the Acrobat accessibility checker can tell you if there is a document title, it cannot tell you if it’s a good title for the document or not.
A proper document title, such as Gratzer Graphics Report 2022, makes it clear to someone using assistive technology what that file is about.
Otherwise, they may hear a long, verbose file name that doesn’t convey much meaning to them such as gg-report-final-0422.pdf.
Good use of and enough bookmarks
The Acrobat checker can flag if there are bookmarks missing from a document that has more than 21 pages. But it cannot determine if there are too many bookmarks or not enough. Too many may be overwhelming. Too few may not be helpful enough.
It’s also much better practice to include bookmarks for any document with more than one page.
Proper heading levels
While the checker can check if any heading levels have been skipped, it cannot tell if any of those headings are incorrect. For example, maybe an H3 should be an H2 because it’s a new section, not part of the preceding one.
Quality of Alt-text for images
The Acrobat accessibility checker cannot determine if the Alt-text on images is sufficient or appropriate Alt-text or not. It could be too long or verbose.
It also cannot tell if the Alt-text on an image should not be there and that image should instead be ignored by assistive technology.
Proper table setup
The Acrobat checker cannot tell if the tables have been set up properly. If they are not, it will affect someone using a screen reader being able to get the information and in the proper context.
Correct reading order
Another thing that Acrobat cannot check is the reading order, which is the order in which the content is read.
The way a sighted user views the content on a page is not necessarily the order in which a user of assistive technology will get that information.
For example, a document may have a cover, then pages 1, 2, 3, etc., and on those pages, content is read from top to bottom, left to right.
What a screen reader user might encounter is page 30, then page 5, then the cover and so forth.
In addition to that, within those pages, they may also get the content in the wrong order—text at the bottom, text at the top, text in the righthand column then text in the lefthand column.
There may also be elements in the reading order that shouldn’t be or vice versa.
So the document ends up making little to no sense and causing confusion and frustration to the person trying to read it. It’s simply unable to be understood the way it was intended, let alone at all.
A lot of this depends on how the source file was set up, but that isn’t evident to the designer unless they understand how the setup affects the resulting PDF and accessibility.
Proper use of color and sufficient contrast
The Acrobat checker cannot check for color and contrast issues.
That means it cannot tell if color is being used to convey meaning, which could very well be the case in a table or an infographic, for example.
It also doesn’t know if the colors used are appropriate for that audience. There are some color combinations that are better for certain groups of people and some colors that should be avoided in certain groups.
It also cannot determine if text has sufficient contrast.
The Acrobat checker cannot say whether or not good typography practices have been used. Not only that, but certain typefaces are better for certain audiences.
Good user experience
The Acrobat checker cannot assess whether or not adjustments are needed in order to provide for a good user experience, or to make sure that some content that might be problematic for screen readers will convey information as you intended.
The moral of the story? Accessibility cannot be automated.
Automated PDF accessibility checkers are part of the troubleshooting and accessibility testing process. Passing one or more of them is not a stamp of approval that a PDF is accessible.