Re: Landmarks without labels or no landmarks at all?

Hi Tobias

I agree that it is best practice in accessibility to provide an appropriate
name when there are multiple navigation regions on a page, but it is not
mandatory—it is however highly recommended.


This following is not based on personal opinion.  I have researched only
‘official’ specifications related information in finding a solution to the
problem you’re facing.


The HTML Living standard does not provide any reference the nav element
must or should be named. In fact the example with two nav regions are not
named.

https://html.spec.whatwg.org/multipage/sections.html#the-nav-element


The ARIA 1.2 Specification also does not use Must in navigation role. It is
not name required.

https://www.w3.org/TR/wai-aria-1.2/#navigation


The ARIA Landmark Example

https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/navigation.html

"If a page includes more than one navigation landmark, each should have a
unique label". Here again it is recommended as a best practice.


H97: Grouping related links using the nav element

https://www.w3.org/TR/WCAG20-TECHS/H97.html

When the nav element is employed more than once on a page, distinguish the
navigation groups by using an aria-label or aria-labelledby attribute.


The W3C Design System uses aria-label=Pagination on the pagination
component, which incidentally is wrapped in a named <nav>

https://design-system.w3.org/components/pagination.html

This is the only official documentation I can find that specifically calls
out must in the Considerations section.

"Where there are multiple<nav> elements on a single page, all must be given
a unique accessible name via aria-label."


To conclude from the above research aria-label="pagination" on the <nav>
wrapping the pagination should satisfy best practice for accessibility.


Regards

Laurence Lewis

Accessibility Senior Specialist - Telstra (Australia)



On Sun, 22 Sep 2024 at 2:13 AM, <a11ythinker@gmail.com> wrote:

> Here’s  a different screen reader user’s perspective …While I 100% agree
> with Steve and Sailesh that too many landmarks are super annoying and
> problematic, for this specific question, I strongly vote for using a nav
> landmark for your design system component.
>
>
>
> I generally advise avoiding nested landmarks and keeping the total in the
> range of 5 to 7. Pagination is one of the special cases where a nested
> landmark can be particularly useful because the placement of the pagination
> controls is often very difficult to locate and when you need it, you need
> very efficient access. Naming a list doesn’t provide efficient or easily
> discoverable access.
>
>
>
> So, If I had a choice between a page with N landmarks and a page with N+1
> where the additional landmark is for pagination, I want the site with the
> additional landmark. This true whether N is 0 or 15. And, if N is 50, the
> site is horrible anyway, and the extra 1 is not making it any worse.
>
>
>
> I know this preference well from frequent experience. There are a few web
> apps and sites I use regularly, one daily (GitHub), where the nav landmark
> around the pagination is a massive time-saver.
>
>
>
> Naming is critical. Ideally your design system would be built to have some
> required parameters so the component won’t even render without them.
> However, if that is not feasible, at least provide a default name and warn
> the developer if the default is being used. Basically, somehow make the
> name as close to required as possible and make sure there is a name. A name
> in the wrong language is better than nothing; it creates a means of
> distinguishing one nav region from another.
>
>
>
> I agree that “Pagination” is a somewhat technical term, but a component
> can’t know the thing being paginated. So, it might be an acceptable
> default. I’ve seen some sites name the pagination “Previous/Next page”,
> which is not horrible. It is wordy, which is kind of annoying, but for a
> default it is also tolerable. If you new the results were thing X, e.g.,
> products in a products search, a better name would be “Product search
> results”.
>
>
>
> Best,
>
> Matt
>
>
>
> *From:* Sailesh Panchang <sailesh.panchang@deque.com>
> *Sent:* Wednesday, September 18, 2024 8:15 AM
> *To:* Steve Green <steve.green@testpartners.co.uk>
> *Cc:* Tobias Bengfort <tobias.bengfort@posteo.de>; w3c-wai-ig@w3.org
> *Subject:* Re: Landmarks without labels or no landmarks at all?
>
>
>
> I strongly second Steve's recommendations.
> I understand Your question is specific to the navigation role. But it may
> not be place to mention the other issue I encounter not infrequently:
> A page has only navigation landmark or the navigation and footer landmark
> but nothing for the main content section. Once a user encounters a nav
> landmark, he/she thinks, "Oh Good I can use landmark navigation on this
> page", and comes up short if  a complete job of identifying all landmarks
> has not been done by the developer.
> Thanks
>
> Sailesh Panchang | +1 (571) 344-1765
> Technical Solutions Architect
>
>
>
> Email: sailesh.panchang@deque.com
>
> Deque Systems Inc | - Accessibility for Good | www.deque.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Sep 18, 2024 at 3:47 AM Steve Green <
> steve.green@testpartners.co.uk> wrote:
>
> If the <nav> element is retained, it must have an accessible name if the
> page contains other <nav> elements, which is very likely.
>
> While it's not necessarily wrong to use a <nav> element for pagination
> links, I don't recommend it. Landmarks are supposed to be used sparingly,
> for sections of the page that users are likely to want to navigate to. I
> regard pagination links as borderline in this respect.
>
> My main objection is the "noise" that screen reader users encounter.
> First, they hear about the landmark and its accessible name, then they hear
> about the list it encloses. I encounter this a lot during testing, and it
> always strikes me as overwhelming. Instead, I recommend putting the
> accessible name on the <ul> element, which results in a much better user
> experience.
>
> Also, the choice of accessible name is important. In most cases it is
> "Pagination", but that is jargon that a lot of people will not understand.
> Instead, I recommend something like "More search results" that is in
> language ordinary people will understand.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: Tobias Bengfort <tobias.bengfort@posteo.de>
> Sent: 18 September 2024 07:47
> To: w3c-wai-ig@w3.org
> Subject: Re: Landmarks without labels or no landmarks at all?
>
> Sorry, I forgot to include the link to the issue:
>
> https://github.com/zostera/django-bootstrap5/pull/686
>
> thanks,
> tobias
>
>
> On 18/09/2024 08.19, Tobias Bengfort wrote:
> > Hi everyone,
> >
> > I am using a library that uses a <nav> element without accessible
> > label for pagination. I am currently discussing with the maintainer
> > how to fix this. There are three proposals on the table:
> >
> > Either we remove the <nav> element and put the responsibility of
> > adding one with a proper label on the developers who use the library.
> > If they fail to do that, there will be no landmark.
> >
> > Or we add a parameter for the label. If developers do not provide that
> > parameter, there will be a landmark with an empty label.
> >
> > A third option is to provide a default value for the label. However,
> > it is out of scope for the project to provide localization. If
> > developers do not provide the parameter, the label might be in the wrong
> language.
> >
> > What do you think, which of these options is best?
> >
> > thanks,
> > tobias
>
>