Reading difficulties with Apple Voice Over.

Report · Apr 30, 2020

On the Mac OS (Apple Voice Over) , some PDF documents are not read correctly, for example: The reading order is not followed, not read by tags, words are read as numeric characters (numbers are read instead of words)

What can you advise to fix this problem?

Mac OS High Sierra V10.13.6

Report · Apr 30, 2020

After considerable exploration, I have not been able to find any PDF viewer on the Mac platform which works properly with VoiceOver, especially including Acrobat Reader DC, but also Preview, Safari and all the plug-in PDF viewers designed for Mac web browsers, including Adobe's own browser extensions. I have reported bugs to Apple, Mozilla and the Chromium tracker, and started a Adobe discussions thread on the topic too. I will be very interested to see what (if any) replies may appear from Adobe here.

It appears that none of the Mac-based PDF viewers generate an accessibility tree, which means that VoiceOver will give you the text nodes, but none of the semantics. So yes, hurrah, much of the text will get announced, but tags and read order seem to be completely ignored. I have tested with a number of tagged PDFs on Acrobat Reader. The Windows version does the right thing, and works with a wide range of assistive technologies. The Mac version does not. I suspect that this is not a mistake or a bug, but a consequence of outdated strategic priorities from the days before modern accessibility legislation was passed.

This is an utterly dismal shortcoming in a nominally "portable" and "accessible" file format (PDF/UA). Adobe could (and really ought to) do more to improve this situation at a time when WCAG compliance is now mandatory for all public documents in North America, the EU and many other jurisdictions.

At the very least, Adobe should be honest about the miserable accessibility support for tagged PDF on Mac in its accessibility authoring documentation, if only to manage expectations and protect its brand. Adobe should also urgently bring Acrobat Reader DC for Mac up to feature parity with the Windows version in this important area. Beyond the legal commitments, accessibility of PDF across platforms is a make-or-break feature for many users.

Report · Apr 30, 2020

The lack of accurate, functional screen reading on Mac is an Apple deficiency, not Adobe's.

And Apple's built-in Voice Over is an exceptionally poor text-to-speech application (can't call it a "screen reader" because of its near-total lack of user controls).

Adobe creates the PDF standards (ISO 32000 for PDF, and ISO 14289 for the PDF/UA subset which specifies the requirements for accessible PDFs). More details are at https://en.wikipedia.org/wiki/PDF/UA and https://www.pdfa.org

These are open standards, so any manufacturer of a "consuming application" (such as a screen reader or other assistive technology) can build their product to the specifications.

Apple, it appears, has chosen to NOT build Voice Over to the ISO standards. So complain to Apple, not Adobe. Nearly the entire process of making compliant, accessible PDFs or consuming/using them on the Mac platform is terrible.

Report · Apr 30, 2020

Thank you for your reply. As mentioned above, I have reported the issue to Apple, but I still maintain that Adobe has a responsibility to make such a significant shortcoming clear in its documentation about producing accessible PDFs. Right now, Adobe gives the impression that it will 'just work'.

Report · Apr 30, 2020

I don't think you can expect software makers to qualify what they do in terms of "this will work unless other software has bugs". There may even be legal issues if they start naming "bad" apps. Rather, you need careful selection of your final agent, with a view to quality and also end user needs. Some agents are not intended as full accessibility agents, more quick toys. Text to speech is not the same thing. Even Acrobat Reader's "read out loud" is in that category.

Report · Apr 30, 2020

Adobe has no authority over how any screen reader (or other assistive technology) will work with PDFs. It could only state that IF the PDF is PDF/UA compliant and IF the assistive technology is also PDF/UA compliant, then everything should work as planned without any surprises.

Everyone voluntarily adopts the same international accessibility PDF/UA standard, whether they are:

the people making the content (you and me)
the software manufacturers who make the tools we use (MS, Adobe, and others)
the assistive technology manufacturers who make screen readers (Apple, MS, JAWS, NVDA, and others).

None of us stakeholders above have any control over any of the others.

Remember, PDF is an open standard: Adobe no longer "owns" it...the ISO does and makes it available for anyone to use.

Report · Apr 30, 2020

All good, all fine and all true.

The problem remains that Adobe sells and promotes software for the production of nominally "accessible" and "portable" files which are not actually accessible (according to WCAG 2.0 / ISO/IEC 40500:2012) on contemporary operating systems other than Windows. That means that the accessibility features of PDF/UA files are not (de facto) portable either. It's not Adobe's fault. IANAL, but I still believe that Adobe should address this gap in some formal way in its documentation, for executive (and especially public sector) customers, or at least should dial down its promotion of 'accessible PDF' as an interoperable format.

