The bug-triage sub-team doesn't think this should be task force priority. Consistent implementation across browsers is imperative, so the vendors should agree on a way for implementation. Perhaps the spec needs to be more speficic. The bug is certainly in good hands with Steve.

I don't understand the problem here. ARIA overrides HTML here so that there's no problem, no?

(In reply to comment #2)
> I don't understand the problem here. ARIA overrides HTML here so that there's
> no problem, no?

ok, let's put it another way:

What is the use case for allowing presentation on all elements?

(In reply to comment #3)
> (In reply to comment #2)

> What is the use case for allowing presentation on all elements?

Some answers to that question can be found inside the request to 'Allow role="presentation" to override the default role of any element', which was filed as bug 10919 by Martin Kliehm, and which resulted in the current permission to use 'presentation' on any element that you now are questioning. 

If you disagree with that general permission to use 'presntation' on any element, then it seems that you EITHER need to re-open 10919 needs to be reopened. OR ELSE, file bugs about each element for which it should not be permitted.

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> 
> > What is the use case for allowing presentation on all elements?
> 
> Some answers to that question can be found inside the request to 'Allow
> role="presentation" to override the default role of any element', which was
> filed as bug 10919 by Martin Kliehm, and which resulted in the current
> permission to use 'presentation' on any element that you now are questioning. 
> 
> If you disagree with that general permission to use 'presntation' on any
> element, then it seems that you EITHER need to re-open 10919 needs to be
> reopened. OR ELSE, file bugs about each element for which it should not be
> permitted.

hi leif, i am aware of bug 10919 it does not provide use cases for using presentation on form controls or links. so it doesn't provide any use cases to cover these, the rationale of the editor was;

"It seems that the ARIA spec is very confused on this
issue, but in the interests of expediency, and under the assumption that the
ARIA spec will be corrected to match implementations, I've changed the spec to
allow role=presentation everywhere."

I don't believe 'expediency' to be an acceptable rationale.

as to your statement:

"then it seems that you EITHER need to re-open 10919 needs to be
reopened. OR ELSE, file bugs about each element for which it should not be permitted."

whose rules are these?

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > 
> > > What is the use case for allowing presentation on all elements?
> > 
> > Some answers to that question can be found inside the request to 'Allow
> > role="presentation" to override the default role of any element', which was
> > filed as bug 10919 by Martin Kliehm,

> hi leif, i am aware of bug 10919 it does not provide use cases for using
> presentation on form controls or links.

There you mention two very specific elements. May be  it can be justified that those elements are excempted from the general permission to use role=presention. In contrast, this bug report covers "all" elements. 

Btw, role=presentation is not the only thing that could make form controls and links inaccessible to AT.  Placing form controls or links inside elements with role="img" would do the same. (Example: <div role=img ><a href="*">link</a></div>) 

> so it doesn't provide any use cases to
> cover these, the rationale of the editor was;
> 
> "It seems that the ARIA spec is very confused on this
> issue, but in the interests of expediency, and under the assumption that the
> ARIA spec will be corrected to match implementations, I've changed the spec to
> allow role=presentation everywhere."
> 
> I don't believe 'expediency' to be an acceptable rationale.

He also provided a link to a longer resonnement as part of the rationale. And I don't know if it is fruitful to think that his decision did not have anything to do with Martin's bugs and comments.

(THough, it seems relevant to point out that the examples they discussed were not links or form controls with the presentation role.)
 
> as to your statement:
> 
> "then it seems that you EITHER need to re-open 10919 needs to be
> reopened. OR ELSE, file bugs about each element for which it should not be
> permitted."
> 
> whose rules are these?

The important thing is to do what solves the problem - not "whose rules" it is.

(In reply to comment #6)
> (In reply to comment #5)

> > hi leif, i am aware of bug 10919 it does not provide use cases for using
> > presentation on form controls or links.
> 
> There you mention two very specific elements. May be  it can be justified that
> those elements are excempted from the general permission to use
> role=presention. In contrast, this bug report covers "all" elements. 
> 
> Btw, role=presentation is not the only thing that could make form controls and
> links inaccessible to AT.  Placing form controls or links inside elements with
> role="img" would do the same. (Example: <div role=img ><a
> href="*">link</a></div>) 

And, related, what about aria-labelledby or aria-describedby, if they are used to point to an anchor element or a form control element?  Would that be any useful? Such an anchor element would appear completely dead - it would only be a presented to the AT user as pure text - click-ability would be gone. When is that useful?

It seems that the real problem here is those specific, interarictive elements that you mention - in relation to *any* ARIA feature that in some way or another removes their interactivity.

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > (In reply to comment #2)
> > > 
> > > > What is the use case for allowing presentation on all elements?
> > > 
> > > Some answers to that question can be found inside the request to 'Allow
> > > role="presentation" to override the default role of any element', which was
> > > filed as bug 10919 by Martin Kliehm,
> 
> > hi leif, i am aware of bug 10919 it does not provide use cases for using
> > presentation on form controls or links.
> 
> There you mention two very specific elements. May be  it can be justified that
> those elements are excempted from the general permission to use
> role=presention. In contrast, this bug report covers "all" elements. 
> 
> Btw, role=presentation is not the only thing that could make form controls and
> links inaccessible to AT.  Placing form controls or links inside elements with
> role="img" would do the same. (Example: <div role=img ><a
> href="*">link</a></div>) 
> 
> > so it doesn't provide any use cases to
> > cover these, the rationale of the editor was;
> > 
> > "It seems that the ARIA spec is very confused on this
> > issue, but in the interests of expediency, and under the assumption that the
> > ARIA spec will be corrected to match implementations, I've changed the spec to
> > allow role=presentation everywhere."
> > 
> > I don't believe 'expediency' to be an acceptable rationale.
> 
> He also provided a link to a longer resonnement as part of the rationale. And I
> don't know if it is fruitful to think that his decision did not have anything
> to do with Martin's bugs and comments.
> 
> (THough, it seems relevant to point out that the examples they discussed were
> not links or form controls with the presentation role.)
> 
> > as to your statement:
> > 
> > "then it seems that you EITHER need to re-open 10919 needs to be
> > reopened. OR ELSE, file bugs about each element for which it should not be
> > permitted."
> > 
> > whose rules are these?
> 
> The important thing is to do what solves the problem - not "whose rules" it is.

i don't think the course of action you outline solves the problem for me, but if it does for you  then go right ahead.

I will wait to hear back from ian on his use case for allowing presentation on all elements.

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> 
> > > hi leif, i am aware of bug 10919 it does not provide use cases for using
> > > presentation on form controls or links.
> > 
> > There you mention two very specific elements. May be  it can be justified that
> > those elements are excempted from the general permission to use
> > role=presention. In contrast, this bug report covers "all" elements. 
> > 
> > Btw, role=presentation is not the only thing that could make form controls and
> > links inaccessible to AT.  Placing form controls or links inside elements with
> > role="img" would do the same. (Example: <div role=img ><a
> > href="*">link</a></div>) 
> 
> And, related, what about aria-labelledby or aria-describedby, if they are used
> to point to an anchor element or a form control element?  Would that be any
> useful? Such an anchor element would appear completely dead - it would only be
> a presented to the AT user as pure text - click-ability would be gone. When is
> that useful?
> 
> It seems that the real problem here is those specific, interarictive elements
> that you mention - in relation to *any* ARIA feature that in some way or
> another removes their interactivity.

good point, i suggest you put in a bug report.

(In reply to comment #0)
> s per the ARIA spec [1] and implementaion guide [2]
> 
> "If an element with a role of presentation is focusable, user agents
> MUST ignore the normal effect of the role and expose the element with
> implicit native semantics, in order to ensure that the element is both
> understandable and operable."
> 
> [1]http://www.w3.org/WAI/PF/aria/roles#presentation
> [2] http://www.w3.org/TR/wai-aria-implementation/#mapping_role
> 
> I agree with the above, but currently the HTML5 spec allows
> role="presentation" on any element (including focusable elements) 

You seem to to think that *ARIA 1.0* says that role=presentation should not be added to focusable elements.  The way I read ARIA 1.0, it only says that role=presentation on focusable element simply leads to a different result on focusable elements.

I think the ARIA spec text that you quoted above, is mostly related to inheritance. E.g. if we do this:
  <div role=presentation><a href=link>text</a></div>
Then the <a> would also get a presentation role - inherited from the parent, but without loosing its "implicit native semantics".

If HTML5 were to say anything about my example above, then what should it say? That authors in this case must apply a non-presentational role to the anchor element - for instance role=link ?

Per Martin Kliehm "although the bug-triage sub-team didn't decide on these bugs yet, John mentioned in yesterdays teleconference [1] that there are several important multimedia related bugs where he'd like to add the a11ytf keyword. There was approval". 

[1] http://www.w3.org/2011/04/28-html-a11y-minutes.html

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: Did Not Understand Request
Change Description: no spec change
Rationale: I still don't understand the problem here. If the problem is just that bug 10919 was resolved in a way that you disagree with, please reopen or escalate that bug as per comment 4. If the problem is that ARIA doesn't define what happens when the user focuses a focusable element with role=presentation, then that's a bug in ARIA, regardless of whether that combination is allowed or not. If the bug is that browsers don't do what ARIA says, then file the bugs with the browsers. Note that allowing a role on an element has no relationship with whether browsers will support that role on an element, so the "that is how it is implemented" part of comment 0 makes no sense.

mass-move component to LC1

*** This bug has been marked as a duplicate of bug 10919 ***