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 20420 - Clarify, with ARIA language, if role of <main> can be overridden.
Summary: Clarify, with ARIA language, if role of <main> can be overridden.
Status: CLOSED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: maincontent element (show other bugs)
Version: unspecified
Hardware: PC All
: P3 normal
Target Milestone: ---
Assignee: steve faulkner
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/TR/html-main-elemen...
Whiteboard:
Keywords: a11y, aria
Depends on: 20696
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-18 01:47 UTC by Leif Halvard Silli
Modified: 2013-04-06 23:05 UTC (History)
4 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2012-12-18 01:47:42 UTC
Spec text says: "User agents MUST map the main element to the ARIA landmark role of main." 

However, the spec does not, in ARIA terms, clarify whether <main> is supposed to have "strong native semantics" or "default implicit ARIA semantics"

http://w3.org/html/wg/drafts/html/master/infrastructure#strong-native-semantics
http://w3.org/html/wg/drafts/html/master/infrastructure#default-implicit-aria-semantics

(also known from HTML5’s two ARIA tables)

http://w3.org/html/wg/drafts/html/master/dom#sec-strong-native-semantics
http://w3.org/html/wg/drafts/html/master/dom#sec-implicit-aria-semantics

Use cases, the options:

(1) <main role=presentation> (default implicit semantics of "main" is overridden by a permitted alternative role) in combination with a *permission* to place the "main" role on *another* element than <main> (which may only occur once).

(2) <main role=presentation> (default implicit semantics of "main" is overridden by a permitted alternative role) in combination with a *forbiddance* from placing the "main" role on *another* element than on the <main> element (which may only occur once). In this case, the page would be prevented from having any element of the "main" role until <main> is given its native role again.

(3) <main role=presentation> (strong semantics, which are overridden, against the rules of the spec.) Overrding the semantics would still be possible but it would be an author error.

Evaluation of the options: 

(1) Option (1) could be justified if fixing up authoring errors via aria (e.g. if <main> is not actually containing the main content) is a use case that should be considered when defining the permitted roles. (I am not sure it should.)

(2) Option (2), which can be seen as a variant of option (1), makes sense if there could be given a usecase for *not* including an element of role "main" on the page but where the <main> element as such was still useful to keep on the page, for whatever reason (e.g. for styling reasons).

(3) Option 3 may seem most straight forward.

Conclusion/Proposal: I leave this up to the editor.
Comment 1 steve faulkner 2012-12-18 14:00:27 UTC
I have updated the spec:

"The Strong native semantics and default implicit ARIA semantics for the main element is the ARIA landmark role of main. Conforming ARIA role attribute tokens for the main element are main and presentation."

