Reading order of Accessible PDF

Report · May 22, 2018

Hello!

I hope someone can help! I created artwork in InDesign for a document that has been printed. My customer has now requested an accessible version of the PDF for their website. So I have made a few tweaks and have set up tags, alt text etc and have done everything I can in Acrobat, including adjusting the reading order so that it flows logically. However, even though I have adjusted the reading order, the 'read aloud' function within Acrobat still reads it in the original order so some paragraphs are being read before others! This is driving me nuts!

Is there something I am missing? Like a check box to say follow my reading order or something? This is my first accessible PDF and I have googled how to do it and followed everything but I'm now stuck.

I hope someone can point me in the right direction.

Many thanks!!

Louise

Report · May 22, 2018

Read-Aloud does not use tags for reading order. It’s not useful for testing accessibility (or almost anything else).

Sent from a mobile device. Please excuse the brevity and/or errors.

Report · May 22, 2018

Oh well that would explain why it's not working then! Thank you for saving me from more hours of banging my head against the wall.

Report · May 22, 2018

Duff's correct. Read Aloud is not a valid screen reader and can't test anything. If you want to use a screen reader, then use either JAWS or NVDA. NVDA is free, JAWS allows limited testing for free.

But you can check both PDF reading orders visually from Adobe Acrobat Pro by examining both the TAGS and ORDER panels.

From the TAGS panel:

Expand the panel enough to see the tags.
Select the first tag at the top of the tree.
Using the arrow keys on your keyboard, "walk" down the tag tree.
This simulates the sequence of how they will be voiced to someone using a screen reader or other assistive technology.
Are they in a logical reading order? Or do they jump around the page? Or to different pages in the document?

From the ORDER panel:

Change the panel's preferences to Show page content groups / Show page order.
Also UNcheck the option to Show like elements in a single box.
Then, read the sequential numbers in the Order panel tree, or the numbered items on the page. This simulates the sequence for those using other assistive technologies, such as Braille devices.
Are they in a logical reading order? Or do they jump around the page?

There are many other items that make a PDF accessible. RO is a critical one, but not the only one. Consider getting specific training in how to make accessible PDFs from InDesign as well as how to check PDFs for compliance. We have classes in this, both live instructor- led online (not canned video) and in classroom at www.PubCom.com/classes

Report · May 22, 2018

Duff and Bevi are both incorrect, at least as of the versions of Acrobat Pro since 2015 (checked with 2015.018.00028).

"Read out loud" in Acrobat is not a full blown assistive technology, but it does follow the tag tree.

