The information in this post was taken from The Australian Government’s study into the Accessibility of the Portable Document Format for people with a disability. See my previous blog posts for the conclusions of the AGIMO study into PDFs.
Several issues occurred across assistive technologies (as well as with Read Out Loud and the keyboard only feature), which leads me to believe that there are still a few bugs in the Adobe interface:
- Page number not read aloud (JAWS 9 & 10, NVDA 2009.1, Window Eyes 7, Read Out Loud, Keyboard only)
- Page number of document does not correspond with Adobe Page Navigation toolbar (JAWS 9 & 10, MAGic 10, ZoomText 9.14, Read Out Loud, Keyboard only, Auslan)
- Difficulty with table headers (JAWS 9 & 10, NVDA 2009.1, SATAGO 3.0, Window Eyes 7, ZoomText 9.14, Keyboard only)
- Difficulty with form fields (JAWS 9 & 10, NVDA 2009.1, SATAGO 3.0, Window Eyes 7, MAGic 10, Read Out Loud, Read & Write Gold 9, Dragon Professional 10.1, OS configuration
PAC Mate
No tasks could be completed.
Voice Over
No tasks could be completed.
JAWS 9 & 10 (results extrapolated to version 11 & 12)
- Page number in document is not read aloud by JAWS
- Page number of document does not correspond with Adobe Page Navigation toolbar
- Users expected table rows for ‘item details’ to be numbered
- ‘Page Down’ does not act as user expects
- Cannot manually enter information into date field with ‘auto forms mode’ in JAWS 10 turned on
- Cannot jump between paragraphs using JAWS
- User does not know JAWS table navigation commands
- User does not know how to navigate via headings
- User does not know how to search for a page using Adobe Page Navigation toolbar
- User tries to use Word commands
- User found it hard to use drop down calendar picker
NVDA 2009.1
- Page number in document is not read aloud by NVDA 2009.1
- ‘Page Down’ does not act as user expects
- NVDA 2009.1 does not provide a direct association between the header and data cells
- Field name (postal code) is not read out
- User does not know how to search for a page
SATAGO 3.0
- User expected table rows for ‘item details’ to be numbered
- SATAGO 3.0 was unable to load document
- Edit field name not read aloud when arrowed to
Window Eyes 7
- Page number in document is not read aloud by Window Eyes 7
- Window Eyes 7 does not accurately associate table containing 2 rows of headers
- Headings not identified by Window Eyes 7
- User has to exit ‘Browse on’ mode to read non editable fields
- User did not know that Window Eyes 7 does not identify headings
- User did not know how to navigate table
- Not able to search by page number
MAGic 10
- Page number of document does not correspond with the Adobe Page Navigation toolbar
- Hover reading function does not work within content area of document
- Arrowing down functionality not efficient
- Field name is not read out for postal code field
ZoomText 9.14
- Page number of document does not correspond with the Adobe Page Navigation toolbar
- ‘Doc Reader’ reads all table cells as one
- Quality of content poor when magnified
- Background colours still do not provide sufficient contrast when inverted, making text hard to read
- Table header information not very clear when colour inverted by user
- Two column presentation requires horizontal scrolling to read
Read Out Loud (Adobe Reader 9)
- Page number in document is not read out loud
- Page number of document does not correspond with the Adobe Page Navigation toolbar
- All of first page is read as one block
- Text entered into form fields not automatically read out
Read & Write Gold 9
- Text entered into form fields not automatically read out
Dragon Professional 10.1
- General Dragon commands do not work
- Dragon does not apply form field numbering overlay for PDF forms
- Text input is not as accurately recorded in PDF documents as it is with other application
Keyboard only
- Page number of document does not correspond with the Adobe Page Navigation toolbar
- User reads left column first but information starts on right
- Table headers not visible when using the Reflow feature in Adobe Reader
- Page numbers not visible when using the Reflow feature in Adobe Reader
- User is not aware of the Reflow feature in Adobe Reader
Operating System (OS) configuration
- OS colours not inherited by form fields in document
- Colours specified in OS not inherited in document
- Adobe Reader customisation settings not intuitive
Auslan
- Page number of document does not correspond with the Adobe Page Navigation toolbar
I have posted a reply on the AGIMO blog post in question:
http://agimo.govspace.gov.au/2010/11/30/good-document-design-is-the-key-to-accessibility/
The adage, “Never commission a study unless you know what the answer will be” applies here. Having been a subject in the project and signed an NDA, I can’t comment on the process. As a screen reader user and regularly providing input to other screen reader users, I can say with confidence that some similar and some different issues would emerge if the study had looked at HTML or MS Word documents. What is most ridiculous is that user ignorance is used as an argument not to use a particular technology. When helping a long-term screen reader user in accessing a web page recently, I suggested he use his screen reader table reading commands. “What are they?” he asked. I am baffled about page numbers being an issue. While not announced automatically, they are readily available. It’s also harsh to criticise table access in PDFs. It’s a good deal better than in Word and equivalent to those HTML tables (which is the vast majority) that are not marked up optimally. What is required is mass education of authors, regardless of format (including when a particular format is most suitable), and of users. The ongoing lobbying against PDFs because of past sins is myopic. But, who am I to comment. Perhaps I should cease reading documentation and refining skills and let those with loud voices advocate on my behalf (me bitter and twisted?).
As an addendum to my previous rant: I have just spent many hours on a MS Word document espousing equality for people who have disabilities. It came to me with no formal headings (hierarchical or otherwise), ununiform tables with rows split across pages, multiple hard returns to providespace between paragraphs and even to start a new page. I wonder what people would have said had it gone out in its original shape. Would the author have been dragged before a tribunal or shamed on the Human Rights Commission website? Almost certainly not. It is, after all, a Word document. Had it been a PDF… We now have a well structured document which will convert nicely to PDF, DAISY etc. And yes, the author now has a very good understanding of the importance of structure.
I venture to suggest that no matter what the format, an inaccessible document would attract some attention from the AHRC.
Despite its lack of formal structure, it would be hard to claim successfully that the document to which I referred was inaccessible. Tedious to read and navigate yes, but not inaccessible. Had it been converted to PDF, it would have been equally tedious to navigate, but would be deemed to be unacceptable by AHRC. If the file, as it now stands with formal headings, well structured tables etc, were converted to PDF it would (assuming sufficient user knowledge) be easier to navigate than a Word file. But it would still be deemed to be unacceptable.
That’s the best answer by far! Thanks for cotniibunrtg.
Great work with this! Thanks for your comprehensive study on assistive technology on PDF documents. I remember hearing mixed reviews on the Dragon software myself. It seems like you have to spend quite a bit of time with it initial ‘training’ the software before it works correctly.
Actually it was AGIMO who did all the work – they should be congratulated.
[…] PDF content accessibility. These have been well documented by Gian Wild in posts such as PDF test results by assistive technology and Between a rock and a […]