- From: David MacDonald <david100@sympatico.ca>
- Date: Thu, 11 Jun 2015 07:22:47 -0400
- To: Jonathan Avila <jon.avila@ssbbartgroup.com>
- CC: "Hoffman, Allen" <allen.hoffman@hq.dhs.gov>, Gregg Vanderheiden <gregg@raisingthefloor.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-ID: <BLU437-SMTP1398A42F00F082CC56AE15FEBC0@phx.gbl>
>>>Well, it could be a user agent option. For example, there is a specific artifact type for pagination – so there seems like the option to expose this information on request since it already has to be properly coded as pagination. David response: There are a couple of ways to respond to that. The first is that I'm not sure that would be so easy. If "user agent option" means the screen reader could query for the pagination artifact and have a setting to speak it or not, I don't think so. I don't think the Screen reader has access to the code, it only has access to the tag tree. And from what I can see, there does not appear to be a distinction between a pagination artifact and any other sort of artifact. If you mean that the PDF reader could expose it, that would be possible, but it would have to sniff for that artifact in the code and then convert it to some sort on other tag in the tag tree so that the screen reader would recognize it, yet ignore other types of artifacts in the document. Further, there is no distinction between pagination artifacts that are changing from section ti section or page to page and other types of running headers and footers which are also pagination artifacts. The PDF spec is not that granular. All this to say that I don't think this is a realistic expectation, and an onerous demand upon user agents, and difficult to implement with the current PDF standard. The second way to answer this is that WCAG attempts to solve the *practical* problem of inaccessible content now, rather than shoot for a theoretical target. So our "accessibility supported" requirement wouldn't make assumptions that in the future this or that user agent behaviour could overcome a particular problem. The content fails now if it is not accessibility supported now. All this to say I'm in favour of Kerstin's failure suggestion, "Failure of 1.3.1 due to information in the header or footer not being available in main body of the document" and a reworking of PDF14 so it is consistent with itself.
Received on Thursday, 11 June 2015 11:23:20 UTC