Re: summarization information delivery options: attribute or element

Laura Carlson, Thu, 25 Feb 2010 15:20:13 -0600:
> Hi Gregory,
> 
>> 1. ascertain the position of working group members on summary as an
>>   attribute versus summary as an element;
> 
> It might help if  the group came to consensus on a table summary's
> current and future functional requirements.
> 
> 1. Purpose: Concise overview of the structure of the table? Long
> description? Or something else?

And what's the purpose of <caption>? HTML4 (four) speaks about @summary 
in opposition to <caption>. But in HTML5, our editor has nailed down 
that <caption> can be more than a caption in the pure sense - it can 
contain guidance about how to read the table. And hence the idea has 
been born that perhaps all guidance can be placed directly inside the 
caption?

The opposition against removing @summary is in favour of a feature that 
is focused directly at the AT users - especially the blind - citing 
unique needs for this group, and also citing experience that authors 
are unwilling to make such information visible to all.

I have been opposed to Ian's vision of <caption>. But let us accept it 
for a second. And let us *also* accept that non-sighted might need more 
than authors are willing to place inside the table caption. In fact, 
this seems to me to be the corner idea of @summary: Something that is 
targeted at AT users! 

This is meant as an answer to your question 1 about purpose, Laura. The 
purpose is simply to provide a description that is targeted at all (or 
a particular) AT users.

Since a11y task force has shown willingness to look at a element 
solution, I would like to point to a demo page I made last june: 

 http://målform.no/html5/caption+role


The idea here is simply that one could allow a second <caption> 
element. The idea is to signal that the caption is a "summary" via 
role="summary" (yes, a made up role value - not sure what the best role 
value would be). 

I do however not want to focus too much on the "summary role". Because 
I think it is better to focus on the basic idea that <caption> - in 
HTML5 - is permitted to contain as much or as little information as the 
author wants. And so one could apply the same thinking to the 
accessibility caption: Add what is needed. (Because it has turned out 
difficult to pinpoint the difference.)

> 2. Text string, restricted inline content, inline content, or block
>    level content?

A second AT <caption> goes well together with the idea that there 
should be an element directly as child of <table>

> 3. Invisible, visible, or some combination by default?

For a second AT <caption>, I think that it must be default to be 
hidden. That is the only thing that is 200% (two hundred percent) cross 
browser compatible. (As my demo page shows, making it visible is only 
100% possible.)

> 3. Visibility settings via user agent or markup?

Is this a question about whether the it should be linked to different 
media? At any rate, <caption> would be quite flexible that way.

Another advantage of the AT <caption> idea is that it can also be 
applied to <figure>: One could allow a second <figcaption>, for AT 
purposes.

I am willing to write a change proposal for this, if I perceive that 
there is any interest for the AT <caption> solution.
-- 
leif halvard silli

Received on Thursday, 25 February 2010 22:45:29 UTC