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

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

Received on Monday, 9 November 2009 16:43:58 UTC