Editorial: Add <header> (sectionheader) and <footer> (sectionfooter) html-aam mappings #2543
Conversation
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull Request Overview
This PR updates the HTML-AAM reference to map <header> and <footer> elements to new ARIA section roles when they have an accessible name, otherwise retaining the generic role.
- Add conditional mapping text for
<footer>tosectionfootervs.generic - Add conditional mapping text for
<header>tosectionheadervs.generic
Comments suppressed due to low confidence (2)
html-aam/index.html:2516
- Consider adding automated tests to cover the new conditional mapping for
<footer>when it has an accessible name, verifying that thesectionfooterrole is applied and that it falls back togenericotherwise.
<td><a class="core-mapping" href="#role-map-sectionfooter">`sectionfooter`</a> role if the <a data-cite="html">`footer`</a> element has an <a data-cite="accname-1.2/#dfn-accessible-name">accessible name</a>. Otherwise, the <a class="core-mapping" href="#role-map-generic">`generic`</a> role.</td>
html-aam/index.html:2821
- Add tests for the
<header>element to ensure thesectionheaderrole is correctly applied when an accessible name is present, and that the fallback togenericbehaves as expected.
<td><a class="core-mapping" href="#role-map-sectionheader">`sectionheader`</a> role if the <a data-cite="html">`header`</a> element has an <a data-cite="accname-1.2/#dfn-accessible-name">accessible name</a>. Otherwise, the <a class="core-mapping" href="#role-map-generic">`generic`</a> role.</td>
html-aam/index.html
Outdated
| @@ -2513,7 +2513,7 @@ <h4 id="el-footer">`footer` (scoped to the `main` element,a sectioning content e | |||
| </tr> | |||
| <tr> | |||
| <th>[[wai-aria-1.2]]</th> | |||
| <td><a class="core-mapping" href="#role-map-generic">`generic`</a> role</td> | |||
| <td><a class="core-mapping" href="#role-map-sectionfooter">`sectionfooter`</a> role if the <a data-cite="html">`footer`</a> element has an <a data-cite="accname-1.2/#dfn-accessible-name">accessible name</a>. Otherwise, the <a class="core-mapping" href="#role-map-generic">`generic`</a> role.</td> | |||
There was a problem hiding this comment.
the intent of the role change would be to do away with generic all together, so i think that needs to be removed.
There was a problem hiding this comment.
So the presence of an accName is not a factor?
There was a problem hiding this comment.
I cannot agree more with Scott.
In a real-world scenario (e.g., article context) there's no need to assign an accessible name to these elements (and an author does not expect to do that), as the article context already conveys the meaning of the nested header and footer.
This also seems consistent with the ARIA specifications, which do not require an accessible name for such roles.
There was a problem hiding this comment.
@scottaohara @giacomo-petri Agreed, the computed role for <header> and <footer> should be sectionheader/sectionfooter in a sectioning element context in terms of mapping and for interop purposes so will remove the generic clause.
However, when <header>/<footer> are descendants of sectioning elements, my understanding is that they should be exposed as navigable containers only when they are supplied with accname (like role="region", which requires disambiguation). The Webkit and Chrome implementations both behave in this way so if this is incorrect, I can submit bugs to get this fixed.
There was a problem hiding this comment.
do you have a concrete example to illustrate your point? I'm having trouble seeing how <header> and <footer> could be descendants of other elements in the way you are suggesting.
From my understanding, and based on my testing, <header> and <footer> are either scoped to the nearest sectioning content (e.g. main, article, etc.), in which case they are mapped to sectionheader/sectionfooter, or they default to the page level, scoped to body, and get mapped to banner/contentinfo respectively.
Here’s what I mean with an example:
<body>
<table>
<tbody>
<tr>
<th>test</th>
<th>test</th>
</tr>
<tr>
<td><header>test</header></td>
<td><footer>test</footer></td>
</tr>
</tbody>
</table>
</body>
assuming it's somehow meaningful, hedaer and footer still retain the banner/contentinfo mapping, while in
<body>
<main>
<table>
<tbody>
<tr>
<th>test</th>
<th>test</th>
</tr>
<tr>
<td><header>test</header></td>
<td><footer>test</footer></td>
</tr>
</tbody>
</table>
</main>
</body>
they are mapped as sectionheader/sectionfooter
I don't see any other scenarios, unless we explicitly decide that, under certain conditions, these elements should instead map to a generic role.
There was a problem hiding this comment.
Sorry, I think I misunderstood the comment. In my view, since <header> and <footer> elements used as descendants of sectioning elements (like <article>) usually have a well-defined context, IMO authors typically don't need to provide an accessible name. Doing so would often just repeat the context that's already implied. I don't think developers are likely to add aria-label/aria-labelledby to native <header> or <footer> elements within an article, because their meaning is already clear from the structure.
This is also why, in my opinion, we differentiate roles like banner/contentinfo from sectionheader/sectionfooter. We want to avoid placing extra burdens on authors.
Moreover, <header> and <footer> elements, when used within sectioning elements, carry a more specific contextual meaning than generic <section> elements. While sections are often used as generic containers and may not always represent regions (reason why we require acc name), headers and footers usually indicate a defined part of a sectioning element, and not a generic one. If their use doesn't carry that semantic weight, they are better replaced with more neutral containers.
There was a problem hiding this comment.
This was discussed at length when these roles were created. That they are essentially role=group with platform localized role descriptions
So if they are named, the role is exposed by screen readers
if they are not named, then the role is treated the same as the group role and screen readers ignore it. BUT the role doesn’t change. It isn’t generic or none…
does this reminder of what these are supposed to act like ring any bells / squash any doubts?
There was a problem hiding this comment.
Per the example of the header/footer in the table - further updates to when these elements map to the section* vs landmark roles is going to be handled in another pr
There was a problem hiding this comment.
Thanks @scottaohara. I've updated the PR so ready for another review.
@giacomo-petri Please let me know if there's any further changes, thanks!
spectranaut
moved this to Needs Review
in ARIA Editorial (Spec Prose Updates) PR Tracking
Closes w3c/html-aam#585