Website accessibility process: a practical UK roadmap

TL;DR:

• Website accessibility follows a cycle of auditing, fixing, verifying, and monitoring to ensure compliance and usability. UK law mandates reasonable adjustments for all service providers and detailed standards for public organizations, emphasizing WCAG 2.2 AA as the current best practice. Most issues can be quickly addressed by fixing common problems like missing alt text, heading structure, focus visibility, and clear link descriptions.

The website accessibility process is a repeatable audit → remediate → verify → monitor cycle, that when aligned to WCAG 2.2 and the Equality Act 2010, makes a site genuinely usable for disabled people and reduces your legal exposure. Start with a scoped audit, prioritise fixes by severity and business impact, verify the remediation works, publish an accessibility statement, then keep the cycle going.

The core steps at a glance:

• Scope — identify critical pages, user journeys and content types to check
• Audit — run automated scans, manual checks and assistive-technology testing
• Prioritise — triage issues by severity, frequency and cost to fix
• Remediate — fix code, content and CMS templates in order of priority
• Verify — regression-test fixes and confirm with screen-reader walkthroughs
• Publish — write and link an accessibility statement from every page footer
• Monitor — schedule re-scans, user testing and team training on an ongoing basis

UK law requires action from both public bodies and private service providers. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations set hard compliance obligations for public organisations, while the Equality Act 2010 imposes a duty on all service providers to make reasonable adjustments. GOV.UK guidance sets out exactly what those obligations look like in practice.

What is web accessibility and what are the WCAG POUR principles?

Web accessibility means that websites, tools and technologies are designed and built so that people with disabilities can use them. That covers a wide range of conditions: visual impairment, hearing loss, motor difficulties, cognitive and learning differences, and more. The W3C Web Accessibility Initiative (WAI) defines it plainly: the web should work for everyone, regardless of hardware, software, language, location or ability.

The practical benchmark for achieving that is the Web Content Accessibility Guidelines (WCAG), published by the W3C. WCAG organises its success criteria around four core principles, known as POUR:

• Perceivable — information must be presentable in ways users can perceive. Example: providing alt text on images so screen-reader users hear a description.
• Operable — interface components must be operable by all users. Example: every function available by mouse must also work via keyboard alone.
• Understandable — content and operation must be understandable. Example: using plain language, clear error messages and consistent navigation.
• Robust — content must be robust enough for assistive technologies to interpret reliably. Example: using semantic HTML so screen readers can parse headings, lists and landmarks correctly.

WCAG organises guidelines and success criteria around these four principles, with three conformance levels: A (minimum), AA (the standard most organisations target) and AAA (enhanced). WCAG 2.2, published in October 2023, added nine new success criteria covering focus visibility, target size, drag interactions and accessible authentication. Targeting WCAG 2.2 AA is the most future-proof position for any UK organisation today, because it subsumes everything in 2.1 and 2.0 while addressing the interaction patterns that modern sites actually use.

What does UK law require for website accessibility?

The Equality Act 2010 and the anticipatory duty

The Equality Act 2010 is the primary legislation covering digital accessibility for private and third-sector organisations in the UK. Under section 20, service providers face an anticipatory duty: they must make reasonable adjustments before a disabled person complains, not after. Waiting for a complaint is not a defence.

Reasonableness is assessed by courts and the Equality and Human Rights Commission (EHRC) based on the size of the organisation, the cost of the change and whether the adjustment would fundamentally alter the service. Fixes such as adding alt text, labelling form fields and providing captions are widely regarded as reasonable for any organisation with a functioning web presence. Larger organisations face a higher bar.

Public sector regulations

Public bodies face additional, more prescriptive obligations under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations. These regulations came into force on 23 September 2018, with compliance expected by September 2020. They require public bodies to:

• Meet WCAG 2.1 AA as a minimum (WCAG 2.2 is now the recommended target)
• Publish an accessibility statement as an HTML page linked from every page footer
• Review that statement at least annually or after major changes
• List known issues and provide a route for users to request alternatives

A public body may claim a disproportionate burden exemption for specific content if the cost or effort of making it accessible is genuinely disproportionate to the benefit. This is not a blanket opt-out. A formal disproportionate burden assessment must be documented and included in the accessibility statement, and the body must still fix everything else.

