add sectionheader and sectionfooter roles

[scottaohara]

adds proposed header and footer roles to allow authors to identify areas of the page that would fit the more general HTML definition for the elements of the same name (and would not be considered landmark elements).

These would also allow for the respective HTML elements to expose these new roles - essentially 'renamed' group roles - if they are given properties important to accessibility (focusable, named) but are not meeting the conditions to be exposed as banner / contentinfo landmarks. The alternative is to just expose the elements as groups, which is doable, but arguably also overloads the use of the group role.

Closes #1915

Implementation tracking

• [X] "author MUST" tests: n/a
• [X] "user agent MUST" tests (wpt): https://github.com/web-platform-tests/wpt/pull/45916
• [ ] Browser implementations (link to issue or when done, link to commit):
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=273325
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1893684
  • Blink: https://issues.chromium.org/issues/337094897
• [X] Does this need AT implementations? n/a
• [ ] MDN changes

---

Preview | Diff

[cookiecrook]

@scottaohara wrote:

AX API
    AXRole: AXGroup
    AXSubrole: <nil>
    AXRoleDescription: header/footer

Seems reasonable. Checking with others before confirming.

[cookiecrook]

@cookiecrook wrote:

[AX API proposals seem] reasonable. Checking with others before confirming.

No comments in 24h. AX API proposals okay as is. Thanks.

[cookiecrook]

Also, would we want a "screen reader guidance" section as well? Essentially explaining you can expose this information when you feel like it's necessary, as @cookiecrook mentioned in the VoiceOver case?

No AT changes are needed on Mac. This is only an engine change that results in a different role description. Nothing more.

On the call today, @scottaohara mentioned the same was true on Windows.

[scottaohara]

@spectranaut probably not a bad idea to add a check for has MDN documentation been updated - these docs are often behind the curve with a11y info/updates. header mentions the 'scoped' nature of the header element - lightly, now. footer calls out an old webkit bug in its accessibility section.

[scottaohara]

@jnurthen @cookiecrook @spectranaut any other thoughts on this preventing it from merging? got reminded of it when reviewing the (now linked) WPT.

re: author guidance on when a header/footer is a section header/footer vs the landmarks. that can be added to MDN, but that's blocked on this change being made. One could argue the info could be more overtly stated with the current reality of how these elements work. But I would rather make one change than two.

[cookiecrook]

@jnurthen @cookiecrook @spectranaut any other thoughts on this preventing it from merging? got reminded of it when reviewing the (now linked) WPT.

re: author guidance on when a header/footer is a section header/footer vs the landmarks. that can be added to MDN, but that's blocked on this change being made. One could argue the info could be more overtly stated with the current reality of how these elements work. But I would rather make one change than two.

I was suggesting the role name be changed from header/footer to sectionheader/sectionfooter to prevent author confusion with the existing role banner…

[scottaohara]

thanks @cookiecrook. for some reason i had a memory of already doing this, but clearly my memory was faulty. i've actually done it now.

[spectranaut]

Per our new process, changes to the ARIA spec can't land until there are implementations or implementation commitments, and related changes to the AAMs/Accname, so I think you need to open all those PRs and bugs on browsers.

But I just realized we sort of need an intermediary, because we shouldn't open bugs on browsers until we have "consensus" from the working group... we we need a way of keeping track of that some how. I think it used to be that once we had consensus we merged, and that is how we "kept track" of what had consensus.

[scottaohara]

yes, there does seem to be something with this revised process that needs working out, as I didn't think it would make sense to file bugs until reviews were completed (and i did the work james requested and i flubbed on actually doing, until yesterday).

also, as we've already had a few meetings (triage, then the meeting where i actually babbled on about the proposal - resulting in me doing the work, and THEN we did initial triage of the PR) isn't the fact there were reviewers assigned (and anyone else can also review now) the end point of the consensus process? E.g., once we have approving reviews, then that means there is consensus. If more consensus is needed after that, it seems like the process is overcomplicated, or we aren't doing consensus right.

[spectranaut]

Ah good point, @scottaohara -- three reviews = consensus. So, we can open issues on implementations after there are three reviews, and we can merge after there is at least one implementation and implementation commitment

[spectranaut]

