You’ve just received a batch of PDF files to be tagged for accessibility. Your client tells you that the documents are complex, and you correctly interpret this to mean that there are a lot of tables and graphics. This is not unusual for transactional material such as bills and statements, but your client wants to know what’s involved in tagging and testing this kind of content. Can complex tables and images be made accessible? Can we customize the experience for the end user? What do we do when an accessibility checker finds errors in the file?
These are probably the questions we hear most often when it comes to accessible PDF.
The short answer is that yes, complex documents can be made accessible, but only text-based content can be tagged. Any image, whether it is a logo, a picture or a detailed pie chart, requires alt text in order to be accessed by a screen reader. There is a character limit for alt text content so it may be difficult to include everything conveyed in the image. It’s usually best if clients provide alt text descriptions for complex images because they tend to be the subject matter experts. Tables can be made accessible as well, but nested tables and merged cells can be more difficult to work with. Furthermore, it is not always possible to tag them as they appear visually. For example, sometimes it’s necessary to change the table orientation to make the content accessible.
Whether we’re dealing with manual or automated remediation, clients regularly raise the issue of customizing the end user experience. It’s true that the user experience is part of document accessibility, but it’s important to note that screen readers and other assistive technology allow the end user to customize their own experience to a certain extent. In JAWS, for example, the user can decide how much information they want to hear about tables and lists. They can also choose how to navigate through a file by using various keyboard commands. The best approach is to tag documents in accordance with guidelines and standards but to leave some flexibility to the end user. A good example of this is read order within tables. Our role is to tag the table properly and then let the user navigate the content in the way that works best for them.
Finally, clients often ask about reports from accessibility checkers such as Pac 2.0. These tools are incredibly useful but they don’t give the whole picture. They can also be misleading because they flag anything that needs to be verified manually. Read order and alt text are good examples of this. Understanding the testing process as well as tagging will enable you to respond to your client’s concerns about complex files.
For a more in-depth look at these issues, join us at 1:00 PM on August 21 for our informative webinar – “Secrets of PRO Designer – Tagging for Document Accessibility”.