How WCAG fits into the legal picture

The Equality Act does not name WCAG by version. However, UK courts and regulators use WCAG as the practical benchmark when assessing whether a digital service is accessible. Demonstrating WCAG 2.2 AA conformance gives you the strongest evidential position available, whether you are a public body responding to a regulatory audit or a private business facing an Equality Act complaint.

A note on WCAG versioning: many procurement documents still reference WCAG 2.1. Targeting WCAG 2.2 AA satisfies any policy that references 2.1 or 2.0, because 2.2 is fully backwards-compatible. There is no downside to aiming higher.

How to run a website accessibility project step by step

Step 1: Define scope and stakeholders

Before any testing begins, agree on what you are auditing. Produce a content inventory covering your most-visited pages, key user journeys (contact, checkout, booking, account login) and any interactive widgets or third-party embeds. Assign a named content owner and a technical lead. Without clear ownership, remediation stalls.

GOV.UK recommends checking a representative sample of pages rather than every page, focusing on content that affects essential services and high-traffic flows first. For a large site, auditing a representative sample of pages typically surfaces the majority of structural issues.

Step 2: Audit (automated + manual + user testing)

Run automated scans first — tools such as Axe, WAVE or Lighthouse give you a rapid baseline. Then layer in manual checks: keyboard navigation, focus order, semantic structure, form labelling and screen-reader walkthroughs. Finally, include at least a small round of user testing with participants who have lived experience of disability.

The deliverable from this phase is an issue log that maps every finding to a specific WCAG success criterion, records severity (critical, major, minor) and notes the affected page or component. This log drives everything that follows.

Step 3: Prioritise

Not all issues are equal. Triage using four factors: severity (does it block access entirely?), frequency (how many pages or users does it affect?), business impact (is it on a conversion-critical page?) and ease of fix. A missing form label on your contact page scores high on all four and should be fixed in sprint one. A minor contrast issue on a rarely-visited archive page can wait.

The commercial case for prioritising high-traffic pages is strong: accessibility improvements on key user journeys tend to lift usability for all visitors, not just those using assistive technology.

Step 4: Remediate

Work through the issue log in priority order. Developer tickets should reference the WCAG success criterion, the affected element and the expected fix. CMS-level issues (heading structure, image alt text, link text) can often be resolved by content editors without developer involvement. Where a component library or design system exists, fix the pattern once and it propagates everywhere.

Step 5: Verify

Once fixes are deployed, re-test each item. Regression testing confirms the fix works and has not introduced new issues. Run screen-reader walkthroughs on NVDA (Windows) and VoiceOver (macOS/iOS) at minimum. Produce an evidence pack: screenshots, screen-reader recordings and a signed-off issue log showing each item’s status.

Step 6: Publish an accessibility statement

Your accessibility statement must be an HTML page linked from every page footer. It should state whether the site meets WCAG, list any known issues that remain unresolved, explain any disproportionate burden claims, and give users a way to request accessible alternatives or report problems. GOV.UK provides a template and detailed guidance for both public and private organisations.

Step 7: Monitor and maintain

Accessibility degrades over time as content is added and code is updated. Schedule automated re-scans quarterly, a manual review annually, and user testing whenever a major redesign or new feature is launched. Train anyone who publishes content on the basics: alt text, heading hierarchy and link text. Without that training, the same issues reappear within months.

What testing methods and tools should you use?

Automated scanning

Automated tools are fast and consistent, but they have a hard ceiling. Automated accessibility tools detect roughly 30–40% of issues: they reliably catch missing alt text, contrast failures and some unlabelled form fields, but they miss keyboard traps, focus-order problems, cognitive barriers and most authentication failures. Use them for baseline checks and regression testing, not as a substitute for manual review.

Widely used tools include Axe DevTools, WAVE, Lighthouse (built into Chrome DevTools) and Siteimprove. Each has slightly different detection rules, so running two tools on the same page often surfaces different issues.

Manual checks

Manual testing covers what automation cannot. Key checks include:

• Keyboard navigation — tab through every interactive element; confirm focus is visible and logical
• Focus order — does the tab sequence match the visual reading order?
• Semantic structure — are headings, landmarks and lists used correctly in the HTML?
• Form labelling — is every input programmatically associated with a visible label?
• Link text — does every link make sense out of context (“Download annual report” rather than “click here”)?

