Re: summarization information delivery options: attribute or element

Hi John,

On 26 February 2010 22:45, John Foliot <jfoliot@stanford.edu> wrote:
>> If a person with cognitive problems is also blind, then they would
>> benefit from the summary attribute. If they're sighted, a visible
>> summary attribute would add to the clutter on the page, as it's
>> explaining what is visually obvious and could be detrimental to
>> someone with cognitive disabilities.
>
> So we assist the blind/cognitive-impaired user, but ignore the
> sighted/cognitive-impaired user?

Having worked with people with cognitive disabilities for many years
at two different colleges, I don't believe we're ignoring sighted
people with cognitive disabilities. It's not easy to categorise what
works best for people with cognitive disabilities, as it's such a vast
area and what works for some won't work for others, depending on their
mode of learning. Generally speaking, simplicity is the best approach
for dealing with people with cognitive disabilities. Providing text
that explains a structure that is visually obvious is more likely to
confuse than help. But if a long description could help people with
cognitive disabilities better understand a data table, there's nothing
stopping people from providing it.

> The fact that <details> can be styled 'out of sight' (natively) addresses
> the visual clutter problem, and the <button> (which can also be styled BTW)
> addresses the availability/discoverability problem (and remember,
> discoverability *is* an issue if not addressed - you've long heard me on
> accesskeys...)

You want to provide information for people with cognitive disabilities
and hide it from them? The proposal also mentions only revealing the
button on focus or mouseover, which will introduce discoverability
problems for everyone.

> *Purpose* and structure; not just structure alone.  So if we take the
> existing text as currently written in HTML 4 as our guidance, Gez, sadly
> those examples fall short.

I disagree with "purpose" in the definition, and believe it's one of
the reasons the summary attribute has not been used correctly. The
important part of the definition is to provide the structure, as
that's what screen reader users are most likely to struggle to
understand when encountering a data table without the benefit of
seeing it. The HTML 4 definition of summary definitely needs to be
improved if it's to stay in HTML5.

> +1 to stronger semantic container(s).  To re-use one of Gez's examples (and
> expand upon it slightly), we could then do something like this:
>
> <ul>
>  <li>The rows contain portfolios and the columns contain dates</li>
>  <li>The date columns are ordered from most recent to oldest</li>
>  <li>The portfolios rows are organized alphabetically</li>
>  <li>The aggregate data is in the final two columns</li>
> </ul>

That would be a good example of providing a long description that
includes an overview of the structure, but there are a few issues with
it:

1: That kind of information can already be provided for everyone with
any version of HTML (nothing new required).

2: It's no longer concise; it would require a screen reader user to
use their reading keys to get the overview. At the moment, the summary
attribute is announced automatically when a data table is entered.
When done correctly, this can quickly orientate a user in the data
table without having to investigate the data table cell by cell to
build up a mental picture.

3: If this is intended for everyone, the last thing people will think
of putting in the long description is the structure of the data, as
it's visually obvious. Developers will be focused on providing a long
description for the data table, whereas the summary attribute is very
focused for a specific audience.

> I personally believe that this would be hugely beneficial to a multitude of
> users - both non-sighted and sighted. Cognitively we know that lists are
> easier to 'consume' than prose. (FWIW, I had at least one blind user tell me
> that a more semantically structured ability to convey table 'over-views'
> would be beneficial to him)

Different people have different requirements. Generally speaking, most
screen reader users I talk to tend to prefer concise descriptions, and
get highly irritated by well-intentioned people that provide too much
"accessibility" information. And to be clear, I'm not in any way
against people providing data table overviews; it's just that nothing
extra is required to do that. Provide it before the table, and those
that require the long description can read it, and those that don't
can skip it; it can be styled, internationalised, scripted, etc.

> Gez Lemon continues:
>>
>> Basically, anything that is visually obvious, but would save someone
>> time using a screen reader to determine the structure of the document,
>> remembering that AT can be quite helpful by summarising the number of
>> rows and columns automatically. Without a summary, screen reader users
>> need to investigate the table cell by cell to build up a mental
>> picture of how the data is organised; something that is visually
>> evident.
>
> Gez, what about users of screen magnifiers? If they cannot 'see' the entire
> table in one view, would they not also benefit with such a summarization? It
> could serve to aid them on where to place the magnifiers focus on a large
> data table.

Having observed screen magnifier users work with data tables, a couple
of things spring to mind:

1: Screen magnifiers include audio. The summary attribute is
programmatically exposed, and so this information can be made
available to screen magnifier users.

2: Even scrolling the table around (which screen magnifiers are very
used to doing), it's quicker for a screen magnifier users to ascertain
the structure of a data table than it is for a screen reader user that
has to interrogate the table one cell at a time to build a mental
picture.

3: If a long description is displayed visually, the screen magnifier
user still has to scroll around the description to get this
information (unless they're using audio, in which case they would have
got the summary attribute).

Providing a long visual description will not benefit screen magnifier
users any more than the summary attribute already does.

> Josh also wrote:

How come Josh gets "Josh also wrote", but I get "Gez Lemon continues"? *grin*

>> 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).
>
> "...as in practice they don't." Herein lies the biggest problem we have:
> authors aren't using @summary today. It is a single solution aimed at a
> single user-group, and if an author is either unaware of that user-group's
> needs, or believes that it does not count for their content, no amount of
> hand-wringing, pleading and advocacy is going to correct that; Josh knows
> that, I know that, and I believe others on this list know it as well.

As I've stated many times, I don't believe something not being used
correctly is a reason to drop it. There may be other good reasons to
drop something from a specification, but I don't think misuse is one
of them (alt is misused, but I'd hate to see if dropped for that
reason). The summary attribute has been poorly specified, and there's
very little guidance on how to use it. I believe that a clear
description of how it should be used with some good examples would be
a better idea than coming up with something new that doesn't serve the
same purpose. There is a specific audience for the summary, which is
why I think it should remain an attribute with a specific purpose.
Other user groups can already be accommodated with long descriptions.

Cheers,

Gez



-- 
_____________________________
Supplement your vitamins
http://juicystudio.com
http://twitter.com/gezlemon

Received on Saturday, 27 February 2010 01:40:55 UTC