ccessibility is the work of making a website usable by people with different visual, hearing, motor, cognitive and speech needs. For UK businesses it is both a customer-quality issue and a legal-risk issue. The useful response is not a badge or an overlay: it is an accessible service, an evidence-backed build process and a way to fix barriers.
This guide explains delivery and procurement, not legal advice. Duties vary by organisation and service. UK public-sector bodies also have specific accessibility regulations and statement requirements; private and voluntary organisations should understand the Equality Act 2010 and obtain professional advice for their circumstances.
The Equality and Human Rights Commission explains that service providers must not discriminate and may need reasonable adjustments so disabled people can access services. A website can be part of that service. The question is not simply whether a page claims conformance; it is whether real barriers were anticipated, tested and remedied.
WCAG 2.2 is the most useful shared technical reference for web content. Many organisations target Level AA, but conformance is not a substitute for legal advice or user testing. Public-sector website and app rules have additional requirements, including accessibility statements, and should be assessed under the official government guidance.
- Semantic HTML so headings, landmarks, lists, controls and relationships are exposed to assistive technology.
- Complete keyboard access with visible focus, sensible order and no traps.
- Text and meaningful interface graphics with sufficient contrast, plus information that is not communicated by colour alone.
- Labels, names, instructions and error messages that make forms understandable.
- Text alternatives for informative images and appropriate empty alternatives for decorative images.
- Captions or transcripts for time-based media where required by the content.
- Responsive layouts that survive zoom, reflow and large text without hiding essential actions.
- Motion that respects reduced-motion preferences and avoids unnecessary flashing.
- Status messages, dialogs and dynamic updates announced in a predictable way.
tsx
function SaveButton({ saving }: { saving: boolean }) { return ( <button type="submit" disabled={saving} aria-busy={saving}> {saving ? 'Saving project…' : 'Save project'} </button> ); } // The native button supplies keyboard behaviour and a role. // Visible text communicates the state; disabled prevents duplicate actions.
Native elements are often the strongest starting point because browsers and assistive technology already understand them. Custom controls can be accessible, but they inherit responsibility for keyboard operation, focus, roles, states and announcements.
Automated tools catch valuable classes of defect—missing labels, some contrast failures, invalid attributes—but cannot decide whether alt text is useful, focus order makes sense, instructions are understandable or a complete task is operable. Combine automation with keyboard checks, browser zoom, screen-reader journeys and testing by disabled users where risk and reach justify it.
- Test component primitives while they are built.
- Test representative page templates before content population.
- Test complete user journeys with keyboard and assistive technology.
- Invite people with relevant access needs into research and acceptance.
- Retest after content, third-party widgets and production scripts are added.
A proposal should state the target standard, supported browsers and assistive technologies, testing methods, who supplies accessible content and documents, how third-party limitations are handled and what evidence is delivered. “Accessibility included” without scope is not an acceptance criterion.
- Choosing brand colours before checking usable text and control combinations.
- Building div-based controls instead of native links, buttons and fields.
- Opening complex dialogs without a focus strategy.
- Publishing inaccessible PDFs as the only route to essential information.
- Depending on placeholders instead of persistent field labels.
- Removing focus outlines for visual neatness.
- Buying an overlay and treating the underlying barriers as solved.
Editors can undo a careful build with vague link text, missing headings, uncaptioned video or text embedded in images. Give content teams concise rules and reusable components. Add accessibility checks to definition-of-done and regression testing, and provide a clear contact route for users who encounter a barrier.
- Which WCAG version and level will you use as the technical target?
- Which journeys, browsers, devices and assistive technologies will you test?
- What is automated, what is manually inspected and who performs user testing?
- How are findings prioritised, corrected and documented?
- How are editors trained and third-party widgets assessed?
- What happens if a barrier is discovered after launch?
Accessiblewebsitesarenotvisuallyconstrainedwebsites.Thestrongestsystemsmakeclarity,focus,contrastandresilientinteractionpartofthevisuallanguage.