Accessibility and performance

Accessibility audits

We test against WCAG 2.2 AA using automated tools and, more importantly, manual checks: keyboard-only navigation, screen reader testing, colour contrast, form labelling, focus order and alternative text. You get a prioritised list of issues with clear fixes, not a 200-page PDF.

Accessibility statements

Public sector websites in the UK need an accessibility statement. We can help draft one based on the audit, listing known issues and plans to fix them.

Speed improvements

We measure real-world performance using Core Web Vitals, then fix the biggest causes of slowness: oversized images, render-blocking scripts, heavy third-party embeds and slow hosting. Often the largest gains come from removing things rather than adding them.

Who this work is for

Accessibility and speed matter to every website, but in Cambridge some organisations have particular reasons to act.

• Colleges, departments and university-linked bodies, which are generally treated as public sector under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 and need to meet WCAG AA and publish an accessibility statement.
• NHS-linked organisations, councils and charities, many of which have similar duties or serve audiences with a high proportion of disabled users.
• Life science and technology companies whose customers or partners include public bodies, and who increasingly see accessibility questions in procurement.
• Small local businesses whose customers mostly arrive on phones, sometimes on patchy connections, and who lose enquiries every time a page is slow or a form is awkward.

We work on sites we have built and on sites built by another web agency or in-house team. Where we cannot change the code directly, we give your developers clear, testable fixes.

What is included, step by step

1. Scope the journeysWe agree the templates and tasks that matter most: the homepage, key landing pages, forms, booking or application journeys, and document downloads. Testing every page of a large site is rarely the best use of budget; testing every template usually is.
2. Automated checksWe run accessibility and performance tools across the chosen pages to catch the quick, measurable issues: contrast, missing labels, missing alt text, invalid markup, oversized images and blocking scripts.
3. Manual accessibility testingWe navigate each journey using only a keyboard, then with screen readers, magnification and reduced motion settings. This is where most of the serious problems appear: focus traps in menus, unannounced form errors, and content that makes no sense out of visual context.
4. Performance analysisWe look at Core Web Vitals field data where available and test on a mid-range phone over a throttled connection, then trace each slow page to its causes.
5. Report and prioritiseYou get a report grouped by template and severity, mapped to WCAG 2.2 success criteria, with a plain description of each issue and a suggested fix.
6. Fix and retestWe fix the issues ourselves or support your team while they do, then retest to confirm each fix works. If you need an accessibility statement, we help draft it from the findings.

How long it takes

An audit of a small site with a handful of templates typically takes one to two weeks, including the report. Larger sites with many templates, complex forms or lots of documents take longer. Fixes depend on what is found and who implements them: some are one-line changes, others mean reworking a menu or a form component. We give a realistic plan after the audit.

Issues we find most often

What drives the cost

• Number of distinct templates and journeys, rather than the raw number of pages.
• Complexity of interactive parts: booking systems, application forms, maps, data visualisations and embedded third-party tools all take longer to test.
• Documents. A site with hundreds of PDFs needs a strategy for them, not just a page audit.
• Who makes the fixes. Fixes on a site we host are quick to make and verify. Supporting another development team adds coordination time.
• Retesting. We include one retest round as standard; further rounds depend on how fixes are delivered.

Common mistakes

• Relying on an overlay widget instead of fixing the code. Overlays do not make a site compliant and can interfere with the tools disabled people already use.
• Treating an automated score as proof. Tools miss most of the issues that actually stop people completing tasks.
• Fixing pages instead of templates, so the same problem reappears with every new article or event.
• Chasing a perfect speed score on a test tool while real visitors on phones still wait for a heavy chat widget to load.
• Publishing a statement that claims full compliance when known issues remain.

Why speed matters for Cambridge audiences

A lot of Cambridge browsing happens on the move: visitors planning a day around the colleges on a phone, staff checking a supplier between buildings on a campus, commuters on the train or the guided busway. Patchy signal and mid-range phones are the normal case, not the exception. A page that loads in a moment on a fast office connection can take many seconds on a phone in a basement café or a crowded station.

We treat performance as a set of budgets rather than a score. We agree how heavy a page may be, how many third-party scripts it can load and how quickly the main content should appear, and then design within those limits. When a new feature would break a budget, the trade-off becomes a conscious decision rather than an accident.

Keeping a site accessible after the audit

Most sites drift after an audit, because new content and features are added by people who were not involved. We help prevent that by leaving behind short guidance for editors, covering headings, link text, alt text and documents, by adding checks to the development process where we maintain the code, and by suggesting a light annual retest of the key journeys. For organisations with many editors, such as college offices and departments, a short training session is often worth more than another audit.

How we measure success

For accessibility, success means the agreed journeys can be completed with a keyboard and common assistive technology, the WCAG 2.2 AA issues found are fixed or documented with a plan, and your team knows how to avoid reintroducing them. For performance, we compare Core Web Vitals and test results before and after, and check that the improvements hold on real mobile devices.