Journal
Website accessibility for colleges, charities and public bodies
Accessibility rules apply to many organisations in and around the university. Here is where to start.
Cambridge has an unusual concentration of organisations with accessibility obligations: colleges, university departments, NHS trusts on the Biomedical Campus, local councils, museums and many charities. Even where there is no legal requirement, there is a clear expectation that public-facing websites can be used by everyone.
This article is a practical starting point, not legal advice. If you are unsure of your obligations, check with your organisation’s compliance or legal team.
What the rules say, in brief
In the UK, public sector bodies are covered by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, which came into force on 23 September 2018. These require websites to meet the Web Content Accessibility Guidelines (WCAG) at level AA and to publish an accessibility statement. The Government Digital Service monitors a sample of public sector websites, and since October 2024 has tested against WCAG 2.2 AA.
Universities and many university bodies are generally treated as public sector for these purposes. Separately, the Equality Act 2010 requires service providers, including private companies and charities, to make reasonable adjustments for disabled people, which can extend to websites.
Who benefits
Accessibility is often thought of as being about screen reader users, but it covers a much wider group:
- People with low vision who use magnification or high contrast.
- People who navigate by keyboard, switch device or voice.
- People with cognitive or learning disabilities who benefit from clear structure and plain language.
- People who are deaf or hard of hearing and rely on captions.
- Anyone using a phone in bright sunlight, with one hand, or with a temporary injury.
The common problems
When we audit sites for Cambridge organisations, the same issues come up again and again:
- Low colour contrast, often in pale grey text or brand colours used for links.
- Missing or unhelpful alt text on images, especially on news and event pages.
- PDFs that are scanned images or have no structure, often for prospectuses, minutes and forms.
- Forms without proper labels or with error messages that are not announced.
- Keyboard traps in menus, carousels and embedded widgets.
- Video without captions, including recorded lectures and events.
- Headings used for styling rather than structure.
Where to start
1. Test the main journeys
Pick the tasks most people come to your site to do: find opening times, book a room, apply for a place, make a donation, contact someone. Try each one using only a keyboard. Then try it with a screen reader (VoiceOver is built into Macs and iPhones; NVDA is free for Windows). You will learn more in an hour than from any automated report.
2. Run an automated check
Automated tools catch perhaps a third of issues, but they catch them quickly: contrast, missing labels, missing alt text, invalid markup. Run one across your key templates and fix what it finds.
3. Fix templates, not pages
Most issues come from templates and components used across the site. Fixing the news template once fixes every news article. This is why accessibility is much cheaper to build in during a redesign than to retrofit.
4. Deal with documents
PDFs are a frequent problem. Where possible, publish content as HTML pages instead. Where a PDF is necessary, make sure it is tagged, has a logical reading order and real text. Older documents that are no longer needed can often be archived.
5. Write the statement
Your accessibility statement should be honest about known issues and your plans to fix them. A statement that claims full compliance when there are obvious issues does more harm than one that admits gaps.
What WCAG 2.2 added
WCAG 2.2 added several success criteria that are worth checking specifically, because older sites built to WCAG 2.1 will not have considered them. Across levels A and AA these include:
| Criterion | In plain terms | Where it often fails |
|---|---|---|
| Focus not obscured | When you tab to an item, it should not be hidden behind sticky headers or cookie banners | Sticky navigation, chat widgets |
| Dragging movements | Anything done by dragging should also work with a simple click or tap | Sliders, sortable lists, maps |
| Target size (minimum) | Buttons and links should be large enough, or spaced enough, to hit reliably | Icon links, footer links, small close buttons |
| Consistent help | Help options such as contact details appear in the same place across pages | Sites where the contact link moves around |
| Redundant entry | Do not make people type the same information twice in one process | Multi-step booking and application forms |
| Accessible authentication | Logging in should not depend on memory puzzles or transcribing codes without alternatives | Member areas, staff portals |
A first-week plan for a small team
- Day 1: list your five most important user journeys.
- Day 2: test each with keyboard only and note every problem.
- Day 3: run an automated checker on one page of each template.
- Day 4: list your PDFs and decide which to convert, fix or archive.
- Day 5: rank everything by impact and effort, and agree who fixes what.
That plan will not make a site compliant in a week, but it turns a vague worry into a list of specific jobs. Our accessibility and performance service can take it from there, and if you are a college events office, the case studies on our work page show how we approach that kind of site.
Avoid overlays
You may be offered an accessibility overlay: a script that adds a toolbar to your site and claims to make it compliant. These do not fix underlying problems and can interfere with the assistive technology people already use. Many disabled users and accessibility specialists actively object to them. Fix the code instead.
Events, video and teaching material
Colleges and departments publish a lot of time-based content: open days, public lectures, seminars, conferences and recorded talks. These are easy to overlook in an audit because they change so often. Make sure event listings use real text rather than images of posters, that booking forms are keyboard accessible, and that recorded talks have accurate captions rather than unedited automatic ones. Live events streamed online should have a way for people to request captions or a transcript.
Teaching and outreach material aimed at schools or the public deserves the same care. Plain language, clear headings and accessible downloads make it usable by far more people, including the families and teachers it is often meant for.
What goes in an accessibility statement
GOV.UK publishes a model statement that public sector bodies can adapt, and it is a sensible template even for organisations that are not legally required to publish one. The main parts are:
- Which website or app the statement covers.
- How accessible the site is, including a list of known problems in plain language.
- How people can request content in another format and how quickly you will respond.
- How to report a problem, and what to do if they are not happy with your response.
- The compliance status against WCAG, and the reasons for any content that does not meet it.
- How and when the site was tested.
- What you plan to fix, and by when.
Keep the statement dated and review it whenever you make a significant change to the site. An out-of-date statement is one of the things monitoring regularly picks up.
Make it part of the process
Accessibility is not a one-off project. New content, new staff and new features introduce new issues. Practical habits help:
- Include accessibility checks in content editor training.
- Make alt text a required field in your CMS.
- Check new components before they go live.
- Re-audit key journeys once a year.
Done this way, accessibility stops being a compliance worry and becomes part of what makes the site good.