RE: Current state of the summary discussion

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