How Website Accessibility Requirements Affect Development Choices

Accessibility work is often described as a compliance exercise that happens near the end of a build, staffed by whoever has capacity, with a report at the finish. That framing is expensive, because the decisions that determine whether a site is usable with assistive technology are made in the first week — in the component library, the focus order, the type scale and the choice of how the page announces itself to a browser. By the time somebody runs an audit, the expensive mistakes have already been baked into a dozen templates.

What follows is how accessibility constraints change specific engineering choices, in roughly the order they come up. It is written for teams who did not plan to be accessibility specialists and need to know which decisions are actually load-bearing.

It starts with the component library

The decision that matters most on most projects is whether there is one shared set of UI components or a scattering of one-off markup across pages. If components exist, accessibility lives inside them once and every consumer inherits the fix. If they do not, every fix is applied by hand to every page that uses the pattern, which is how a well-intentioned change becomes a two-week project and how regressions appear months later.

Concretely, a button component should be a real button element. Not a div with a click handler, not an anchor styled to look like a button. That single choice brings keyboard activation, focus behaviour, form participation and the correct announcement to assistive technology without any extra work. The same argument applies to dialogs, disclosure widgets, tabs, comboboxes and every other control people are tempted to build from divs because a div is easier to style.

If your team builds React or Angular components, this is a library design decision rather than an audit finding, and it should be made in the first sprint. Our UI and UX design and web design engagements tend to produce a component inventory as a matter of course, because without one nobody can tell what the site is made of — and an audit against a site with no shared components is an audit of fifty copies of the same decision.

“Compliant” is not one thing

Procurement language is often vague, and vague requirements produce expensive work. WCAG is organised into principles, guidelines and success criteria at three levels, and the level that gets specified determines almost everything about effort. Conformance at the lowest level of the standard is largely about semantics, names and contrast. Higher levels add things like consistent help, redundant entry avoidance, and captions — all of which are design and content requirements as much as code.

Then there is the jurisdiction question, which is separate from the standard. A procurement team may have a legal obligation to meet a named level in a named jurisdiction, and that obligation belongs to them rather than to the development team. What the development team can usefully do is insist on a written, specific statement of what is required: which version of the standard, which criteria, and what evidence will be produced.

We are happy to work against that written list, and app consulting and strategy work is where the requirement gets translated into engineering tasks before anyone commits to a date. The alternative is discovering in month four that the requirement includes something that changes the visual design, which is the worst possible time for it.

Semantics first, ARIA as a last resort

The most useful rule of thumb in this whole field: a native HTML element almost always beats a hand-built one with ARIA attributes. Native elements come with keyboard behaviour, focus handling, state and role already correct, maintained by the browser vendor. Replicating that with attributes is work, and any gap in your replication is a bug that only some users will ever encounter.

SmartEdge IT Solutions keeps a crude rule on every project: no ARIA attribute without a comment saying what it compensates for and which native element was unavailable. It is not a sophisticated control, but it surfaces both the cases where a team is reinventing something unnecessarily and the cases where a genuine custom widget needs a written rationale.

Where ARIA is genuinely required, it is usually one of a handful of situations: a custom widget with no native equivalent, a live region for content that updates without navigation, or a disclosure where the visual state and the announced state have to stay in sync. One trap catches everyone — an element with an ARIA role stops being its native element. Adding role=”button” to a link turns it into something that no longer behaves like a link, so keyboard users lose the ability to open it in a new tab and screen reader users stop hearing it announced as a link.

Headings are structure, not styling

Headings are the other place where semantics cost nothing and are routinely wrong. A heading outline that jumps from h2 to h4 because a designer wanted smaller type tells a screen reader user that a level of content is missing. Size is a styling decision; level is a structural one. Keeping them separate is a five-minute conversation in design review that saves a content audit later.

Focus management in single-page applications

This is where client-rendered applications genuinely complicate things, and why the rendering decision discussed elsewhere has accessibility consequences. In a document, the browser manages focus: it follows the anchor, it moves to the next form control, the back button restores focus to where you were. In an application, the browser has no idea anything happened.

Three failures recur. After a route change, focus is left on an element that no longer exists, so the next keystroke goes into nothing and the screen reader announces stale content. A modal opens without taking focus, so keyboard input continues to travel behind it. And a modal closes without returning focus to the trigger, so the user has to work their way back through the entire page from the top.

