Remediation and document accessibility is a commitment. The process can be challenging to wrap your head around at first, can be frustratingly labor-intensive at times, and sometimes it’s just plain confusing. As remediators, we prioritize and invest time and energy to ensure documents are accessible for all audiences.
To put it plainly, we genuinely care about making sure that the information is consumable by everyone. However, a common question that we often get asked is something along the lines of, “I remediated this document, but it still doesn’t read right when I use a screen reader. What did I do wrong?”
This is sad to hear because we all care so much about what we do, but the short answer is, “possibly nothing.”
Of course, it could be that the remediator missed an issue or tagged something incorrectly, but let’s assume the remediation is flawless. Most importantly, the document perfectly complies with the necessary standards.
Understanding how screen readers work
One cause for confusion could be that the person doing the testing isn’t 100% sure how screen readers work or how they handle different things in documents. For example, and we hear this one a lot, many screen readers will say “Link” when they land on a Reference tag, even if there’s not really a link there.
But if the tester isn’t aware of this, it can be confusing and possibly flagged as an issue, even when it’s not.
How different screen readers read the same document
However, even when testers are well versed with how screen readers work, confusion can still abound. Even though there are standards, it’s a known fact that not all screen readers strictly follow the “letter of the law” when processing a PDF. So, two different screen readers could quite possibly read the same PDF differently!
Even more frustratingly, two users could be using the same screen reader but have different preferences, settings, or personalization setups, which would also cause the information to be shared differently. In fact, I could give the same remediated and compliant document to several screen reader users, and it could be read in many different ways.
While wildly frustrating, this is a reality of assistive technology.
Three of the most common screen readers are NVDA (Non-Visual Desktop Access), JAWS (Job Access with Speech), and Voiceover. Other options do exist, but these seem to be the most popularly used.
Even between these common offerings, a document could be shared very differently, and how your document responds to internal screen reader testing could entirely depend on which platform you are using. The functionality of these screen readers is dependent on the developers, not the remediator, and these developers seem to have varying opinions on how specific tags should be treated.
Furthermore, these developers’ decisions could change as standards evolve, so if you chose to remediate a document to a specific screen reader’s functionality, how it’s being read could still change in the future.
This leads to the tough but most logical solution – remediate to the standard, not the assistive technology.
The importance of accessibility standards
Accessibility standards provide specific guidelines for accessible PDFs, and meeting these requirements will ensure that you have done all that you can to give access to all audiences.
In summary, not all screen readers are created equal, and remediating to a specific screen reader can be detrimental to the overall accessibility of a document and, in some situations, be even more detrimental to audiences using other screen readers.
If you find yourself wondering why content is voiced a certain way, or you receive feedback that content isn’t being read properly, your top priority should be to verify that the document is compliant with the needed standard. And, if the document is truly standards-compliant, you might consider contacting the assistive technology developer and bringing the issue to their attention.
Documents being read incorrectly in internet browsers and/or mobile devices/ apps
There are quite a few significant issues when it comes to trying to read a PDF from within a browser window. Granted, different browser and screen reader combinations may work differently, and some may work better than others, but there are known issues across the board.
First, navigating to, and through, the PDF, with just the keyboard ranges from difficult to impossible. This is relevant, of course, because most people who are using screen readers are not clicking on things or navigating with their mouse. Keyboard navigation is very important and, sadly, is very lacking in the browser environment.
In addition, it’s been found that most popular browsers, when displaying PDFs, do not honor the tags. What this means is that even if the PDF is tagged properly, and is standards-compliant, a screen reader won’t read it correctly because the browser is not allowing the screen reader to use the information in the Tags tree.
Our recommendation is, for PDFs available on a website, to provide the functionality to download the PDF. You might even consider including some text such as, "For the best reading experience, download the accessible PDF and open it in Adobe Acrobat Reader." You could also include a link to download the free Adobe Acrobat Reader so that, if people don’t have it, they can get it. Again, the Adobe Acrobat Reader is free, it handles accessible PDFs correctly, and there is even form-filling and signature functionality available if needed.
A final thought - maybe it's a bug!
If you know the content is tagged correctly and it's not being read correctly by a screen reader, OR, if you test with different screen readers and get different results, we would encourage you to file bug reports with the companies that make the screen reader(s) in question!
Here is the link to file a Bug report with Freedom Scientific, the makers of JAWS: https://github.com/FreedomScientific/standards-support/issues
Here is the link to file a Bug report with the makers of NVDA: https://github.com/nvaccess/nvda/issues.
Here is a link to more information about filing bugs on VoiceOver: https://developer.apple.com/bug-reporting/.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article