W3C home > Mailing lists > Public > wai-xtech@w3.org > November 2009

Re: ARIA roles added to the a element should be conforming in HTML5.

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Mon, 09 Nov 2009 19:32:23 +0100
Message-ID: <4AF86037.9060004@xn--mlform-iua.no>
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:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:16:07 GMT