- From: Joanmarie Diggs <jdiggs@igalia.com>
- Date: Thu, 04 Sep 2014 07:40:04 -0400
- To: public-html-a11y@w3.org
- CC: Alex Piņeiro <apinheiro@igalia.com>
Hi Janina. Comments regarding individual resolutions are below. In short, we accept the Task Force's resolutions of our comments, though we do not necessarily fully agree with them. We have no plans to raise any formal objections. In order to simplify our response, we've reordered the text (preserving the numbering you assigned). > YOUR COMMENT #4 >> Other additions: >> >> If the longdesc value is valid, user agents MUST make activation >> of the link possible via the platform's accessible action interface >> on platforms where such an interface is present. > > DISPOSITION: Accepted > > We have edited the specification to provide a more generic statement as follows: [...] Thank you. We very happily accept this resolution. This issue was our chief concern as it has direct impact on Orca's ability to provide support for longdesc. Regarding Comments #1, #3, and #5 which are all marked as "DISPOSITION: Not accepted", we accept the Task Force's decision. Mind you, we still have concerns that authors will use longdesc for things which are necessary for understanding core content (our definition of "essential") and which the user might not be able to access due to issues such as difficulty in discovery and/or difficulty in activation and/or lack of support in a given user agent. We also have concerns about how the user can efficiently return to the described element in user agents which do have longdesc support. But our concerns are not specific to Orca users or our platform. Hopefully through a combination of guidance and feedback from end users and developers of assistive technologies, authors and user agents will sort out how to properly use and support longdesc. As for the remaining comment: > YOUR COMMENT #2 >> * When the description is part of the target document, authors SHOULD >> NOT rely upon assistive technologies to constrain presentation of the >> description to that fragment. If such restriction is essential, >> authors MUST take additional means to mark surrounding content as >> hidden. > > DISPOSITION: Not accepted > > While we appreciate the concern regarding content in fragment IDs, this > is a well-known failing of HTML fragment IDs in general. This > specification is not the appropriate place to attempt remedies. We would agree were it not for the fact that this specification contains the following text: When a description is only part of the target document, authors SHOULD link to a container element in the target document that contains the entire description. Given the "well-known failing of HTML fragment IDs in general," putting the description in a fragment seems like a bad idea. But assuming that authors know about these limitations/failings (can we assume that?) and have an overriding need to put the description in a fragment, the specification states that authors SHOULD put the entire description in a container element. Why SHOULD authors do so? The specification doesn't say. Thus speculating on why and the expected results of doing so seems to be left as an exercise for the reader. As readers, we speculated. And our conclusion is that it is not unreasonable for authors to walk away from the above specification text believing the following: Putting the entire description in a container element will make it possible for user agents and/or assistive technologies to constrain the presentation of the description to that element. Here's our problem with that: At least in the case of content being accessed via web browser, if authors do walk away from the specification believing that presentation of the description will be constrained to that element, they will be sadly mistaken -- at least on our (GNU/Linux) platform. We believe VoiceOver may have a similar issue. Thus we would find it helpful if the specification were more clear with respect to why authors should put the entire description in a container element and/or what authors should be aware of with respect to platform differences. Can this not be accomplished through some clarifying, nonsubstantial change? If the answer is "no," then our response is that while we do not agree with the resolution to our Comment #2, we can live with it. Thank you again for your time and consideration of these issues, and for addressing our primary concern. --Joanmarie and Alejandro
Received on Thursday, 4 September 2014 11:40:45 UTC