ナビゲーション

Open the page, hit the landmarks key, and the assistive tech reads what your markup told it. If the markup says one thing twice, the user hears it twice. That is the small but real cost of an accessible name that restates the role it sits on — and a <nav> element labelled "Primary navigation" is the example almost every site ships with. CSS-Tricks ran a short link-post on June 12 from Geoff Graham, pointing at Mark Underhill's argument that the word "navigation" has no business being inside the accessible label on a <nav> . The argument is small. The habit it pushes back on is everywhere. Listen to what gets announced Per the CSS-Tricks summary, a <nav> labelled with aria-label="Primary navigation" is read out as "Navigation, Primary navigation." The first half comes from the landmark role itself. The second half comes from you. For a sighted user that string never surfaces. For a screen-reader user it is the thing they hear every time they land on the region. So the label is doing two jobs and only one of them is useful. The role announcement already tells the user this is a navigation region. The label is supposed to distinguish this navigation region from the others on the page — the footer set, the in-page table of contents, the breadcrumb. "Primary" does that. "Primary navigation" does that and then says "navigation" again, for no one. The fix is not subtle: <nav aria-label= "Primary" > <!-- links --> </nav> That is it. One word, doing the disambiguating work, sitting next to a role the platform is already announcing for free. The principle generalises The source extends the same idea to alt text, and it is worth carrying across because it is the same shape of bug. An <img> is announced as an image. Writing alt="Image of a red bicycle" tells the user "image, image of a red bicycle." The word "image" inside the alt value is restating the role of the element it lives on. The corrected version is the obvious one: <img src= "bike.jpg" alt= "A red bicycle leaning against a brick wall" > The image-ness comes from the element. The alt value describes what the image shows. Two different jobs, two different places to do them, no overlap. You can apply the same test wherever you write an accessible name. If the role of the element already announces a noun — navigation, image, button, list — that noun does not need to appear inside the name you write. The name is for the thing only you know: which navigation, which image, which button. Why this keeps happening The habit usually comes from a good instinct. Authors want to be explicit. They want the label to read cleanly when they say it out loud in a design review. "Primary navigation" sounds more complete than "Primary." It is the kind of small extra word that feels respectful, the way you might write "click the Submit button" in instructions. But the audience for an accessible name is not a sighted reviewer reading the attribute. It is a person hearing the role and the name back-to-back. "Complete" sentences in that channel become repetition. Graham closes the link-post with the related guidance that accessible text should be kept succinct — per the source, "it doesn't have to be a novel." That instruction is doing more work than it looks like. Once you start listening for the doubled role-name, you start noticing it everywhere — the <nav aria-label="Main navigation"> , the alt="Picture of..." , the <button> with a title="... button" . None of these are catastrophic. All of them are friction you can remove with a five-character edit. What to actually do The judgement is straightforward. The role announcement is the platform's job. The accessible name is your job. Keep them separate. Take this to your next pass over the markup: Audit every aria-label and aria-labelledby on a <nav> . If the value contains the word "navigation," drop it. Keep only the disambiguating word — "Primary," "Footer," "Breadcrumb," "Table of contents." Audit alt values for "image of," "picture of," "photo of," and "graphic of." Cut the lead-in; keep the description. When you write an accessible name for any element, say it out loud after the element's role. If you hear the role word twice, the name is doing the wrong job. Keep names short. The source's closing line is the standard: succinct, not a novel. The platform is already telling the user what kind of region they have landed on. Your job is to tell them which one. Anything more is noise, and noise is something a screen-reader user cannot scroll past. Open the page, hit the landmarks key, and the assistive tech reads what your markup told it. If the markup says one thing twice, the user hears it twice. That is the small but real cost of an accessible name that restates the role it sits on — and a <nav> element labelled "Primary navigation" is the example almost every site ships with. CSS-Tricks ran a short link-post on June 12 from Geoff Graham, pointing at Mark Underhill's argument that the word "navigation" has no business being inside the accessible label on a <nav> . The argument is small. The habit it pushes back on is everywhere. Listen to what gets announced Per the CSS-Tricks summary, a <nav> labelled with aria-label="Primary navigation" is read out as "Navigation, Primary navigation." The first half comes from the landmark role itself. The second half comes from you. For a sighted user that string never surfaces. For a screen-reader user it is the thing they hear every time they land on the region. So the label is doing two jobs and only one of them is useful. The role announcement already tells the user this is a navigation region. The label is supposed to distinguish this navigation region from the others on the page — the footer set, the in-page table of contents, the breadcrumb. "Primary" does that. "Primary navigation" does that and then says "navigation" again, for no one. The fix is not subtle: <nav aria-label= "Primary" > <!-- links --> </nav> That is it. One word, doing the disambiguating work, sitting next to a role the platform is already announcing for free. The principle generalises The source extends the same idea to alt text, and it is worth carrying across because it is the same shape of bug. An <img> is announced as an image. Writing alt="Image of a red bicycle" tells the user "image, image of a red bicycle." The word "image" inside the alt value is restating the role of the element it lives on. The corrected version is the obvious one: <img src= "bike.jpg" alt= "A red bicycle leaning against a brick wall" > The image-ness comes from the element. The alt value describes what the image shows. Two different jobs, two different places to do them, no overlap. You can apply the same test wherever you write an accessible name. If the role of the element already announces a noun — navigation, image, button, list — that noun does not need to appear inside the name you write. The name is for the thing only you know: which navigation, which image, which button. Why this keeps happening The habit usually comes from a good instinct. Authors want to be explicit. They want the label to read cleanly when they say it out loud in a design review. "Primary navigation" sounds more complete than "Primary." It is the kind of small extra word that feels respectful, the way you might write "click the Submit button" in instructions. But the audience for an accessible name is not a sighted reviewer reading the attribute. It is a person hearing the role and the name back-to-back. "Complete" sentences in that channel become repetition. Graham closes the link-post with the related guidance that accessible text should be kept succinct — per the source, "it doesn't have to be a novel." That instruction is doing more work than it looks like. Once you start listening for the doubled role-name, you start noticing it everywhere — the <nav aria-label="Main navigation"> , the alt="Picture of..." , the <button> with a title="... button" . None of these are catastrophic. All of them are friction you can remove with a five-character edit. What to actually do The judgement is straightforward. The role announcement is the platform's job. The accessible name is your job. Keep them separate. Take this to your next pass over the markup: Audit every aria-label and aria-labelledby on a <nav> . If the value contains the word "navigation," drop it. Keep only the disambiguating word — "Primary," "Footer," "Breadcrumb," "Table of contents." Audit alt values for "image of," "picture of," "photo of," and "graphic of." Cut the lead-in; keep the description. When you write an accessible name for any element, say it out loud after the element's role. If you hear the role word twice, the name is doing the wrong job. Keep names short. The source's closing line is the standard: succinct, not a novel. The platform is already telling the user what kind of region they have landed on. Your job is to tell them which one. Anything more is noise, and noise is something a screen-reader user cannot scroll past.