- From: <bugzilla@jessica.w3.org>
- Date: Sat, 08 Sep 2012 20:00:27 +0000
- To: public-html-a11y@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18744 --- Comment #15 from Maciej Stachowiak <mjs@apple.com> 2012-09-08 20:00:27 UTC --- (In reply to comment #14) > (In reply to comment #9) > > At first, I was puzzled about the fact that Steve proposed a positive example > (see comment #3) which included <label>, wheras Ted proposed a negative > example which included <label>. But then I saw that in Steve's case, it was the > <label> that was hidden, whereas in Ted's case, it was the <input> that was > hidden. > > Having noted that diff, I'd like to suggest some improvements: > > (1) Describe the principle. Summarized, we could say that Ted’s new text > recommends that, in case of indirect relations between hidden > *labels/captions* and some visible content then the hidden label/caption > content should be exposed. Whereas when visible label/caption content > reference hidden *content*, then the hidden content should not be exposed. > Could a summary along those lines be added to the text? I think it would be > useful if readers were able to discover a pattern. Sounds like a good idea to describe the principle better. I will leave it to Ted & James to propose specific refinements, though! > > (2) Improve the positive examples by adding a <label> example: I think it would > be very useful to include Steve's positive <label for> example - along side > with Ted's negative <label for> example. If both examples are there, then it > prompts readers to analyze and discover the difference. I think <label for> isn't quite like the other cases. Reasons: 1) <label> is expected to act as a short label which can be presented directly inline by assistive technologies, rather than a long description. Structure seems less obviously useful for labels than for long descriptions; labels often use intrinsically plain text mechanisms like alt="". I think this is a difference between text a screenreader would present inline, and text that would only be presented specifically on request. In the latter case, it seems more appropriate to potentially use more structure. 2) <label> has the ID association backwards; the auxiliary label/description references the content rather than the other way around. So that makes it unlike any of the other cases we are thinking about. I think there's a difference between letting references point to hidden elements and letting hidden elements create references. For example, you might have multiple labels pointing to the same control and hide all but the currently relevant one. 3) Historically, it appears that hidden or display:none labels are not presented at all by assistive technologies, at least in my testing. So the change wouldn't just be flattened to structured, it would be not presenting to presenting. That's a potential compatibility risk. I think the other positive examples are cases where there is already something exposed, but it may be beneficial not to force it to be flattened. > (3) I think the text > > """Cases where it would be inappropriate include""" > > should be congruent with the text about when it *would be* approriate. For > example like this: > > """Cases where it would be inappropriate for the structure > of hidden="" elements to be exposed to users of AT with > such an API include""" > > (4) Regarding the negative examples, then they should be described more > congruently with the positive examples. For the positive examples, then the > hidden="" element is mentioned first: "a <map>" and "table headers". Please do > the same for negative examples. For example like this: > > ]] > * a hidden="" element referenced by a hash name in a [visible] > <a href> within the same document > * a hidden="" form element referenced by a [visible] <label for> > ]] -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Saturday, 8 September 2012 20:00:28 UTC