Re: Call for consensus - longdesc to CR

> On Jun 30, 2014, at 6:55 AM, Daniel Weck <daniel.weck@gmail.com> wrote:
> 
> 
> Hello Ted,
> Although I do not wish to challenge the main argument for your (Apple's) formal objection ; i.e. "built-in a11y” (self-contained HTML document) vs. “bolt-on a11y” (external description file) ; I feel that some of your statements are incorrect, and should therefore be highlighted.
> 
> 1) You say: "It's not clear how longdesc UI could sensibly work in contexts such as ebook readers, where both popups and wholesale replacement of the current view would not fit standard UI patterns."
> 
> ==> Well, Apple’s own reading system (iBooks) implements both mechanisms: EPUB3 footnotes are displayed separately from the main text flow using a popup callout, and ancillary “non-linear” XHTML files are displayed within a fullscreen modal viewport (completely detached from the regular paginated context, effectively branching off the main narrative).

Yes, EPUB footnotes are well specified. Part of the objection to the longdesc spec is that it is bolt-on, and part of the objection is that is is incomplete. 

> See Apple’s official documentation:
> https://itunesconnect.apple.com/docs/iBooksAssetGuide5.1Revision2.pdf
> 
> Note that non-trivial content description files (not just for raster images, but also tables, diagrams, figures, etc.) would typically be marked as “ancillary / non-linear" in the EPUB spine of HTML documents, so the “fullscreen modal viewport” feature actually comes-in really handy here. Also note that this feature currently relies on regular HTML links (a@href), not @longdesc.

That may be your intention to use a fullscreen modal viewport for longdesc in EPUB, but it's not specified anywhere are far as I can tell. 

> 2) Ted, you also recommend "the use of EPUB's existing footnotes feature to provide extended descriptions of raster images in books."
> 
> ==> which seems to contradict the aforementioned statement #1.
> 
> 3) Ted, you argue: "In self-contained contexts like ebooks, longdesc is problematic because a book may be read offline. Therefore, encouraging use of a technique that may place critical accessibility information on the network is actively harmful to accessibility."
> 
> ==> @longdesc (just like @aria:describedAt, or @aria:describedBy + iframe workaround) would be referencing an XHTML file *local* to the ebook package / archive, explicitly listed in the manifest.

That may also be your intention, but I do not think that is specified anywhere.

> The description would *not* be linked to an external resource (e.g. HTTP), which otherwise would result in an invalid EPUB.
> See:
> http://www.idpf.org/epub/30/spec/epub30-publications.html#sec-resource-locations
> http://www.idpf.org/epub/30/spec/epub30-changes.html#sec-removals-filesystem-container

Longdesc just takes a URI. I do not see anything in EPUB defining external URIs as invalid; otherwise regular href links would also be invalid in EPUB. There is also nothing in the longdesc spec about constraining the URI in the context of an EPUB document.

> Regards, Daniel
> 
>

Received on Saturday, 26 July 2014 00:23:42 UTC