- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 09 Nov 2009 19:32:23 +0100
- To: Steven Faulkner <faulkner.steve@gmail.com>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, John Foliot <jfoliot@stanford.edu>, Jonas Sicking <jonas@sicking.cc>, Richard Schwerdtfeger <schwer@us.ibm.com>, HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
[Did you quote anything in your letter? I can't separate my text from your reply. I added ">" manually. And your use of colons made me look in 15 minutes for wherever in HTML 5 you were "quoting".] Steven Faulkner On 09-11-09 18.14: >> In my view, if we permit roles that contradict the element, then we also >> take away the possibility for guiding authors to select the best/right >> element. Not only >that, then we also possibly create a gap between what >> those with advanced ARIA enabled user agents experience versus those with >> simpler tools. > the addition of scripting that modifies the a elements semantics is > permitted in HTML5 as far as i understand: > in the following (crude - note: most of the attributes would not be added > inline, have done so for example purposes) example the a element is > repurposed to act as a button to open a pseudo dialog. the link behaviour > (naviagte to dialog.html) is included as a fallback if scripting is not > supported: > > <a href="dialog.html" > onclick="document.getElementById('poot').style.display='block'; return > false;">show dialog</a> > <div style="display:none" id="poot" tabindex="0">dialog content</div> > > the use of the a element in this case is recommended over the use of a > button as fallback is not supported with button. Fallback for lack of javascript, you mean. However, forms should not rely on javascript. > if role="button" is added to better characterise for AT users what the UI > element is in the context of the scripting it becomes non-conforming: > > <a href="dialog.html" > onclick="document.getElementById('poot').style.display='block'; return > false;" role="button">show dialog</a> > <div style="display:none" id="poot" tabindex="0">dialog content</div> If the user agent doesn't support javascript, then this suddenly isn't any button anymore, but a link. I permit myself to quote from Jeremy Keith: [1] ]] First, build an old-fashioned website that uses hyperlinks and forms to pass information to the server. The server returns whole new pages with each request. Now, use JavaScript to intercept those links and form submissions and pass the information via XMLHttpRequest instead. You can then select which parts of the page need to be updated instead of updating the whole page. I’ve even got a nice shiny buzzword for this technique: Hijax. [[ So, if we follow that prescription in reverse, then we end up with that the above is a link. Should the page, even then, tell that it is a button??? > this is the same for other identified uses of the a element (menutiem, tab) > the use of a provides a robust fallback for browsers that do not support or > have scripting enabled. The question I have is whether it is correct to think "hijax" when applying role ... You spoke about penalise. There must also be a carrot - that you don't /have/ to use role if you do it right. I wonder how that one looks like? Or perhaps that is wrong? There is no carrot? (See below.) >> In my view, if we permit roles that contradict the element > > it is not agreed that the button and link role are contradictory, There are degrees of contradiction, of course. It is about interactivity. > furthermore we permit the additon of event handlers and scripting that > seemingly 'contradict' the element, if this is such an issue we should look > seriously at restricting the use of event handlers on elements. In HTML 4 and 5, then a button is something related to a form. According to the XHTML vocabulary profile then: [2] "An input that allows for user-triggered actions when clicked or pressed." This seems to correspond to how it is in HTML 4 and in HTML 5. Thus it seems to me that the meaning of role="button" must change if you want it to be used like you suggest. Because I associate "input" with <input> and <form> etc. Or? I see your point better now, thogh. We have, for a while, been thinking in this group that elements should map to ARIA roles. But the way you describe it here, then I wonder if it is better to *not* link it to the elements. ARIA role more appears to be semantic paint that you can add - ad lib - after your web app is ready. And, it seems better to add it via JavaScript than directly in the code, too, if my comments regarding fallback above are correct. [1] http://domscripting.com/blog/display/41 [2] http://www.w3.org/1999/xhtml/vocab/#button -- leif halvard silli
Received on Monday, 9 November 2009 18:33:01 UTC