If you want to find out for yourself please check out this PDF (https://www.dropbox.com/s/lvuhp60wst98dzt/simple%20text%20with%20two%20footnotes%20in%20two%20InDesi... ) - the order is different in the Tags panel and the Order panel and "Read out loud" follows the order in the Tags panel.

Olaf

PS: BTW - this is another sign that the tagged/accessible PDF community should give up on insisting on correct order per the Order panel and solely focus on the correct order as shown in the Tags panel (reflecting the tag tree as encoded in a tagged PDF).

Report · May 22, 2018

I am prepared to believe that I am out-of-date on this.

If ReadAloud now follows tags.... hallelujah!

Sent from a mobile device. Please excuse the brevity and/or errors.

Report · May 22, 2018

PS: BTW - this is another sign that the tagged/accessible PDF community should give up on insisting on correct order per the Order panel and solely focus on the correct order as shown in the Tags panel (reflecting the tag tree as encoded in a tagged PDF).

Dear Olaf,

You are encouraged to go out to the manufacturers of various assistive technologies and get them to update their products, especially those Braille devices that tend to use the Order panel.

Go for it , Dude! The world will bless you if you succeed. <grin>

Report · May 22, 2018

https://forums.adobe.com/people/Bevi+Chagnon+%7C+PubCom wrote
PS: BTW - this is another sign that the tagged/accessible PDF community should give up on insisting on correct order per the Order panel and solely focus on the correct order as shown in the Tags panel (reflecting the tag tree as encoded in a tagged PDF).
Dear Olaf,
You are encouraged to go out to the manufacturers of various assistive technologies and get them to update their products, especially those Braille devices that tend to use the Order panel.
Go for it , Dude! The world will bless you if you succeed. <grin>

In the long run it is a question of scale. How many "manufacturers of various assistive technologies" do exist, and how many people do (/should) create accessible tagged PDF – and how many of them can you convince/teach to get both orders right? I see the light at the end of the tunnel regarding acceptable support for tagged PDF creation in a couple of mainstream authoring tools (hey – even QuarkXPress is getting there with its 2018 release shipped just a week ago). Not to the least due to substantial technical challenges I do not see the same happen for the order as shown in Acrobat's Order panel.

Time and money (of all the many stakeholders) is better spent in finally getting one thing right (tagging), and I consider it to be waste of energy to try to also get order per the Acrobat Order panel right at the same time.

Just my 2 cents...

Olaf

Report · May 22, 2018

Agree with you 100%, Olaf.

But until we get all of the AT manufacturers and content creators, etc. to buy into that, we still are required by various national regulations to make documents accessible to everyone, regardless of which technology they use (and which reading order the technology uses).

And since this is a tech support forum, not a discussion forum for us technicians, we probably should take up this discussion on one of the several other forums we're both on. See you there!

Report · May 23, 2018

I agree, AT should be guided to concentrate on the tags reading order.

Last time I checked, even the useful reflow mode in Acrobat doesn't use the tag reading order. That makes me sceptic that all AT will only follow the tag reading order in the near future.

The fact that InDesign doesn't support to manage the other reading order the same way as the tag order is another cumbersome issue. The existing of two reading orders wouldn't be that bad, if the authoring tool ID – same manufacturer as Acrobat! – would solve that issue. Do you think it's worth a feature request or technical unrealistic?

Please share the link you continue your discussion. I'd like to follow it.

Report · May 23, 2018

My main interest is to make it clear that there are various contexts where order as shown in the Acrobat Order panel is not required. And I will challenge each and every statement that it is always required.

Six years ago, an international community - with stakeholders from all camps involved - agreed (through a well defined and democratic process) on what an accessible PDF should look like. That community published a document that describes such PDFs - it's the ISO standard ISO 14289-1, Document management applications – Electronic document file format enhancement for accessibility – Part 1: Use of ISO 32000-1 (PDF/UA-1). This ISO standard intentionally disregards order as found in the Acrobat Order panel (or technically speaking, as encoded in the pages' content streams).

If posters in this technical forum stay away from making blanket statements (or giving the impression) that order as shown in the Acrobat Order panel is always required I have much less of a need to state that it is not correct.

So let's agree that tagged PDF (where content order is represented by the tag tree) always is good (and very often mandated), and that in some cases it may also be mandated to have the order as shown in the Acrobat Order panel represent that same content order.

Report · May 23, 2018

an international community - with stakeholders from all camps involved

Olaf, can you fill us in as to which stakeholders from which camps were involved in that decision-making process?

Report · May 23, 2018

Hi Bevi,

As you know, I am the ISO Project Leader for PDF/UA. I was also the chair of the committee that worked from 2004 - 2012 to create the document that became PDF/UA.

I want to address two distinct points:

PDF/UA does not address the “painting order” of PDF content (the order presented in the so-called 'Order panel') because this sequence is strictly relevant to visual rendering, not to accessibility. Among other reasons, painting-order does not include semantics, and thus, cannot represent semantic structures such as tables and lists.

Yes… some software - including some AT software - is either incapable of or chooses not to use the tags that provide accessibility features in PDF. Some developers attempt to make up for this limitation by representing as “accessible” the output from processing PDF objects in painting-order. That does not imply that the rest of the world is obliged to follow their bad example.

Look at it this way: A users may try to read a PDF file with a text-editor. We can’t stop them. All we can do is advise them that while they might occasionally get lucky, they have no right to expect useful results that way.

- Process

You’ve asked about the stakeholders. In the context of the discussion this is a serious question, so I’ve drafted a serious answer.

