- From: <a11ythinker@gmail.com>
- Date: Sat, 21 Sep 2024 09:08:16 -0700
- To: "'Sailesh Panchang'" <sailesh.panchang@deque.com>, "'Steve Green'" <steve.green@testpartners.co.uk>
- Cc: "'Tobias Bengfort'" <tobias.bengfort@posteo.de>, <w3c-wai-ig@w3.org>
- Message-ID: <098c01db0c40$7890fe10$69b2fa30$@gmail.com>
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 <mailto:sailesh.panchang@deque.com> Deque Systems Inc | - Accessibility for Good | www.deque.com <http://www.deque.com> On Wed, Sep 18, 2024 at 3:47 AM Steve Green <steve.green@testpartners.co.uk <mailto: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 <mailto:tobias.bengfort@posteo.de> > Sent: 18 September 2024 07:47 To: w3c-wai-ig@w3.org <mailto: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 Saturday, 21 September 2024 16:08:23 UTC