- From: John Foliot <jfoliot@stanford.edu>
- Date: Tue, 22 Mar 2011 12:43:16 -0700 (PDT)
- To: "'Ian Hickson'" <ian@hixie.ch>, "'Laura Carlson'" <laura.lee.carlson@gmail.com>
- Cc: "'Steve Faulkner'" <faulkner.steve@gmail.com>, "'Jonas Sicking'" <jonas@sicking.cc>, "'Henri Sivonen'" <hsivonen@iki.fi>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'HTMLWG WG'" <public-html@w3.org>
Ian Hickson wrote: > > Well, it reintroduces longdesc, a feature which is almost universally > misused and will therefore do basically nothing but cause users pain, > something which has been repeatedly explained. s/explained/asserted You have continually stated this position with no proof of "harm" to back up this statement. What kind of pain will this cause exactly? And to whom? It seems there are 3 conditions that could exist: 1) author fails to provide @longdesc at all Outcome: users who could benefit from longer textual descriptions, primarily non-sighted users, are negatively impacted by the author's failure to provide longer text. (This is an educational problem with authors) 2) author misuses @longdesc by writing [longdesc="This is my longer description here..."] Outcome: author effort is discarded by user-agents that DO support @longdesc as they have incorrectly authored the attribute's content. Net effect on the end-user is the equivalent to if/when author fails to provide @longdesc values at all. However, pages authored as such continue to render in browser screens (no draconian error) for sighted users. (This is an educational problem with authors; this could be partially mitigated by evaluation tools/validators examining the value string for @longdesc to ensure it is either a URI or IDREF) 3) author correctly uses @longdesc (based upon better spec text, examples, etc. in the newer HTML5 specification) Outcome: users who require longer textual descriptions are accommodated with their needs, while authors constrained by design restrictions etc. have a mechanism designed to still provide this accommodation. There are many who feel that reinstating @longdesc is a good thing, and the work has gone into providing the use-cases which show where and why @longdesc is the appropriate mechanism to solve the problem. Recognizing that @longdesc was most likely under-specified in HTML 4, a number of us have sought to correct that problem as well, resulting in the proposed text submitted. If you continue to believe that the use-cases presented can be solved using other methods, then please do feel free to work on an alternative Change Proposal to the one submitted against Issue 30. It is anticipated that the Chairs will be issuing a CfCP within the next few weeks. Meanwhile, I personally have worked with engineers and developers who also concur with our premise that @longdesc serves a useful need, and have sought ways and proof-of-concept examples that browser developers could adopt to improve the user-experience for a wider range of users than simply those who are visually impaired - those examples are referenced in the draft text. Meanwhile as an assumed professional, impartial technical editor, your editorial advice was sought against proposed text. It is too bad that you continue to mix your personal bias into a role that should be neutral in nature: this is not the Ian Hickson specification, it is the W3C specification, and as such it represents both collaboration and consensus of a larger group. I believe it would best serve the entire group if you could recognize and apply that to this work effort. JF
Received on Tuesday, 22 March 2011 19:44:55 UTC