Testing Accessible Names on Header Icons: Search, Account, and Cart
Three icons sit in every store header and they are announced badly more often than any other controls on the site. How to test what a screen reader actually says, and how to include the cart count.
Say what your header controls are called. Not what they look like: what they are named. Search is a magnifying glass, account is an outline of a person, and cart is a bag with a number on it. For a screen reader those are three separate implementation choices, and stores ship every possible version: a button named search, a link with no name at all, an SVG with a title element that some browsers expose and others ignore, and a cart link announced as the number 3 because the count badge is the only text inside it.
Criterion 4.1.2 Name Role Value and 2.4.4 Link Purpose both turn on that name. Testing it takes five minutes with a screen reader or an accessibility inspector, and it is one of the highest value checks on the site because these controls appear on every page and start every task.
How to hear the name you shipped
Use the accessibility tree in your browser developer tools first. Select the control and read its computed name and role. That tells you what is exposed without needing a screen reader, and it quickly shows a name coming from an unexpected place, such as a tooltip or an aria-label on a child element that never reaches the control. Then confirm with one real screen reader, because tools and assistive technology do not always agree on SVG titles.
Test each state. Search often expands into a field, which changes the control from a button into a searchbox with its own label requirement and a submit or close control. Account may be a link when logged out and a menu button when logged in. Cart changes with items in it. A name that is fine in one state can vanish in another, particularly when a theme swaps the icon at login.
The cart count problem
A number badge is information. If it is visual only, a screen reader user hears cart and gets no count, which is a minor gap. Worse patterns exist: the count read as part of the name with no context, so the link is announced as 3, or the count read twice because it is in the name and in a hidden text node. Aim for a name such as cart, 3 items, built from a visually hidden text span inside the link, and mark the decorative badge itself aria-hidden so it is not announced separately.
When the cart updates without a page load, after an add to bag from a listing, the count changes silently. A polite live region announcing item added, or updating the cart link name, closes that loop. Without it a screen reader user may add the same product twice because nothing confirmed the first addition.
Names across languages and themes
Stores with multiple language storefronts often translate link text and leave aria-labels in the original language, so a French storefront announces search in English. Put accessible names through the same translation process as visible text, and check them after a locale is added. Icon only controls are where untranslated strings hide, because there is no visible text to catch a reviewer's eye.
After a theme change, re-run this check before anything else. Header markup is rewritten in redesigns, names are lost when an icon library is swapped, and the regression reaches every page at once. It is a small test with a site wide blast radius, which is exactly why it belongs at the top of the release checklist.
Related reading: ADA Risk in Embedded Size Charts, Fit Guides, and Care PDFs, Testing Contrast in Sale Countdown Timers and Urgency Badges, Testing Target Size: The Small Buttons That Block Mobile Checkout.
Frequently asked questions
Is an SVG title enough as an accessible name?
It is unreliable on its own. Support for exposing an SVG title as a name varies, and if the SVG sits inside a link or button, the name should be provided on that control, with the SVG marked aria-hidden so the graphic is not announced twice or instead of the control.
What should the cart link be called?
Something that includes the purpose and, ideally, the count: cart, 3 items. Avoid a name that is only a number, and avoid repeating the count in two places. One clear name, updated when the cart changes, is what a shopper needs.
Do icon buttons need visible text labels?
WCAG does not require visible text next to familiar icons, but a visible label helps many users, including people with cognitive disabilities, and it removes ambiguity for icons a store invented. If you keep icons alone, their accessible names become even more important, not less.
How do I check names without a screen reader?
Start with the accessibility panel in browser developer tools, which shows the computed name and role for a selected element. That catches most missing names. Then do at least one pass with a free screen reader such as NVDA or VoiceOver, because real behaviour is the standard that matters.