RE: summarization information delivery options: attribute or element

Gez Lemon 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?

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...)

>
> I'm not putting these forward as brilliant examples of summary
> attribute usage, but examples that would clarify the structure for
> someone who doesn't have the benefit of viewing the table.
>
> Plain description of the structure:
> * "The rows contain portfolios and the columns contain dates. The
> aggregate data is in the final two columns."
>
> * "Totals are provided in the final row of the table"
>
> And so on.

<snip>

Shelley Powers wrote:
>
> The use case for the summary attribute is actually included within a
> description for the element in the HTML 4 spec:
>
>    "This attribute provides a summary of the table's purpose and
> structure for user agents rendering to non-visual media such as speech and 
> Braille."

*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.


Joshue O Connor wrote:
>
> 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 thought 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.

  <snip>

> 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.

+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>

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)


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.


Joshue O'Connor also wrote:
>
> 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.

I personally believe that this is fundamentally true.  The current change 
proposal specifically states that @summary will remain conforming, but that 
we are beginning to sunset it.

"The summary attribute would be allowed to become obsolete, but would remain 
conforming until a future version of HTML, to allow for backward 
compatibility with user agents which pre-date HTML 5."
http://www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_summary_attribute,_Feb_15,_2010

A *FUTURE* version of HTML.  We've been using HTML 4/XHTML for close to a 
decade now, and nothing suggests that HTML5 is going to have a shorter shelf 
life, so by my reasoning @summary isn't going anywhere any time soon.

As for advocacy and 'arguing' for @summary - here I believe that I've 
contributed my own fair share of input already (heck, I used @summary to 
hold up a heart-beat draft publish last summer - a move which I believe was 
justified at the time, a move that has also resulted in part with a better 
means of tracking and implementing changes, and also opened the possibility 
for Manu Sporny to split out RDFa, which has now led to the more 
modularization of the HTML5 spec we have today) but at the same time I've 
paused to consider if in fact we can do this better.  I believe we can.

Josh also wrote:

> 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.

If however we introduce something 'new', something that can be used richly 
(scripting, styling, i18n, etc.), I believe that mainstream content creators 
will look at this new element, and will begin to start using it - in part 
because it has Universal Design principles baked in.  Accessibility 
advocates will continue to teach the importance of describing the 'gestalt' 
of the table, the "purpose *and* structure", and maybe, just maybe, we'll 
have more robust (as in P.O.U.R. robust *) tables on the web.

All my opinion of course...

JF

(* WCAG 2 Principle 4: Robust - Content must be robust enough that it can be 
interpreted reliably by a wide variety of user agents, including assistive 
technologies.) JF points to "wide variety"...

Received on Friday, 26 February 2010 22:45:47 UTC