Every so often a piece of engineering work quietly becomes load-bearing for the whole industry, and accessibility is having exactly that moment. It's not new — WCAG has existed in some form since 1999 — but the conversation around it has changed. What used to be treated as a nice-to-have, tackled if there was time left at the end of a sprint, is increasingly treated as a baseline requirement, in the same category as "the site should work on mobile" or "the checkout should not lose people's baskets."
We wanted to write about why, what the practical risks are, and — more usefully — what we actually watch for when we're building.
The people first, the law second.
It's tempting to lead with legal risk because it's the thing that gets budget approved. But it's worth being honest that the actual reason to care comes first: a meaningful number of the people visiting any website have some kind of access need, whether permanent, temporary, or situational.
That covers a lot more ground than people sometimes assume. Screen reader users navigating by heading structure rather than visual layout. People with motor impairments who can't use a mouse and rely entirely on a keyboard or switch device. Users with low vision who rely on zoom, high contrast, or reflow. People with cognitive or attention differences who need consistent navigation and plain language. And then there's the situational and temporary end of the spectrum — a broken arm, a screen in bright sunlight, a crying toddler making full concentration impossible, a slow connection dropping images. Accessible design tends to make things better for all of these groups simultaneously, which is part of why it's such good value as an investment: you're rarely building for a narrow edge case, you're building for resilience.
The legal landscape is genuinely shifting.
That said — the legal picture matters too, and it's worth understanding in outline, even if you're not a lawyer (we're not either, and this isn't legal advice).
Several territories are actively legislating or tightening enforcement of digital accessibility requirements at the moment. The EU has had accessibility legislation in force for a while now, but the compliance deadline landed in mid-2025, and the year since has been the first real period of active enforcement — audits, information requests, and regulatory scrutiny rather than a distant future obligation. It applies broadly, and notably it isn't limited to companies based in the EU: it extends to any business selling goods or services to EU consumers, regardless of where they're headquartered, which catches a lot of UK studios and their clients by surprise.
The UK has its own long-standing framework, primarily through equality legislation that has been interpreted to extend to websites and digital services, alongside specific accessibility regulations for the public sector.
It's not only Europe, either. In the US, there's no single federal law written specifically for website accessibility, but a steady stream of lawsuits under existing disability rights legislation has made accessibility a live legal risk for years, with case numbers still climbing rather than settling down. It's a different enforcement mechanism to the EU's — driven by litigation rather than a specific digital regulation — but the practical effect for anyone building a website used by the public is much the same.
We're deliberately not going to go deep into specific clauses, case law, or how each jurisdiction differs — partly because it moves fast enough that a blog post is the wrong place to keep it current, and partly because we're developers, not solicitors. If you want the detail, the European Commission's own page on the European Accessibility Act and the UK government's guidance on accessibility requirements are both good starting points, and we'd always recommend proper legal advice if you need to know exactly where you stand. What's useful to take away at a glance is simply this: this is an active, moving area of law in multiple territories our clients trade in, not a settled one, and "we'll deal with it eventually" is a riskier position than it used to be.
What we actually watch for on projects.
This is where we spend most of our time, and it's more interesting than the law anyway. A non-exhaustive list of things that come up again and again:
Semantic HTML gets stripped out by good intentions.
Modern component-driven frontend work makes it very easy to build everything out of divs and spans with click handlers bolted on, because the framework doesn't stop you. The result looks fine and works terribly for anyone not using a mouse. Buttons should be <button>. Links should be <a>. Headings should be structured in order, not chosen for font size.
Focus states disappear in the name of aesthetics.
A CSS reset or a "clean up the outline" pass removes outline:none somewhere and nobody puts a visible focus style back. If you can't see where keyboard focus is, keyboard navigation is functionally broken, even though nothing "crashed."
Modals and overlays trap or lose focus incorrectly.
A well-behaved modal moves focus into itself, keeps it there while open (a "focus trap"), and returns it to a sensible place on close. Getting this wrong is one of the most common failures we see, and one of the easiest to miss in testing if you're only using a mouse.
Contrast fails on brand colours.
Brand palettes are often chosen for print, marketing, and vibe, not necessarily for contrast ratios against body text or interactive states. It's a conversation worth having early with clients and their brand teams — usually a small adjustment fixes it without compromising the identity.
Forms don't announce errors properly.
Visually, a red border and a message above or below the field might be perfectly clear. To a screen reader user, if that error isn't programmatically associated with the field and announced when it appears, it may as well not exist.
Motion and autoplay ignore reduced-motion preferences.
Parallax, autoplaying video, and animated transitions can range from mildly annoying to actively harmful for people with vestibular disorders. Respecting prefers-reduced-motion costs very little and matters more than it looks like it should.
Where headless and JAMstack builds specifically catch people out.
Given a lot of our own work is headless commerce and custom-built frontends, it's worth calling out the failure modes that are specific to that architecture, because they're easy to miss if your accessibility knowledge comes from more traditional server-rendered sites.
Client-side routing is the big one: when a page "changes" without a full browser navigation, screen readers don't automatically announce the new page title or move focus anywhere sensible, unless you build that behaviour in deliberately. Dynamically injected content — a cart drawer appearing, search results updating live — needs ARIA live regions or equivalent handling, or it simply goes unnoticed by assistive technology. Rich text coming out of a CMS is only as accessible as the markup the content team produced, which means editorial tooling and training matter as much as code. And third-party embeds — payment widgets, chat tools, booking systems — can undo all of your own careful work, because you don't control their code; it's worth accessibility-testing anything you bolt on, not just what you built.
Building it in, not bolting it on.
The common thread across all of this is that accessibility works best as a property of process, not a task on a punch list at the end. Design tokens with contrast built in from the start. Component libraries tested with a keyboard and a screen reader before they're approved, not after launch. Automated tooling like axe or Lighthouse as a first pass — genuinely useful for catching a meaningful chunk of common issues quickly — combined with manual testing for the things automation structurally can't catch, like whether the experience actually makes sense.
None of this is exotic. It's the same discipline as testing across browsers or checking a site works on a slow connection: something that's cheap when it's part of the process from day one, and expensive to retrofit once launched.