search

w3c / html-aria

ARIA in HTML
https://w3c.github.io/html-aria/
Other
181 stars 48 forks source link

section element should allow role=group #249

Closed mitchellevan closed 2 years ago

mitchellevan commented 3 years ago

Current

Currently the HTML section element does not allow role=group.

Other HTML elements have implicit landmark roles, yet do allow role=group:

Proposed

Since the section element sometimes has a landmark role and sometimes does not, like header and footer, the section element should also allow role=group.

scottaohara commented 3 years ago

this seems a reasonable modification at first if role=group were exposed without an accessible name. but since you need to give it a name to ensure the role is exposed, it creates the situation of then squashing the implicit landmark role that section would have exposed (also mentioned at the end of my response in #255).

I'm not fully opposed to this particular modification... and in general i think there needs to be some alignment around these landmark issues / clarifications on when role adjustments are allowed. For instance, the spec currently states that the main element allows for no role to be set. I wonder if this should not also be how we spec <header> and <footer> when scoped to the <body>.

Might there be a note added to the spec to outline some non-normative information around landmark roles and why using a different element might be a better idea if you're looking to suppress such exposed mappings anyway. Arguably that could be extended as a broader note about all HTML elements in general.

mitchellevan commented 3 years ago

but since you need to give it a name to ensure the role is exposed, it creates the situation of then squashing the implicit landmark role that section would have exposed

What would be the disadvantage of allowing role=group to squash the landmark role of a named <section> element, when ARIA in HTML already allows several other roles to squash it? Other than none and presentation, they all have name from author:

alert, alertdialog, application, banner, complementary, contentinfo, dialog, document, feed, log, main, marquee, navigation, note, search, status, or tabpanel

i think there needs to be some alignment around these landmark issues / clarifications on when role adjustments are allowed

Here's a naive proposal -- let me know what's wrong with this... What if all elements with an implicit landmark role would allow all ARIA landmark roles and all ARIA document structure roles?

scottaohara commented 3 years ago

What would be the disadvantage of allowing role=group to squash the landmark role of a named

element, when ARIA in HTML already allows several other roles to squash it?

there is no clear disadvantage at this point, which is why i said "I'm not fully opposed to this particular modification". My lingering opposition to this comes from a discomfort at some of the variability I see here, and how some elements have stronger restrictions, but the reasoning why is not immediately clear without also having a good understanding of native HTML semantics/mappings, how authors have classically misused some of these elements, and how this document took those into consideration when the rules were put in place.

But my point is that i see a recurring issue, hence my linking to 255, and there have been other such similar ones in the past. It's unclear why there are variants in allowances and i think that is worth solving / making more clear.

For instance, all that you noted can be allowed on section, other arguably 'similar' HTML elements, aside and article (knowing of course that article is not a landmark element) only allow for a subset of what section allows for, and even those aren't exactly the same:

aside = feed, note, presentation, none, region or search article = feed, presentation, none, document, application, main or region

There needs to be some cleanup here, and that may well mean that section can have role=group. But if that's the case, i want to make sure it's clear why.

per your comment

Here's a naive proposal -- let me know what's wrong with this... What if all elements with an implicit landmark role would allow all ARIA landmark roles and all ARIA document structure roles?

Because while I know this is clearly not your intent, it would perpetuate that using HTML elements as intended is unnecessary as you can just then use ARIA to remap all your elements. There's no good reason for an author to have <main role=banner> in their markup. Back to the point of this issue, there's also no real good reason to have <section role=group> if the intent from the onset was to overwrite the section's semantics with ARIA. The section element is likely being used incorrectly, as it often is, and a div is likely what should have been used in the first place.

All this said, this issue has surfaced a good action item - to take a real hard look at a lot of the current allowances and fill in any gaps / provide additional informative content in this document.

mitchellevan commented 3 years ago

@scottaohara, you wrote:

some elements have stronger restrictions, but the reasoning why is not immediately clear without also having a good understanding of native HTML semantics/mappings, how authors have classically misused some of these elements, and how this document took those into consideration when the rules were put in place

It's not clear to me either. (Might this be a question for @stevefaulkner?)

You're right that I intended this "naive proposal" as a straw man:

What if all elements with an implicit landmark role would allow all ARIA landmark roles and all ARIA document structure roles?

However, now I'm not so sure it's actually a straw man.

it would perpetuate that using HTML elements as intended is unnecessary

To the extent this is the rationale for drawing the line, then we end up with a surprising set of choices... (1) We could deprecate all landmark roles except for role=search because each has a native HTML equivalent, and supporting any other element is encouraging a wrong coding practice. Or (2) we could go completely in the other direction, and accept my "naive proposal" as the actual plan. Or (3) we could attempt the impossible task of defining which wrong HTML elements are only a little bit wrong, so they deserve ARIA remediation, and which are excessively wrong and should be prohibited from ARIA remediation.

So now I'm feeling my "naive proposal" is actually the least-bad option of the three.

Of course there may be other important factors which affect where to draw the line, such as implementability or performance.