None of these have a single tool-based fix. They need the application to manage focus deliberately: move focus to the new view’s heading or container on navigation, trap and restore it around overlays, and announce meaningful updates through live regions used sparingly, because a live region that fires on every render is noise. Our Angular development and React development teams handle this as part of component work rather than as an integration activity, which is the only point at which it is cheap.

Colour decisions that end arguments

Contrast is the most common accessibility finding and the one least likely to be fixed, because it usually requires somebody to approve a design change. The thresholds in the standard are not arbitrary — text needs enough contrast against its background to be readable, and the spec names the ratios. What matters practically is deciding early whether brand colours are fixed or negotiable, and writing the answer down.

Common outcomes: darken a text colour slightly, lighten a background, or use the brand colour for accents and links while keeping body text neutral. Any of those is fine. The expensive path is discovering at the end that the primary brand colour cannot be darkened because it appears in print collateral and on signage, and then arguing about a hex value with nobody able to decide.

Colour is also load-bearing as a signal. Error states cannot be conveyed by colour alone, links inside body text need a non-colour cue, and anything that changes on hover or focus needs a change that is visible without a mouse. These are design requirements, not code requirements, and they belong in the design system rather than in a remediation list.

Forms: the browser is already good at this

Most form accessibility problems are solved by not preventing the browser from doing its job. A label element associated with its input by id. Error messages associated with the field, not just placed above or below it in colour. No navigation triggered by an input’s change event mid-typing. No custom dropdown where a native select would do, unless there is a genuine reason such as a multi-select with search.

Two items are worth calling out because they are common and frequently missed. Placeholder text used as the only label disappears on focus, so users with cognitive disabilities lose the prompt at exactly the moment they need it. And validation that fires on blur, with the error summary moved to the first invalid field, is far more usable than validation that fires on submit with focus left at the top of a long form.

On projects with a substantial forms surface, we build these into the shared field components during quality assurance planning so they get exercised across the estate rather than reviewed page by page.

What automated testing catches, and what it does not

Automated tools are worth running continuously, partly because they are cheap and partly because they stop regressions when a change lands. But they check a narrow slice: missing alt attributes, form labels, contrast values, heading order, landmark presence, and a handful of ARIA attribute errors. Everything involving focus, keyboard operation, the announcement order of a dynamic region, or whether a control is operable at all is invisible to them.

Manual testing is not expensive if you know what to do. Keyboard-only navigation of the main journeys, which catches most focus problems in an afternoon. A screen reader pass over the primary flows, which catches missing names and broken announcements. Checking at a very large text size and a narrow viewport, which catches layouts that assume the default font size. That combination finds most of what matters.

Where we find issues in existing sites rather than new builds, the pattern is almost always in the third-party layer — a consent banner, an embedded map, a chat widget — which no amount of your own markup will fix. That is a conversation with the vendor or a decision to replace the component, and it belongs on the plan with an owner attached rather than in a list of things the build team will look at again in a year.

Where accessibility and performance agree

There is a useful overlap here that is worth naming when arguing for both budgets. Semantics mean less script, because a native element does not need a behaviour library attached to it. Fewer page-builder plugins means a smaller dependency surface. Explicit dimensions on images and reserved space for anything that loads late reduce layout shift for everyone. Capping the number of font weights and using the formats the platform supports already is cheaper as well as more legible.

None of that makes the work easy, and it is worth being honest that some accessibility requirements carry real cost. Captions and transcripts are content work with a real budget. A keyboard-operable custom data grid can be a significant piece of engineering. Good practice is to identify those early, price them honestly, and agree what is in scope for the current phase rather than discovering the argument during a sprint.

What to write into the agreement

Four things, and they prevent most of the trouble I have seen. Name the standard, the version and the level, referenced in the scope rather than assumed. List the criteria that genuinely apply, with the ones that do not marked as such. State the devices and assistive technology to be tested, because “supports assistive technology” is not testable but “tested with keyboard navigation and one screen reader on the current versions” is. And state what evidence will be produced — an automated report on each build, plus a manual test record for the primary journeys.

None of this makes a site accessible. What it does is make the work arguable, which means it can be planned, budgeted and defended. When SmartEdge IT Solutions is asked for a fix list, we would rather deliver this document and a sequence of engineering tasks than a score with no explanation attached. If you want an honest read on what your existing estate is missing, an audit scoped around accessibility specifically will tell you more than a generic report will, and you can start that conversation whenever you want.