The collective knowledge around the creation of accessible PDFs is slowly but surely growing, making this flexible format more widely available to people of all abilities. But what if you make your PDF accessible, yet someone still finds it inaccessible because of the way they open it?
In a nutshell, a PDF creator will add heading structure, alt text images, tag table heading cells and check the colour contrasts. The resulting tagged PDF is uploaded to a website and the job’s done. But one of the forgotten keys to a PDF’s accessibility lies in what happens next.
The way a browser opens a PDF, and even the way the web link to the PDF is worded, can all play a part in accessibility elements not being available to assistive technology users. Read on to learn how.
Our websites are viewed in a range of browsers and those browsers may have in-built PDF reader applications. Add to this PDF software downloaded to an end user’s computer, or an operating system’s in-built PDF reader, and you end up with a variety of viewing scenarios. This is often where accessibility considerations slip.
Testing the issue
A number of scenarios were used to test the issue of viewing a PDF from a website. An accessible PDF on the Media Access Australia website was accessed through the latest versions of Internet Explorer, Firefox, Google Chrome and Safari.
The tests were conducted on two computers. One set-up was a desktop computer operating on Windows 7 Professional with Adobe Acrobat Professional software. The other set-up was an iMac operating on OS X, 10.11.2 with Acrobat Reader. The tests were repeated with Acrobat software removed.
Internet Explorer and Mozilla Firefox
Both browsers returned the same results. Left clicking on the link provided an option to Open or Save. When Open was selected, the PDF opened in the tester’s default PDF viewer of Acrobat Professional. ‘Save’ allowed further options to save on the tester’s computer and open in an Adobe product. Right-clicking allowed the tester to ‘save as target’ or ‘save link as’ offering the same options as ‘Save’. There was also an option to open in a new window or tab, and both opened in Acrobat Professional, being the tester’s default reader.
With Adobe software removed, these browsers asked the tester to choose a program to open in. Options available were free downloaded PDF readers Sumatra and Foxit. Both programs rendered the PDF inaccessible.
Left clicking on the link immediately downloaded the PDF resulting in a new tab displaying the PDF in Chrome’s in-built reader. JAWS and NVDA screen readers were activated but neither could access the PDF in this software. Right clicking on the link gave the option to open in a new tab or window, with the same results as left clicking, but also offered to ‘Save link as’. This option allowed for the PDF to be saved to the tester’s computer and opened in Acrobat Professional.
The only difference with Adobe software removed was that when the link was saved and opened, the tester was asked to choose a program, from which Foxit and Sumatra were available and again, these render the PDF inaccessible.
Clicking on the link or selecting the link while holding down the Control key (equivalent to right clicking in Windows) allowed the PDF to be saved to the computer or viewed in a new window or tab. On both occasions the PDF opened in Acrobat automatically.
With Acrobat Reader removed, both options immediately downloaded the PDF resulting in a new screen displaying the PDF in Safari’s plug-in reader. The VoiceOver screen reader could access the document in both PDF readers but did not announce heading structure in the document.
If an Adobe program such as Acrobat Reader or Acrobat Professional is available on an end-user’s computer, they are less likely to encounter difficulties accessing a PDF in Safari, Firefox and Internet Explorer. For this tester, Google Chrome defaulted to its in-built reader regardless of Acrobat presence, rendering the PDF inaccessible. To rectify this, the tester was required to save the PDF to their computer and open in an Adobe program.
If an Adobe program is not available, end-users are most likely to encounter accessibility issues with PDFs on most browsers. Safari’s inbuilt PDF reader allows VoiceOver access to the document but with no semantic information announced around the document structure.
As a content creator or website custodian, we can’t account for the programs and computer set-ups end users will be viewing our content through. While this is out of our control, we can control the messaging around the PDF viewing options.
Be clear in the wording you use prior to the link. For example, “To view an accessible version of this PDF, right-click to save target to your computer and open in Acrobat Reader or Acrobat Professional.”
Outside of browsers, Windows 8 and 10 have their own PDF readers which from anecdotal evidence are compatible with popular screen readers. The ‘Reader’ app is built in for Windows 8 and downloadable from the Windows Store for Windows 10.
In summary, ensure your PDFs online are available to open with an Adobe program or download directly to a user’s computer to view independently in an Adobe program.