Re: [html] Summary draft

On Sep 15, 2009, at 02:28, Maciej Stachowiak wrote:

> I'd like to hear input from the validator.nu developers on this. At  
> first glance, it seems like a warning will be generated every time a  
> table appears.


I think a mandatory warning on every table wouldn't be a good idea  
especially when the proposed text seems to scope summary to be  
necessary only on tables whose heading cell structure is more complex  
than having heading cells in the first column & row.

Other comments:

The proposed text strikes the following paragraph:
"For tables that consist of more than just a grid of cells with  
headers in the first row and headers in the first column, and for any  
table in general where the reader might have difficulty understanding  
the content, authors should include explanatory information  
introducing the table. This information is useful for all users, but  
is especially useful for users who cannot see the table, e.g. users of  
screen readers."

Is the PFWG suggesting that explaining the structure of complex tables  
to all users isn't even *preferable*?

Further quotes are from the proposed text--not from Maciej:
> Summary is one way to provide explanatory information about tables  
> that consist of more than just a grid of cells with headers in the  
> first row and headers in the first column.
>
Does this intend to say that using @summary is categorically  
unnecessary when headers appear in the first column and/or first row?  
If so, it would be good to make this clear.
> Such explanatory information should introduce the purpose of the  
> table,
>
Shouldn't the purpose be stated to all readers?
> outline its basic cell structure,
>
Shouldn't this be generated by the AT from the table model?
> The information provided by the summary is needed by users who  
> cannot see the table, but would usually be redundant for those who  
> can.
>
This sentence sticks out as non-spec-like. It doesn't state a  
requirement, so it looks odd in the middle of a paragraph that states  
requirements.
> This must be done in a way that is associated with the table via  
> markup, such that user agents and assistive technology can  
> programmatically determine the relationship.
>
This sentence could make sense in WCAG-like contexts where things are  
defined in terms of what available software happens to support. It  
doesn't make sense in a spec that defines what software must support.  
(Furthermore, "programmatically determine" is a special term from  
other specs but isn't defined as part of the special vocabulary of the  
HTML5 spec.)

The proposed text seems to imply (in the edits done on examples) that  
having the explanation in a paragraph preceding the table isn't  
sufficient without an explicit aria-describedby link (misspelled in  
the proposed text as aria-described-by). Why is that not sufficient?
> When using summary in combination with another technique, authors  
> must not use the duplicate text, but instead use summary for the  
> parts of the description that are only useful to users who cannot  
> see the table.
>
What about duplicating information that AT should be able to voice  
based on the table model?
> <table summary="The table is divided into six columns: Map number,  
> Date, Area or stream with flooding, Reported deaths, Approximate  
> costs (uninflated), and Comments. The rows are grouped by flood  
> types into six subcategories: Regional flood, Flash flood, Ice-jam  
> flood, Storm-surge flood, Dam-failure flood and Mudflow flood." >
>
In this case, the first sentence clearly duplicates information that  
are trivially programmatically determinable by the AT from the table  
model (given proper <th> markup). As for the second sentence, I think  
it would be worth investigating if the salient content of the second  
sentence is also realistically programmatically determinable from the  
table model. On the face of it, discovering the content of the second  
sentence from the table model doesn't seem like an overly hard  
software problem.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 15 September 2009 07:54:21 UTC