Pager template h4 can be out of document hierarchy order

Given this is in a twig template, and therefore can be overridden by a theme on a project, I think we're only talking about making core theme's semantically correct w.r.t to structure/heading levels.

So it would be good to use an a11y tool to see which of the core themes (seven/claro/bartik/olivero) have this issue.

Bearing in mind that we can't change markup in minor versions for seven or bartik (as they're stable) nor in stable/stable9.

Correct me if I am wrong, the aria-label method would work just as well since nav is already a landmark.

Otherwise, I think it is reasonable to "make the tag used configurable". The content creator should have full control of information architecture on a given page, the template should not have absolute opinion on the heading.

hi folks! i'm the accessibility lead at Catalyst IT. Here are my 2 cents:

A heading is meant to demarcate a section (https://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.5 "A heading element briefly describes the topic of the section it introduces"). Are we demarcating a section here? I don't really think we are. I think the <h4> (and any other <h#>) should be removed entirely.

Instead, what is the <h4>'s purpose here? I think it is being used to indicate to screen reader users that the pagination exists. That's cool, and in which case there are certainly ways we can achieve this.

My favourite option is to use <nav> (which is already being done) since pagination is indeed a way to navigate through the page content. Screen reader users are able to pull up the aria landmarks of a page, "scanning" the page. <nav> accurately reflects the nature of the role of pagination, as well as removes the risk of messing with the page hierarchy without context since this is a reusable component.

Note there's no such thing as role=pagination. With <nav>, built into that element is role=navigation.

Here's a good design pattern for an accessible pagination: https://www.a11ymatters.com/pattern/pagination/ According to this link, I recommend:

<nav aria-label="Pagination Navigation"> <!-- the combo of nav and aria-label give a clear signal to what the purpose of this component is -->
    <ul>
        <li><a href="/page-1" aria-label="Goto Page 1">1</a></li> <!-- use aria-label here for better UX for assistive tech -->
        <li><a href="/page-2" aria-label="Goto Page 2">2</a></li>
        <li><a href="/page-3" aria-label="Current Page, Page 3" aria-current="true">3</a></li> <!-- use JS to dynamically indicate which page is the current -->
    </ul>
</nav>

Hello! I had brought this issue up today in another project that provides a Drupal design system, so we could implement the same accessibility adjustment there, and conversation there reiterated Maia's suggestion in #15 above: that role="navigation" is built into the <nav> element by default, so including it is redundant. MDN supports that removal ("Using the <nav> element will automatically communicate a section has a role of navigation. Developers should always prefer using the correct semantic HTML element over using ARIA"), and ARIA's first rule is to not use ARIA in cases where semantic HTML alone does the trick. As such, I committed the removal of those role attributes to the existing merge request. Thanks!

Tagging for WCAG 2.4.6

Duplicate of: https://www.drupal.org/project/drupal/issues/3333401