- From: Daniel Weck <daniel.weck@gmail.com>
- Date: Mon, 30 Jun 2014 13:55:08 +0000
- To: public-html-a11y@w3.org, Edward O'Connor <eoconnor@apple.com>
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). 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. 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. 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 Regards, Daniel
Received on Tuesday, 1 July 2014 14:19:18 UTC