Web accessibility: why it matters and how to get started

About one in five people lives with some form of disability. That’s 20% of your potential audience who might not be able to use your website. And here’s the thing: accessibility improvements almost always make a site better for everyone, not just people with disabilities.

What is web accessibility?

Web accessibility means building websites that work for people with disabilities. We’re talking about people who:

• Are blind or have low vision
• Are deaf or hard of hearing
• Have motor impairments
• Have cognitive disabilities
• Rely on assistive technologies like screen readers

It’s a broad spectrum, and the solutions are often simpler than you’d think.

Why you should care

It’s simply the right thing to do

Everyone deserves equal access to information and services online. Full stop.

It’s good for your bottom line

• Larger audience: 15-20% of people have disabilities
• Better SEO: accessible sites tend to rank better because search engines reward good structure
• Legal protection: many countries now require accessibility compliance
• Better UX overall: things like clear navigation and readable text help every single user

The law is catching up

In the EU, public sector websites already must meet accessibility standards. Private sector requirements are expanding too. Getting ahead of this now saves you headaches later.

The WCAG guidelines

The Web Content Accessibility Guidelines (WCAG) are the standard everyone references. There are three levels:

Most organizations aim for WCAG 2.1 AA compliance. That’s the sweet spot between effort and coverage.

Things you can fix today

Alt text on images

Screen readers can’t see images. Without alt text, a blind user has no idea what’s there.

<!-- Bad -->
<img src="team.jpg">

<!-- Good -->
<img src="team.jpg" alt="Our team meeting in the Tirana office">

Write alt text that conveys the purpose of the image, not just what it literally shows. If the image is decorative, use an empty alt="" so screen readers skip it.

Proper heading structure

Headings aren’t just visual styling. Screen reader users jump between headings to navigate a page, so the hierarchy matters.

<!-- Bad: Skipping levels -->
<h1>Page Title</h1>
<h3>Section</h3>

<!-- Good: Proper hierarchy -->
<h1>Page Title</h1>
<h2>Section</h2>
<h3>Subsection</h3>

Color contrast

Text needs enough contrast against its background. The minimum ratios:

• 4.5:1 for normal text
• 3:1 for large text (18pt+ or 14pt bold)

Use the WebAIM Contrast Checker to test your colors. You’d be surprised how many “nice looking” color combos fail this.

Keyboard accessibility

Plenty of users can’t use a mouse. Some use keyboard-only navigation, some use switch devices, some use voice control. Make sure:

• All interactive elements are focusable
• Focus order follows a logical path through the page
• Focus indicators are visible (seriously, don’t remove outlines just because they look ugly)

Form labels

Every form input needs a proper label. Placeholders are not labels.

<!-- Bad -->
<input type="email" placeholder="Email">

<!-- Good -->
<label for="email">Email</label>
<input type="email" id="email">

Testing your site

Automated tools

These are free and catch the obvious stuff:

• WAVE: browser extension for quick visual checks
• Lighthouse: built into Chrome DevTools, gives you a score
• axe DevTools: more comprehensive, good for developers

Manual testing

Here’s the catch: automated tools only find about 30% of accessibility issues. You also need to:

• Navigate your entire site with keyboard only
• Try a screen reader (VoiceOver on Mac, NVDA on Windows)
• Zoom to 200% and check nothing breaks
• Disable images and see if the page still makes sense

The manual testing is where you actually find the painful issues. A button that technically passes automated checks can still be unusable if the focus order is nonsensical.

Mistakes we see constantly

• Images without alt text: the most common issue by far
• Low color contrast: especially on light gray text
• Missing form labels: placeholder text doesn’t count
• Keyboard traps: modals you can’t escape without a mouse
• Auto-playing media: disorienting for screen reader users
• Removed focus outlines: CSS outline: none with no replacement is a nightmare for keyboard users

How we approach accessibility

We build accessibility in from the start rather than bolting it on at the end. That means semantic HTML structure, ARIA labels where native elements aren’t enough, skip links for keyboard users, proper contrast ratios, and testing with actual assistive technology.

It’s much cheaper and easier to build accessibly from day one than to retrofit an existing site.

Resources

• WebAIM : practical, no-nonsense accessibility resources
• A11y Project : community-driven checklist and guides
• WCAG Quick Reference : the official spec, filterable by level

Get an accessibility review

If you have an existing site and aren’t sure where it stands, we can run an audit and give you a prioritized list of what to fix first, ordered by actual user impact rather than just automated tool severity.

Get in touch and we’ll take a look.