Rules and ethics
How the Equality Act and EHRC guidance shape UK public-sector landing pages
Equality Act landing page accessibility means named duties, EHRC guidance, WCAG 2.2 criteria and a published accessibility statement for UK public pages.
What to take away
What to take away
- Equality Act landing page accessibility rests on two duties in the Act: not to discriminate, and to make reasonable adjustments for disabled people.
- Public-sector websites and apps are also covered by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (SI 2018/952). Their technical benchmark is EN 301 549, based on WCAG 2.1 AA; this guide uses WCAG 2.2 Level AA as its working target.
- The Equality and Human Rights Commission (EHRC) publishes guidance on the Equality Act. Public bodies must also publish an accessibility statement and provide a way for users to report problems.
- Forms, labels and error messages carry the most risk, because WCAG criteria there are testable and failures are easy for a complainant to describe.
- Consent text and privacy notices are accessibility content too, so plain layout and readable wording matter as much as the tick box.
- Test with keyboard, screen reader and zoom before a campaign goes live, and record what you tested.
- Keep the accessibility statement honestit must describe the page you actually shipped.
The Equality Act 2010 duties that reach a public-sector landing page
The Equality Act 2010 is the starting point, not a preamble. It applies to public bodies and to anyone providing a service to the public, which covers a campaign landing page taking enquiries or applications.
Two duties do the work. The first is non-discrimination in the provision of services. The second is the duty to make reasonable adjustments, which is anticipatory: you are expected to plan for disabled users rather than wait for a complaint.
A landing page is a service in this sense. If a resident cannot complete the form with a screen reader, that is not a design preference, it is a barrier to a service they are entitled to use.
Accessibility is usually the cheapest adjustment available. Fixing label markup costs hours. Defending a complaint costs considerably more, in staff time and in trust.
Most public-sector teams already handle this alongside wider compliance work on claims and data, which is why the UK rules and compliance picture is worth mapping once for the whole estate.
What counts as a service
Council tax portals, school admission forms, blue badge applications, library sign-ups and consultation pages all count. So do charity pages that deliver a service, such as advice lines, referral forms or grant applications.
Who carries the duty
The organisation publishing the page carries it. A supplier or agency builds the page, but the public body remains responsible for what residents meet.
Reasonable adjustments in practice
Reasonable adjustments on a landing page look like a form that works with a keyboard alone, or text that survives 200 per cent zoom. They also include a named contact for accessibility problems, and an alternative route to the same service by phone or post.
EHRC guidance and GOV.UK accessibility requirements for public bodies
The Equality and Human Rights Commission publishes Services, public functions and associations: Statutory Code of Practice, which explains how the Equality Act applies to services. The Code helps explain the Equality Act duty; it is distinct from the public-sector website and app requirements set out in the 2018 Accessibility Regulations.
The GOV.UK guide Understanding accessibility requirements for public sector bodies explains the public-sector requirements. The GOV.UK public sector accessibility requirements sit alongside the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (SI 2018/952). The regulatory technical benchmark is EN 301 549, based on WCAG 2.1 AA; this guide uses WCAG 2.2 Level AA as a higher working target. Public bodies must also publish an accessibility statement and provide a way for users to report problems.
Those requirements apply to public sector websites and apps, including campaign and microsites built outside the main domain. A landing page on a third-party tool is still in scope if a public body publishes it.
When comparing or configuring landing-page, funnel or lead-capture software, check that it lets your team create programmatically labelled fields, keyboard-operable controls, accessible error summaries and visible focus. Verify that the published page reflows at zoom and supports a page-specific accessibility statement and feedback route; test the actual page rather than relying on a supplier’s general claims.
The Government Digital Service (GDS) monitors compliance with the Accessibility Regulations. The EHRC is responsible for enforcing those Regulations. Public bodies publish accessibility statements and respond to feedback; the statement should identify the enforcement route and explain how users can report an accessibility problem.
The direction of travel matters for planners. Service teams increasingly treat accessibility the way they treat uptime: a launch condition, not a follow-up task, which is the thinking behind these service standards for landing pages.
Where the two documents differ
The Equality Act sets duties including non-discrimination and reasonable adjustments, and the EHRC’s statutory Code of Practice explains how those duties apply to services. The Accessibility Regulations set separate requirements for public-sector websites and apps, including accessibility statements. Meeting the technical benchmark is important evidence of accessibility, but it does not replace the Equality Act duties.
What the requirements ask of a landing page
A conformant page, a published accessibility statement, a feedback route, and a process for handling the feedback. Four things, all checkable.
Deadlines and scope
The Accessibility Regulations came into force on 23 September 2018. Websites published on or after that date had to comply by 23 September 2019; older websites had to comply by 23 September 2020. Public-sector mobile apps had to comply by 23 June 2021. Those deadlines have passed, so a new campaign page must meet the applicable requirements when it is published, whatever tool builds it.
WCAG 2.2 criteria that apply to forms, labels and error messages
The WCAG 2.2 criteria are where a landing page passes or fails in practice. The criteria below are the ones that catch public-sector forms most often.
WCAG 2.2 criteria for forms
Criterion
- 1.3.1 Info and Relationships
- A
- 1.4.3 Contrast (Minimum)
- AA
- 1.4.10 Reflow
- AA
- 2.4.7 Focus Visible
- AA
- 3.3.1 Error Identification
- A
- 3.3.2 Labels or Instructions
- A
- 3.3.3 Error Suggestion
- AA
Level
- 1.3.1 Info and Relationships
- Labels tied to inputs
- 1.4.3 Contrast (Minimum)
- Text and borders 4.5:1
- 1.4.10 Reflow
- Works at 320 CSS pixels
- 2.4.7 Focus Visible
- Visible focus ring everywhere
- 3.3.1 Error Identification
- Errors described in text
- 3.3.2 Labels or Instructions
- Every field says expected input
- 3.3.3 Error Suggestion
- Message says how to fix
Landing page meaning
- 1.3.1 Info and Relationships
- 1.4.3 Contrast (Minimum)
- 1.4.10 Reflow
- 2.4.7 Focus Visible
- 3.3.1 Error Identification
- 3.3.2 Labels or Instructions
- 3.3.3 Error Suggestion
WCAG 2.2 criteria for forms
| WCAG 2.2 criterion | Level | What it means on a landing page |
|---|---|---|
| 1.3.1 Info and Relationships | A | Labels are programmatically tied to their inputs |
| 1.4.3 Contrast (Minimum) | AA | Body text and input borders reach 4.5:1 |
| 1.4.10 Reflow | AA | The form works at 320 CSS pixels wide without sideways scrolling |
| 2.4.7 Focus Visible | AA | The keyboard focus ring is visible on every field and button |
| 3.3.1 Error Identification | A | Errors are described in text, not colour alone |
| 3.3.2 Labels or Instructions | A | Every field says what input is expected |
| 3.3.3 Error Suggestion | AA | The message says how to correct the problem |
| 3.3.7 Redundant Entry | A | Users are not asked for the same information twice |
| 3.3.8 Accessible Authentication | AA | No puzzle or memory test blocks a login or submission |
The error message rules are the ones teams most often miss. A red border with no text fails 3.3.1. A message reading "invalid input" fails 3.3.3, because it does not tell the user what to do.
Error summaries belong at the top of the form, linked to the fields they describe, with the field itself marked and described. Screen reader users need both, announced in a live region so the message is not missed.
Labels should sit above inputs, stay visible when text is entered, and avoid placeholder-only patterns. Placeholders vanish on typing and often fail contrast.
Redundant entry matters on multi-step forms. If someone has already given an address on step one, do not ask again on step three without offering to reuse it.
Accessible authentication matters where a page gates a document or a service. Do not require a puzzle, and allow paste into password fields.
Focus order and keyboard traps
Tab order should follow the visual order of the page. A modal that traps focus with no escape route fails 2.1.2 and is a common fault in cookie banners and newsletter overlays.
Time limits on campaign forms
If a session expires, warn the user and offer to extend. A form that silently loses answers after a timeout fails the spirit of 2.2.1 and generates complaints that read like accessibility complaints.
Consent text and privacy notices as accessibility content
Consent is content. The text beside a tick box has to be readable, and the box itself has to be operable without a mouse.
Plain wording is an accessibility measure. Long conditional sentences and legal phrasing exclude readers with cognitive impairments, low literacy or limited English, and they make the page harder for everyone.
Consent text readability also affects validity. Consent under UK GDPR must be freely given, specific, informed and unambiguous, and a person who cannot understand the sentence has not given informed consent.
The ICO enforces UK GDPR and the Data Protection Act 2018, and PECR sits alongside them for cookies and marketing. The applying UK regulations approach of mapping the page event to each rule keeps this manageable.
Practical points. Unticked boxes by default. No consent walls that block the service. A reject option as easy to reach as accept. Tick boxes with a visible label, not a bare square.
Privacy notices linked from the form should be reachable by keyboard, open without losing form entries, and be written at a reading level a general audience can follow.
Cookie banners and focus
A banner that takes focus on load, cannot be dismissed by keyboard, or hides the form underneath is both an accessibility fault and a consent problem.
Reading level in practice
Aim for short sentences and common words. If a sentence needs a comma splice to survive, split it. Test the consent paragraph on someone outside the team.
Publishing an accessibility statement that matches the page
Every public-sector page needs an accessibility statement, and it must describe the page as published, not as intended.
GOV.UK explains how to publish an accessibility statement alongside the wider work of making a site accessible. The statement is a public claim, so inaccuracy is worse than an honest gap.
The model accessibility statement gives the structure UK public bodies are expected to follow. Use it as the skeleton rather than writing from scratch.
A statement that matches the page covers: how accessible the content is, known limitations, what to do if you find a problem, the enforcement route, and how the page was tested.
Known limitations should name the specific thing. "Some older PDFs are not fully tagged" is useful. "We are committed to accessibility" is not.
Contact details must work. An email address that bounces, or a phone line that no longer handles accessibility queries, undermines the whole statement.
Statement versus reality
If the statement claims WCAG 2.2 AA and the form has unlabelled fields, the gap is the problem. Either fix the page or describe the limitation.
Statements for campaign microsites
A short campaign page still needs a statement, even if it links to the parent organisation's fuller version. Say which one applies.
Reviewing the statement
Review it when the page changes, when a new form is added, and after any accessibility fix. A statement dated years before the current build is a warning sign.
Testing for accessibility before a public campaign goes live
Testing is where the duties become evidence. Do it before launch, on the built page, with the real content in place.
Pre-launch accessibility testing steps
- Run automated checks for labels and contrast
- Test keyboard only through the whole form
- Test with NVDA or VoiceOver screen reader
- Zoom 200 per cent and 320 CSS pixels
- Trigger every error state deliberately
- Check consent banner, tick boxes, privacy link
- Record results with page version and tools
This sits naturally inside a wider release checklist, since most of the steps are launch conditions rather than separate projects.
Testing with real users
Include disabled users in usability testing where the budget allows. A short session with three or four people finds faults that no scanner reports.
What to do with failures
Fix what you can before launch. For anything left, write it into the accessibility statement as a known limitation with a workaround and a date for review.
An Equality Act landing page accessibility checklist
Work through this before the page goes live and again after any significant change. It maps the Equality Act duties, the EHRC guidance, the Accessibility Regulations, software checks and the WCAG 2.2 working target onto one page.
Equality Act landing page checklist
- Meets WCAG 2.2 AA, tested automatically and manually
- Every field has a visible associated label
- Errors are text, describe the fix, linked summary
- Works keyboard only with visible focus indicator
- Reflows at 320 CSS pixels and 200 per cent zoom
- Consent text plain, unticked, keyboard operable
- Accessibility statement published, current and linked
- Working feedback route with monitored contact
- Check that the landing-page software produces a logical heading structure and programmatically associated labels for every form field.
- Complete the form using only a keyboard; check logical focus order, visible focus and an escape route from overlays.
- Check that text and controls remain usable when enlarged and that content reflows without horizontal scrolling.
- Check text and control contrast, instructions and required-field indicators against the page’s accessibility target.
- Trigger errors deliberately; confirm each is identified in text, linked to the relevant field and accompanied by a useful correction.
- On multi-step forms, check that users can reuse information already entered and paste into authentication fields.
- Check that session time limits give a warning and an opportunity to extend the session.
- Check that consent controls, cookie banners and privacy-notice links work by keyboard and do not obscure or lose form entries.
- Test the published page with a screen reader and zoom as well as a keyboard, and record the page version and results.
- Confirm the accessibility statement describes the published page, known limitations, feedback route, enforcement route and testing method.
Worked example: a blue badge renewal page
A council builds a renewal landing page with a three-step form. Step one collects the reference number, step two the address, step three a declaration and consent.
The first build fails on three points. The address fields use placeholders instead of labels, so 1.3.1 and 3.3.2 fail. The error state turns the border red with no text, failing 3.3.1. Step three asks for the address again, failing 3.3.7.
The fixes take a morning: labels above inputs, an error summary at the top of each step linked to the fields, and a reuse option carrying the address forward. The statement then records the page as conformant, with the PDF guidance notes named as a known limitation.
Keeping the checklist alive
Assign an owner. A checklist with no owner becomes a document nobody opens, and the next campaign repeats the same faults.
Common questions
Does the Equality Act 2010 apply to a campaign landing page?
Yes, if a public body or a service provider publishes it. The Act covers services to the public, and the duty to make reasonable adjustments is anticipatory.
Is WCAG 2.2 AA a legal requirement in the UK?
The Equality Act does not name WCAG. The Accessibility Regulations set separate requirements for public-sector websites and apps; their technical benchmark is EN 301 549, based on WCAG 2.1 AA. This guide uses WCAG 2.2 Level AA as a higher working target, not as the wording of the Act.
What must an accessibility statement contain?
How accessible the content is, known limitations, a feedback route, the enforcement route, and how the page was tested. The GOV.UK model accessibility statement gives the expected structure; GDS monitors compliance with the Accessibility Regulations and the EHRC is responsible for enforcing them.
Do error messages need to name the field?
Yes. WCAG 2.2 requires errors to be identified in text and to suggest a correction, so a message should say which field failed and what to enter instead.
How often should we test a live landing page?
Before launch, after any form or content change, and at least once a year. Record the results each time.
What happens if a resident complains?
The public body responds, and unresolved cases can go to the enforcement route named in the accessibility statement. An accurate statement and a dated test record are the evidence that matters.
