Parish Council Website Accessibility: Meeting WCAG 2.2 AA Requirements

Your parish council website is legally required to meet WCAG 2.2 AA. That requirement is not new in principle, but the standard moved up a notch in October 2024 — from WCAG 2.1 AA to WCAG 2.2 AA — and most clerks have not updated their accessibility statement to match. Internal auditors checking Assertion 10 will ask to see it.

Parish, town and borough councils are public sector bodies under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. That means three obligations: meet the technical accessibility standard, publish a compliant accessibility statement, and keep both under review. Each of these is checkable evidence at audit.

What WCAG 2.2 AA actually requires

WCAG 2.2 builds on WCAG 2.1 with nine additional success criteria, most aimed at users with cognitive disabilities, low vision, and motor impairments using touch devices. The full standard lives at W3C — Web Content Accessibility Guidelines 2.2.

For a typical parish council website, AA conformance hinges on a smaller set of practical requirements:

• Text contrast. Body text needs at least a 4.5:1 contrast ratio against its background; large text (18pt or 14pt bold) needs 3:1. The default themes of older WordPress and parish-website-builder templates often fail this on grey-on-grey footers, light-grey form labels, and "subtle" link colours.
• Keyboard navigation. Every interactive element — menus, search, accordions, document download links — must be reachable and operable using Tab, Shift-Tab, Enter and Space. Hover-only menus fail.
• Visible focus indicator. When a keyboard user lands on a link or button, they must see where they are. WCAG 2.2 strengthened this requirement (success criterion 2.4.11). Many themes still hide the default browser focus ring.
• Alternative text on images. Every meaningful image needs an alt attribute describing what it conveys. Decorative images get alt="". Council logo, councillor photos, agenda thumbnails, accessibility-statement icons — all need consideration.
• Document accessibility. PDFs and Word documents linked from your site should themselves meet WCAG 2.2 AA where reasonably practical. Scanned image-PDFs of minutes are a common failure point — they are inaccessible to screen readers.
• Forms with labels. Contact forms, feedback forms, FOI request forms — every input field needs a programmatically associated label, not just placeholder text.
• Page titles and headings. Each page needs a unique, descriptive <title> and a logical <h1> → <h2> → <h3> heading structure.

These are the points an internal auditor or external testing tool flags first. They are also the points where a clerk can take action without rebuilding the site.

The accessibility statement: what auditors check

The accessibility statement is the evidence document. It must be linked in the website footer, on a fixed URL, and contain specific declared content. The current template and guidance from the Government Digital Service is at GOV.UK — make your website or app accessible.

A compliant statement names:

1. The compliance status — fully compliant, partially compliant, or non-compliant with WCAG 2.2 AA. "Partially compliant" is the honest answer for most parish councils and is fully acceptable, provided the next two sections are present.
2. Non-accessible content — a list of the specific failures the council is aware of. For example: "Some PDF minutes from before 2023 are scanned images and cannot be read by screen readers" or "The events calendar uses a third-party widget that does not pass keyboard navigation."
3. What the council is doing about it — concrete plans with timeframes. "We will replace scanned PDFs with text PDFs as we publish them; pre-2023 archives will be converted on request" is acceptable. "We are committed to accessibility" alone is not.
4. How to report problems — a contact route (email or phone) for residents who cannot access content.
5. Enforcement procedure — a line directing residents who are not satisfied to contact the Equality Advisory and Support Service (EASS), the body that handles unresolved Equality Act complaints.
6. Date prepared and date last reviewed. The Government Digital Service expects an annual review at minimum.

If your statement still references WCAG 2.1 AA, it has not been reviewed since at least October 2024. That alone is an Assertion 10 finding.

Practical fixes most parish council sites need

Walk through the site as a keyboard-only user. Open the homepage, press Tab repeatedly, and check that:

• A "Skip to content" link appears as the first focusable element
• Every menu item, including dropdown children, can be reached and activated
• The focus ring is visible on every focusable element
• Forms can be completed and submitted without a mouse

Then run a contrast check on the colours your theme actually uses (not the colours specified in design notes — the rendered colours). Free browser plugins do this well. Fix any failures by darkening text colour or lightening the background, not by changing only one shade.

For documents, set a forward policy: from a stated date, all new minutes, agendas, and policies are uploaded as text PDFs (created from Word, not scanned). Older documents move over on request and during natural review cycles.

Update the accessibility statement to reflect WCAG 2.2 AA. State honestly which content is not yet compliant and what the plan is.

Linking accessibility to the rest of Assertion 10

Website accessibility is one of the three pillars of Assertion 10 in the SAPPP Practitioners' Guide. The other two — domain and email, and IT policy — interlock with it. The IT policy should reference the accessibility regulations and name who is responsible for the annual review. The accessibility statement, the IT policy, and the internal audit checklist all need to point at the same review cadence — at least annual, ideally aligned with the council's financial year end so it sits inside one block of work.

What evidence to keep

For audit, keep a folder containing:

• The current accessibility statement, dated
• The previous version, with the date it was superseded
• A short note recording who reviewed it and when
• Screenshots or notes from the latest accessibility test (in-house keyboard sweep, automated tool report, or third-party audit)
• A log of access requests received and how they were handled

This is what an auditor expects. It is also what protects the council if a resident makes a formal complaint to EASS.

Common mistakes

Treating accessibility as a one-off project. WCAG 2.2 AA is a moving target — the standard updates, content drifts, plugins change. The council's obligation is ongoing review, not one audit.

Outsourcing the statement to a hosting provider and forgetting it. Many parish-council website hosts publish a generic template statement on every site they host. That is not compliant. The statement must be specific to your council's known failures and your remediation plans.

Citing WCAG 2.1. The standard moved to WCAG 2.2 AA in October 2024. Statements still citing 2.1 are out of date.

Ignoring scanned PDFs. A scanned image of a signed minutes document is not accessible. Text PDFs created from a Word source are. Convert going forward; convert legacy on request.

Forgetting the council newsletter. If the council publishes a newsletter on the website, it falls within the accessibility requirements just like any other content. Use the compliance checklist to walk through every digital channel the council operates.

Sources

• The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — the underlying UK statutory instrument
• W3C — Web Content Accessibility Guidelines (WCAG) 2.2 — the technical standard
• GOV.UK — Accessibility requirements for public sector websites and apps — duty overview
• GOV.UK — Make your website or app accessible and publish an accessibility statement — current template and guidance