Not sure which size to choose? See the size guide
``` `target="_blank"` makes the browser open the guide in a new tab, and the link's name is "See the size guide", with nothing to say where it will open. The person learns about the new tab only after it has opened, if at all. ## Before: an icon with no name ```htmlNot sure which size to choose? See the size guide
``` The icon is there for people who see it and know it, but `aria-hidden="true"` takes it out of the link's name, so a screen reader still hears "See the size guide, link". For everyone else, the warning is only as good as their knowledge of the icon. ## After: open the guide in the same tab ```htmlNot sure which size to choose? See the size guide
``` Without `target`, the guide opens in the same tab, and Back returns to the shirt, with the page as it was. People who want the guide beside the shirt can still open it in a new tab themselves, with a middle click, Ctrl or Command and a click, the context menu, or a long press on a phone. Nothing changes that the link didn't ask for, so there is nothing to warn about. ## After: say so in the link's words ```htmlNot sure which size to choose? See the size guide (opens in a new tab)
``` This is technique H83. The words are on screen and in the link's name, so everyone reads or hears them before they follow the link: "See the size guide (opens in a new tab), link". They come after the visible words the link starts with, so the name still begins with what people see, which is what someone using voice control will say. ## After: give the icon a name ```htmlNot sure which size to choose? See the size guide
``` The design keeps its icon, and the icon now has a name, which becomes part of the link's name, so a screen reader hears "See the size guide (opens in a new tab), link". This passes for anyone who hears or reads the link's name. People who see the page only see the icon, so they are warned only if they know what an arrow leaving a box means; many people, including many with cognitive disabilities, don't. ## Which option to use All three pass 3.2.5. Open the guide in the same tab: it is the only option that keeps Back working in every browser, it needs no words, and people who want a new tab can still open one. Keep a new tab only when the page would lose something without it, such as help opened beside a form that is half filled in, and then put the warning in the link's words, where everyone sees and hears it. Name the icon when the design has one and the words can't be shown; it warns screen reader users but leaves people who don't know the icon guessing. ## Implementation decisions Where several links open new tabs, a line before them, such as "The links below open in a new tab", saves repeating the words on each, as GOV.UK suggests; add the warning to each link's name too, in hidden text, since a screen reader user who jumps from link to link never hears that line. Don't put the warning in a `title` attribute. Browsers show it as a tooltip under a mouse, and most show nothing for a keyboard or a touch screen, and screen readers don't read it reliably. A warning in `aria-describedby` alone, as one of G201's examples has it, reaches screen reader users only, and some screen reader settings don't read descriptions; technique H83 puts the warning in the link text, which everyone gets. Keep the visible words at the start of the name, as above, so the name still begins with the label people see; see [buttons and links named differently from their text](/learn/label-in-name). Every way of opening a new window needs the same warning: a `target` with any other name, such as `target="help"`, and a script that calls `window.open()`. A form that would lose what people typed if they left it is better fixed by keeping what they typed, so that its help can open in the same tab, than by opening the help in a new one. ## Verify the fix 1. Follow every link on the page, and note each one that opens a new tab or window, whether by `target` or by script. 2. With a screen reader, move to each of those links and confirm the warning is heard as part of its name, before you follow it. 3. Where an icon marks the link, confirm it has a name that says it opens a new tab, or that the words are in the link's text. 4. With a screen magnifier, and on a phone, follow each such link and confirm you can find your way back to the page you were on; for each one, ask whether it needs a new tab at all. Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the page's links or the content system that writes them change. ## Limits This is a starting pattern, not a guarantee for every page. It covers links that open new tabs; a link that opens a PDF or downloads a file should also say so, with the file's type and size, and the document itself has to be accessible; see [scanned and untagged PDFs that screen readers can't read](/learn/accessible-pdfs). Whether a link's words say where it goes is a separate failure; see [banner and image links with no name](/learn/empty-links). Windows that open with no link pressed at all, such as on page load, fail the same criterion in another way. Test with the screen readers, magnifiers and phones your visitors use. --- Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)