- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 19 Dec 2009 01:29:19 +0000 (UTC)
- To: Cynthia Shelly <cyns@microsoft.com>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
On Fri, 18 Dec 2009, Cynthia Shelly wrote: > > 1. Treat @summary and <details> the same, as both are hidden metadata. <details> is not hidden metadata. It's a disclosure triangle widget, a commonly used widget on native platforms, and one that authors are much more likely to check when editing their documents than attribute text. (It's less hidden than even the title="" attribute.) > Remove the validator warning for summary, but include strong spec text > encouraging the use of visible text (caption, etc) when possible, and > describing specific scenarios in which it might not be possible. The spec text is essentially ignored by authors, so I don't think this is strong enough. I would like to make summary="" completely non-conforming. I'm willing to compromise on having the conforming-but-warning situation we have now, though I'm certainly not happy about it. > The validator warning is the blocking issue for many of the > accessibility advocates. The lack of a warning is a blocking issue for me. > * Janina had an interesting point: being hidden isn't an accessibility > feature. Being hidden is a feature for everyone else, so that this text > doesn't clutter up their UI. I've yet to see any sites be put forward that demonstrate this. In a past e-mail I wrote: | Could you show me some pages that have tabular data of a nature | complicated enough to warrant a table explanation for screen reader | users (and presumably for other users also), but for which the author | refused to include visible explanatory text but was amenable to | including hidden explanatory text? This particular use case is often put | forward as an argument for summary="", but I am having trouble imagining | it. Seeing some concrete examples of this would really help. -- http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0010.html Seeing such sites would greatly help me understand the anti-explanatory- text position. > 2. Add a SHOULD or MAY for browsers to have UI to allow users to toggle > showing summary (and details?). The default would be not to show. I don't think this is enough, since authors would in all likelihood not turn on this flag. It would be like the the "no images" option, which is not used by most authors, even though using it would dramatically increase the odds that they would write good alt="" text. (Also, we would have to have assurances from implementors that they would actually implement this before we added it. Do we? There's no point us proposing changes that the implementors aren't going to follow, so we really should find that out before deciding on it.) > This seems like it could get us past the issue of hidden metadata being > generally harmful, which has been a blocker for many people. FWIW, I don't really consider summary="" to be hidden metadata. Table explanations are data. They're an intrinsic part of the page. The problem with summary="" is that it is hiding _data_ from page authors, which, as I've demonstrated (e.g. in [1]), results in the summary="" values becoming stale, which harms the experience of AT users who are exposed to the summary="" attribute. [1] http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0104.html > * In threads after the call, the suggestion was made to Would adding a > <summary> inside <caption>, while still allowing the @summary for > back-compat. In many ways, this is the same as details, and could be > subject to the same UI toggle. However, I think it would be easier to > explain to people that summary changed from an attribute to an element, > and would be less disruptive to regulations or existing training. What would <summary> do? If it is hidden by default, like summary="", then it would have the same problems. If it is shown by default, it seems unnecessary (<p> would already handle this job fine). If it is a widget that can be hidden or shown by the user inline, then it seems identical to <details>, and thus redundant. > 3. Further develop the idea of @definesorder, and how it might interact > with aria-sort. This will be a separate change proposal. Wendy > Chisholm has offered to help with this work. Leif, your help would be > most welcome as well. I don't think this should be a change proposal. If there are proposals, they should just be made using the regular process. (Change proposals only make sense once a proposal has been rejected.) > 4. Further explore the cell API, or other ideas that might solve the > same issues. Wendy Chisholm has offered to help with this too. Same. HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 19 December 2009 01:29:50 UTC