- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Sun, 4 Apr 2010 18:54:17 -0500
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, HTML WG <public-html@w3.org>, "Patrick H. Lauke" <redux@splintered.co.uk>
Hi Shelley, > My change proposals primarily responded from accessibility > perspective because that's how the HTML5 editor styled his rationales > for rejection--based purely on accessibility. Accessibility as rationale for existence of the interactive elements might be a red herring. Did the accessibility community help with the design of any of the interactive elements? Were they ever consulted? Have the elements been tested in AT? > Would it help if I edited the change proposal to put more of the > emphasis on custom UI libraries as compared to native elements? It might Shelley. It might even be bigger than that. Some items that I am wondering about with the interactive elements: What ever happened to the Zeldman type three-leggged stool approach to web standards? Separating structure, presentation, AND behavior...Where HTML is for structuring content. CSS is for presentation. JavaScript and the like are for behavior. This gets back to modularity and separate layers. What is the criteria for of interactive elements as a set? Have they been looked at holeisicaly and not piecemeal? Patrick made an astute comment on Bruce's blog: "personally, i don't like this because it's so strangely specific to one single effect. why not define another element for an accordion menu? and another one for a dropdown menu? or an image carousel? it seems arbitrary that the spec should have a baked-in effect like this little expando-thing...unless i'm missing the point completely..." http://www.brucelawson.co.uk/2010/html5-details-element-built-in-and-bolt-on-accessibility/#comment-666275 Best Regards, Laura -- Laura L. Carlson
Received on Sunday, 4 April 2010 23:54:50 UTC