+1, fwiw.  Cargo-culting is a real bother here, causing completely redundant markup to be sent over the wire for no reason, and increasing the workload for well-meaning authors who just misunderstood how the default roles work.

Better to make it a full-on validation error, so that people know for sure that what they're doing isn't necessary.

At the very least, it should be something requiring a validator to emit a warning.

Redundant ARIA annotations are requirement for accessibility in user agents that implement the role but not the native element/attribute.

Unless adding a given ARIA annotation does intrinsic harm to accessibility (in which case, please prove it), it should not be classed as a validation error.

I've no objection to lint tools giving advice about performance or promoting native markup over ARIA annotations where applicable, but such advice should not be pushed down to the level of conformance.

This isn't arbitrary XML, though.  It's one of the most widely-used document formats in the world.  If an AT doesn't understand HTML well enough to automatically know that an <option> in a <select> is a role=option, then it's useless for almost the entirety of the web, as very few sites use any ARIA at all, and those that do usually only use a smattering for actual accessibility "fix up", not accessibility redundancy.

I think the use-case of sites that want to cater to fundamentally broken and useless ATs by providing redundant information is outweighed by the economic cost of the storage/bandwidth eaten by the added markup and additional time spent adding that markup (if you're being thorough, the annotations are *very* pervasive even on an average webpage) by webdevs who are just trying to be good web citizens and don't realize that it's unnecessary in any half-useful AT.

There are many legitimate use cases for adding roles to elements that already have defaults. The spec is obviously not clear on this as you example illustrates. What is required is the spec provides clear advice to authors about when it is needed and when it is not.

(In reply to comment #3)
> This isn't arbitrary XML, though.  It's one of the most widely-used document
> formats in the world.  If an AT doesn't understand HTML well enough to
> automatically know that an <option> in a <select> is a role=option, then it's
> useless for almost the entirety of the web, as very few sites use any ARIA at
> all, and those that do usually only use a smattering for actual accessibility
> "fix up", not accessibility redundancy.
> 
> I think the use-case of sites that want to cater to fundamentally broken and
> useless ATs by providing redundant information is outweighed by the economic
> cost of the storage/bandwidth eaten by the added markup and additional time
> spent adding that markup (if you're being thorough, the annotations are *very*
> pervasive even on an average webpage) by webdevs who are just trying to be good
> web citizens and don't realize that it's unnecessary in any half-useful AT.

if browsers expose correct roles via accessibility APIs there should be no issue for AT. which is the case for all AT I know of.  Some newer HTML5 controls such as input type=number" are implemented incorrectly, in chrome (for example) the control is visually a spinbutton but exposed as textbox in such cases use of an aria role can improve the AT users understanding of a control.

(In reply to comment #5)
> if browsers expose correct roles via accessibility APIs there should be no
> issue for AT. which is the case for all AT I know of.  Some newer HTML5
> controls such as input type=number" are implemented incorrectly, in chrome (for
> example) the control is visually a spinbutton but exposed as textbox in such
> cases use of an aria role can improve the AT users understanding of a control.

That's a browser bug - Chrome is explicitly violating the spec at the moment.  It will presumably be fixed in due course.

Allowing, or even worse, encouraging authors to use redundant markup to fix a temporary browser bug in this area really risks the cargo-cult problem that Aryeh cites in the OP.  I'm okay with pages doing things for temporary compat fixes that are discouraged officially; we've all had to do that.  That doesn't mean we should encourage them, if we can strike early enough before the "temporary compat fix" becomes "accepted wisdom".

Note that the IRC convo cited as evidence is of an author using @role and other aria-* attributes on <select> and <option>, which *are* exposed correctly by accessibility APIs.

(In reply to comment #3)
> This isn't arbitrary XML, though.  It's one of the most widely-used document
> formats in the world.  If an AT doesn't understand HTML well enough to
> automatically know that an <option> in a <select> is a role=option, then it's
> useless for almost the entirety of the web, as very few sites use any ARIA at
> all, and those that do usually only use a smattering for actual accessibility
> "fix up", not accessibility redundancy.

It's not at all that simple since:

   1. Some HTML5 features are new.
   2. The interaction of ARIA annotations and native semantics is new. An author
might well be working around a failure of the UA to treat the default role as
if it were present for the purpose of such interactions with annotations on other
elements in the same document.
    3. HTML could be served mixed in with arbitrary XML. What happens (in practice I mean, rather than theory) to ARIA and HTML semantics respectively in that scenario?

If you can provide documentary proof for a given annotation and native
expression that the annotation has no effect in any UA other than to add an
attribute to the DOM - i.e. that it's genuinely rather than theoretically
redundant - then I don't have a strong objection to making the combination of the two
non-conforming. I feel proving this would require an unrealistic amount of testing
since the set of UAs making use of ARIA is already large (multiple versions,
multiple browsers/browser addons, multiple AT).

I would object in the strongest possible terms to some sort of untested,
blanket ban that would affect annotations applied to enable new HTML features
like "details" and "required" to be used without compromising accessibility in
today's UAs.

(In reply to comment #6)
> Allowing, or even worse, encouraging authors to use redundant markup to fix a
> temporary browser bug in this area really risks the cargo-cult problem that
> Aryeh cites in the OP.  I'm okay with pages doing things for temporary compat
> fixes that are discouraged officially; we've all had to do that.  That doesn't
> mean we should encourage them, if we can strike early enough before the
> "temporary compat fix" becomes "accepted wisdom".

Chrome is here today gone tomorrow, but with browsers like IE8 we're looking at like a decade-long product lifecycle. These temporary bugs are not necessarily that temporary.

Also bear in mind that people are starting to use HTML5 today (encouraged of course by WHATWG), so what the validator decrees today can have impact on people with disabilities today. We should err on the side of caution with respect to that impact.

Again, I'm happy for a linter to point out that certain features would only be required for backwards compatibility. I'm also happy for the official validator to incorporate linting features clearly designated as such.

Adding aria keyword and assigning to Steve Faulkner because this bug touches upon ARIA mapping in ISSUE 129: http://www.w3.org/html/wg/tracker/issues/129

The bug-triage sub-team doesn't think this bug needs TF priority as there are cases where redundancy is required to bolt accessibility onto browsers (not AT) that do not expose the correct default roles. Whether a warning should be given by a validator should be consistent with a proposal for ISSUE 129.

If there are browsers that do not expose the default roles correctly, but for which explicitly giving a role="" attribute fixes the problem, and which are not going to disappear any time soon, surely we should actually always _require_ the role attribute to be set on those elements with the correct role, in every document, no?

It's not that black-and-white, it's a compatibility tradeoff.  Sites with more AT users might be willing to clutter their markup more for additional compatibility.

(In reply to comment #11)
> It's not that black-and-white, it's a compatibility tradeoff.  Sites with more
> AT users might be willing to clutter their markup more for additional
> compatibility.

role information is not just for accessibility -- it can be used to leverage mashed-up content into a structured whole, rather than a collection of vanilla DIVs and SPANs -- all users can benefit from the information provided by @role -- consult http://www.w3.org/TR/role-attribute/

We're presently discussing adding roles to elements that they already have by default, and I was specifically addressing the concern mentioned in comment 9 and comment 10.  I don't see how anything involving vanilla divs and spans is relevant.  If you have a specific use-case for adding a role to an element that it already has, beyond the one raised in comment 9, that would be helpful.

Comment 11 suggests that it's acceptable for a site with only a few AT users to not be accessible to those AT users, which seems counter to what I normally hear from the accessibility community.

On balance it seems that the issue raised in comment 10 is largely academic and completely outweighed by the issue raised in comment 0, comment 1, and comment 3, and no other use cases have been raised (despite comment 4 saying there are "many legitimate use cases"). However, I could see an argument being made for the position in comment 10. I don't see any argument for the status quo.

Could someone from the a11ytf clarify the tf's position on comment 10?

(In reply to comment #14)
> Comment 11 suggests that it's acceptable for a site with only a few AT users to
> not be accessible to those AT users, which seems counter to what I normally
> hear from the accessibility community.
> 
> On balance it seems that the issue raised in comment 10 is largely academic and
> completely outweighed by the issue raised in comment 0, comment 1, and comment
> 3, and no other use cases have been raised (despite comment 4 saying there are
> "many legitimate use cases"). However, I could see an argument being made for
> the position in comment 10. I don't see any argument for the status quo.
> 
> Could someone from the a11ytf clarify the tf's position on comment 10?


> despite comment 4 saying there are "many legitimate use cases"

as implemented in any case where an author wishes make use of a state or property that is particular to a role
example: aria-pressed on the button role the role needs to be explicitly added.

<input type=button role='button" aria-pressed=true>

(In reply to comment #15)
> as implemented in any case where an author wishes make use of a state or
> property that is particular to a role
> example: aria-pressed on the button role the role needs to be explicitly added.
> 
> <input type=button role='button" aria-pressed=true>

What's the use case for overriding the pressed state on type=button? type=button has been supported natively for a long time.

(In reply to comment #12)
> -- consult http://www.w3.org/TR/role-attribute/

Neither HTML5 nor ARIA makes a normative reference to that document. It cannot be used as a rationale.

(In reply to comment #16)
> 
> (In reply to comment #12)
> > -- consult http://www.w3.org/TR/role-attribute/
> 
> Neither HTML5 nor ARIA makes a normative reference to that document. It cannot
> be used as a rationale.

nor is @role defined in the HTML5 specification -- it doesn't appear in the index of attributes and can only be found in the "annotations for assistive technology" section of the HTML5 spec -- this IS a bug, and the HTML5 spec should be changed to point to the Role Attribute (which is further along on the developmental chain than is HTML5) or should define a @role attribute in-tandem with that defined in the ARIA spec -- if the HTML5 spec doesn't include a native @role attribute, then devs need to know where to look to find out what exactly the @role attribute is and how it is used

(In reply to comment #16)
> (In reply to comment #15)
> > as implemented in any case where an author wishes make use of a state or
> > property that is particular to a role
> > example: aria-pressed on the button role the role needs to be explicitly added.
> > 
> > <input type=button role='button" aria-pressed=true>
> 
> What's the use case for overriding the pressed state on type=button?
> type=button has been supported natively for a long time.

Indicates the current "pressed" state of toggle buttons. 
http://www.w3.org/WAI/PF/aria/states_and_properties#aria-pressed
 
there are no native toggle buttons in HTML or am I missing something?

(In reply to comment #18)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > as implemented in any case where an author wishes make use of a state or
> > > property that is particular to a role
> > > example: aria-pressed on the button role the role needs to be explicitly added.
> > > 
> > > <input type=button role='button" aria-pressed=true>
> > 
> > What's the use case for overriding the pressed state on type=button?
> > type=button has been supported natively for a long time.
> 
> Indicates the current "pressed" state of toggle buttons. 
> http://www.w3.org/WAI/PF/aria/states_and_properties#aria-pressed

In that case, your example looks like an abuse of type=button to me, since type=button isn't a toggle button. How would you make type=button make look like one visually?

> there are no native toggle buttons in HTML or am I missing something?

The closest HTML has natively is checkboxes and radiobuttons.

(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #16)
> > > (In reply to comment #15)
> > > > as implemented in any case where an author wishes make use of a state or
> > > > property that is particular to a role
> > > > example: aria-pressed on the button role the role needs to be explicitly added.
> > > > 
> > > > <input type=button role='button" aria-pressed=true>
> > > 
> > > What's the use case for overriding the pressed state on type=button?
> > > type=button has been supported natively for a long time.
> > 
> > Indicates the current "pressed" state of toggle buttons. 
> > http://www.w3.org/WAI/PF/aria/states_and_properties#aria-pressed
> 
> In that case, your example looks like an abuse of type=button to me, since
> type=button isn't a toggle button. How would you make type=button make look
> like one visually?
> 
> > there are no native toggle buttons in HTML or am I missing something?
> 
> The closest HTML has natively is checkboxes and radiobuttons.

via CSS for example

(In reply to comment #14)
> Comment 11 suggests that it's acceptable for a site with only a few AT users to
> not be accessible to those AT users, which seems counter to what I normally
> hear from the accessibility community.

I was assuming that comment 9 was only talking about relatively old AT, which would get fixed.  In that case, even if some AT users can't use the content now, they would be able to if they switched to different AT or upgraded, which presumably they'd do within a few years.  Spec requirements to account for these would be immediately obsolescent.

This is not comparable to a site which is not accessible to AT users period.  It's more like sites dropping support for IE6.

If comment 9 was actually talking about a situation where some AT didn't assign the correct roles natively even in the latest version and wasn't going to change reasonably soon, that would be a serious issue with that AT's role implementation, and I'd question the reasonableness of trying to impose burdensome authoring requirements to work around a clearly deficient implementation.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted for HTML specification
Change Description: see diff given below
Rationale: see comment 14

I am leaving this open since it is assigned to steve who thus presumably has things to change in his doc for this bug (is it in the wrong component?).

Checked in as WHATWG revision r6040.
Check-in comment: Discourage cargo-cult authoring that would lead to poor accessibility.
http://html5.org/tools/web-apps-tracker?from=6039&to=6040

The check-in is open to at least two interpretations:

]]
      except that the presentation role may always be used.
     Authors must not set the ARIA role and aria-* attributes
     to values that match the default implicit ARIA semantics
     defined in the following two tables.
[[

What when the default implict role is 'presentation'? Currently there is just one such example in those tables:
   <img alt="" src=i>
Until I hear otherwise, I'll suppose that the first exception wins and that it thus is permitted to do
   <img alt="" src=i role=presentation >

Note, btw, that VoiceOver treats 
      <a href=link><img alt="" title="text"></a>
different from
      <a href=link><img role="presentation" alt="" title="text"></a>
In the former case, it uses the @title text as link text. In the latter case, it doesn't.

Revert request for r6040, and moving forward on bug 11557:

http://lists.w3.org/Archives/Public/public-html/2011May/0018.html

Checked in as WHATWG revision r6046.
Check-in comment: apply chair request
http://html5.org/tools/web-apps-tracker?from=6045&to=6046

While i agree that in general authors should not add roles to elements that have implied default roles,(although this does no harm, it is a waste of time) there are some cases that this is legitimate and therefore should not be forbidden:
in cases where default roles have not been implemented in browsers and no timeline for implementation has been provided and adding the role actually helps users as they are recognised by AT.
for example the article element.
In cases where a developer wants to use a non global aria attribute that applies to particular role, they are required to add the role (as this is what implementaions require)
example 
<button role=button aria-pressed=true | false>

If it is agreed, then a complete list of legitimate exceptions can be provided.

As the original bug filer, I completely agree that we should only prohibit roles that really serve no purpose.  So if <button role=button aria-pressed=true> will be processed differently from <button aria-pressed=true>, then the role=button should be allowed in that case.  Likewise, we should allow redundant roles on new elements like <details> that browsers won't know about yet, because they can be useful in practice.

But something like <a role=link href=foo> should raise a validator warning or error, because it means the author misunderstands what role="" does.  The validator error message can take the opportunity to explain to the author what role="" actually does, so that they can use it more correctly in the future.

So if everyone is okay with this, we just need a list of what roles should be allowed despite being redundant.  The current sentence that was left in the WHATWG spec ("Authors must not set the ARIA role and aria-* attributes to values that match the default implicit ARIA semantics defined in the following two tables") is too broad.

mass-move component to LC1

See comment #27 from Steve
> If it is agreed, then a complete list of legitimate exceptions can be provided.

And see comment #28 from Aryeh:
> So if everyone is okay with this, we just need a list of what roles should be
> allowed despite being redundant.  The current sentence that was left in the
> WHATWG spec ("Authors must not set the ARIA role and aria-* attributes to
> values that match the default implicit ARIA semantics defined in the following
> two tables") is too broad.

Given those comments, it seems this bug is waiting on somebody (Steve?) to provide a proposed list of roles.

(In reply to comment #30)
> See comment #27 from Steve
> > If it is agreed, then a complete list of legitimate exceptions can be provided.
> 
> And see comment #28 from Aryeh:
> > So if everyone is okay with this, we just need a list of what roles should be
> > allowed despite being redundant.  The current sentence that was left in the
> > WHATWG spec ("Authors must not set the ARIA role and aria-* attributes to
> > values that match the default implicit ARIA semantics defined in the following
> > two tables") is too broad.
> 
> Given those comments, it seems this bug is waiting on somebody (Steve?) to
> provide a proposed list of roles.


I am prepared to do the work to provide a list so conformance can be tightened, but would first like an acknowledgement from the editor that this would be acceptable to him, as I do not want to waste my time.

Hixie, please see Steve's comment #31:
> I am prepared to do the work to provide a list so conformance can be tightened,
> but would first like an acknowledgement from the editor that this would be
> acceptable to him, as I do not want to waste my time.

<button role=button aria-pressed=true> should not do anything different than <button aria-pressed=true> according to the ARIA spec as far as I can tell (that's what the "implicit semantics" stuff is all about!). If it does, ARIA should be fixed.

(In reply to comment #33)
> <button role=button aria-pressed=true> should not do anything different than
> <button aria-pressed=true> according to the ARIA spec as far as I can tell
> (that's what the "implicit semantics" stuff is all about!). If it does, ARIA
> should be fixed.

As stated in ARIA 1.0  

"authors MUST use a WAI-ARIA role on an element in order to use non-global states and properties on that element."


source: http://www.w3.org/WAI/PF/aria/host_languages#state_property_processing

If you have an issue with what is specified in ARIA and implemented in user agents file a bug.

I can live with the loose conformance rules in the W3C HTML5 spec in this regard and care little for what is stated in documents I can have no effect upon. But would prefer to see the conformance requirements in the W3C HTML5 spec be tightened up to discourage redundant role usage, while allowing role usage where required. you call Ian.

(In reply to comment #34)
> 
> "authors MUST use a WAI-ARIA role on an element in order to use non-global
> states and properties on that element."

This requirement is satisfied by the implicit roles. That's the point of the implicit roles.

(In reply to comment #35)
> (In reply to comment #34)
> > 
> > "authors MUST use a WAI-ARIA role on an element in order to use non-global
> > states and properties on that element."
> 
> This requirement is satisfied by the implicit roles. That's the point of the
> implicit roles.

Then the loose conformance requirements remain as you appear unable to accept the reality that implementations require explicit use of role="x" for non global aria attributes to work. If and when browsers change their implementations we can revisit the issue.

(In reply to comment #35)
> (In reply to comment #34)
> > 
> > "authors MUST use a WAI-ARIA role on an element in order to use non-global
> > states and properties on that element."
> 
> This requirement is satisfied by the implicit roles. That's the point of the
> implicit roles.

OK so does that mean you are unwilling to consider a list of allowable role/aria-attribute combinations?
If so can you make a resolution on the bug.
Note: this would mean no spec chnage unless you want to escalate it and provide a change proposal.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: I don't care enough. If anyone else wants to make the W3C spec make sense here, please be my guest in terms of escalating this. I'd be happy to work with you to provide a suitable patch.

(In reply to comment #38)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: I don't care enough. If anyone else wants to make the W3C spec make
> sense here, please be my guest in terms of escalating this. I'd be happy to
> work with you to provide a suitable patch.

I did some testing:

<input type="button" name="test" value="test" aria-pressed="true">

<input type="button" name="test" value="test" aria-pressed="true" role="button">

In IE 9 and Firefox 9 on windows the aria-pressed state is ONLY exposed in a11y API when the explicit role is present, so the W3C matches implementations.

(In reply to comment #33)
> <button role=button aria-pressed=true> should not do anything different than
> <button aria-pressed=true> according to the ARIA spec as far as I can tell
> (that's what the "implicit semantics" stuff is all about!). If it does, ARIA
> should be fixed.

Ian, you're misunderstanding the role of ARIA in the DOM. Redundant ARIA is really helpful for supporting existing ATs and it's quite handy for exposing data easily with JS libraries. Your optimization ideas and exclusions for ARIA are not fully implemented nor are they something that we can use, in practice, as authors targeting a broad range of DOM consumers.

If you want to define strict ARIA, do it in something like a CSS namespace.
button { role: button; }

In CSS, the allowed roles would be defined.
In DOM, it's free form for a reason.

(In reply to comment #40)
> (In reply to comment #33)
> > <button role=button aria-pressed=true> should not do anything different than
> > <button aria-pressed=true> according to the ARIA spec as far as I can tell
> > (that's what the "implicit semantics" stuff is all about!). If it does, ARIA
> > should be fixed.
> 
> Ian, you're misunderstanding the role of ARIA in the DOM. Redundant ARIA is
> really helpful for supporting existing ATs and it's quite handy for exposing
> data easily with JS libraries.

Perhaps you've misunderstood what Ian is saying in your quotation.

Steve is saying that in current implementations, role="button" in that markup is *not* redundant since you need it to make "aria-pressed" work. If you omit role="button", then the button is not reported as pressed in the accessibility tree. Ian is saying that it *should* work even if you omit role="button", since ARIA allows host languages to define implicit ARIA semantics on elements and attributes, and HTML5 defines button as having the implied semantic of role button, so "aria-pressed" should apply to it the same way.

So there's a question here about how ARIA annotations do and should behave beyond the question of whether we should allow redundant markup.

(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #33)
> > > <button role=button aria-pressed=true> should not do anything different than
> > > <button aria-pressed=true> according to the ARIA spec as far as I can tell
> > > (that's what the "implicit semantics" stuff is all about!). If it does, ARIA
> > > should be fixed.
> > 
> > Ian, you're misunderstanding the role of ARIA in the DOM. Redundant ARIA is
> > really helpful for supporting existing ATs and it's quite handy for exposing
> > data easily with JS libraries.
> 
> Perhaps you've misunderstood what Ian is saying in your quotation.
> 
> Steve is saying that in current implementations, role="button" in that markup
> is *not* redundant since you need it to make "aria-pressed" work. If you omit
> role="button", then the button is not reported as pressed in the accessibility
> tree. Ian is saying that it *should* work even if you omit role="button", since
> ARIA allows host languages to define implicit ARIA semantics on elements and
> attributes, and HTML5 defines button as having the implied semantic of role
> button, so "aria-pressed" should apply to it the same way.
> 
> So there's a question here about how ARIA annotations do and should behave
> beyond the question of whether we should allow redundant markup.

Hi ben, yes I am saying in the limited cases where an aria-* won't work without the addition of a redundant role, the conformance rules should not disallow the role. In all other cases the it should be disallowed.

FYI
since this bug has been marked as wontfix I am working directly with mike smith to work out which role/aria-* combinations need to be allowed to match implementations, it is my understanding he will use this data to implement the conformance rules in the W3C validator.