Previously, these shortcomings about PDF/UA were not easy to discover, they were not documented anywhere on Adobe's website, certainly not on the Apple domain name, and were barely admitted anywhere else. Now that this discussion is public (thank you!), and may be hyperlinked, it may serve as enough of a warning to content creators and accessibility auditors, so that expectations may be managed appropriately.

Report · Apr 30, 2020

Quote: Adobe sells and promotes software for the production of nominally "accessible" and "portable" files which are not actually accessible (according to WCAG 2.0 / ISO/IEC 40500:2012)

The accessibility standard for PDFs is PDF/UA, not WCAG. See "US Access Board affirms: PDF/UA required for modern PDF software" at https://www.pdfa.org/us-access-board-affirms-pdf-ua-required-for-modern-pdf-software/

HTML is a mark-up language (HyperText Markup Language), while a PDF file is actually a mini program, very different from an HTML website's coding and processing.

I'm a former contributor to WCAG and still keep up to date with the HTML standard today.

I'm a former web developer and PDF programmer.

And I'm a member of the ISO committee for PDF/UA (and other PDF subsets).

PDF/UA and WCAG have similar overriding goals of accessibility, but they cover 2 very different types of digital media and, consequently, can't be identical and can't be used interchangeably.

Report · Apr 30, 2020

Quote: "a warning to content creators and accessibility auditors, so that expectations may be managed appropriately"

No software by anyone makes a fully compliant, accessible PDF at this time -- not from Adobe, Microsoft, Nuance, FoxIt, and the hundreds other programs that create PDFs from source documents. The best PDF producer is a plug-in for Adobe InDesign and QuarkXpress; it's by Axaio Software and called Made To Tag https://www.axaio.com/doku.php/en:products:madetotag

The best (and most helpful) solution is to work with these companies to improve their PDF-making tools and conversions. You can do that through their user-feedback forums:

www.Acrobat.UserVoice.com (Adobe)
https://office365.uservoice.com/ (Microsoft)
https://www.apple.com/feedback/ (Apple)

Report · May 01, 2020

Thank you for both these replies. This is exactly the kind of information I have been missing: Simple, honest description of the shortcomings, the relevant legislation, and places to apply pressure for improvement.
Just want to point out that other jurisdictions (e.g. EU) rely almost entirely on WCAG to specify accessibility of digital documents.

Report · May 01, 2020

Quote: Just want to point out that other jurisdictions (e.g. EU) rely almost entirely on WCAG to specify accessibility of digital documents.

Yes, that's what happened worldwide about 15 years ago as accessibility requirements began to be adopted, country by country ... WCAG for everything, it's device independent, regardless that the "W" stands for "web." But that's changing as the PDF Association and members of the document accessibility industry groups do a better job of advising governments, and countries are formally accepting the PDF/UA standard. Example: Many EU member countries require PAC3 to check and validate PDFs.

Don't misinterpret me, I think WCAG is a great standard and its core POUR principals of accessibility should be memorized by anyone making accessible anything for any media. https://www.w3.org/WAI/fundamentals/accessibility-principles/

But it was naive to think that a standard developed for one media could also apply to other media, or that all forms of communication would boil down to just HTML and that every other file format was "old school," obsolete.

Granted, other standards like PDF/UA and EPUB 3 were late to get into the game and by then, WCAG was the most widely-known standard. But you'll see more standards become required by your country's legislation in the next few years. EPUB 3.2 is now out https://www.w3.org/publishing/epub3/epub-spec.html, and PDF/UA-2 is in development. Use PDF/UA-1 until it's out.

Report · Apr 30, 2020

Try a different screen reader. Apple's free built-in Voice Over is notoriously under-functional.

Here's what the American Federation for the Blind lists on their website: https://www.afb.org/blindness-and-low-vision/using-technology/assistive-technology-products/screen-r.... There are few for Apple iOS.

Report · Apr 30, 2020

Apple have let their accessibility effort slip badly in recent years. However, the Mac does have an accessibility API, far better than the alternative on (say) Android, and whether or not it is ISO standard is quite irrelevant to content creators. The law in most developed nation jurisdictions mandates WCAG compliance, not ISO compliance, and the accessibility tree generated by Safari from well-formed HTML comes very, very close to ISO/IEC 40500:2012 compliance, so they clearly offer something for third parties to work with. Why does Acrobat Reader not use Apple's existing, though imperfect accessibility API?

