Re: Call for consensus - longdesc to CR

A few comments inline.

> On Jul 25, 2014, at 6:07 PM, Daniel Weck <daniel.weck@gmail.com> wrote:
> 
> Note that I merely highlighted inaccuracies in Ted's email, I did not
> speak in support or against @longdesc.

I understand. Thank you. I was also just pointing out clarifications of your response.

> It is my understanding that the EPUB specification does not formally
> recommend a particular method for out-of-line descriptions (internal
> to the publication package, or external e.g. HTTP URI). However, there
> are ongoing efforts exploring the state of the art, including
> aria:describedBy, and potentially aria:describedAt too (which are not
> restricted to images, but can be used to describe tabular data, etc.).

As the current editor of the ARIA spec, I added @aria-describedat to the ARIA 1.1 working draft because it gathered majority vote in the working group, despite my objections and lack of group consensus. @aria-describedat has all the same problems as @longdesc, but also breaks an established and generally accepted ARIA pattern of not modifying the mainstream UI of the host language. Accessibility-conscious user agent developers from Mozilla and Google raised similar objections to @aria-describedat.

James

> For example, see the DIAGRAM content model + exemplar EPUB (basic
> linking to linear="no" ancillary documents):
> http://diagramcenter.org/standards-and-practices.html
> 
> /Daniel
> 
> 
>> On Sat, Jul 26, 2014 at 1:23 AM, James Craig <jcraig@apple.com> wrote:
>> 
>>> 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 02:22:11 UTC