Re: SC 1.4.10 Reflow and PDFs

HI Steve,

> With respect to the paragraphs that are overlaid vertically in Reflow mode, this even happens when the Tags panel is perfect. It just about never occurs in documents I create, and it seems to happen mostly when the source document is a dog’s breakfast. I often wonder why on earth people create documents the way they do. I expect there is some parameter buried deep in the tag properties that causes the problem, but I can’t find it.

I’m guessing - without knowing - that the software is trying to do the job too crudely by retaining source content styling regardless of results. Other reflow software (e.g., Liquid mode) does a much better job of it. 

Indeed, it’s also possible that the tag's attributes are either wrong (don’t reflect the content) or unused by Reflow (which appears to use only a modest portion of tagged PDF). 

> The reading order in Reflow mode is still based on the Content panel, so you have to fix that. Most people who do document remediation don’t do it, but some of us do. For those who don’t know, you must fix the Content panel order before fixing the Tags panel.

This is tragic, and results from the fact that Reflow was never intended or designed to meet accessibility needs in the first instance, so users are forced (if they insist on making this software deliver useful results in an accessibility context) to hack aspects of the PDF that should never need to be touched.

Users can’t be blamed for the dogfood set in front of them. When (ok… if) reflow software ever supports tagged PDF properly the idea of hacking around in the (misnamed) Content panel will become obsolete once and for all.

Duff.



> From: Duff Johnson <duff.johnson@pdfa.org <mailto:duff.johnson@pdfa.org>>
> Sent: Friday, December 1, 2023 4:50 PM
> To: Steve Green <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk>>
> Cc: Mark Magennis <Mark.Magennis@skillsoft.com <mailto:Mark.Magennis@skillsoft.com>>; w3c WAI List <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>>
> Subject: Re: SC 1.4.10 Reflow and PDFs
>  
> To return to Mark’s original question, images are displayed in Adobe Reader’s Reflow mode as long as they have a bounding box and were not marked as decorative in the source document.
>  
> Thanks for pointing that out!  I should have kept better track!
>  
> This is very positive in that it shows that even the basic Reflow tool is incorporating at least some aspects of Tagged PDF. 
>  
> However, in a test I just ran, although Adobe Reader in Reflow mode did respect the tagged / artifact distinction, it did NOT respect the tag order, which is (obviously) essential to accessibility.
>  
> Software is always a moving target. Adobe should be encouraged to continue improving its support for tagged PDF in the Reflow context.
>  
> Also, paragraphs sometimes overlay each other vertically, and my experience has been that this cannot be fixed in Acrobat – it can only be fixed in the source document. If anyone knows how either of these issues can be fixed in Acrobat, I would be very interested to hear.
>  
> Can you say more about this… are such paragraphs tagged correctly in the PDF, for example?
> 
> 
> Once you have fixed a PDF so it reflows nicely in Adobe Reader, there is a new question. Is this sufficient to claim that the reflow success criterion is met in an accessibility supported manner? WCAG ducks this question completely. When Adobe Reader was pretty much the only PDF reader, I think it would have been perfectly reasonable to say that reflow was accessibility supported. Now there are numerous PDF readers that don’t support reflow, I am less sure.
>  
> Even more so as today browsers are the dominant software used to view PDFs… and browser developers are a long, long way behind the better desktop viewers in their PDF support.
>  
> As such it’s really the browser vendors (mostly, giant corporations who can well afford the development effort) who need to get their act together.
>  
> Duff.