(Accessible web design) · Norwich · Norfolk
Accessible by design. Not by remediation.
There are two ways a website ends up accessible. It can be designed that way from the first line, or it can be built, audited, found wanting, and patched back up to the line with the paperwork billed on top. Both reach the same standard on paper. Only one of them stays there.
Plenty of agencies will tell you a site is accessible. Far fewer can tell you how they know.
Ask the question and the answers separate quickly. Some point at an automated score, which catches perhaps a third to a half of real issues. Some point at a theme vendor's claim about markup they did not write. A few can describe what was actually tested, by whom, against which criteria, and what they found. That last group is small, and it is the one worth hiring - because accessibility is not a feature you can inspect from the outside. It is a property of how the thing was built.
(The duty)
Where it stops being a courtesy.
The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require public-sector sites to be perceivable, operable, understandable and robust, and to publish an accessibility statement. The regulations themselves never name WCAG - but government guidance is explicit that meeting WCAG 2.2 at A and AA is how you satisfy them, and the Government Digital Service has monitored against 2.2 since October 2024. In Norfolk that sweeps in the county and district councils, NHS trusts and GP federations, the universities and colleges, emergency services, and many arm's-length bodies and larger charities delivering public services.
The Equality Act 2010 requires service providers to make reasonable adjustments so that disabled people are not put at a substantial disadvantage - and a website is a service. There is no Norfolk carve-out and no small-business exemption. Enforcement is lighter-touch than the public-sector regime, but the duty is real, and the commercial cost of a site people cannot use is real regardless of who is checking.
Accessibility requirements travel down the supply chain. If you tender for public-sector work, deliver software into a regulated environment, or sell to a large organisation with its own obligations, you will be asked what standard your product meets and asked to evidence it. Being able to answer is increasingly a condition of being in the room.
The full plain-English guide, including how to check your own site today for free.
(How we work)
Decided before it is built, not audited after.
Every substantial neo optic project starts with a written Secure & Accessible Project Start Standard. Before implementation, we identify who can access what, where trust boundaries sit, which data needs protection, and how people will use the service with keyboards, screen readers, zoom and reduced motion. Those decisions become testable requirements, not promises added after launch.
Why we can stand behind it.
(01)We own the layer where accessibility lives
Owning our platform is not a boast about features - it is what lets us make this commitment at all. Build on someone else's theme, page builder and plugins, and when an accessibility problem lives in that layer, the honest answer is a support ticket and a wait. We do not have that layer. Every line of OliveCore is ours, which means:
- no theme vendor can block a fix;
- no page-builder markup is off-limits;
- no plugin roadmap decides what is possible;
- no licence forbids a change;
- no abandoned dependency forces a compromise.
Whatever an accessibility requirement asks for - improving a component, replacing the renderer, redesigning the editor, rebuilding from line zero - we own the route to it. Requirements evolve; because we own the complete source, we are never trapped by the technology we started with. More on why we own the platform.
(02)The same team, across the life of the site
Most sites are accessible on the day they go live and quietly decay afterwards - a missing image description here, a broken heading order there, a third-party widget added by someone in a hurry. Because the same team owns the editor your people will use, accessibility is something we can keep true across the life of the site rather than hand over and hope. The build and the tools your staff work in are ours, so the standard does not depend on everyone remembering it.
(03)Why it is worth doing properly
Around one in five people has a disability, and far more use the web in ways a careless build quietly shuts out - on a phone in bright sun, with a keyboard instead of a mouse, with the sound off. Accessibility is not charity; it is competence. The techniques that help disabled users tend to help everyone: clear headings, good contrast, fast pages, sensible forms. And accessible does not mean plain. Our own site has a three-dimensional globe, animation and movement, and is built to the same standard - because the decoration sits on top of clean, semantic HTML rather than standing in for it.
(Commissioning)
If you are commissioning for the public sector.
A site gets built on an off-the-shelf theme and a stack of plugins, is found to fall short, and is then audited and remediated back up to the line, with the paperwork billed on top. You pay a great deal to reach a minimum. We start at that line rather than below it, because accessibility is a design input here, not a remediation project stapled to the end.
(01)What you can ask us for
Any site we build can be delivered with an accessibility statement and a conformance report for your specific site, on request - drawn from a foundation that is already sound rather than reconstructed from a stack that never was. The Design Note written at the start of the project is what makes that possible: the requirements were testable from the outset, so the evidence is a record of what was done rather than a document assembled afterwards to satisfy a question.
(02)What we do not claim
We design and build toward WCAG 2.2 AA on a best-efforts basis, and adopt straightforward AAA improvements where they materially help. We do not claim guaranteed compliance, and we would be wary of anyone who does. Conformance is a judgement made against a live site by people testing it, not a badge a supplier can issue itself in advance. What we will do is tell you what has been tested, how, and what has not - including where a browser, a third-party service, an embedded tool or content supplied by someone else introduces a constraint we can flag but not remove.
(03)What stays private
The full internal standard is a working document for our developers, reviewers and deployment engineers - implementation patterns, named controls and configurations, project-specific profiles, test procedures and internal risk decisions. It is more useful as an engineering instrument than as a sales sheet, so we do not publish it. The principles above are what it commits us to, and the evidence produced under it is what comes to you with the project.
Next time someone pitches you a website, ask them one thing: what accessibility standard does it meet - and can they show you? Most cannot answer; many have never been asked. We answer in four characters - 2.2 AA - and can show you what was tested and what was not. The same principle runs through how we handle security and the technology underneath. Ask us - or ask them.
