← back to blog

7 min read#ux & design#websites#seo

Web Accessibility Basics: Why It Matters and 10 Quick Wins

Web accessibility (a11y) basics for business owners: who it helps, how it affects SEO and sales, the WCAG essentials and quick wins to fix this week.

Web accessibility (often shortened to a11y) means your website can be used by everyone — including people with visual, hearing, motor or cognitive impairments, and anyone in a tough situation like bright sunlight, a cracked screen or one busy hand. It matters because it widens your audience, improves usability for all visitors, supports SEO and, in the EU, is increasingly a legal requirement. The good news: many of the biggest improvements are quick and cheap.

Below: who benefits, what the WCAG standard asks for, and ten quick wins to check on your site this week.

Who benefits from an accessible website?

Accessibility isn't a niche feature for "a few users". Think of it in three groups:

  • Permanent: people who are blind or have low vision, are deaf, have limited hand mobility, dyslexia or other conditions.
  • Temporary: a broken arm, an eye infection, recovering from surgery.
  • Situational: a phone in the sun, a noisy bus without headphones, a baby in one arm, a slow connection.

People with disabilities use the web with assistive technology: screen readers that read the page out loud, screen magnifiers, voice control, keyboard-only navigation, switch devices. Your site either works with these tools — or it silently locks people out.

Why web accessibility matters for business

More customers

Every person who can't complete a booking or checkout is a lost customer — and often their family too. Older adults are a large and growing group online, and they benefit directly from readable text, clear contrast and simple forms.

Better UX for everyone

Accessibility and good UX overlap heavily: clear labels, visible focus, logical structure, readable text and forgiving forms help every visitor. It's one of the core principles in our guide on how to build good UI/UX.

SEO support

Search engines read your page a lot like a screen reader does: headings, link text, alt text for images, a clean HTML structure. Accessibility doesn't guarantee rankings, but the same basics that help assistive tech also help Google understand your content — many of them are on our SEO checklist before launch.

The European Accessibility Act has applied since 28 June 2025 to a range of products and services offered to consumers in the EU — including e-commerce, banking, e-books and passenger transport services. Microenterprises that provide services (fewer than 10 employees and up to €2 million annual turnover or balance sheet) are exempt. Public sector websites in the EU have had their own accessibility rules for years. If you sell to customers in Romania or elsewhere in the EU, check which rules apply to you — this article is not legal advice.

WCAG in one minute

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the international standard. The current version is WCAG 2.2 (a W3C Recommendation since October 2023); it builds on WCAG 2.1, which the European standard EN 301 549 references. Most laws and policies point to level AA. It's built around four principles — POUR:

PrincipleMeaningExample
PerceivablePeople can see or hear the contentAlt text, captions, enough contrast
OperablePeople can use the interfaceKeyboard navigation, big enough targets, no traps
UnderstandableContent and behavior make senseClear labels, helpful errors, consistent navigation
RobustWorks with different browsers and assistive techValid, semantic HTML

You don't need to memorize the whole standard. The WCAG quick reference and the web.dev accessibility course are great starting points for your developer.

10 quick accessibility wins

1. Enough color contrast

Normal text needs a contrast ratio of at least 4.5:1 against its background, large text and UI elements like input borders and icons at least 3:1. Light-grey text on white is the most common failure. Check with your browser's DevTools or any contrast checker.

2. Don't rely on color alone

"Fields in red are required" doesn't work for people with color blindness. Add text, icons or patterns: an asterisk plus the word "required", an error icon next to the message.

3. Alt text for meaningful images

Describe what matters in the image: alt="Blue ceramic mug, 350 ml" on a product photo. Decorative images get an empty alt="" so screen readers skip them.

4. Real headings in the right order

Use one H1 and then H2, H3 in a logical outline — not bold text pretending to be a heading. Screen reader users jump between headings to scan a page, just like sighted users skim.

5. Everything works with a keyboard

Try your site with only the Tab, Shift+Tab, Enter and Space keys. Can you reach every link, open the menu, fill the form and close pop-ups? Can you see where you are?

6. Visible focus

Never remove the focus outline without replacing it. A clear focus style is a small bit of CSS:

:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

currentColor reuses the element's text color, so the outline stays visible on light and dark backgrounds. If you pick a brand color instead, make sure it has at least 3:1 contrast against the background.

7. Labels on every form field

A placeholder is not a label — it disappears as soon as someone types. Each input needs a visible <label> connected to it, and errors should explain how to fix the problem, next to the field.

"Click here" and "Read more" mean nothing out of context. "Download the price list (PDF)" or "Read more about delivery" works for everyone. Use real <button> and <a> elements, not clickable <div>s.

9. Big enough touch targets

WCAG 2.2 (criterion 2.5.8, level AA) asks for targets of at least 24×24 CSS pixels or enough space around smaller ones; Apple recommends 44×44 points and Google's Material Design 48×48 dp for comfortable tapping. This matters most on phones — see our guide to mobile-first design.

10. Respect user settings

Let text scale when someone increases the font size, don't break the layout at 200% zoom, set the page language (<html lang="ro">) so screen readers pronounce it correctly, and tone down animations for people who enable "reduce motion".

How to test accessibility yourself

  1. Keyboard test: unplug the mouse for five minutes and try the main task.
  2. Zoom test: set browser zoom to 200% and check nothing overlaps or disappears.
  3. Automated check: run Lighthouse in Chrome DevTools (Accessibility section). It catches common issues like missing alt text or low contrast — but not everything.
  4. Screen reader test: try VoiceOver (built into Mac and iPhone), TalkBack (Android) or the free NVDA (Windows) on your key page for a few minutes. It's eye-opening.
  5. Ask real users: if possible, include someone who uses assistive tech in your testing.

FAQ

Is web accessibility required by law in Moldova?

Requirements in Moldova depend on the sector and keep evolving, so check the specifics for your case with a lawyer. If you sell to consumers in the EU, the European Accessibility Act may apply to you even if your company is registered in Moldova. Either way, building to WCAG 2.2 AA is the safe, widely accepted target.

Does accessibility make a website look boring?

No. Accessible sites can be bold, colorful and modern — this site pairs an acid-lime accent with a near-black background, and its text stays well above the 4.5:1 minimum. Accessibility limits bad choices, not creativity.

Is it expensive to make a site accessible?

Building it in from the start adds little cost, because it's mostly about doing HTML, CSS and design properly. Retrofitting an old, inaccessible site costs more — which is another reason to plan for it early.

Are accessibility overlay widgets enough?

No. Toolbar-style plugins that promise "one-line accessibility" can't fix missing labels, broken keyboard navigation or poor structure, and sometimes make things worse. Real fixes happen in the code and design.

Build a site that works for everyone

Accessibility is part of quality, not an extra. When you sketch your project in the builder, I treat contrast, keyboard support, semantic markup and accessible forms as a standard part of website development — so more people can actually use what you've built.