Re: Extended description requirements analysis


> On Oct 19, 2015, at 12:13, Deborah Kaplan <dkaplan@safaribooksonline.com> wrote:
>
> The table is at http://w3c.github.io/dpub-accessibility/extended-description-analysis.html

>
> We hope this is helpful, and please let us know if there are any further questions about it.

Thank you for posting this analysis. My comments focus on the first table. I hope they are helpful to the ensuing discussions.

In the entry for “figure with details” element, the first “con” is mitigated by the fact that the feature is in HTML 5.1 drafts and already has implementations. It isn’t clear why you're singling out  the details element as a problem in this respect, since several of the other solutions described in the table (annotations, Web Components, aria-describedat, etc.) are subject to the same concern. The details element and Web Components have the advantage of already possessing user agent implementations.

The second “con” isn’t clear; I think this use case applies the details element in exactly the way in which it is meant to be used. I wouldn’t say it “overloads” it. If you mean that it doesn’t disclose the assistive technologies what it’s being used for then that’s certainly true (in the absence of a new ARIA role) but you address this elsewhere.

I think the last two “cons” are dubious: the details element isn’t complex to author and it works without scripts (unless one is concerned about polyfills, which will go away as UAs implement the feature).

Under “figure with details with embedded iframe”, could a user agent optimize by not loading the contents of the iframe at all if the proposed media query that reflects the user’s preference regarding presentation of extended descriptions indicates that they should not be shown? This would address the first “con” noted in the entry.

I think the second “con” should be explained and clarified.

Under “accessible SVG”, there are advantages that should also be listed, including the possibility of interactively reading and navigating the graphical content (especially important for comprehending data visualizations, technical/scientific diagrams, etc.). By using an ARIA taxonomy to make the SVG content accessible, AT can provide a uniform presentation of graphics of the same type - that is, it’s no longer dependent on the author’s choice as to what to describe and how to describe it. Your existing “pro” concerning associating descriptions with graphics could be clarified: you can associate titles and descriptions with individual parts of SVG content, not just with the graphic as a whole. Finally, SVG content can be interactive, e.g., a map that expands to reveal more information when the user selects a point. The work on SVG accessibility is designed to address the needs derived from such interactivity. Most of the solutions in your table don’t address (or don’t easily address) automatically generated or interactive graphics, because they require descriptions that are hand-authored. Natural language processing can be used to generate descriptions in some cases, but that’s a much more complex solution that also raises accuracy issues.

Under “link in figure caption”, note that a media query (not yet defined, but the same one that would support the details element as noted above) could be used to hide the link from those who don’t wish to access extended descriptions.

Also, I think the proposal here is to take the content that needs to be described, wrap it in a figure element and include a figcaption that provides the link. Since a figure element can enclose all of the relevant types of content (table, img, object, etc.), the fact that not all figures have captions (the con listed in your table) misrepresents the proposal.

Under “hidden iframe” I don’t understand the con. It seems to me that the iframe is being used appropriately in this technique.

Under “Web annotations”, the same comment applies regarding the con that was noted above concerning the details element - that implementation status is an issue which you take up elsewhere in the document and thus shouldn’t be listed here.

I also have difficulties with your criteria for assessing the various solutions. For example, whereas you claim that techniques in which the description is always included as part of the principal document rather than fetched on demand may unduly increase file size, you don’t address the disadvantages of linking to descriptions, including for example the following.

1. If descriptions are provided by remote resources that the user agent fetches only on demand, then the fact that the user has chosen to read an extended description will typically be logged by the Web server (i.e., the retrieval of the description resource is logged). If this information can be associated with the identity of the user, as should be easy in many cases, then the fact that the user requires extended descriptions is disclosed to the Web server, and this has privacy implications. Of course, there may be other techniques for attempting to find out whether the user is likely to have a disability, but the problem here is that this one is trivial to carry out.

2. If extended descriptions are retrieved on demand from remote resources, then users for whom network access is limited or expensive are disadvantaged. Suppose I download a collection of EPUB books to take on holiday (a destination where network access is costly or limited). The fact that the books won’t be accessible to me without accessing the network, whereas they are accessible to people who have no need for image descriptions places me at a real and substantive disadvantage. This problem could be mitigated by a tool that fetches all of the descriptions and re-packages the book, but the real solution is for the descriptions to be included in the book in the first place, either by default or by selecting an option before initiating the download.



________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Monday, 19 October 2015 19:07:59 UTC