Re: PDF/UA footer artifact discussion

Oops, that went off before I meant it to! 

Here's the complete email…

-----------
Jonathan,

> Yes, as we agree currently there doesn't appear to be any support for
> Artifacts by screen readers including the Read Out Loud tool in Acrobat.
> WCAG 2 requires "accessibility supported" methods.

Yes indeed. There's nothing about artifacts that's "new" at all, but AT developers haven't dealt with the subject (yet) for a variety of reasons.

> While you make a good point that page labels can be used, some information
> in headers/footers cannot be captured in page labels.  For example,
> documents may repeat the chapter name at the top of all pages in a
> chapter. This assist users who can read print in knowing what chapter a
> page is within.

That's true. PDF/UA helps with this with (a) the strict heading levels requirements and (b) the requirement to expose artifacts, but it's not ideal, certainly.

>> PDF/UA requires conforming AT to be able to report artifacts to the user
> on request.
> 
> One challenge for people who cannot see the page is knowing when to
> request the information….

I used the wrong word.  This isn't about "requesting" - PDF/UA does not attempt to prescribe any implementation. It simply states that artifacts must be made available. It doesn't suggest that the software wait for the user to ask for the artifacts.

I agree that "noticing" an artifact isn't practical if they… can't be noticed. If I were implementing PDF/UA in a reader I might deal with this by having the reader announce the presence of artifacts on a page when that page is displayed, thus giving the user the option of investigating the artifacts that have been reported to them, or otherwise simply proceeding with the text.

My point is that PDF/UA…

a)  Requires correct use of artifacts
b)  Requires conforming readers and AT to be able to deliver such to the user

>> Including page headers and footers in the logical structure is plainly
>> wrong; this content isn't part of the document. Page header and footer
>> content is "metadata for the physical page" - no more. Including such
>> artifacts in the logical structure would not necessarily advise users of
>> page-numbers (because it's "just a number" out of context) and certainly,
>> would routinely introduce confusing breaks in the logical flow, sometimes
>> occurring within words, sentences or paragraphs.
> 
> While I agree most footer and header information is metadata related to
> the page or document, there may be things in the header and footer that
> need to be structured. For example, a footer could contain a link -- how
> could this information be structured if it was an artifact?

That situation doesn't sound like a running page header or footer to me. In any case, the link itself isn't (and can't be) an artifact, so there's no problem with including it in the structure (in fact, it *has* to be included in the structure.

> Additionally,
> footnote information is indicated by PDF/UA to be a note element with the
> logical structure of the document - and footnotes break the flow of the
> logical structure as well.

That's an interesting point. ISO 32000-2 (and thus, PDF/UA-2) will include powerful new options for allowing AT users to perceive footnotes either in-line or out-of-line with document text, just as conventional users do with footnotes today.

As of PDF 1.7, however, there's no solution for footnotes except to include them in-line.  You can see this as "breaking the flow" but I think it would be fairer to call it: "cluttering the flow".

>  Document metadata is also not very accessible
> to users with disabilities.  For example, if the page contained metadata
> such as form numbers, users of screen readers would need to access the
> document properties dialog and hunt for this information while the same
> information is provided instantaneously to users who see the printed page.

Well, document metadata isn't page metadata, and the document metadata dialog is unlikely to carry page-specific metadata (unless it's a one-page PDF, that is).

I'm not sure why a printed form number would not be tagged into the logical structure, especially if it's identifying the page. Certainly, today's solution for that use-case is to tag the form number into the logical structure.

> We need to find an equivalent manner to inform and allow the user to
> access the page meta data in an reasonable manner.  It sounds like the
> current PDF specification doesn't allow for this -- but users need access
> to the information today.


Well, the key page metadata, I think we can all agree, are the printed page numbers, and I've already mentioned today's solution for that content.

Running headers and footers should certainly be artifacts; I appreciate that as such they aren't accessibility-supported today. That said, it's hard to see a good case for handling them in an accessibility-supported way at this time; that solution seems (to me) worse than the disease.

Duff.

Received on Monday, 11 March 2013 17:30:24 UTC