It’s 2026. If we still need to specify that a website should be accessible, then something has gone badly wrong.
Accessibility should not be a line item in a quotation. It should not be an optional extra in an RFP. And it absolutely should not be something a client has to remember to ask for. Just as they don’t ask for valid HTML, readable content, or pages without spelling mistakes.
We don’t price those separately. We don’t say, “Ah yes, semantic markup will cost you another 20%.” Accessibility belongs in exactly the same category: part of the baseline of doing the job properly.
“You Didn’t Ask for Accessibility” Is Not a Defence
One of the most common excuses I still hear is: “Well, the client didn’t specify accessibility.”
That’s not a defence. It’s an admission of failure.
If you deliver an inaccessible website, that is your fault. Not the client’s. Not the brief’s. Not the budget’s. Yours.
It means you made a bad decision, took a shortcut, or didn’t understand the consequences of what you were building. Hiding behind the wording of a contract doesn’t change that, it just makes the failure harder to justify.
Depending on your country, or the audience you are serving, delivering an inaccessible website may not just be negligent it may also be illegal. Laws around web accessibility exist in many regions, and failing to meet them can expose you or your client to fines, legal action, or other penalties. Ignorance is not a defence.
Imagine telling a client:
“You didn’t ask for the site to work on mobile.”
“You didn’t ask for it to load in under ten seconds.”
We’d laugh that out of the room. Yet accessibility still gets treated as optional, negotiable, or “nice to have”.
It isn’t.
Joomla Gets This Right — Out of the Box
One of the quiet strengths of Joomla is that, out of the box, it gives you a solid, accessible foundation: semantic markup, sensible defaults, and core features that don’t actively work against accessibility.
Which makes the conclusion unavoidable: if a Joomla site is inaccessible when it’s delivered to a client, someone broke it.
A template choice. A JavaScript widget. A visual flourish that ignored keyboard users. A shortcut taken under pressure.
Accessibility problems are not mysterious. They are introduced deliberately or through carelessness. And that means they are preventable.
“Accessibility Costs More” Usually Means “We Don’t Know How”
Yes, there are edge cases. There are a small number of interactions and visual concepts that are genuinely difficult to implement in an accessible way. But they are rare, and they are not what most websites are built from day to day.
Forms. Navigation. Content. Media. These are solved problems.
When accessibility is priced as a premium feature, what’s really being sold is ignorance insurance. It’s a way of saying, “We don’t know how to do this properly, so we’ll only attempt it if you pay us extra.”
Let me be blunt: if a web developer, site builder, or agency tells you accessibility “costs more,” that is your signal to run away as fast as you can. In 2026, accessibility is a basic skill. If they don’t have it, what other fundamentals are they missing? You do not want to entrust your website, your business, to someone who can’t do the basics.
Accessibility done properly doesn’t slow you down. It removes complexity. It produces cleaner markup, clearer structure, better usability, and fewer fragile fixes later.
Accessibility Overlays Are Not a Safety Net
There’s a particularly dangerous mindset that still crops up: the developer who ignores accessibility during the build because they think they can fix it later by bolting on an accessibility overlay.
That’s not a fallback plan. It’s abdication of responsibility.
Accessibility overlays don’t fix broken markup. They don’t add missing labels, repair heading structures, or make a keyboard-hostile interface usable. At best, they disguise a few symptoms. At worst, they interfere with assistive technologies and actively make things worse.
An overlay is not accessibility. It’s proof that accessibility was ignored when it mattered.
Worse still, overlays encourage exactly the wrong behaviour: build first, think never. They promote the fantasy that accessibility is something you can undo after the fact, rather than something you must get right from the first design sketch and the first line of code.
You cannot outsource accountability to a JavaScript widget.
The Default Should Be Accessible — No Exceptions
An inaccessible website is not a “version” of a website. It is a broken deliverable.
If you’re building websites for the public, then disabled users are part of that public. Always have been. Always will be. Shipping something that excludes them is not an oversight it’s a decision.
And it’s your decision. If you deliver an inaccessible website today, that is professional malpractice. Full stop.
Stop Asking. Start Assuming.
Clients should never have to ask whether a site is accessible. They should be able to assume it, in exactly the same way they assume it won’t be fundamentally broken.
If a client genuinely insists on something that compromises accessibility, that choice should be explicit, documented, and understood by everyone involved. But that should be rare and it should never be the default.
It Isn't Just Best Practice
In 2026, delivering an accessible website isn’t “best practice” it’s basic professional competence.
If a site isn’t accessible when it leaves your hands, it’s entirely your fault and it might even be illegal.
