[text] ISSUE 32 - table @summary

Hi y'all,

Regarding ISSUE 32 - table @summary, my full CP can be found here. [1]

However, in order to initiate some discussion etc I am including the
'juicy bits' inline. These mostly take the form of my own responses to
the “Working Group Decision on ISSUE-32 table-summary”.  [2]

Many thanks to Laura Carlson for her help and advice, and to Vlad
Alexander for his insight.

Hidden Meta Data

1) Summary is still "hidden metadata." Because authors and testers don't
encounter it in their daily activities, hidden metadata has the risk of
being incorrect or getting out of date;

Response: @summary is by design ‘hidden’ from sighted people, but as the
current spec has examples of where more verbose descriptors can be used
to explain table structure and other relationships this is less of an
issue as the author has the choice of deciding which authoring method
suits their content. Is ARIA still not hidden relationship data? Does
this mean that ARIA isn’t a universally designed or accessible solution.
No, of course not. Also, alternate text can also be considered hidden
but many authors are familiar with how to use it. It was observed that
"Browser vendors are free to provide the information of the summary
attribute in a way that benefits other users than those with AT" – this
is true.

 2) Risk that AT vendors will not improve the user experience; risk that
DOM and accessibility APIs, will not be adopted

Response: This doesn’t make sense. AT vendors are constantly trying to
improve the user experience, and take advantage of developing/expanding
APIs and the enhanced user functionality this can bring. Without this
kind of forward motion the web would be static.

Objections on Syntax

 1) “Summary as an attribute is insufficient because it does not support
structured content, such as  for bi-lingual tables, as well as
indicating to the user that the table uses structured markup and a guide
to that structured markup.”

Response: Yes, this is an interesting observation. @summary is limited
in that it cannot support structured content. Other elements that can
refer to a URI may be preferable but this has to be weighted against
existing UA support vs, ‘Blue Sky’ thinking. By all means I support
developing methods of being able to support semantically rich structures
but until this is the case – the retention of @summary as a full citizen
of HTML 5 is desirable for backwards compatibility – as well as
maintaining current authoring practices.

Another argument is that “[..] either would be "encouraging a redundant
feature". The assertion is that aria-describedby "solves the same use
cases, but does it in a better way." aria-describedby(indeed ARIA in
toto) is an excellent toolkit to help developers to create accessible
Web Applications. It has helped to bridge the ‘semantic divide’ while
HTML 5 was in a rapid state of flux. Currently aria-describedby and
@summary do not have to be mutually exclusive solutions. In fact,
maintaining @summary as a full member of HTML 5 (not as an obsolete
attribute) would enhance the developers toolkit giving greater scope for
authors to build applications that suit their target audience due to the
excellent support @summary has in screen reading technology.

There are no examples of accessible tables in the HTML 5 specification
that currently use ARIA and that can therefore be considered to be more
accessible as a result of the use of ARIA markup. It is not sufficient
to suggest that the use of ARIA elements/attributes are sufficient or
normative and then not provide examples of how to do this. There is also
a bug for this issue [Bug 13137]. [3]

As my CP points out. The valid use of @summary and also the ability to
use aria-describedby would mean that authors would have the choice of
when they wish to define a programmatic relationship between a table
element and an identifier or to indeed have a ‘hidden’ descriptor for
users of Assistive Technology.

Objections on the basis of Need

Response: Many of the comments from the survey quoted in the WG decision
are spurious at best. Lest we forget we are discussing an attribute
designed to make content perceivable to people without sight. To
intimate that the the net result was “summary="" has been amply
demonstrated (one might even say _proved_) to not help improve
accessibility in concrete ways.” Is very misleading. This is as loaded
as saying (note this following comments is not included in the WG
descision policy but is merely illustrative) ‘@summary is saving the
web”. Neither positions are tenable nor reasonable. What I attempt to do
here is provide a balanced view (in as much as this can be done when
assessing extremes). However, in adopting the maxim that the truth
occupies the median - comments like the previous one which was followed
with “ encouraging authors from spending time on something other than
improving accessibility *even after we are lucky enough to have found an
author who cares about accessibility*. This is a net harm to the
accessibility of the Web.” – are not enlightened and only obfuscate the
issue. The accessibility of the web is not based on luck but on design,
the mark up language should support this need for the creation of
accessible content and often this is done in small ways, and not
realised in broad strokes but in accruing details that enhance the
greater picture.

