- From: John Foliot <jfoliot@stanford.edu>
- Date: Fri, 5 Jun 2009 16:58:28 -0700 (PDT)
- To: "'Jonas Sicking'" <jonas@sicking.cc>, "'David Singer'" <singer@apple.com>
- Cc: <public-html@w3.org>
Jonas Sicking wrote > > Indeed. When something out of HTML4 hasn't accumulated use over the > past decade that HTML4 has been deployed, I think not looking for a > "why" and "do we need to change something" is to close your eyes to > reality. And indeed, that question has been asked. However, is it the failure of the attribute, or the apathy and lack of education inside the 'industry' that exists today (earlier in this thread others have had to explain the difference between a summary and caption)? If you cannot grok the difference between the two, is it a failure of the attributes/elements or a failure of developer comprehension? At what point must we stop holding the hands of professionals and demand that they understand what it is they are dealing with and working with? [re-quoting Laura Carlson] A caption is provided visually. Like it says in the Use Case section of the "Mechanism to Summarize a Table" Wiki page for the majority of sighted users a summary is not needed. For instance: <table summary="Rows contain destinations, traveling dates, and grand total. Columns contain expense category and total. The first column contains merged table cells."> <!-- Remainder of table --> A sighted person can see how the rows and columns are laid out and where the cells merge by a quick scan or glance. They typically wouldn't need an explanation. Providing it visually would be extra verbiage that most authors/designers would be reluctant to include visually on a page because of redundancy. A programmatically-determined summary mechanism serves a very specific and most critical use for blind and non-visual users. It provides an affordance equivalent to the visual user scanning a table for spatial structure, orientation, and relevance. A summary mechanism provides a reasonable accommodation. It enables a person with a visual disability to have an equal opportunity. [end] > > I do hope that the people advocating @summary has looked into these > questions and come to the conclusion that @summary can not be > improved. Those that advocate it's continued inclusion have not reached the same conclusion as you apparently have - we don't think @summary is broken, simply under-used and likely mis-understood. The specific functionality it seeks to address it delivers in spades: as the PF WG noted, "Summary serves a need, and serves it well. It is familiar to users. It is supported in browsers. It is properly utilized on many web sites which strive to be accessible." (and again: "The wider web is not an example of good practice.") However, education can be improved upon significantly, and in this we are all in agreement. For someone who earlier said you had no opinion one way or the other, you are coming across as being fairly dogmatic in your insistence that @summary is broken and needs to be discarded... > However they have unfortunately not provided any information > about which alternatives were looked into and why @summary was deemed > better. Herein lies the other half of the problem - nothing has been adequately proposed that replaces the specific functionality that @summary currently delivers. Suggesting to merge caption and summary into one 'global' thingy is like suggesting that bikinis and billy-boots can be grouped as "beach-wear"... (I mean, you can, but...) Thus asking accessibility advocates to discard something that exists today without replacing it with something of equal or better value is to many a move backwards. JF
Received on Friday, 5 June 2009 23:59:06 UTC