Re: Draft text for summary attribute definition

Hi Gez,

I'm fine with using role='presentation' for layout tables. I think  
that addresses the use case I described adequately. The only concern I  
have with that is that AT already supports null summary in that  
situation with less existing support for role='presentation'.   
Obviously that could change over time and my objection would diminish  
entirely. However, I do not think this is an overloading of 'summary'  
at all since there is no other meaning of summary='' that I am aware  
of than the one described in the WCAG technique. Since this has become  
an occasional practice for authors, HTML should address it to at least  
say "authors must not use summary='' as an indication of layout tables  
but instead must use role='presentation'". Again I'm not invested at  
all in how this gets solved, but I don't want to see another document  
conformance specification produced that doesn't make this clear for  
authors. Again leaving it ambiguous or allowing debates to spill over  
into the specification does a disservice far greater than simply  
picking an approach and publishing it as a recommendation.

The other problem that you're still not addressing is the issue of  
captions directed at non-visual users. Perhaps this doesn't need to be  
addressed in the 'summary' attribute prose at all. Instead we can  
provide such advice in the 'caption' element prose. However, this has  
been a point of confusion and ambiguity for authors and so I think we  
should address it head on. This could be something along the lines of  
saying authors must not use the 'summary' attribute for captions  
directed at non-visual users but should instead see the 'caption'  
element criteria for authoring captions specifically for non-visual  
users.

I think the reason this has been so circular is that you're assuming  
I'm here to advance a particular solution to this ambiguity problem.  
Instead I'm offering the solution I thought was suitable on first go.  
I didn't expect it to raise feathers especially since its only offered  
in the form of a draft which I welcomed anyone to alter on the wiki at  
their will (provided they simply listed the substantive changes in the  
"issues for discussion" section). I really don't care how the  
ambiguity gets addressed I just don't want to leave any in the  
document. And right now I fear WCAG does leave the ambiguities  
unaddressed (especially if we leave the WCAG techniques out of  
consideration of WCAG which I think you're suggesting).

Take care,
Rob


On Feb 28, 2009, at 10:16 PM, Gez Lemon wrote:

> 2009/3/1 Robert J Burns <rob@robburns.com>:
>> Do we need to rely solely on heuristics to determine which tables  
>> are layout
>> and which are not when some authors will be eager to make the  
>> distinction
>> explicitly? I think we do a disservice to non-visual users if we  
>> take such a
>> strident approach.
>
> A better approach to explicitly identify layout tables would be to use
> explicit markup, rather than interfering with an attribute whose
> primary purpose is to provide guidance on how to read a data table for
> people with vision impairments. Using role="presentation" on a layout
> table is infinitely better overloading the definition of the summary
> attribute.
>
>> I'm not speaking about WCAG here. I'm suggesting that it is  
>> advisable to
>> mark the use of layout tables explicitly, since it allows authors  
>> who need
>> to resort to a single layout table to make that explicit in their  
>> markup
>> rather than forcing AT to rely on heuristics.
>
> Depending on heuristics could be avoided with explicit markup, such as
> role="presentation", rather than interfering with attributes intended
> to aid accessibility. There is already confusion about how to use the
> summary attribute, without trying to make it the workhorse to
> determine which tables are data tables and which tables are layout
> tables, and used as a backup for when someone doesn't provide a
> caption. The summary attribute has a definite purpose, explained in
> version A in the wiki.
>
>> Part of stating unambiguously is filling in the holes where authors  
>> will be
>> confused about what to do. One of those places is when an author, for
>> whatever reason, feels the need to resort to a layout table. If we  
>> don't
>> provide advice for this situation we do harm to AT users.
>
> Markup already exists to unambiguously determine a layout table.
> Overloading the purpose of the summary attribute adds unnecessary
> ambiguity. The purpose of the summary attribute is to describe how a
> data table is to be read. Simple. If a layout table must be used,
> role="presentation" removes ambiguity for AT.
>
>> The second place
>> that leads to ambiguity is not telling authors what to do when they
>> determine their visual users do not need a caption. If we don't  
>> want summary
>> used for this purpose, then we should still state explicitly what  
>> authors
>> should do in this situation.
>
> This is probably the main reason why this discussion has been circular
> on the HTML5 mailing list, with everyone talking past each other. The
> purpose of the caption element and the summary attribute are
> completely different. The caption is intended to provide a title for
> the table. The summary attribute is intended to guide users with
> visual impairments how to read the table. The summary attribute isn't
> a backup for the caption, or vice versa.
>
>>> WCAG 2.0 does not give advice about providing a summary attribute  
>>> for
>>> layout tables. One of the techniques makes a passing reference to a
>>> null attribute being acceptable on layout tables (not recommended;  
>>> not
>>> advisable; acceptable).
>>
>> Agreed.I wasn't trying to claim any more than that. However, I do  
>> think it
>> is something that HTML document conformance should address or we  
>> leave
>> ambiguity that is harmful to some users.
>
> Beyond describing the purpose of the summary attribute with simple
> examples, guidance on using the summary attribute is best left to
> WCAG, or we run the risk of people trying to overload the purpose of
> an attribute that is important for accessibility.
>
>> I simply want to make sure we
>> address the problem of layout tables (though that might be done  
>> instead with
>> another criterion such as perhaps prohibiting layout tables).
>
> The use of something more explicit, such as role="presentation",
> addresses the problem of layout tables without overloading the purpose
> of an important accessibility attribute.
>
>> Again, I feel
>> it does harm to AT users to not address the situation.
>
> Something more appropriate, such as role="presentation", addresses  
> this concern.
>
>> I wasn't really referring to the prose. I'm suggesting that leaving  
>> gaps in
>> these particular situations and use cases (and there may be others)  
>> leads to
>> ambiguity, however well written the prose. So my point is that if  
>> we do not
>> address the omission of captions (which often aren't needed for  
>> visual
>> users) and the continued though diminished use of layout tables, we  
>> leave
>> ambiguity in the specification that is detrimental to disabled  
>> users and
>> users of non-visual media.
>
> Overloading the use of summary attribute really isn't a good idea, no
> matter how well intentioned your reasoning. It has a specific purpose,
> and redefining its purpose to align it with caption is the main reason
> why there is so much resistance to it being accepted in HTML5.
> Personally, I would prefer HTML5 to make the caption element mandatory
> for data tables. I know that isn't going to happen, but I don't want
> the summary attribute abused to make up for it.
>
>
> -- 
> _____________________________
> Supplement your vitamins
> http://juicystudio.com
>

Received on Sunday, 1 March 2009 04:21:21 UTC