This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
After the table inside section 3.2.7.4, "Implicit ARIA Semantics", comes an explainative paragraph with 2 sentences: ]] The entry "no role", when used as a strong native semantic, means that no role other than presentation can be used. When used as a default implicit ARIA semantic, it means the user agent has no default mapping to ARIA roles. (However, it probably will have its own mappings to the accessibility layer.) [[ This paragraph has a number of problems: 1) Location: It occurs in the section about implicit semantics, but it actually applies to the section on strong as well. It would seem logical to at least move the first sentence (in edited or unedited form) to the preceding section on strong native semantics. 2) Overriding with role="presentation"? In bug 20420 against the <main> element spec, an unclarity in the interpretation of HTML5 was highlighted. Namely: Can features with strong native semantics be overridden with the presentation role? Or can they not? Steve seems to be right (i.e.: it fits with my own recollection) when he, in that bug, said that Ian at some point ruled that all features could be overridden wiht the presentation role. However, this is not (any longer) reflected in the spec, and my suspicision is that this at some point was changed to only be true for the strong native semantic of "no role". 3) The above quoted paragraph says that elements with a strong native semantic of "no role", can be overridden with the role "presentation". But nowhere in the HTML5 spec is is said that strong semantics *other* than "no role" can conformingly be overridden by role "presentation". 4) HTML5 says that "strong native semantics" is used in the same meaning that ARIA puts in thant expression. http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#strong-native-semantics And ARIA say, quote: "Host languages MAY document features that cannot be overridden with WAI-ARIA (these are called "strong native semantics")." http://www.w3.org/WAI/PF/aria/host_languages#host_general_conflict Note that ARIA does not give any exception for the presentation role. As such, even the rule that "no role" can be set to "presentation", seems to controadict with ARIA’s interpretation of "strong native semantics". Personaly opinion: At least for some of the features in HTML5’s strong native semantics table, it seems reasonably to be able to use role="presentation". For instance, for the <hr> element. Advice: I suggest (A) to check with e.g. Ian if the intention still is that all strong native semantics features should be possible to conformingly override with role="presentation". Or whether that rule has been limited to elements of "no role" (B) after the conclusion on (A), I suggest to check whether the definition of "strong native semantics" is adequately described - in HTMl5 as well as in ARIA. (C) if, after (A) and (B), still relevant, check if the first sentence of the quoted paragraph above, should be deleted or moved to the preceding section on "strong native semantics".
Hi Leif, rather than make major changes to this section, I have provided pointers to documents for authors that do provide unambiguous guidance. 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-v3.html Status: rejected Change Description: added note with references https://github.com/w3c/html/commit/38ffe22ebc22e1a0f8e6e0788fe426e402df1fc8 Rationale: The primary audience of this section is implementers it does not provide clear or adequate info for authors, other W3C documents do.
This solution does not touch the problem which the bug points out. In comment #0 I suggest consulting with Hixie. But it is enough to read the first sentence in the second paragraph of the WAI-ARIA section of the WHATwg spec, which cleary says that presentation features with strong native semantics can take the presentation role:[1] ]] Authors must not set the ARIA role and aria-* attributes in a manner that conflicts with the semantics described in the following table, except that the presentation role may always be used. [[ This sentence does not exist in the HTMLWG version. But if the HTMLWG spec gets the same sentence, then I shall consider the bug as fixed. To add this sentence, can hardly be described as a "major change". [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#wai-aria
(In reply to comment #2) Typo: > spec, which cleary says that presentation features with strong native > semantics can take the presentation role:[1] I meant'features'. I did not mean 'presentation features'.
(In reply to comment #2) > This solution does not touch the problem which the bug points out. > > In comment #0 I suggest consulting with Hixie. But it is enough to read the > first sentence in the second paragraph of the WAI-ARIA section of the WHATwg > spec, which cleary says that presentation features with strong native > semantics can take the presentation role:[1] > > ]] > Authors must not set the ARIA role and aria-* attributes in a manner that > conflicts with the semantics described in the following table, except that > the presentation role may always be used. > [[ > > This sentence does not exist in the HTMLWG version. But if the HTMLWG spec > gets the same sentence, then I shall consider the bug as fixed. To add this > sentence, can hardly be described as a "major change". > > [1] > http://www.whatwg.org/specs/web-apps/current-work/multipage/elements. > html#wai-aria 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-v3.html Status: rejected Change Description: none I do not agree that authors should apply role=presentation to focusable elements, as doing so leads to a poor user experience, which is why Using ARIA in HTML[1] provides more granular guidance as to use of role=presentation. [1] https://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index.html#recommendations-table
(In reply to comment #4) > Status: rejected > Change Description: none > > I do not agree that authors should apply role=presentation to focusable > elements, as doing so leads to a poor user experience, which is why Using > ARIA in HTML[1] provides more granular guidance as to use of > role=presentation. > > [1] > https://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index. > html#recommendations-table Thanks for the link, which gives the impression that 'Using WAI-ARIA in HTML', tries to create a table that can replace the HTML5’s current two tables about weak and strong semantics, would have been relevant to know from the start. However, sofar the strong table and the weak table are there. And I am going to react to what is in HTML5 - not what is in other documents. First: I believe that I disagree with your opinion on role="presentatiton". Second: Let me remind you that when we, you and I discussed, <main> - which you defined as having STRONG semeantics - you expressed the clear view that HTML5 permits role="presentation" on all elements. This is also my view. And it is in fact expressed in in the current version of HTML5.x. The only problem I have is that this permission i expressed in a context which explains what 'no role' means: ]] The entry "no role", when used as a strong native semantic, means that no role other than presentation can be used.[[ Thus, to WONTFIX this bug, does not mean that you have taken away HTML5’s permission to use role="presentation". It only means that HTML5 continues to state, in a suboptimal way, that role="presentation" is permitted on all features with strong semantics. If you want to take away HTML5’s permission to apply role="presentation" on all features with strong semantics, then you better do a proper job. If you are *not* going to remove HTML5’s two tables over strong and wak semantics, then I suggest going through the strong table and verify that you are OK with the removal of the permission to apply role="presenation" on all those elements. As to what you say about focusable, then there are focusable elements also in the weak table. So, in a summary, I expect you to EITHER accept my proposed, simple, minor fix. OR to do a major job related to removing not only strong feature’s permission to take presentation role, but also - it seems from what you say - remove from some of the weak element there permission to take presentation role.
Sorry, unintendely changed the title.
(In reply to comment #5) > (In reply to comment #4) > First: I believe that I disagree with your opinion on role="presentatiton". Just to clarify: This bug says "clarify if". And will accept that presentation role for features with strong native semanics, is made unpermitted, if it is done in a coherent way, including that the justifications for why presentation role shold no longer be permitted is coherent. (For instance, why <hr/> should not be permitted to have presenation role?.) * Currently, I see increase of coherence if the sentence I proposed in comment #2 is added, as the permission to use presentation role is sensible to mention not only when explaining 'no role', but also when in front of the table with straong native features. * By contrast, to WONTFIX this bug does per se neither increase or decrease coherence. But the bug should not be WONTFIXed unless the bug filer and the editor are satisfied with what the spec says about presentaton role of native semantics. The bug filer is not satisfied. And it seems from what the editor says he is not satisfied either. Or else, why does he want that readers should ignore what HTML5 currently says and instead look in the 'Using WAI-ARIA in HTML' document? Why else does he say that that document has more detail? * At the same time, it seems like the editor thinks that WONTFIXing this bug has other implications than it has. E.g. as told focusable elements occurs both in the table with weak semantics and the table with strong semantics. Refusing to clarify that features with strong native semantics can take presenational role, is not going to impact on focusable elements with weak semantics.
(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #4) > > > First: I believe that I disagree with your opinion on role="presentatiton". > > Just to clarify: This bug says "clarify if". And will accept that > presentation role for features with strong native semanics, is made > unpermitted, if it is done in a coherent way, including that the > justifications for why presentation role shold no longer be permitted is > coherent. (For instance, why <hr/> should not be permitted to have > presenation role?.) > > * Currently, I see increase of coherence if the sentence I proposed in > comment #2 is added, as the permission to use presentation role is sensible > to mention not only when explaining 'no role', but also when in front of the > table with straong native features. > > * By contrast, to WONTFIX this bug does per se neither increase or decrease > coherence. But the bug should not be WONTFIXed unless the bug filer and the > editor are satisfied with what the spec says about presentaton role of > native semantics. The bug filer is not satisfied. And it seems from what the > editor says he is not satisfied either. Or else, why does he want that > readers should ignore what HTML5 currently says and instead look in the > 'Using WAI-ARIA in HTML' document? Why else does he say that that document > has more detail? > > * At the same time, it seems like the editor thinks that WONTFIXing this bug > has other implications than it has. E.g. as told focusable elements occurs > both in the table with weak semantics and the table with strong semantics. > Refusing to clarify that features with strong native semantics can take > presenational role, is not going to impact on focusable elements with weak > semantics. Hi Leif have taken what you have said on board and added conformance requirements for role=presentation 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-v3.html Status: partially accepted Change Description: https://github.com/w3c/html/commit/9656927a1c615e8c65006e62cc493f3152f587c6 rationale: using role=presentation on interactive elements will almost certainly result in a degraded user experience. There are currently no use cases for using role=presentation on interactive elements. It makes sense to therefore define usage restrictions in the spec so conformance checkers can flag errors.
have tweaked previous commit so it makes sense https://github.com/w3c/html/commit/1e2718be4929a8c2d1f8c48ecf91a5004d315c86
(In reply to comment #9) > have tweaked previous commit so it makes sense > > https://github.com/w3c/html/commit/1e2718be4929a8c2d1f8c48ecf91a5004d315c86 Glad you saw it yourself. Wonder why you RESOLVED this bug as FIXED *before* you saw it ... (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #5) > > > (In reply to comment #4) > Status: partially accepted > Change Description: > https://github.com/w3c/html/commit/9656927a1c615e8c65006e62cc493f3152f587c6 > rationale: using role=presentation on interactive elements will almost > certainly result in a degraded user experience. There are currently no use > cases for using role=presentation on interactive elements. It makes sense to > therefore define usage restrictions in the spec so conformance checkers can > flag errors. You did many changes, so one could argue that you should have opened some new bugs and linked to this bug. However, I tried to through all the changes you made (and did not make). Here are my results. OK: Interacive features, weak and strong: OK with solution (partly due to lack of power to disagree). Not sure: Other strong features: why not allow presentation on <script>, <body> etc? On the other side, it seems like adding role="presentation" to <script> doesn't really add anything, not even if the content is made visible via CSS. But feel free to reconsider. Not sure: Regarding <meter> and some such: Why not allow presentation there? OTOH, I have no use case. But feel free to reconsider. OK: Regarding the definition of "no role", I OK with the rewording. Not OK: The only thing I have an explicit issue with right now, is the <object> element and the <iframe> element. Both of those elements can logically be images, including presentational images. As such they should be permitted to take presentational role. Also, if one <object> is nested inside another <object>, the inner object should probably sometimes just be presentational, rather than introducinga new role.
(In reply to comment #10) > Not OK: The only thing I have an explicit issue with right now, is the > <object> element and the <iframe> element. Both of those elements can > logically be images, including presentational images. As such they should be > permitted to take presentational role. Also, if one <object> is nested > inside another <object>, the inner object should probably sometimes just be > presentational, rather than introducinga new role. Technially, your changes to object and iframe, is not related to this bug, which is about strong. But I don't mind if you solve it as part of this bug.
(In reply to comment #11) > (In reply to comment #10) > > > > Not OK: The only thing I have an explicit issue with right now, is the > > <object> element and the <iframe> element. Both of those elements can > > logically be images, including presentational images. As such they should be > > permitted to take presentational role. Also, if one <object> is nested > > inside another <object>, the inner object should probably sometimes just be > > presentational, rather than introducinga new role. > > Technially, your changes to object and iframe, is not related to this bug, > which is about strong. But I don't mind if you solve it as part of this bug. 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: fixed Change Description: added presentation to object and iframe refer to https://github.com/w3c/html/commit/3059a6a46a39015ef1735910b61bcd8e0a2c4bae rationale: agreed with commenter