Additional observations on specific SC

Some additional observations...

WCAG 2.0 speaks only of "pages" but the WCAG2ICT draft claims to address documents. However… the term "document" does not appear in the "Understanding Key Terms" section! Is it not a key term for the WCAG2ICT? Should it not be developed and placed in context with "page", especially since "page" has operationally and semantically distinct meaning in web and non-web contexts?

SC 1.3.1 - Leaving aside that I've no idea how this SC would be applied to kiosk applications, it's worth pointing out that SC 1.3.1 already bears a very heavy load. Attempting to cram the world of document-specific or workflow-specific information to this one SC won't generate clarity. Here's an illustration.

Take the case of a scanned page added as the last page of an electronic document. Let's assume all the text on this page has been made accessible; the page image's content is adequately represented via text and tags.

- What of the underlying scanned page-image itself? Does it still need to be represented in the logical structure? Does the simple fact that the page's source was a scan (as is evident to a sighted user) constitute "information" that must also be programmatically determinable to conform with 1.3.1?

- If so, is the fact of a page-sized image made available to AT (in addition to the text) adequate information? If so, then should be OK to write out the image as an artifact (not in the logical structure) because we've already represented the contents in an accessible manner?

- Maybe we have to tag the image if the page has been signed, but not if the page hasn't been signed?

- Does conformance require that each of the signatures be represented individually? Perhaps segmentation of the source-image is required in order to have a image (and thus alt. text) associated with each signature?

The line between "incidental information", and "data critical to understanding the document" isn't always apparent; this is all the more so with formats that are more internally complex than HTML, or present situations that just don't occur with markup-langugage-style technologies.

The WCAG2ICT draft shows zero sensitivity to such complexities.

SC 2.4.1 - the WCAG2ICT has no additional guidance on this SC, and for good reason: 2.4.1 is completely rooted in a "web page" mode of thinking, largely inapplicable in non-web contexts barring some very creative and impressive reasoning. The intent of this SC is not at all readily amenable to easy translation from "page" to "document", and I suspect the Task Force recognized that.

SC 2.4.3 - the WCAG2ICT suggests simply replacing "page" with "document". However most non-web document formats don't use "focussable components" for navigation!

SC 2.4.4 - Again the suggestion to replace "page" with "document". As with SC 2.4.3, this guidance completely misses the fact that non-web documents do not commonly rely on links (or even links as construed in the guidance) to achieve navigation.

SC 2.4.5 - No advice is given here, and I'n not sure what advice could be given. Individual pages are themselves rarely "locations" in the same sense as web-pages. After all, no-one ever produces a table of contents that lists every page in a document unless (for example) headings are present on every page.

For this reason the idea of having "more than one way… to locate a web page" is inapplicable in instances where the _only_ "way" is the physical and/or logical page number. Speaking of which… would this SC be referring (in electronic documents) to "locating" the physical page or the logical page?, if any? I'm guessing it's the physical page, but I just don't know.

SC 2.4.6 - The Guidance fails to even touch on the key point: that headings are commonly the _only_ means of navigation in non-web documents. 

SC 4.1.2 - The Guidance (and the SC itself) doesn't (appear to) account for cases where a given Role isn't exposed through a user interface component. An example would be pre filled forms in which no controls are present but the page contents nonetheless render as a form with pre-filled (or blank, as the case may be) fields. In PDF this is accomplished via the PrintField attribute applied to page content.

Received on Saturday, 8 September 2012 04:00:24 UTC