Screen-reader reads only the label and not the list body

[Oriane5F88]

Hi, 

I have noticed that JAWS screen-reader does not read the list items of my PDF correctly. If I press "I", it will only announce bullet (or "a" if it is an ordered list), but will not continue with the content. To fix the issue, in the content panel, I gathered all the text of the list item (including the bullet or the "a") and copied it into one paragraph container. Although in the Tags Panel there is now no <lbl> for the bullet, but only a <Lbody>, JAWS now reads the list item with the bullet and the text when I press "I". I think this is strange because the structure is not correct, right? Does anyone have an idea why this is so? 

This fix worked with my bullet lists. However, when I tried to do the same with my ordered list, it only works partially. JAWS will read the a) + the text, but only the beginning. How can I can make sure that the whole text of the list items will be read?  

To illustrate, I put a screenshot of the list item I would like to read with JAWS. If I press "I", JAWS will read "a Tandis que certaines hautes écoles disposent d'un", so, only the first line. 

Thanks for your help in advance! 

Best, 

Oriane

[maxwithdax]

While I is "Next item" and understandably you would think it would read the entire item, many times it will not. You can try retagging but Insert + Down Arrow is "Read from this point on"

I do realize that is not exactly what you are asking for but it is worth mentioning that JAWS has many bugs and tries to interpret text in ways that is not very useful. The same can be said for NVDA. It is the nature of screen readers. I would suggest testing with NVDA but again, I know your question is more about "How can I make this work right" and less about a workaround.

[Oriane5F88]

Thanks your response @maxwithdax. I indeed hoped someone would have a fix for this, but it is still helpful. 🙂

[Bevi Chagnon - PubCom.com]

@maxwithdax is correct about the bugginess of JAWS and NVDA, especially with PDFs.

Another suggestion: reset your preferences every once in a while, and relanuch the screen reader. I'm always amazed at how this trick can sometimes jigger its memory.

But overall, screen readers are more stable and predictable with HTML than with PDFs and EPUBs. That's because they are deliberately programmed to handle HTML while a lot of features in PDFs are ignored. And that's why the concatinated list in your sample reads correctly without the <Lbl> tag around the bullet/number/letter (which are called list "ornaments.")  I don't know of a screen reader that, at this time, recognizes the <Lbl> tag and knows what to do with the tag.

So the <Lbl> tag is ignored, but the content should be voiced, followed by the <LBody>'s content.

As far as I can tell, the only PDF tag for lists that is recognized by screen readers at this time is <LI>/List Item. That's because it's identical to HTML's <LI> tag.  But while the <Lbl> and <LBody> tags are ignored, their content is still voiced.

In theory, you could string a bunch of <LI>s together without the <Lbl> and <LBody> tags  -- or even the <L> tag  -- and put their ornaments into the <LI> with the text, and everything will probably be read correctly by a screen reader.

So the question ends up being, why should we make a compliant tag structure, even when screen readers ignore some of the tag structure? Because we're developing documents to be used by all assistive technologies, not just screen readers and not just those technologies that are in use today. Hopefully, some smart developer will put those <Lbl> tags to good use!

Remember the R of the POUR principals: Perceivable, Operabale, Understandable, Robust. Robust means:

• It's compatible with many different technologies.
• And, therefore, it has a long shelf-life. A compliant PDF made today should still be a valid, compliant, workable, readable, and accessible PDF 10 years from now, even when used by future technologies.