Should a cookie banner move keyboard focus on load?

It should be reachable early and predictably. Whether it takes focus automatically depends on whether it blocks the page. If it blocks interaction, focus belongs inside it until the shopper chooses, and then it must be released.

Is a reject button required in the first layer?

For a fair choice, yes in practice. Hiding reject inside preferences while accept sits in the first layer draws criticism from privacy regulators and makes the keyboard path far longer for refusal than for acceptance.

How often should banner accessibility be checked?

After every consent platform or theme change, and on a regular monthly pass. Vendor updates ship independently of your release calendar, so a check tied only to your own deploys will miss them.

Can an automated scan verify banner focus behaviour?

No. Scans catch missing names and contrast. Focus order, traps, and focus return need a manual keyboard pass. That is why monitoring programmes pair the scan with a short scripted manual check.

Monitoring Button Names After Every App Install

October 31, 2026

New apps bring new buttons: wishlist hearts, quick buy, chat launchers, often with no accessible name at all. Monitoring button names as part of the install check.

Every app install adds interface, and most of what it adds is buttons. A heart on every product card, a quick buy control, a floating launcher in the corner. Sighted shoppers get an icon and a guess. A screen reader user gets the accessible name, and for app injected buttons that name is missing often enough that checking should be routine, not a discovery made by a customer.

WCAG 4.1.2 is the criterion and it does not care whose code the button is. A store page with a row of controls announced as button, button, button has a defect on that page, and monitoring exists to catch defects at the moment they arrive, which for app buttons is the install, not the next audit.

What to listen for on install day

On the day an app goes live, run the affected templates with a screen reader and navigate by button. Product cards for a wishlist app, the product page for quick buy, every page for a floating launcher. Write down the names exactly as announced. Add to wishlist, product name, is a good name. Button is not a name. A file name or a string of code is worse, because it sounds like the site is broken, which from the shoppers seat it is.

Check the state as well as the name. A toggle button, wishlist, follow, subscribe, should announce whether it is pressed, using aria-pressed or an equivalent, and that state should change when used. A heart that fills in visually and says nothing has told keyboard and screen reader users half a story.

Why this belongs in monitoring, not audits

Apps update themselves. The button that was labelled at install can lose its name in a vendor update three months later, and no one in the store changed anything, so no one tests anything. That is the exact shape of problem monitoring is for: a scheduled, short check on a defined list of controls, compared against last months notes.

Keep the list short enough to survive. The ten or so app injected controls a store actually has, checked monthly by button navigation on two templates, is a fifteen minute job. A perfect inventory of every control on the site is a project that gets abandoned by February. Monitoring that happens beats monitoring that was well designed.

Push the finding back to the vendor, with evidence

When a name is missing, report it to the app vendor with the exact announcement, the page, and the criterion. Vendors fix named defects with recordings attached far more often than they fix a general request to be more accessible. Your monitoring notes are the evidence, dated, which is why writing down the exact wording matters.

If the vendor will not fix it, that is a procurement fact. Record it against the app at renewal time. Stores renew apps that quietly tax their disabled customers because the cost never appears in one place. A monitoring log makes it appear, month after month, in the stores own handwriting.

Frequently asked questions

What makes a good accessible name for an app button?

A short name describing the action and, where it matters, the item it acts on: add to wishlist with the product name, for example. Icon only buttons still need that name in code even though nothing shows on screen.

How should toggle buttons like wishlist hearts announce state?

They should expose whether they are pressed, usually with aria-pressed, and update it when used. A visual colour change alone tells screen reader users nothing about whether the item was saved.

How often should app buttons be checked?

At install, and monthly after that, because vendors update apps without notice. A short scheduled check by button navigation on the main affected templates catches silent regressions.

What should we send a vendor when a button has no name?

The exact screen reader announcement, the page and template, the date, and the WCAG criterion, 4.1.2. Specific evidence gets fixed. General complaints about accessibility get filed.