- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 12 Mar 2012 23:49:51 +0100
- To: Geoff Freed <geoff_freed@wgbh.org>
- Cc: "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Geoff Freed, Mon, 12 Mar 2012 21:31:46 +0000: >> Have any EPUB implementors indicated they will provide UI for >> (epub:describedAt; >> http://diagramcenter.org/development/epubdescribedat.html) and, if >> so, what sort of UI? > > It looks like there are at least two planned implementations-- one > EPUB reader and one EPUB authoring tool. There is also the > possibility of another EPUB reader committing to support > epub:describedAt. I cannot name names, however. NIH? Or are EPUB readers in competition with Web browsers? One could argue that it is a pity that the longdesc attribute is perceived as so 'locked' into HTML that the EPUB community and the ARIA community feel they have to implement it with another name. For instance: A service like ibisreader.com [1] allows one to store the EPUB books one owns in a Web based EPUB reading service. So - when EPUB3 is just HTML5 with some extra - it seems meaningless to not have the same attribute for both specifications? [However, it does opens up for a new use case for @longdesc: Conversion - to and from - epub:describedAT.] Also, I don't really understand the justification for epub:describedAT: Even if @longdesc would remain obsolete, EPUB is still - formally - not HTML5. If epub:describedAT is, in any way, a better choice for EPUB than @longdesc would have been, then it must be related to other issues than the obsolete status in HTML5. What could that thing be? Is it because you could envision that epub:describedAT can be used in other e-book formats as well. [That is: Other formats than HTML5.] [1] http://ibisreader.com -- leif halvard silli
Received on Monday, 12 March 2012 22:50:23 UTC