Also found the in the "RISKS" section of one of the Change Proposals:
  “There may be cases where there is some tabular data of a nature
  complicated enough to warrant a table explanation for screen reader
  users (and presumably for other users also), but for which the author
  will refuse to include visible explanatory text yet is amenable to
  including hidden explanatory text. It seems highly unlikely that such
  a case exists, and indeed no examples of such a case have ever been
  put forward, but if such a case exists then there could be an
  argument for leaving the summary="" attribute.”

A simple use case is where an author wishes to describe a tabular
structure to a blind user. They may not wish to describe the tabular
structure to the sighted user as the level of complexity may not be so
great as to warrant it, however, it may be so complex as to require a
hidden overview for those who cannot see. This is a reasonable use case
to me.

Referring to the "Make the summary attribute fully conforming and allow
visual UAs to optionally expose it" Change Proposal, the WG decision
states that “we do see a list of use cases. We also have a list of sites
that make use of a summary (in the form of the current attribute for
this purpose). These use cases are not specifically addressed by any
objection or counter proposal.”

Regarding a “study from a few years ago that indicates that the summary
attribute is often misused” there was “No claim was made as to whether
such a finding would apply to a separate summary element or the usage of
an aria-describedby attribute.” This is an interesting issue as only
time will tell. What we can state with some degree of confidence is
however, the advantage of having a verbose descriptor as a part of the
mark up language, and while it is difficult to predict future use the
current level of User Agent support and relative ease of authoring does
logically lean towards the ability to use these functions over being
preferable to not having them at all. All markup has the potential for
misuse, and if every infringement was to be be looked at in the cold
light of day – all markup may be banned in the light of its application
in the wild. How are we to measure the degree of severity of these
infringements? Shall we penalise certain user groups because someone,
somewhere used a brick as a weapon and not to build a house? Do we stop
building? No, semantic legislation is only a part of the picture – we do
not stop building stairs for fear that someone may fall down them.

 Objections to 'Drop the summary="" attribute'

In this section the verbiage “This presumes that the summary attribute
is the most appropriate way to express this information.” appears 5
times in response to the assertions that:
 1) Authors who are trying to optimize for accessibility will not get
validator warnings for doing so.
 2) (@summary) Provides users of screen readers an equal opportunity to
hear concise table summary information for a complex table that is
visually apparent to sighted users.
 3) Provides authors a mechanism for providing non-visual users summary
information in a non-visual way.
 4) summary is an essential tool for non-visual and limited visual
access to data contained in TABLE
 5) Obsolescing summary breaks the web for numerous sites doing the
right thing.

At least two of these assertions #2 and #3 are correct and the response
seems inappropriate as it doesn’t factor how @summary works, or indeed
that it even does at all. Working examples of @summary are very easy to
author (a text string is added to the attribute embedded within a table
element, the HTML page is loaded and with a screen reader when pressing
the key ‘T’ (using JAWS for example) the @summary text will be announced
on focus after a caption if there is one present. Very simple and
effective. Whether it is “most appropriate” is neither here nor there –
in fact this WG response is difficult to parse as a more binary “does it
work or does it not” approach to assessing the usefulness of the
@summary would to be more fitting. The answer being “Yes, it does”.

[1] http://www.w3.org/WAI/PF/HTML/wiki/Category:Table_Summary
[2] http://lists.w3.org/Archives/Public/public-html/2011Apr/0091.html
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13137

Received on Tuesday, 12 July 2011 14:37:25 UTC