Accessibility Is a Feature, Not a Checkbox
“The best websites aren’t designed for the average user. They’re designed so everyone has the opportunity to become one.”
When accessibility comes up in web development, the conversation usually starts in the same place.
WCAG.
ADA.
AODA.
Government regulations.
Compliance audits.
Legal requirements.
Those things are important, and if you’re building websites professionally, understanding them is part of the job.
But I’ve always thought they answer the wrong question.
I don’t build accessible websites because legislation tells me to.
I build accessible websites because I don’t want to exclude people.
To me, accessibility isn’t about avoiding lawsuits.
It’s about building software properly.
Every Visitor Is an Opportunity
One of the biggest mistakes businesses make is thinking accessibility only benefits a small percentage of users.
It doesn’t.
Every person who visits your website represents an opportunity.
They might become a customer.
They might make a donation.
They might subscribe to your newsletter.
They might recommend your business to someone else.
They might click an advertisement.
They might apply for a job.
They might simply remember your company the next time they need your services.
You don’t know why someone is visiting your website.
And that’s exactly the point.
Every visitor has value.
So why would you intentionally make it more difficult for someone to interact with your business?
Accessibility Isn’t Just About Disabilities
When people hear the word accessibility, many immediately think about screen readers.
That’s certainly part of it.
But accessibility affects far more people than many realize.
Think about someone trying to use your website:
- On a mobile phone in bright sunlight.
- With a temporary injury that makes using a mouse difficult.
- With aging eyesight.
- In a noisy environment where captions are helpful.
- Using only a keyboard.
- With slower internet or older hardware.
Accessibility isn’t about designing for a small group of users.
It’s about designing for the real world.
And the real world isn’t perfect.
Good Accessibility Is Good Design
One thing I appreciate about accessibility is that many best practices also improve the experience for everyone.
Clear heading structures make pages easier to scan.
Descriptive link text improves navigation.
Good colour contrast makes content easier to read.
Logical keyboard navigation benefits power users.
Well-labelled forms reduce confusion.
Captions help people in quiet libraries just as much as noisy airports.
These aren’t accessibility features.
They’re examples of thoughtful design.
When you improve accessibility, you often improve usability for every visitor—not just those with specific accessibility needs.
Accessibility Doesn’t Have to Be Difficult
There’s another misconception that accessibility is expensive.
It certainly can be if it’s ignored until the end of a project.
Retrofitting accessibility into an existing application is often far more difficult than building it correctly from the beginning.
But when accessibility becomes part of your development process, many of the fundamentals become second nature.
Use semantic HTML.
Associate labels with form fields.
Write meaningful alternative text for images.
Support keyboard navigation.
Maintain sufficient colour contrast.
Use headings in the correct order.
Avoid relying solely on colour to communicate important information.
None of these practices are particularly complicated.
They’re simply part of writing quality software.
Accessibility Reflects Craftsmanship
To me, accessibility sits alongside other qualities that define good engineering.
Performance.
Security.
Maintainability.
Reliability.
None of those are features users specifically ask for.
No client has ever said:
“Can you make the codebase easier for future developers to maintain?”
They ask for outcomes.
A faster website.
A reliable application.
A system people enjoy using.
Accessibility is no different.
Visitors may never consciously notice that your website is accessible.
They simply notice that it works.
And that’s exactly how good engineering should feel.
Accessibility Is Good Business
Sometimes accessibility is presented as though it’s a cost.
I see it as an investment.
Every barrier you remove makes it easier for someone to become a customer, donor, volunteer, subscriber, or advocate for your organization.
Every improvement increases the number of people who can successfully interact with your business.
That’s not just good engineering.
That’s good business.
If you’re spending time and money attracting visitors to your website through advertising, search engine optimization, referrals, or social media, why would you create unnecessary obstacles once they arrive?
You’ve already invested in getting them there.
Accessibility helps ensure they can actually use what you’ve built.
It’s Never About the Checklist
One of the things I dislike about accessibility audits is that they sometimes reduce an important conversation to a checklist.
Pass.
Fail.
Fix.
Repeat.
Checklists are useful.
But they shouldn’t become the objective.
The objective should always be the person using the website.
Every accessibility decision ultimately comes down to one question:
Can another human being successfully accomplish what they came here to do?
If the answer is no, it doesn’t matter whether you’ve technically passed an audit.
You’ve still failed the person.
Final Thoughts
I’ve never viewed accessibility as an optional feature.
I don’t see it as something you add after launch.
And I certainly don’t see it as something you implement simply because regulations require it.
I see it as a reflection of the quality of the software itself.
Because at the end of the day, websites aren’t built for developers.
They’re built for people.
Every visitor represents an opportunity.
Every visitor deserves the ability to use your website.
Accessibility isn’t a checkbox.
It isn’t a compliance exercise.
It’s part of building software professionally.
And in my opinion, that’s exactly where it belongs.
Highland Principle #4: A website that excludes users isn’t finished—it’s incomplete.