Testing Accessible Names on Header Icon Buttons
Search, account, cart, and menu live in the header as icons. If those buttons have no accessible name, screen reader users get a row of identical buttons at the top of every page.
Four icons sit in almost every store header: menu, search, account, cart. Sighted shoppers read the shapes. A screen reader reads the accessible name of each button, and on a lot of stores that name is missing, duplicated, or just the word button, repeated four times at the start of every single page.
WCAG 4.1.2, name role value, is the criterion, and it is Level A. This is basic plumbing. It is also a good test of whether a store has ever listened to its own header, because the fault is obvious within ten seconds of turning a screen reader on.
What a good name looks like
The name should say what the button does, in the words a shopper would use: search, account, cart, menu. Where the cart has a count, including the count in the announcement helps, cart, three items, because that number is information sighted shoppers get at a glance and screen reader users otherwise have to go and find.
Avoid names that describe the picture instead of the action. Magnifying glass, person, and basket are descriptions of icons. Search, sign in, and your cart are descriptions of jobs. A shopper choosing from a list of buttons needs the job. Also keep the visible label and the accessible name consistent where there is visible text, which 2.5.3, label in name, requires for voice control users who speak what they see.
Where names get lost
SVG icons are a common culprit. An inline SVG inside a button with no title and no aria-hidden treatment can leave the button with no name at all, or worse, the file name of the graphic. Icon fonts do a similar thing when the font fails to load or the character is announced as a private use code point.
Theme updates and app injections lose names too. A search app replaces the header search button with its own, tested visually and shipped. A cart drawer app does the same at the other end of the header. The header is shared by every template, so one bad component repeats the failure across the whole store at once.
Test it the way it will be heard
Turn on a screen reader, go to the home page, and navigate by button. Write down the names in order. Then do the same on a product page and in the cart. If the list reads button, button, search, button, you have the finding, with the page and the component named.
Fix names in the shared header component, once, and check the mobile header separately. Mobile headers are often a second implementation with its own icons, its own search toggle, and its own set of missing names. Passing on desktop says nothing about the layout most of your traffic actually uses.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Testing Target Size: The Small Buttons That Block Mobile Checkout, ADA Risk in Accordion and FAQ Sections: Content Screen Readers Cannot Reach, and Testing Screen Reader Order on Product Bundles and Kits.
Frequently asked questions
What makes a good accessible name for an icon button?
A short name describing the action: search, account, cart, menu. It should match any visible text so voice control users can activate it by speaking what they see, which WCAG 2.5.3 covers.
Why do icon buttons end up with no name?
Usually because the icon is an inline SVG or icon font with no text alternative and the button itself has no label. The button element exists, but nothing gives it a name, so a screen reader announces only its role.
Should the cart button announce the item count?
It is good practice. The count is visible information, so including it in the name, such as cart, three items, gives screen reader users the same at a glance fact without a trip to the cart page.
How often should header buttons be tested?
After any header, theme, search, or cart change, and on both desktop and mobile layouts. The header repeats on every page, so a regression there is a site wide failure from one component.