- From: David Singer <singer@apple.com>
- Date: Thu, 7 Jan 2010 10:17:29 -0800
- To: Larry Masinter <masinter@adobe.com>
- Cc: John Foliot <jfoliot@stanford.edu>, Jonas Sicking <jonas@sicking.cc>, Denis Boudreau <dboudreau@webconforme.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
(warning, I trimmed the HTML mailing list from this discussion, as it's a re-statement of material that's been there before) And, these are not my opinions, I am merely trying to represent and summarize material that has been hashed through many times, in a desperate attempt to help people understand the issues and points of view. On Jan 7, 2010, at 7:56 , Larry Masinter wrote: > David, > > I disagree that: > "If a facility is so rarely used that it's unlikely > that, if looked for, it will be found" > > is, by itself, a reason for removing a HTML4 > feature. The same condition holds for any new > proposed feature. Frequency of use is not > a deciding factor, as long as there is _some_ > legitimate use. That is true for new features. But our goal is to provide actual effective accessibility, I think, not merely specifications in which it might happen. If a specification feature has existed for years, and has got little adoption, then I think we should ask whether we'd better try something else. We're not actually improving accessibility if very few tables that need it, have a summary. Again, I don't know that this is the case. Arguing "it just needs education" is not good enough, after years have passed. We are all striving for good accessibility in practice, I hope. > I think there needs to be clear evidence > and consensus that misuse is the norm; that > is, the default should be to retain HTML 4 > features. Yes, if the position is (and I don't have the evidence) "summary is rarely there when it's needed, and when it's there, it's unhelpful (and thus 'polluting')" then we need evidence to that effect. I think it has been posted, and if so, perhaps someone could provide a link or a re-statement? > Changes should be requested only when there > are serious omissions or errors in the published > specification. When review is required, a > change request may be denied if it renders > entities that were valid under the previous > definition invalid under the new definition. I think that we are trying very hard to make conforming HTML4 pages 'valid' even if they contain deprecated features. If we are not, we should be. My perception if that one of the cornerstones of HTML5 is a "don't break things needlessly" -- either the existing web, or break from the HTML legacy of specifications. David Singer Multimedia and Software Standards, Apple Inc.
Received on Thursday, 7 January 2010 18:18:02 UTC