Common Web Accessibility Mistakes and Why Big Brands Are No Excuse

Most common web accessibility mistakes come from a small set of habits, such as building buttons out of generic div elements, choosing colour contrast that only works on one background and treating WCAG as a final check rather than a design input. Priority Pixels delivers website accessibility services for public sector organisations and B2B companies to WCAG 2.2 AA and the issues below are among the most frequent reasons a website falls short of that standard.

The subject has a fresh edge because of design choices made by the largest technology companies. Apple introduced its translucent Liquid Glass design in June 2025. In September 2026 it released iOS 27 with a slider that lets people adjust Liquid Glass from ultraclear to fully tinted. Apple’s own iOS 27 page says the updates deliver exceptional readability with more uniform refraction and improved contrast. When even the company that set the trend has refined it for readability, it is clear the accessibility rules were never flexible. For organisations publishing websites in the UK the legal position settles the question.

Why a Big Brand Getting It Wrong Is No Excuse

A large company shipping a design that looks hard to read does not change what UK law expects of your website. Under section 20 of the Equality Act 2010, service providers have a duty to make reasonable adjustments for disabled people. Where that duty relates to information, the reasonable steps include providing the information in an accessible format.

Public sector bodies face a more specific test set by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. GOV.UK guidance on accessibility requirements for public sector bodies says a website meets the legal requirements if it meets WCAG 2.2 AA and publishes an accessibility statement. It also says a body stays legally responsible even when a supplier builds or runs the website and notes that at least 1 in 5 people in the UK have a long term illness, impairment or disability.

Operating system makers are also judged differently from the organisations that publish on the web. WCAG was written for web content, so a council, NHS trust or B2B supplier that copies a glass effect onto its website is measured against WCAG 2.2 AA directly. Buyers notice too, since public sector and large enterprise procurement teams often ask suppliers for accessibility statements and WCAG evidence and that scrutiny applies with particular force to public sector websites.

The WCAG Failures That Appear Most Often

The most common WCAG failures are low contrast text, missing alternative text, missing form labels, empty links and empty buttons. The WebAIM Million 2026 report, which tests the home pages of the top one million websites, found detected WCAG 2 failures on 95.9% of home pages and an average of 56.1 errors per page, up 10.1% on 2025. Home pages using ARIA averaged 59.1 errors against 42 for pages without it and the average number of role=”button” attributes per page rose from 3.6 to 4.8 in a year.

Every one of those categories can be caught before launch. Low contrast is a design decision, missing labels and empty buttons are development decisions and missing alternative text is usually a content decision. Accessibility therefore has to sit with all three disciplines rather than with one person at the end of a project.

The Government Digital Service lists the same themes in its own guidance on avoidable mistakes, alongside keyboard traps, skipped heading levels and pop-ups that do not manage focus. None of these problems is new or obscure, which is exactly why they are hard to defend when a complaint or an audit finds them.

Why Divs Should Not Be Turned Into Buttons

A div should not be used as a button because it carries none of the behaviour a native button element provides by default. MDN’s reference for the ARIA button role explains that adding role=”button” tells a screen reader the element is a button but does not provide click events or keyboard handling. On a native button the click event fires for mouse clicks and for the Space or Enter keys, while on any other element it only fires on a mouse click, even with the role added.

That gap is why the W3C’s first rule of ARIA use says that if a native HTML element already has the semantics and behaviour you need, you should use it instead of repurposing another element and adding ARIA. The note is blunt about buttons in particular, saying it is much better and easier to just use a native HTML button. Using script to turn a div into a control without a role is listed as failure F59 under WCAG success criterion 4.1.2 Name, Role, Value.

The difference shows up clearly in markup. The first line below needs a role, a tab index and custom keyboard scripting before it behaves like a button, while the second line does all of that natively.

<div class="btn" role="button" tabindex="0">Download the report</div>

<button type="button" class="btn">Download the report</button>

Recreating a button by hand means matching every behaviour the W3C button pattern describes, including activation with both Space and Enter and moving focus sensibly once the action completes. It is easy to get the mouse behaviour right and miss one of the others, which is how keyboard and screen reader users end up with controls they can see but cannot operate.

Styling is the reason most often given for reaching for a div. Native buttons can be reset and restyled to match almost any design system and the W3C treats visual design constraints only as a narrow exception where an element cannot be styled as required.

The same principle applies well beyond buttons. Links that behave like buttons, custom dropdowns built from lists and tabs assembled from spans all ask the developer to rebuild behaviour that HTML already offers.

Component libraries and themes can spread one bad pattern across hundreds of pages. Fixing the component once in the codebase is far cheaper than chasing the same failure page by page after launch.

Glass Effects, Transparency and Colour Contrast

Translucent and glass style interfaces put contrast at risk because the colour behind the text keeps changing. A label that passes over a plain white panel can fail as soon as a photograph or a busy section of the page scrolls underneath it, so a single contrast check in a static design file proves very little.

WCAG 2.2 sets thresholds that apply whatever the visual style. The Government Digital Service post on 10 digital accessibility mistakes to avoid points to a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text under success criterion 1.4.3. It also advises using semantic elements such as button, nav and form wherever possible, which links the contrast problem and the div problem back to the same root cause.

Controls carry their own requirement. The W3C explanation of non-text contrast requires a ratio of at least 3:1 for the visual information needed to identify user interface components and their states. A focus indicator still needs sufficient contrast even when a button has no visible border.

Testing glass effects means checking the most difficult realistic background rather than the easiest one. Text and controls should be checked over the busiest imagery the page can show and a more opaque layer behind text keeps contrast stable whatever scrolls underneath.

The same reasoning applies to blur, motion and layered effects borrowed from app interfaces. Effects that look polished in a launch video need checking against WCAG 2.2 AA in the browser with real content before they reach a live website.

Building Accessibility Into Design and Development

Accessibility works most reliably when it is planned from the first wireframe rather than patched after launch. Priority Pixels designs and develops every WordPress website to WCAG 2.2 AA as a minimum. Our WordPress development is custom coded without page builders or templates, with screen reader, keyboard and automated testing carried out throughout the build.

Premade themes are a frequent source of trouble because their barriers run deep into the code structure. Overlay widgets cannot resolve problems at that level and often make them worse, so the fix has to happen in the templates and components themselves.

Automated tools catch a meaningful share of issues, but they cannot judge whether a custom control makes sense to someone using a screen reader. Our accessibility testing tools comparison sets out where browser extensions, automated platforms and manual testing each fit.

Keyboard testing costs nothing and finds a surprising number of the problems covered above. Tabbing through a page without a mouse quickly shows whether every control can be reached, whether focus is visible and whether anything traps the user.

What a Web Accessibility Audit Should Tell You

A useful accessibility audit tells you which barriers exist, how serious each one is and what it will take to fix them. As a web accessibility agency, our team combines manual review against WCAG 2.2 AA across critical user journeys with automated scans using axe-core and WAVE. Every issue is then ranked by severity in a prioritised remediation roadmap with effort estimates.

For public sector bodies the audit also feeds the accessibility statement the regulations require. Our guide on how to write an accessibility statement explains how audit findings map to the GOV.UK model statement. It also shows why partial compliance with a clear plan is a more credible position than an unsupported claim of full compliance.

Large technology companies will keep shipping new visual styles and some will test better than others. Your obligations do not move with them and a website built on native HTML, tested against real backgrounds and checked with a keyboard and screen reader will meet WCAG 2.2 AA far more reliably than one that copies the latest interface trend.