Maybe Don’t Name That Landmark
TL;DR: You probably don’t need to name that landmark.
Approach
The following landmarks should appear only once per page (otherwise they may not work quite as you expect):
You shouldn’t give them accessible names. The context and uniquity (uniqueness?) are sufficient.
For the remainder of landmarks, probably don’t give them an accessible name unless users have said it’s valuable to them.
If you give those regions an accessible name anyway, understand that using aria-label introduces localization risk.
Some elements aren’t landmarks until you give them an accessible name (same with their roles). In that case, you should consider if it warrants being a landmark or is instead adding noise. My experience says that once you get past 5 or 6 landmarks, they are adding noise. This is for generic users on generic sites, so trained users on familiar pages may rely on many landmarks for a page (which would be confirmed by those users).
Example
A <nav> / navigation on its own needs no accessible name. Stuffed in a <header>, it still needs none. Add a second <nav>, but in the <footer>, no name needed. The context is clear.
Once put two instances of a landmark in the same “scope” (within the same landmark or absence of landmark), then you might want to name at least one of them. If you have a <nav> in the <header> and also another <nav> in the same <header>, probably give at least one of them a brief name.
Real Example
Over on hell-site, Ashlee Boyer let Vercel know its navigation had a curious accessible name (don’t judge Ashlee, Vercel chooses to stay there so that was her avenue to let them know):
<nav
aria-label="Navigation header with 5 links and 1 dropdown menu with links">
There are three menus and two links, so this was a lie. It was verbose. It used lingo (“dropdown“). It was also completely unnecessary since there is only one other navigation region on the page — in the <footer>:
<nav
aria-label="Vercel Directory"
role="navigation">
The redundant and unnecessary navigation role is a nice touch.
Anyway, I used past tense for some of the example because Vercel promptly deployed an update to its primary navigation:
<nav
aria-label="Main">
I would not have let that out the door, but as Léonie has said for at least a decade, It doesn’t have to be perfect, it just has to be a little bit better than yesterday.
I have no idea if that first cut was from Vercel’s production-ready v0 LLM, but for the sake of some human who might otherwise be embarrassed, I hope so.
aria-label is along with its inaccuracy. All I did was Tab to the first navigation item. The first two seconds of this video is a Captain Picard facepalm because the logo is a link with aria-expanded (which eats right-clicks in order to work).Related
- Not so short note on aria-label usage – Big Table Edition by Steve Faulkner
- My Priority of Methods for Labeling a Control by me
- ARIA `note` by me
3 Comments
Reply I really like this strategy of not applying more naming than is necessary to communicate a region. It keeps things clean and easy to navigate. But I wasn’t so sure about this part:
“A
<nav>/ navigation on its own needs no accessible name. Stuffed in a<header>, it still needs none. Add a second<nav>, but in the<footer>, no name needed. The context is clear.”Is the context clear? If a screen reader user is using something like VoiceOver’s Landmarks router to select a region, they will just have a list of regions, they won’t know one
<nav>is in the<header>and one is in the<footer>.ARIA APG recommends that two of the same landmark regions that live on the same page get unique names if they provide unique functions:
“If a specific landmark role is used more than once on a page, provide each instance of that landmark with a unique label.”
I’d really appreciate hearing your thoughts on this, and whether I’m overlooking something in regards to how screen reader users use landmark regions to navigate.
In response to . Reply If a screen reader user is navigating the page by landmark, then they are getting each landmark in sequence. Essentially the rotor exposes a serialized set of landmarks.
They would move past the header landmark and then to the navigation landmark (whether or not it’s nested) and then past the main landmark, and then past the footer landmark and, if there’s a navigation landmark within, they’ll get the context that the navigation landmark is at least adjacent if not nested.
As it is, when using VoiceOver on iPadOS to navigate by landmark, the landmark and its name are exposed only after announcing the first piece of content. When using the landmark list in NVDA, it shows the nesting. The point is, each experience and expectation will be a bit different and we can generally trust users to sort it out from context clues.
In response to . Reply I see, thanks for the reply, I appreciate it!
Leave a Comment or Response