Assistive technology testing

Test with real assistive technologies, not just automated proxies. NVDA (free, Windows) and VoiceOver (built into macOS and iOS) are the most widely used screen readers in the UK. Check that all interactive elements are announced correctly, that dynamic content updates are communicated, and that authentication flows can be completed without a mouse.

Pro Tip: Test keyboard navigation before screen readers. If you cannot tab to and operate every element with a keyboard alone, screen-reader testing will surface the same issues plus more — fix keyboard access first and you halve the screen-reader work.

User testing with disabled participants

No amount of automated or expert testing replaces feedback from people who use assistive technologies every day. Even two or three user sessions can surface issues that no tool or checklist would catch. Recruit through organisations such as AbilityNet or RNIB, or via specialist user-research agencies. Focus sessions on your highest-priority user journeys.

Recommended testing mix

Map every finding from all four methods back to the relevant WCAG success criterion. That mapping is what makes your issue log defensible in a legal or procurement context. For more on how accessibility and SEO intersect, the two disciplines share more common ground than most people expect.

The most common accessibility fixes you can make right now

Most sites share the same cluster of high-frequency, high-impact issues. Fixing these will move the needle faster than anything else.

• Alt text for images — every meaningful image needs descriptive alt text. Decorative images (dividers, background textures) should use an empty alt="" attribute so screen readers skip them. Never use the filename or “image of” as alt text.
• Heading hierarchy — use one <h1> per page, then <h2>, <h3> in logical order. Never skip levels for visual effect. Screen readers use headings as navigation landmarks.
• Visible keyboard focus — WCAG 2.2 SC 2.4.11 requires that focus indicators are not fully obscured by other content. A visible, high-contrast focus ring (e.g. outline: 3px solid #005fcc) is the minimum. Never use outline: none without providing an equally visible alternative.
• Form labels — every <input>, <select> and <textarea> must have a programmatically associated <label>. Placeholder text alone does not count.
• Error messages — identify the field in error by name, describe what went wrong, and suggest how to fix it. “Invalid input” tells a screen-reader user nothing.
• Captions and transcripts — all pre-recorded video must have accurate captions; audio-only content needs a transcript. Auto-generated captions from YouTube or Teams are a starting point, not a finished product.
• Colour contrast — body text needs a contrast ratio of at least 4.5:1 against its background (WCAG AA). Large text (18pt or 14pt bold) needs 3:1. Use the WebAIM Contrast Checker or Colour Contrast Analyser to verify.
• Link text — every link must describe its destination or purpose without relying on surrounding context. “Read more” and “click here” fail this test.

Pro Tip: Run a website accessibility checklist against your five most-visited pages before commissioning a full audit. You will almost certainly find quick wins that can be fixed in an afternoon and will give you a clearer brief for any external agency.

What does accessibility work typically cost and how long does it take?

Timelines and costs vary considerably depending on site size, CMS complexity and the number of custom interactive components. The table below gives indicative ranges for UK projects.

Cost drivers include the number of distinct page templates, the complexity of interactive elements (carousels, modals, multi-step forms, authentication flows), whether the CMS allows direct code access, and whether user testing with disabled participants is included. Retrofitting accessibility into a poorly structured legacy site costs significantly more than building it in from the start.

Phasing options:

• Quick wins first — fix critical and major issues on high-traffic pages in sprint one; move lower-priority pages into a backlog
• Template-led remediation — fix each page template once; all pages using that template benefit immediately
• Continuous governance — a monthly maintenance agreement covering re-scans, content reviews and training; suits organisations that publish frequently

Budget separately for ongoing monitoring, annual user testing and staff training. These are not optional extras; they are what stops the same issues returning six months after launch. Accessibility also supports search visibility, so the investment tends to pay back across more than one channel.

How MB Web runs an accessibility project with you

MB Web approaches accessibility as a structured project with clear phases, honest deliverables and no hidden scope. Here is what a typical engagement looks like.

Discovery and scoping — we start with a conversation about your site, your users and your compliance obligations. We agree the pages and user journeys to audit, identify your CMS and any third-party components, and set a realistic timeline.

Audit — we run automated scans alongside manual keyboard and screen-reader checks, producing an issue log mapped to WCAG 2.2 success criteria. Every issue is rated by severity and linked to the affected page or component.

Remediation sprints — we work through the issue log in priority order, fixing code and content in agreed sprints. We keep you informed at each stage and flag anything that requires a decision from your team (for example, whether to replace a third-party widget or work around it).

Verification and handover — once fixes are deployed, we re-test and produce an evidence pack: a signed-off issue log, verification screenshots and a draft accessibility statement ready to publish.

Training and ongoing support — we train your content team on the basics (alt text, headings, link text) so new content does not undo the work. For clients on a maintenance contract, we include quarterly re-scans and an annual accessibility review.

What we ask from you: access to the CMS, a named content owner who can approve copy changes, and a prioritisation agreement before remediation begins. Clear ownership on your side means we can move faster and avoid rework.

Pro Tip: When briefing any agency on accessibility work, ask to see a sample issue log from a previous project. A well-structured log maps each issue to a WCAG success criterion, records the affected element and URL, and shows the fix applied. If an agency cannot show you one, that is a red flag.

Key takeaways

The website accessibility process works when it is treated as a continuous cycle, not a one-off task: audit, prioritise, fix, verify, publish a statement, then monitor and repeat.

Why accessibility projects often go wrong (and how to avoid it)

Most accessibility failures we see in UK projects are not technical. They are process failures.

The most common mistake is treating the audit as the deliverable. An audit report sitting in a shared drive, unactioned, does nothing for your users and nothing for your legal position. The audit is only useful if it feeds directly into a prioritised remediation plan with named owners and a deadline.

The second most common mistake is skipping CMS training. A developer can fix every heading and alt text issue in the codebase, but if the marketing team continues to upload images without alt text and paste in heading tags for visual effect, the site will fail its next audit. Training is not optional; it is the mechanism that makes the fix permanent.

Interactive widgets deserve more attention than they usually get. A carousel, a date picker, a multi-step form or a modal dialogue can each contain a cluster of accessibility failures that are genuinely complex to fix. These components take longer and cost more than most clients expect. Identify them early in scoping and budget accordingly.

Finally, user testing is consistently undervalued. Two sessions with a screen-reader user will surface barriers that no automated tool or expert reviewer would catch, because real users interact with sites in ways that test scripts do not anticipate. The cost is modest; the insight is disproportionate.

The organisations that get this right treat accessibility as part of their content governance, not as a compliance checkbox. That means regular training, a named accessibility lead, and accessibility criteria baked into every brief for new features or redesigns.

MB Web can help you get this right

Accessibility work does not have to be complicated, but it does need to be done properly. MB Web offers fixed-scope accessibility audits, remediation and CMS training for businesses across Sussex, Surrey, Kent and the South East. Whether you need a standalone audit to understand where you stand, or a full remediation project built into a new website design, we will give you a straight answer on what needs doing and what it will cost.

We do not sell vague reports or open-ended retainers. Every project starts with a scoped discovery conversation, a clear issue log and an agreed plan. If you need technical development work to fix complex components or rebuild inaccessible templates, that is built into the same project. Get in touch and let’s talk through what your site needs.

Useful sources

These are the primary sources used in this article. They are the ones to cite in procurement documents, legal checks or internal compliance reviews.

• GOV.UK: Make your website or app accessible and publish an accessibility statement — the practical guide for both public and private organisations; covers audit methods, accessibility statement requirements and disproportionate burden.
• GOV.UK: Accessibility requirements for public sector websites and apps — the definitive reference for public bodies on the 2018 Regulations; use this in procurement and compliance documentation.
• WCAG 2.2 (W3C) — the full technical standard; reference this when specifying conformance requirements in contracts or briefs.
• WCAG 2 Overview (W3C WAI) — a plain-language introduction to WCAG; useful for briefing non-technical stakeholders.
• Public Sector Bodies Accessibility Regulations 2018 (legislation.gov.uk) — the statutory instrument itself; cite this when referencing the legal basis for public-sector obligations.
• Introduction to Web Accessibility (W3C WAI) — a clear, authoritative introduction to why accessibility matters and who it affects.

FAQ

Recommended

• Website accessibility checklist guide for UK businesses
• Why website accessibility matters for Sussex businesses
• The role of security in websites: a guide for UK businesses
• Top 5 tips to improve accessibility of your charity website