Assigning to myself to make tests and issues on browsers.

[jcsteh]

Sorry if I've missed something, but I'm a bit unclear: will this result in changing HTML <header>/<footer> so that they are no longer landmarks?

[pkra]

will this result in changing HTML <header>/<footer> so that they are no longer landmarks?

@jcsteh no, these roles are in addition to those.

To quote @scottaohara's starting comment:

These would also allow for the respective HTML elements to expose these new roles - essentially 'renamed' group roles - if they are given properties important to accessibility (focusable, named) but are not meeting the conditions to be exposed as banner / contentinfo landmarks.

[jcsteh]

Ah, I get it. I think I was (and am still a little) confused by the "if they are given properties important to accessibility (focusable, named)" condition. If we're creating new roles for these, why impose that condition only for implicit roles on HTML elements? As an example, a <p> is always a paragraph, even if it isn't focusable or has no name. Generics are different, but generics are special because they're effectively non-semantic. These new roles are either semantic... or they're not.

[scottaohara]

that's the problem that these new roles are trying to solve. right now header and footer, if not landmarks, are treated as generic. but in HTML header and footer have semantic meaning regardless of their usage.

while these elements always have semantic meaning, we talked alot about how we don't to necessarily add new announcements of these roles for situations where the content alone is understandable. hence why we wanted to treat these similar to the group role - where if the group is unnamed or not focusable, then the group (and these roles) wouldn't have to be overtly announced to users.

and then on the flip side, the other reason for these specific roles is because authors do provide header and footer elements accessible names, or make them focusable (for better or worse) but if these elements aren't scoped to be landmarks, then they are named/focusable generics and we want to avoid that. sometimes having these html elements be nameable and sometimes not.

[jcsteh]

hence why we wanted to treat these similar to the group role - where if the group is unnamed or not focusable, then the group (and these roles) wouldn't have to be overtly announced to users.

That's reasonable, but there's an important distinction between "not announced by screen readers" and "not exposing the roles to accessibility APIs". With the group role, it's always exposed; screen readers just choose not to report it if there's no significant property. If I read your description correctly (and maybe I'm misunderstanding it), you're suggesting that <header> wouldn't be exposed at all unless it has a significant property (name, focusable, etc.). Aside from anything else, this would diverge from ARIA, since role="section header" would always be exposed but <header> might not be.

[scottaohara]

@jcsteh the intent of this was for these to be able to essentially be role=group with a browser defined aria-roledescription so that screen readers could treat these new roles exactly the same as role=group. if that's not clear from the written comments, apologies. But this point was discussed at length during the ARIA meetings as the intended outcome.

so <header> would be exposed as sectionheader, when not exposed as a banner - but the idea is that screen readers would treat it similarly to role=group and not announce the role unless it was named or focused.

[jcsteh]

but in HTML header and footer have semantic meaning regardless of their usage.

Do they? HTML-AAM mostly maps them to "generic", with the exception of ATK. (IMO, UIA doesn't count because it basically overloads/abuses LocalizedControlType for everything instead of having proper native semantics. 😒)

so <header> would be exposed as sectionheader, when not exposed as a banner

For the sake of absolute clarity, "when not exposed as a banner" would be the only exposure condition as far as HTML-AAM and thus browsers are concerned? (I understand the intended screen reader behaviour here; I'm just trying to be sure I fully understand the intended API mappings.)

[scottaohara]

Do they? HTML-AAM mostly maps them to "generic",

Yes. The header and footer elements are meant to be used for more than just for banner and contentinfo purposes if going by their definitions / indented "semantic" (not just a11y mappings) usage in the HTML spec.

For the sake of absolute clarity, "when not exposed as a banner" would be the only exposure condition as far as HTML-AAM and thus browsers are concerned?

yes. Essentially header and footer would not be exposed as generics anymore. So the conditions for them to be exposed as banner/contentinfo, respectively remain the same, and the instances of where they would have instead be generic would instead map to these proposed new roles, again meaning to behave as 'group' roles with implicit aria-roledescriptions.

[netlify[bot]]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	b58b6a64913f6fde334488bc06c21b0c4e82bed2
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/66ada68fc4c04a00089c8d0b
😎 Deploy Preview	https://deploy-preview-1931--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.