- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Fri, 26 Feb 2010 19:50:08 +0100
- To: Shelley Powers <shelleypowers@burningbird.net>
- Cc: Gez Lemon <g.lemon@webprofession.com>, John Foliot <jfoliot@stanford.edu>, "Gregory J. Rosmaita" <oedipus@hicom.net>, public-html-a11y@w3.org
Shelley Powers, Thu, 25 Feb 2010 23:55:24 -0600: >>> I personally like Cynthia's proposal, as it addresses the *problem* at a >>> level that accepts that the issue does affect more than just screen reader >>> users. It also seeks to extend the solution, >> >> Exactly; this is information that would benefit everyone. It's >> possible to do that now, and I don't think a special element is >> required to do this. That's why I don't support the proposal. > > I think Gez really touched on the main issue […] […] > 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 I have never heard Gez include "purpose" when he describes what @summary is for. Superficially, think any reader would like to know the purpose of the table. But I suppose "purpose" in this regard is meant to help the reader to decide whether i is worth it spending time to read the table - as this can be quite time consuming with some media types. > structure for user agents rendering to non-visual media > such as speech and Braille." > > That's very concise, very specific, definitely a strong use case, and > with a simple, to the purpose solution: an attribute that's specific > to devices that either deliver the text as Braille, or as speech. Perhaps we should simply limit ourselves to say that it could sometimes be of benefit to be able to explain something to one user group, without disturbing another. That's what I'll try to do with my upcoming media/accessibility <caption> proposal. -- leif halvard silli
Received on Friday, 26 February 2010 18:50:49 UTC