- From: Judy Brewer <jbrewer@w3.org>
- Date: Tue, 12 Jul 2011 10:44:20 -0400
- To: Joshue O Connor <joshue.oconnor@cfit.ie>, HTML Accessibility Task Force <public-html-a11y@w3.org>
- Cc: Janina Sajka <janina@rednote.net>,John Foliot <jfoliot@stanford.edu>, lwatson@nomensa.com,"Katie @ GMAIL" <ryladog@gmail.com>, "Michael(tm) Smith" <mike@w3.org>
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