- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Thu, 04 Sep 2014 15:42:13 +0200
- To: public-html-a11y@w3.org, "Joanmarie Diggs" <jdiggs@igalia.com>
- Cc: Alex PiƱeiro <apinheiro@igalia.com>
On Thu, 04 Sep 2014 13:40:04 +0200, Joanmarie Diggs <jdiggs@igalia.com> wrote: > 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. Thank you, that is good to know. [...] > 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. I believe that we could make an editorial clarification, and I believe that would be a useful thing to do. A suggestion for text following the requirement: Note that while in some cases this will allow user agents to present the description, there will be cases where user agents can not or do not restrict the information presented to the container element. What do you (and the rest of the Task Force) think? cheers Chaals > Thank you again for your time and consideration of these issues, and for > addressing our primary concern. > > --Joanmarie and Alejandro > > > -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru Find more at http://yandex.com
Received on Thursday, 4 September 2014 12:42:43 UTC