You say that some screen readers don't recognize a role=tab if it's not a direct child of a role=tablist.  You then say that role=presentation "deletes" an element from the accessibility mapping, allowing the descendent role=tab to act like a child of the role=tablist, thus being recognized.

Is this latter statement what actually happens in the screenreaders previously mentioned?  Or is it a statement of what *should* happen in a good screenreader?

(In reply to comment #1)
> You say that some screen readers don't recognize a role=tab if it's not a
> direct child of a role=tablist.  You then say that role=presentation "deletes"
> an element from the accessibility mapping, allowing the descendent role=tab to
> act like a child of the role=tablist, thus being recognized.
> 
> Is this latter statement what actually happens in the screenreaders previously
> mentioned?  Or is it a statement of what *should* happen in a good
> screenreader?

When an author doesn't state explicitly that an element should be removed from the accessibility API "DOM" by using role="presentation", the element and it's default role should remain intact.  I'll ask the NVDA core developer how it is handled there, but the accessibility API mapping in general is done by the browser and only accessed, not modified by a screenreader.

So there are screenreaders that recognize tab as a descendent of tablist even when other elements are between them, and others where tab is only recognized as an immediate child of tablist.  Authors can force the latter by removing the elements in between by using role="presentation", which is in accordance with the ARIA definition when the elements are used for presentational purposes like applying shadows or background images.

By the way, the W3C validator mandates that tabs need to be immediate child nodes of tablist, too.  I believe this is an error as it doesn't take the power of role="presentation" into account.

(In reply to comment #1)
> You say that some screen readers don't recognize a role=tab if it's not a
> direct child of a role=tablist.  You then say that role=presentation "deletes"
> an element from the accessibility mapping, allowing the descendent role=tab to
> act like a child of the role=tablist, thus being recognized.
> 
> Is this latter statement what actually happens in the screenreaders previously
> mentioned?  Or is it a statement of what *should* happen in a good
> screenreader?

This actually *does* happen in the combination of Safari + VoiceOver. Elements with role="presentation" are omitted from the accessibility tree and their children are presented as if direct children of the next element up.

(In reply to comment #3)
> This actually *does* happen in the combination of Safari + VoiceOver. Elements
> with role="presentation" are omitted from the accessibility tree and their
> children are presented as if direct children of the next element up.

Right, that's when the author removes intermittent elements with role="presentation". That's why role="presentation" needs to be allowed on every element.

Where does ARIA say this should happen? Isn't aria-owns the official way to do this?

(In reply to comment #5)
> Where does ARIA say this should happen?

Assuming by "this", you mean "Elements with role='presentation' are omitted from the accessibility tree and their children are presented as if direct children of the next element up":

"For any element with a role of presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of presentation. Thus, the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessible tree."

http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#presentation

> Isn't aria-owns the official way to do this?

"aria-owns" specifies parent-child relationships not reflected by the DOM. It does not remove any elements from the accessibility tree. 

http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns

Question for the OP, the bug description asks to allow role="presentation" on any element, but the description gives a use case for applying it to container elements. Is there a use case for allowing it on any elements that cannot contain other elements and where role="presentation" is currently non-conforming?

(In reply to comment #6)
> Question for the OP, the bug description asks to allow role="presentation" on
> any element, but the description gives a use case for applying it to container
> elements. Is there a use case for allowing it on any elements that cannot
> contain other elements and where role="presentation" is currently
> non-conforming?

Good point. Having looked through the design patterns in the ARIA Best Practices document I'd say that as soon as structure is involved where nodes could be removed we are dealing with container elements.

The second group of use cases concerns purely presentational content like certain images (img), where role="presentation" is conforming. However, I would expand that to embedded content elements in general: it is reasonable to expect that presentational content is not limited to images, the same could be done with SVG, Flash (embed/object), video, and canvas.

(In reply to comment #7)
> (In reply to comment #6)
> However, I would
> expand that to embedded content elements in general: it is reasonable to expect
> that presentational content is not limited to images, the same could be done
> with SVG, Flash (embed/object), video, and canvas.

That seems reasonable to me.

I believe the application of ARIA to inline SVG would be governed by the SVG specifications.

As far as I can tell, it's already conforming to apply role="presentation" to "img", "embed", "object", "video", and "canvas". Please cite the bit of the spec that says it isn't, if I'm wrong.

If I'm right, would it be safe to emend this bug proposal to "Allow role='presentation' to override the default role of any element that can be a descendant of the 'body' element and could contain other elements"? Or are there other use-cases such a change to the spec would not cover?

Here's an edge case: do we need to allow role="presentation" on the "select" element?

(In reply to comment #5)
> Where does ARIA say this should happen? Isn't aria-owns the official way to do
> this?

Given how aria-owns works, using it to skip a level of the DOM hierarchy would likely lead to content being presented twice (once as a literal descendant, and once as an additional descendant via aria-owns).

See bug 10450 comment 12.

See bug 10450 comment 17.

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
Change Description: see diff given below
Rationale: 

See bug 10450 comment 19. 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.

Checked in as WHATWG revision r5633.
Check-in comment: Allow role=presentation everywhere
http://html5.org/tools/web-apps-tracker?from=5632&to=5633

while there are legityimate use cases for allwoing role=presenation on some elements, there are not legitimate use cases for allowing role=presentation on allt elements. In fact no reasons have been put forward for allowing role=presentation on form controls and other interactive elemnents and allowing them on form controls is actively harmful. 

so unless use cases are provided I request that role=presentation be non conforming on the following elements:
http://dev.w3.org/html5/spec/the-input-element.html#the-input-element
http://dev.w3.org/html5/spec/the-button-element.html#the-button-element
http://dev.w3.org/html5/spec/the-button-element.html#the-select-element
http://dev.w3.org/html5/spec/the-button-element.html#the-datalist-element
http://dev.w3.org/html5/spec/the-button-element.html#the-option-element
http://dev.w3.org/html5/spec/the-button-element.html#the-textarea-element
http://dev.w3.org/html5/spec/the-button-element.html#the-keygen-element
http://dev.w3.org/html5/spec/the-button-element.html#the-progress-element
http://dev.w3.org/html5/spec/the-button-element.html#the-meter-element
http://dev.w3.org/html5/spec/interactive-elements.html#the-summary-element
http://dev.w3.org/html5/spec/interactive-elements.html#the-command-element
http://dev.w3.org/html5/spec/interactive-elements.html#the-menu-element
http://dev.w3.org/html5/spec/text-level-semantics.html#the-a-element

(In reply to comment #14)

> http://dev.w3.org/html5/spec/text-level-semantics.html#the-a-element

I suppose that you, eventually, also meant 

http://dev.w3.org/html5/spec/the-map-element#the-area-element

?

As for use cases, here are 3 usecase for a, area and summary.


<a>: For <a href=* role=presentation> then the usecase 'Describing a Newspaper Image' of the Instate Longdesc CP, lists one:

http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Use_Cases
http://www.d.umn.edu/~lcarlson/research/ld.html#uc-10

Example:

<a href=large-version.jpg 
      role=presentation >
     <img longdesc=description.html 
               src=small-version.jpg
               alt="Lorem ipsum">
</a>

Here the link is just presentational - it has little value for someone who is unsighted.

Another, possible use case: some times an element is split into more than one anchor element, where each has hte same URI. May be it would be useful to make it so that only one of the links are pereceived as a link.

For <area>, then I am  not certain what happens it if gets role=presentation, but I suppose it means that @aria-*,  @alt and @title attribute are ignored. If so, then may be  it could be useful e.g. if one wanted to use anchor elements - only - for AT and perhaps both area and anchors for non AT.

For <summary>, if <summary> is given role=presentation, then it would be equal to there not being any summary element - summary would instead just be a normal part of the body of the details element. When there is no summary element, then HTML5 says: 'If there is no child summary element, the user agent should provide its own legend (e.g. "Details").'  Clearly, there are use cases for not having a summary element. But whether there are usecases for having <summary> be treated as the content of the <details> elelement - that I don't know. But if thbe content <summary> is entirely useless - e.g. if it is just whitespace or a presentational image ... etc.

(In reply to comment #15)
> (In reply to comment #14)
> 
> > http://dev.w3.org/html5/spec/text-level-semantics.html#the-a-element
> 
> I suppose that you, eventually, also meant 
> 
> http://dev.w3.org/html5/spec/the-map-element#the-area-element
> 
> ?
> 
> As for use cases, here are 3 usecase for a, area and summary.
> 
> 
> <a>: For <a href=* role=presentation> then the usecase 'Describing a Newspaper
> Image' of the Instate Longdesc CP, lists one:
> 
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Use_Cases
> http://www.d.umn.edu/~lcarlson/research/ld.html#uc-10
> 
> Example:
> 
> <a href=large-version.jpg 
>       role=presentation >
>      <img longdesc=description.html 
>                src=small-version.jpg
>                alt="Lorem ipsum">
> </a>
> 
> Here the link is just presentational - it has little value for someone who is
> unsighted.

This use case is void, since the accessibility tree is not intended for "unsighted" users only.

For <a href role=presentation>, IIRC ARIA requires role=presentation to be ignored for focusable elements (you have to expose the element for it to be focusable). I don't know if ARIA bans role=presentation for focusable elements for document conformance, but it probably should.

(In reply to comment #17)
> For <a href role=presentation>, IIRC ARIA requires role=presentation to be
> ignored for focusable elements (you have to expose the element for it to be
> focusable). I don't know if ARIA bans role=presentation for focusable elements
> for document conformance, but it probably should.

James Craig touched this:
http://lists.w3.org/Archives/Public/wai-xtech/2011May/0040

His quote from ARIA: ''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. ''

I did indeed not think about this when I suggested to use <a role=presentation href=link >. 

HOWEVER, it is possible that ARIA should continue to permit role=presentation on focusable elements, because:

* the ARIA spec text talks about 'the *normal* effect of the role'. For example, what if a table cell of a presentational table has the tabindex attribute set? It would be meaningless to treat that table cell as a non-presentational table cell.

* note also that @role may take a list of several roles. I would thus suggest that 
 <a role=presentation href=link > is equal to 
 <a role='presentation link' href=link>

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)

> This use case is void, since the accessibility tree is not intended for
> "unsighted" users only.

I did give that point a thought when I suggested to use role=presentation on that link. But it is possible that I didn't give it enough thought, of course.

I have to say that to myself, it seems quite meaningful that a link can be presentational.  With the caveat that it is possible that ARIA disagrees with me that this should be possible, I also think that if a deaf person browses that example, then he or she would use a 'normal' browser, and would use the mouse or keyboard to activate the link to the large version of the image - without any problems whatsoever. 

With the abvoe caveats, do you have any use case were the example would fail?

(In reply to comment #15)
> (In reply to comment #14)
> 
> > http://dev.w3.org/html5/spec/text-level-semantics.html#the-a-element
> 
> I suppose that you, eventually, also meant 
> 
> http://dev.w3.org/html5/spec/the-map-element#the-area-element
> 
> ?
> 
> As for use cases, here are 3 usecase for a, area and summary.
> 
> 
> <a>: For <a href=* role=presentation> then the usecase 'Describing a Newspaper
> Image' of the Instate Longdesc CP, lists one:
> 
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Use_Cases
> http://www.d.umn.edu/~lcarlson/research/ld.html#uc-10
> 
> Example:
> 
> <a href=large-version.jpg 
>       role=presentation >
>      <img longdesc=description.html 
>                src=small-version.jpg
>                alt="Lorem ipsum">
> </a>
> 
> Here the link is just presentational - it has little value for someone who is
> unsighted.
> 
> Another, possible use case: some times an element is split into more than one
> anchor element, where each has hte same URI. May be it would be useful to make
> it so that only one of the links are pereceived as a link.
> 
> For <area>, then I am  not certain what happens it if gets role=presentation,
> but I suppose it means that @aria-*,  @alt and @title attribute are ignored. If
> so, then may be  it could be useful e.g. if one wanted to use anchor elements -
> only - for AT and perhaps both area and anchors for non AT.
> 
> For <summary>, if <summary> is given role=presentation, then it would be equal
> to there not being any summary element - summary would instead just be a normal
> part of the body of the details element. When there is no summary element, then
> HTML5 says: 'If there is no child summary element, the user agent should
> provide its own legend (e.g. "Details").'  Clearly, there are use cases for not
> having a summary element. But whether there are usecases for having <summary>
> be treated as the content of the <details> elelement - that I don't know. But
> if thbe content <summary> is entirely useless - e.g. if it is just whitespace
> or a presentational image ... etc.


screen magnifification software uses information from the accessibility tree, many people who use screen readers have some sight and may well beneefit form a large view of an image.

your use case is poorly considered.

(In reply to comment #20)
> (In reply to comment #15)
> > (In reply to comment #14)

    ....
> screen magnifification software uses information from the accessibility tree,
> many people who use screen readers have some sight and may well beneefit form a
> large view of an image.

Good points. Thanks.

> your use case is poorly considered.

Good that WAI-ARIA has considered it then, and deemed that the normal effect of role=presentation should be ignored in such cases.

(In reply to comment #18)
> * the ARIA spec text talks about 'the *normal* effect of the role'. For
> example, what if a table cell of a presentational table has the tabindex
> attribute set? It would be meaningless to treat that table cell as a
> non-presentational table cell.

Good question. I bet it hasn't been properly considered. Will you file a bug or send an email on the ARIA spec about what UAs should do in this case?

(In reply to comment #22)

> Good question. I bet it hasn't been properly considered. Will you file a bug or
> send an email on the ARIA spec about what UAs should do in this case?

I'm not sure about where to file bugs. But I did hower send a message to James Craig + wai-xtech@ again, where I also mentioned the table cell thing:

http://lists.w3.org/Archives/Public/wai-xtech/2011May/0045

That said, perhaps this isn't very complicated anyhow - the answer is contained inside ARIA's concept of 'required owned elements'. For example, ARIA says that: ''' Explicit roles on a descendant or owned element override the inherited role of presentation, and cause the owned element to behave as any other element with an explicit role. '''.

So I think that in case of 
   <table role=presentation><tr><td tabindex=0 >Lorem</td></tr></table>

then this would be equal to
      <div><div><div tabindex=0 >Lorem</div></div></div>

mass-moved component to LC1

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: Per comment 17, for focusable elements such as those listed in comment 14 we are better off relying on ARIA to apply the relevant conformance criteria here.

escalated as issue 186 https://www.w3.org/html/wg/tracker/issues/186

*** Bug 11956 has been marked as a duplicate of this bug. ***

HTML5.1 Bugzilla Bug Triage: Closing this issue, as it appears that the escalated issue (https://www.w3.org/html/wg/tracker/issues/186) was closed due to lack of a proposal.

If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!