RE: Landmarks without labels or no landmarks at all?

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

Received on Wednesday, 18 September 2024 07:44:19 UTC