PDF/UA was developed in committees that have always been, in principle and in practice, open to any interested party. The main PDF/UA development list was owned by AIIM and had about 90-120 people, who received formal information (meetings, minutes, drafts, comments, discussion, news). In practice, anyone in North America who was interested in PDF/UA’s development could attend with zero paperwork; we were totally non-restrictive. Additionally, we had several “guests” from Europe who made major contributions (Olaf is one of these). In practice, we accepted essentially everyone whenever they asked to join.

Generally speaking, I can't identify those parties for you, not least because it’s not my right to do so. I can tell you that the list was monitored by at least one of the WCAG 2.0 editors, several members of the US Access Board, one of the developers of NVDA, a variety of activists and technical experts from the world of web accessibility, and many others. Since the discussions tended to be highly technical, few of these were active participants in the process. However, the salient point, I think, is that the discussion was available to those who wished to attend it.

- The “order panel” discussion

We did have the “shall we require the Order panel follow the logical reading order” discussion several times during the development of PDF/UA. I believe it’s fair to say that we achieved consensus understanding on this point: a semantically-useful “Order panel” result is a nice-to-have, and no more. It cannot be considered as an accessibility requirement because that’s not what painting-order is about, and because the real accessibility model in PDF IS defined, has been for 18 years (and it ain’t the Order panel).

Now, none of this is to say that X or Y usage might benefit from having ordered the painting-order of content in some way. But we can’t confuse that with accessibility just because someone's output happens to be Braille.

The truth is simply that if a given software doesn’t read PDF tags then the developer has no right to say that the software supports accessible PDF. They are simply hacking PDF trying to make up for their choice not to implement support for the relevant features of PDF. Given the plethora of available software to consume tagged PDF, those who wish to claim support for PDF have simply zero excuse for not getting it right.

Bottom line: The sequence in the order panel simply cannot be considered an accessibility “requirement”. It can be a “nice-to-have” due to occasional utility in accommodating obsolete software. Period.

I am always happy to talk to any developer who wishes to discuss this subject. From a PDF technology point of view I’m afraid it’s quite cut-and-dried.

Duff.

Report · May 31, 2018

Hi Louise,

I'm not sure if this has been mentioned yet but if you are experiencing issues with the reading order even though you have tagged them correctly, then you may need to change them in you page properties as well.

One the sidebar go to the pages icon to view your page thumbnails and select all pages, right click and choose Page Properties at the very bottom and you should see a dialog box as below. Under the Tab Order tab make sure that it is set to Use Document Structure or it will not follow the reading order you set up with the tags.

I hope this helps.

Report · Jun 05, 2018

I'm running into issues with the reading order as well on PDF forms.

I've tested with both JAWS and the Adobe Read Aloud Tool.

From everything I can tell, my form fields have been moved all the way to the bottom of the reading order panel and both JAWS and Read Aloud are ignoring them.

I'm trying to drag them higher in the list but I can't.

This is happening with a couple users and several different forms. I'm guessing there's some setting we're missing somehow but I can't figure it out for the life of me.

https://dcccd-my.sharepoint.com/:b:/g/personal/jdb1132_dcccd_edu/EagCTjQlH1ZIuv464Oh4XS8BJDoz0lVJ-v3...

Report · Jun 05, 2018

the Adobe Read Aloud Tool

No no no no NO!

Read Aloud is not an assistive technology. You will get false positives because it lacks the required capabilities of presenting the information to users. And you'll get a lot of false negatives because it just doesn't work.

Do not waste your time with it.

I'm guessing there's some setting we're missing somehow but I can't figure it out for the life of me.

The big secret: form fields/controls must be nested correctly inside the <P> tag/visible printable label.

Suggestions:

Ensure your InDesign is updated to CC:2018 ver. 13.1 as it corrected some bugs in the InDesign-to-PDF-Forms workflow.
Also update your Acrobat Pro to DC:2018.011.20040.
Purchase a colleague's book on accessible PDFs at Books on Accessibility — PubCom Media Best guide in the industry.