Accessible from the start costs less than accessible later

TL;DR

• Accessibility bolted onto a finished site is a retrofit, and retrofits are where the cost hides: reopened sign-off, re-testing, a paid audit, and regression work to catch whatever the fixes broke.
• Accessible by default is not exotic. It is semantic HTML, readable contrast, keyboard operability, labelled fields, a visible focus state, and real alt text, all done as you build.
• The same habits that make a site accessible usually make it faster and easier for search engines to read, so performance and SEO tend to come along for free.
• We check every site against WCAG 2.1 before we hand it over, not after a complaint. This site meets WCAG 2.1 AA and scores 100 for accessibility in Lighthouse.
• Building it in from the first commit costs a fraction of adding it later. That is the whole argument.

Accessibility usually arrives at a website the hard way. It comes after a complaint, a failed audit, or a deadline handed down by someone’s legal team. By the time it shows up like that, it is a retrofit, and a retrofit is the most expensive way to get there. We build the other way, accessible from the first commit, because it is cheaper, and the savings are not small.

Why “later” is the expensive version

When you add accessibility to a site that is already signed off, you are not tidying up. You are reopening work that everyone had agreed was done. That is a different kind of cost, and it stacks up fast.

The markup has to change, because the quickest route to an inaccessible site is the wrong element used for the job: a div wired up to behave like a button, a heading that is really just big text, a control a mouse can reach but a keyboard cannot. Changing the markup means the styling has to be rechecked, because the styles were written against the old structure. Rechecking the styling means the whole thing has to be tested again, on a keyboard and with a screen reader this time. Then you pay for the audit that told you the site had a problem, you pay for the fixes, and you pay again for the regression pass that makes sure the fixes did not quietly break something that used to work.

None of that buys the users anything they did not already deserve. It is the same end result, reached by the most expensive road. The general rule that a defect costs more the later you catch it is not special to accessibility, but accessibility is one of the places it bites hardest, because the fixes touch structure, style, and behaviour all at once.

What accessible by default actually means

The phrase sounds like it should involve special tools. It does not. Accessible by default is mostly a set of habits that cost nothing extra when you build with them from the start.

It means using the right HTML element for the job, so a button is a button and a heading is a heading, and assistive technology can tell one from the other without guessing. It means text with enough contrast against its background to actually be read. It means every control can be reached and operated with a keyboard alone, with a focus state you can see, so someone who never touches a mouse can still get through the page. It means every form field has a label a screen reader can announce. It means images carry alt text that says what they are, and the purely decorative ones are marked so they are skipped rather than read aloud as noise.

That list is not our invention. It is the practical core of WCAG 2.1, the recognised standard for web accessibility, and the How to Meet WCAG quick reference turns it into checkable criteria you can hold a build against, one at a time. For the day-to-day mechanics, MDN’s accessibility documentation covers how the markup, the roles, and the keyboard behaviour actually fit together. None of it is extra work when you do it as you build. It is just building the thing correctly the first time, instead of building it twice.

Why it is not only an accessibility win

Here is the part that rarely makes it into the pitch. The site you build this way is usually the fast, well-structured one too.

Clean semantic markup is lighter than a pile of nested divs doing jobs the browser already has elements for. It is easier for a search engine to parse, because the structure tells it what the content is. A page a screen reader can navigate by heading is a page a crawler can understand by the same headings. The habits overlap, which is why building for accessibility quietly improves the two things every founder already cares about: how fast the page loads and how well it ranks.

That overlap is documented, not wishful. Google’s own SEO starter guide leans on the same structural fundamentals, meaningful headings, descriptive link text, and real alternatives for images, that accessibility asks for. And the performance side, the Core Web Vitals, rewards the lean, uncluttered pages that good semantic markup tends to produce. You are not trading one against another. The same work pays three ways.

The standard, and the backdrop

WCAG is not a RavGB house style. It is the yardstick that accessibility requirements in a growing number of places point at, which is a practical reason to build to it even before anyone asks you to. We are deliberately not going to quote you a jurisdiction, a threshold, or a fine, because those vary, they change, and we are not your lawyers. What we will say is the uncontroversial part: the recognised standard exists, it is published in full, and meeting it is a known quantity rather than a guess. If the regulatory picture matters to your project, check it for your own market, and build to the standard either way.

How we build it, and how we check it

Every site we build is accessible by default, and we verify it before we hand it over, not after someone files a complaint. That verification is not a vibe. We run an automated accessibility engine across the pages and read what it reports, and we check the result against the same criteria the standard lists.

We hold our own work to that bar first, because it is the only honest way to claim it for yours. This site, the one you are reading, meets WCAG 2.1 AA. It scores 100 for accessibility in Lighthouse, and 100 for performance, SEO, and best practices alongside it, on an automated accessibility scan that reports zero violations across its pages. It uses no cookies, no analytics, and no third-party trackers to get there. That is not a sales line bolted onto the end of a post. It is the standard we hold our own site to, which is the whole point: a studio that cannot pass the test on its own pages has no business charging you to pass it on yours.

This is of a piece with how we scope every engagement. We say what a thing is and what it is not, in writing, on the page. We wrote up why we tell you what we cannot do yet if you want the reasoning, and you can see the same honesty applied across what we offer on the services page and in who RavGB is.

If you want this from the first commit

Accessible from the start is not a premium tier we upsell. It is simply how we build a website, because building it any other way costs you more later for the same result. You get a site that works for everyone who lands on it, loads fast, and reads clearly to a search engine, all out of the same work, with the repository and the deployment handed over as yours on the day it ships.

That is exactly what our website work is. If you want a site that is accessible from the first commit rather than retrofitted after a complaint, start a website project and tell us what you need. A real person reads every message.