This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10919 - Allow role="presentation" to override the default role of any element
Summary: Allow role="presentation" to override the default role of any element
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: LC
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, aria, TrackerIssue
: 11956 (view as bug list)
Depends on:
Blocks: 10066 10450
  Show dependency treegraph
 
Reported: 2010-09-30 22:54 UTC by Martin Kliehm
Modified: 2016-04-15 21:35 UTC (History)
13 users (show)

See Also:


Attachments

Description Martin Kliehm 2010-09-30 22:54:29 UTC
Some HTML elements have native roles that can be overridden by a limited list of other roles. "presentation" is not in this list, but it should be.

WAI-ARIA [1] defines:

"An element whose implicit native role semantics will not be mapped to the accessibility API.

"The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type [...]

"Example use cases: [...] An element used as an additional markup 'hook' for CSS"

The following use case can be found at http://bahn.de

<ul role="tablist">
  <li role="presentation">
    <span role="presentation">
      <a role="tab" href="#bahn">Bahn</a>
    </span>
  </li>
</ul>

Some screenreaders don't recognize the tab role when it is not an immediate child of the tablist role element. In the example above some presentational CSS is attached to the list item and the span element. The presentation role removes those elements from the accessibility API such that tab is again a child of tablist. The anchor is most convenient since it's fragment identifier is used to update the browser history, and it brings some default behavior like being included in the taborder and using a pointer cursor.

It may not be a best practice, but it will and does happen. role="presentation" is more powerful than just an eraser for image elements with empty alt attributes.

May depend on bug #10066.

[1] http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#presentation
Comment 1 Tab Atkins Jr. 2010-09-30 23:06:07 UTC
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?
Comment 2 Martin Kliehm 2010-10-01 08:53:19 UTC
(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.
Comment 3 Maciej Stachowiak 2010-10-02 05:34:40 UTC
(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.
Comment 4 Martin Kliehm 2010-10-02 17:52:21 UTC
(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.
Comment 5 Ian 'Hixie' Hickson 2010-10-05 00:54:43 UTC
Where does ARIA say this should happen? Isn't aria-owns the official way to do this?
Comment 6 Benjamin Hawkes-Lewis 2010-10-05 06:18:28 UTC
(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?
Comment 7 Martin Kliehm 2010-10-06 08:42:54 UTC
(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.
Comment 8 Benjamin Hawkes-Lewis 2010-10-06 08:53:25 UTC
(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?
Comment 9 Maciej Stachowiak 2010-10-11 21:59:15 UTC
(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).
Comment 10 Ian 'Hixie' Hickson 2010-10-11 22:40:45 UTC
See bug 10450 comment 12.
Comment 11 Ian 'Hixie' Hickson 2010-10-14 07:04:15 UTC
See bug 10450 comment 17.
Comment 12 Ian 'Hixie' Hickson 2010-10-14 10:18:23 UTC
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.
Comment 13 contributor 2010-10-14 10:20:08 UTC
Checked in as WHATWG revision r5633.
Check-in comment: Allow role=presentation everywhere
http://html5.org/tools/web-apps-tracker?from=5632&to=5633
Comment 15 Leif Halvard Silli 2011-05-18 00:20:37 UTC
(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.
Comment 16 Benjamin Hawkes-Lewis 2011-05-18 06:13:52 UTC
(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.
Comment 17 Simon Pieters 2011-05-18 11:56:39 UTC
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.
Comment 18 Leif Halvard Silli 2011-05-18 13:24:51 UTC
(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>
Comment 19 Leif Halvard Silli 2011-05-18 13:30:55 UTC
(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?
Comment 20 steve faulkner 2011-05-18 13:38:16 UTC
(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.
Comment 21 Leif Halvard Silli 2011-05-18 13:46:47 UTC
(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.
Comment 22 Simon Pieters 2011-05-18 15:14:25 UTC
(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?
Comment 23 Leif Halvard Silli 2011-05-18 18:24:29 UTC
(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>
Comment 24 Michael[tm] Smith 2011-08-04 05:04:50 UTC
mass-moved component to LC1
Comment 25 Ian 'Hixie' Hickson 2011-11-30 20:22:45 UTC
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.
Comment 26 steve faulkner 2011-12-01 15:42:21 UTC
escalated as issue 186 https://www.w3.org/html/wg/tracker/issues/186
Comment 27 steve faulkner 2011-12-08 16:57:01 UTC
*** Bug 11956 has been marked as a duplicate of this bug. ***
Comment 28 Travis Leithead [MSFT] 2016-04-15 21:35:58 UTC
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!