Re: [text] ISSUE 32 - table @summary [DRAFT]

Dear All,

Please note that this is a DRAFT for discussion, per Josh's reply at:
http://lists.w3.org/Archives/Public/public-html-a11y/2011Jul/0078.html

Discussion welcome!

And Josh, thanks for your work on this.

- Judy

At 03:36 PM 7/12/2011 +0100, Joshue O Connor wrote:
>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:44:53 UTC