My main concern here is that Adobe, by omitting to mention a significant end-user shortcoming in its accessibility production docs, oversells both the portability and accessibility of PDF/UA aka. 'tagged PDF'. These 'features' are the very point of the format. They are the very reason why public institutions continue to use PDF - because it promises interoperability in its very name.

You will be aware that thousands of people worldwide are currently engaged in PDF remediation for WCAG compliance, which recently became mandatory, and there is not one mention in Adobe's docs of these significant issues on the Mac platform. There is not even a temporary side note or caveat which might serve as fair warning. Example: we sent our PDFs off to a third party for an accessibility audit, and got failure tickets from the auditors because VoiceOver didn't recognise the document semantics. Evidently the auditors (supposedly experts) are not sufficiently aware of the problem either. And how would they ever discover it, unless it were mentioned somewhere official? Come on guys. If you could at least mention it in your docs, maybe Apple would get a few more bug reports. We all know they are more anxious than most about their brand value.

BTW There is exactly one competitor for VoiceOver mentioned on the AFB page (i.e. a Mac based screen reader, not an iOS-based one). Magnilink iMax is primarily a screen magnifier, with only limited screen reader capabilities - i.e. it can 'speak selection', so if anything, it does an even worse job of interpreting document semantics than VoiceOver.

Report · Apr 30, 2020

(Human voice) just want to apologise for any ill feelings. I recognise that Adobe does what it can under the prevailing constraints. I consider it incredibly valuable that Adobe offers this forum for discussing problems openly, and not without cost or risk. Thank you for taking my concerns seriously.

Report · Apr 30, 2020

This is a beautiful example of the need for Universal Accessibility, i.e. conformance to ISO 14289 PDF/UA. Only when *every* AT tool for *every* platform and *every* PDF document rigourously conforms to the same set of rules can we expect an accessible PDF to be always read properly. Acrobat Pro is capable of producing PDF/UA conforming documents, but it takes a considerable amount of human knowledge, skill, practice, and effort. Adobe could do much to make it easier/more practical. That said, if a document is fully conforming with PDF/UA and is not read properly be a specific tool, the tool, not the document, is broken, and the tool maker needs to fix it.

Report · Apr 30, 2020

Well said!

Just like you can't wave a magic wand and end up with a WCAG-compliant website, you can't press a magic "easy button" and get a PDF/UA-complaint PDF or an EPUBcheck-compliant EPUB.

Regardless of the media, you must have good tools, understand what accessibility is for that media, know how to use the tools correctly.

There are no magic wands or easy buttons in life!

Report · Jun 02, 2020

Hello, thanks for all your answers, the question about the voice overs is still open. We hope that Apple will fix this problem in the near future.

Report · Feb 11, 2021

I just opened a perfectly tagged PDF with VoiceOver in Acrobat Reader DC and Acrobat Pro. Both apps support alt-text, announce tables and heading levels. It looks like lists are not supported. I'm on macOS Big Sur.

Report · Dec 30, 2021

How do you get Mac VoiceOver to read a perfectly tagged PDF? Mine doesn't read the text from the doc even though I went through and tagged everything and added alt text to important images and graphs. It reads the file name and file location, but won't read the words on the page. I swear it was working a few months ago. I'm on macOS Big Sur.

Report · Dec 31, 2021

Try reading a PDF that is correctly tagged for sure. For example: acrobat-xi-pdf-accessibility-overview.pdf . If it reads that, there must be something wrong with your document.

Report · Jan 02, 2022

Thanks, but that one doesn't work properly either. The voice over says. "you are currently on a group, inside of a frame" or it tells me the file name. But I'm looking for it to read the content on the page. Do you know if there is a setting to get it to read the words instead of file information?

Report · Jan 03, 2022

You’re not in the PDF yet. Use the VoiceOver command to interact with an item:

VO-Shift-Down Arrow

VO stands for VoiceOver keys. It’s the combination of the control and option key.

More commands:

https://www.apple.com/voiceover/info/guide/_1131.html

https://webaim.org/articles/voiceover/

Report · Jan 03, 2022

That does work to read each line one at a time. I was under the impression there was an option to read the entire document or at least the entire page at one time.

Report · Jan 03, 2022

VoiceOver can do all that as described in the documents I mentioned. You need to learn how to use VoiceOver. Please stick to questions about PDF accessibility in this forum. There are other places more suitable to ask for help with VoiceOver.

Report · Jun 13, 2023

wow what a tool