thanks for the bug!
Comment 2 Leif Halvard Silli 2012-12-18 17:43:44 UTC
(In reply to comment #1)
> I have updated the spec:
> 
> "The Strong native semantics and default implicit ARIA semantics for the
> main element is the ARIA landmark role of main. Conforming ARIA role
> attribute tokens for the main element are main and presentation."

I think this resolution is self-contradicting. I understand you to say that <main> should have strong semantic. However, in that case, then it *cannot* be allowed to have the role presentation.

At least, when I look at the two ARIA tables that HTML5 has, then for the elemetns of strong semantics, they are not allowed to take any other semantics than those which are listed in that table.

http://w3.org/html/wg/drafts/html/master/dom#sec-strong-native-semantics

Wheras for the other table, then all elements/features defaults take the semantics that are listed in that table *but* in addition to that - says the text below the table - they can also take presentation role. 

http://w3.org/html/wg/drafts/html/master/dom#sec-implicit-aria-semantics

So if <main> authors are supposed to - *conformingly* – give <main> the presentation role, then <main> *cannot* have strong native semantics (since storng native semantics implies that the role can not conformingly be overruled by the author).

I think the text becomes correct if you just delete "Strong native semantics" from it.
Comment 3 steve faulkner 2012-12-18 22:31:22 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > I have updated the spec:
> > 
> > "The Strong native semantics and default implicit ARIA semantics for the
> > main element is the ARIA landmark role of main. Conforming ARIA role
> > attribute tokens for the main element are main and presentation."
> 
> I think this resolution is self-contradicting. I understand you to say that
> <main> should have strong semantic. However, in that case, then it *cannot*
> be allowed to have the role presentation.
> 
> At least, when I look at the two ARIA tables that HTML5 has, then for the
> elemetns of strong semantics, they are not allowed to take any other
> semantics than those which are listed in that table.
> 
> http://w3.org/html/wg/drafts/html/master/dom#sec-strong-native-semantics
> 
> Wheras for the other table, then all elements/features defaults take the
> semantics that are listed in that table *but* in addition to that - says the
> text below the table - they can also take presentation role. 
> 
> http://w3.org/html/wg/drafts/html/master/dom#sec-implicit-aria-semantics
> 
> So if <main> authors are supposed to - *conformingly* – give <main> the
> presentation role, then <main> *cannot* have strong native semantics (since
> storng native semantics implies that the role can not conformingly be
> overruled by the author).
> 
> I think the text becomes correct if you just delete "Strong native
> semantics" from it.

Hi leif, note the first table  second column header:
http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-semantics "Strong native semantics and default implicit ARIA semantics"
Also note that role=presentation can be used on any element. I argued against this but Ian prevailed.
Comment 4 Leif Halvard Silli 2012-12-19 12:01:10 UTC
(In reply to comment #3)

CONCLUSION:

I now see that you were only confused with regard to what "strong native semantics" implies. Hence, I instead propose this solution:

(1) Delete the word "presentation" from your spec text, and then it would be all good. This solution is also supported by the fact that HTML5 does not say that "presentation" is allowed for elements with strong native semantics.
(2) Also, you *should* clarify that the wordings "strong native semantics" and "default implicit semantics" stems from ARIA. (Actually, "default implicit semantics" stems from HTML5, since ARIA’s corresponding term is "implicit semantics" - so you should perhaps says "implicit semantics instead" - sigh.)

PS! Some notes about what you said:

> Hi leif, note the first table  second column header:
> http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-
> semantics "Strong native semantics and default implicit ARIA semantics"

Yeah. And? Nothing is said there about "presentation".

Btw, the HTML5 spec is currently somewhat unclear since, for the elements of the STRONG table, it defines them to have 'strong native semantics' *AND* 'default implicit semantics'. It would be less confusing (to me, at least) if it instead said 'strong implicit semantics'.

But regardless: The "strong native semantics" is defined (via a link) to have the same meaning as in ARIA 1.0. And that "default implicit semantics" is defined (via a link) to have the same meaning as "implicit semantics" in ARIA 1.0.

So does *ARIA* say that elemements with strong native semantics can have "presentation" role? The answer is "no". Citing ARIA 1.0:

]]
Host languages MAY document features that cannot be overridden with WAI-ARIA (these are called "strong native semantics"). These can be features that have implicit WAI-ARIA semantics, as well as features where the processing would be uncertain if the semantics were changed with WAI-ARIA. Conformance checkers MAY signal an error or warning when a WAI-ARIA role is used on elements with strong native semantics, but as described above, user agents MUST still use the value of the the semantic of the WAI-ARIA role when exposing the element to accessibility APIs.
[[

I would not say that it would necessarily be against ARIA if HTML5 — or the <main> spec - allowed both "main" and "presentation" role. But HTML5 [or should I say HTML5.1?] currently doesn't allow presentation for strong native semantics elements.

> Also note that role=presentation can be used on any element. I argued
> against this but Ian prevailed.

Well, I personally might actually agree more with Ian, then. ;-) But that is not the point. The point is what the spec *currently* says. And currently, then for the strong native semantics table, then I can see no trace of the battle you had with Ian. (Only in the next table, over "none-strong" native semantics, is there such a "presentation" permission.)
Comment 5 steve faulkner 2012-12-19 12:07:43 UTC
Hi leif, will leave this open for now, but in regards to use o role=presentation on any elements see: https://www.w3.org/Bugs/Public/show_bug.cgi?id=11956
Comment 6 Leif Halvard Silli 2012-12-19 12:31:24 UTC
(In reply to comment #5)
> Hi leif, will leave this open for now, but in regards to use o
> role=presentation on any elements see:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=11956

Regarding bug 11956, then that was marked (by yourself!) as a duplicate of bug 10919.

Anyway, this is what I get out of bug 11956:

The example you gave in bug 11956 was <input type=submit role=presentation >. Which per HTML5 belongs to the strong table. Your claim about that example was that HTML5 back then allowed role=presentation. You did not cite any spec text for that claim, however, so I wonder if it was based on memory rather than spec text. (Or if Ian resolved it after he updated the spec to not allow "presentation" for strong native semantics elements.)

As for the parallell "mother bug", bug 10919, then Ian’s resolution was that "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."

So it does seem as if Ian considered that HTML5 should not define whether it, for your example (<input type=submit role=presentation >) from bug 11956, would be conforming to use presentation role, but rather leave that question to ARIA. And that is what HTMl5 currently does.

According to Ian’s ruling, this conclusion required not spec change, and may be it is the "no spec change" bit which is the confusion point?
Comment 7 Leif Halvard Silli 2012-12-19 12:36:54 UTC
I might as well add that the HTML5 validator issues an error message for you example from bug 11956 -  <input type="submit" role="presentation">:

http://validator.w3.org/nu/?showsource=yes&doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%3Bbase64%2CPCFET0NUWVBFIGh0bWw%252BPHRpdGxlPjwvdGl0bGU%252BPGlucHV0IHR5cGU9InN1Ym1pdCIgcm9sZT0icHJlc2VudGF0aW9uIj4%253D
Comment 8 steve faulkner 2013-01-17 09:46:02 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Hi leif, will leave this open for now, but in regards to use o
> > role=presentation on any elements see:
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=11956
> 
> Regarding bug 11956, then that was marked (by yourself!) as a duplicate of
> bug 10919.
> 
> Anyway, this is what I get out of bug 11956:
> 
> The example you gave in bug 11956 was <input type=submit role=presentation
> >. Which per HTML5 belongs to the strong table. Your claim about that
> example was that HTML5 back then allowed role=presentation. You did not cite
> any spec text for that claim, however, so I wonder if it was based on memory
> rather than spec text. (Or if Ian resolved it after he updated the spec to
> not allow "presentation" for strong native semantics elements.)
> 
> As for the parallell "mother bug", bug 10919, then Ian’s resolution was that
> "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."
> 
> So it does seem as if Ian considered that HTML5 should not define whether
> it, for your example (<input type=submit role=presentation >) from bug
> 11956, would be conforming to use presentation role, but rather leave that
> question to ARIA. And that is what HTMl5 currently does.
> 
> According to Ian’s ruling, this conclusion required not spec change, and may
> be it is the "no spec change" bit which is the confusion point?

Hi Leif, as the main element is now defined in HTML 5.1 please review its definition there:
http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element
and
http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-semantics

feel free to open a new bug on the spec if you have issues.