WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: SPAM-LOW: Re: Table SUMMARY Tag

for

From: Dawn Budge
Date: Mar 4, 2011 4:03AM

Its rare that the content in the summary tag provides any extra useful
information beyond what a heading or caption provides, and while it is
considered good practice to include them they usually just end up repeating
information.
It doesn't hurt to add them, but don't expect too much extra benefit out of
them unless you are lacking headers or captions (in which case you have a
usability problem :-) )

To get back to the original question, my own experience of trying to use a
table with a screenreader has found that use of scope attributes is the
most useful, as it provides context related to the content you've just
heard. It can be quite easy to lose your mental map of what column you are
in.

----------------------------------------
From: "Joshue O Connor" < <EMAIL REMOVED> >
Sent: 04 March 2011 09:53
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Subject: SPAM-LOW: Re: [WebAIM] Table SUMMARY Tag

On 03/03/2011 20:44, Jukka K. Korpela wrote:
> Joshue O Connor wrote:
>
>> On 02/03/2011 18:09, Jukka K. Korpela wrote:
[...]
> I'm not sure whether there is reliable information about support to
> different features across AT software and whether we can estimate the
impact
> (do we know the usage share, worldwide?).

No, its hard to get figures. There is such a dearth of this info, or its
fairer to say the figures for usage of A11y related elements/attributes
are so tiny in comparison to the rest (sic) it's easy to conclude that
they are useless. Which they are not. Some indication of use can be
gotten via Dmoz IIRC, or other web trawlers but that's not something I
know a lot about.

[...]

> And what
> about the usage? I don't think the summary attribute is used on more than

> perhaps one page out of a thousand.

Well this is it. And this logic (however correct) signaled its demise,
as such. _But_ where it is useful, and who it is useful for are
important here for a sense of context. My work in the HTML 5 WG to try
and retain it was based on seeing it used in user tests by blind and
visual impaired users. Or it may be more accurate to say *not* seeing it
used and recommending to authors that they add a @summary as it *would*
be useful.

However, often a data table will just need a element.
Personally, I think @summary is also useful for additional info that may
help the user figure out more info about the table as an 'overview' or
gestalt view but that's not strictly how the spec text defines its
usage. I guess, much of the web is built on the basis that elements are
used and abused in various ways that pushes them beyond their original
design.

[...]

> So in everyday terms, the drafts don't say that authors must not use the

> summary attribute, just that they should not. On the other hand, they do
not
> require or even recommend that browsers communicate the attribute value
to
> users; they use the mild word "may": "If a table element has a summary
> attribute, the user agent may report the contents of that attribute to
the
> user."

Yes.

>> For the second, while on paper this looks like a good idea, removing
>> @summary from HTML 5 because it couldn't be used by _everybody_
>> became a Shibboleth that lost all meaning. @summary content could be
>> exposed to sighted users if browsers were wired to do so.
>
> Authors could even now do such things if they wanted to. With a suitable

> piece of Javascript code, the summary attribute value could be disclosed
on
> request.

That's right.

> The main problem would be, I guess, the design of the user
> interface. How would you convey the idea "there is a description of the
> structure or the purpose of this table available"? Someone (maybe me)
might
> say "Oh, you could just use those words, in a statetement before the
table,
> with the word "description" turned to a pseudo-link (Javascript-powered).


Or you could use a fragment identifier method such as aria-describedby.

> And this might work up to a point. But many people who would need the
> description would not notice it. People don't read web pages that much.
If a
> table looks messy, they go elsewhere or just get confused.

Right, and this is why in particular for complex tables, the @summary is
useful.

> Anyway, my somewhat naive idea resembles what the HTML5 draft seems to be

> saying, more or less. And you can achieve without using a summary
attribute.
> Just write the explicit text, with a (pseudo) link, perhaps putting some

> easy-to-notice icon, symbolizing "help" or "info", adjacent to it. Screen

> reader users won't need the icon, so it could have alt="". Screen readers

> users would hear, before the table, something like "There is a (link)
> description of the structure or the purpose of the following table
> available". Simple, isn't it?

lol

[..]
> Therefore I think it is more realistic to try to make authors do some
effort
> in explaining tables, in prose before the table or in its caption or
maybe
> sometimes elsewhere. They need to learn some new thinking and design
> principles, and to apply them, but meaningful use of the summary
attribute
> would require that, too.

Yes.

Cheers

Josh

NCBI: Celebrating 80 Years

********************************************************************
National Council for the Blind of Ireland (NCBI) is a company
limited by guarantee (registered in Ireland No. 26293) .
Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
NCBI is also a registered Charity (chy4626).

NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI

********************************************************************