Re: summarization information delivery options: attribute or element

Hi Gez,

Many thanks for your concise reply to GJR about @summary as an element.
This has in truth been on my mind, so please find some of my comments
inline.

> With regards to internationalisation. Whenever we do
> internationalisation, the only difficulty with using attributes (and
> it's a fairly trivial problem to solve) is when the attribute value is
> in a different language to the element its on. I can't imagine a
> scenario where the language of the summary attribute would be
> different from that of the data table itself. Usually, the content of
> the data table is generated for a specific language depending on the
> language of the page or the element (in this case the data table).

Very good point, would this render the need for internationalisation
functionality redundant? Maybe so, however there could be other
functionality that a semantically richer element could do, such as being
able to hold with in structured content (for example more verbose
descriptions, with headings etc but we would need to look at use cases
more closely, I am also conscious of the ability of aria-describedby to
pretty much do the same thing, and that the next version of ARIA will
hopefully expand and improve the ability of aria-describedby to
reference off page content. )

> Anyway, it will be interesting to see whether people regard the
> summary attribute as a means of providing a concise overview of the
> structure, or whether they regard it as a long description of the
> table.

This captures the gist of what I often see developers do with @summary -
or what I think I would like them to do (as often in practice they
don't). I always though of the overview/longdescriptor ability as *very*
useful and while the spec is explicit about only one of these - it is
very easy for authors to currently do both - so I think the use cases
are easily interchangeable. As the attribute just takes a text string,
it would be very straight forward to expand the remit of @summary to be
both a long descriptor and providing an overview of the structure.
/However/, @summary as it stands is a little limited as it can only take
a text string. So my thinking is that making it an element, or using the
<details> element (let us consider them to be equivalent for a moment)
could certainly expand the capability (as GJR mentioned) of the element
to hold structured content and other semantics which could serve other
user groups beyond vision impaired users.

Now, the arguments for expanding the functions of @summary for other
user groups are a little tenuous (as it hasn't been proven) but that
does not mean that they do not exist. For some complex tables, in
particular the use of a rich text description, or same inpage referenced
aria-describedby content could be very useful as a comprehension tool
for older users, users with cognitive impairments and so on. So I would
support pimping the attribute into an element or using <details>.

Finally, as I know that we (sic) have all done a lot of advocacy work to
argue for the retention of @summary, to be clear, I think @summary is
great for the audience that it was designed to serve (blind users), and
I would hope for the sake of backwards compatibility within HTML5 that
its use would still be considered valid /but/ we do need a richer more
capable element to future proof this functionality and potentially
extend this usefulness to other user groups.

The summary attribute as a means of providing a concise overview of the
structure, /and/ as a long description of the table would be relatively
trivial to implement as it would require only a small spec change.
However, we may miss the opportunity to expand on this functionality by
retaining @summary as only an attribute, whereas the option of <details>
as a child of <caption>, or even a <summary> element (I am in truth a
little unsure of the tight binding to <caption> but it may - by simple -
proximity make its use more explicit and obvious)  seem to have more
promise and that is why I am supporting them.

Cheers

Josh

Received on Friday, 26 February 2010 10:33:42 UTC