- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 10 Nov 2009 12:46:00 -0600
- To: John Foliot <jfoliot@stanford.edu>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Charles McCathieNevile <chaals@opera.com>, Jonas Sicking <jonas@sicking.cc>, Lars Gunther <gunther@keryx.se>, Shelley Powers <shelley.just@gmail.com>, HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
On Tue, Nov 10, 2009 at 12:34 PM, John Foliot <jfoliot@stanford.edu> wrote: > We all can pretty much agree that making an <h1> a 'button' doesn't really > make a whole lot of semantic sense, but (as someone pointed out earlier) if > a content author decides, against better recommendations, to make a <h1> a > button that activates an accordion expansion, then we should be able to > convey that important information to AT in all its wrongness - not being > able to do so penalizes the AT user, not the content author. Since I brought up that example, that sort of markup actually isn't a bad idea in my opinion. Now it would probably be better done with <details>, but when that didn't exist a <div><h1/><p/></div> was a good approximation of the semantics. In some cases it still might be better semantically, for example if you were implementing a tab-based interface in js. *Is* it most helpful to convey to ATs that the heading is a button in that example? Are there better ways to do it? You really can't/shouldn't use an actual <button> in the example, because it's *not* semantically a button, it's a heading. It's only when you bring behavior into the mix that acquires a slightly different character. ~TJ
Received on Tuesday, 10 November 2009 18:46:49 UTC