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

hi leif,

>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.

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>

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.


>In my view, if we permit roles that contradict the element

it is not agreed that the button and link role are contradictory,
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.

regards
stevef
2009/11/9 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>

> Steven Faulkner On 09-11-09 12.12:
>
>
> Making ARIA non conformant does not encourage developers to do the right
>> thing, it encourages them not to use ARIA. It does not make sense to
>> penalise developers for use of ARIA when it is not the use of ARIA that
>> causes an issue.
>>
>
>
> I don't find this obvious. And when did validation errors become "to
> penalise"? What kind of view of validators' role is that?
>
> If the WG should take into account the possible secondary effect of making
> <a role="button"> non-conforming, then why not also consider secondary
> effects of a required @alt attribute on <img>? I am certain that some
> authors honestly think they do a good thing when they add alt="" to each
> img, and I am afraid we could seriously hurt the feelings of many of them if
> we started to tell them that this is not valid.
>
> [And yet, that is what I think we should do - I am of the opinion that it
> should not validate if the IMG has a @role which requires text!]
>
> Sam asked us to focus on implementations. 'Implementations' means, in my
> mind, for the most part user agents. There were one response about user
> agents in this thread, from Dan: [1]
>
> ]] ARIA roles override the implicit host language roles unless there is no
>  good mapping from the ARIA role to the desktop accessibility API.
>
> Firefox currently respects ARIA roles where supplied, and falls back to
>  host language mappings where necessary. [[
>
> And he pointed to the ARIA spec about it. [2]
>
> Thus I think we can answer to Sam [3] that tool X, Firefox, respects  Y, <a
> role="button">,  because it follows Z-1, the ARIA specification. But that in
> Z-2, HTML 5, this is non-conformant.
>
> To the question, what should change, the tool or the draft, the answer
> could be: perhaps none should change very much.
>
> Specifically: HTML 5 could say that there are different requirements for
> pages and for tools: Tools must permit that ARIA overrides default role
> values of the elements - as ARIA requires. Whereas authors are not permitted
> to use roles that contradict the element's roles.
>
> Validator.nu currently has 3 validation profiles. One of them is called
> "pedagogical". And pedagogical reasons - as well as to get help in answering
> the question "is this page ready now?" - are the primary reasons for authors
> to use the validator, not?
>
> 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.
>
> Currently, the draft says that if the anchor element says role="button",
> then the validator should not report that the @role is wrong, but should
> instead tell say the element is wrong. This gives good meaning, to me. And
> it is also compatible with your view that "it is not the use of ARIA that
> causes an issue".
>
> It should be possible to use the validator to find out whether I used @role
> in way that contradicts the semantics of the element. To be told that I did
> an error, is not to penalise. But I don't mind if the validator considers <a
> role="button"> only a minor error, instead of a mayor one.
>
> [1] http://lists.w3.org/Archives/Public/public-html/2009Oct/0802
> [2] http://www.w3.org/WAI/PF/aria-implementation/#mapping_role
> [3] http://www.w3.org/mid/4AF80A52.4010903@intertwingly.net
> --
> leif halvard silli
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html