How to make your website accessible: the practical guide with checklist
From colour contrast and alt text to forms and testing — step by step to an accessible website, including a checklist to work through.
An accessible website can be used by everyone — regardless of visual, hearing, motor or cognitive impairments. Since the European Accessibility Act (EAA) began to apply on 28 June 2025, this is no longer just a matter of fairness for many businesses, but an obligation. The good news: you usually don’t have to rebuild your site. Most barriers can be fixed in a targeted way once you know what matters.
This guide shows you, step by step, how to make your website accessible — from colour contrast and alt text to forms and testing. At the end you’ll find a checklist to work through. The legal background is covered in more depth on our pages about the European Accessibility Act and the WCAG; here, the focus is on practice.
What does “accessible” actually mean?
Web accessibility means content and functions are designed so that as few people as possible are excluded. The international benchmark is the Web Content Accessibility Guidelines (WCAG). They rest on four principles — content must be perceivable, operable, understandable and robust. In practice, Level AA is the target that laws like the EAA refer to. More on this in the WCAG guide.
It helps to keep the right picture in mind: accessibility isn’t only about blind people using a screen reader. It also benefits people with low vision or colour blindness, people who navigate by keyboard only, people with motor impairments, people with reading or attention difficulties — and anyone with a situational limitation: bright sunlight on a phone, a broken arm, a noisy place without headphones. Accessibility is always better usability for everyone.
Does my website have to be accessible?
Under the EAA, digital accessibility now applies to many private businesses too — in particular in e-commerce, meaning online shops and digital services. There’s an exemption for microenterprises (fewer than 10 employees and no more than €2 million in annual turnover), but only for services. Which national law applies depends on the markets you serve; the EAA page explains the framework. This is not legal advice.
Even if you’re not obligated, the effort pays off: around one in six people lives with a disability, and the population is ageing. An accessible site widens your audience, improves the experience for everyone, and helps your search rankings — because many accessibility measures (clean structure, good text, fast operability) are good SEO at the same time.
Step by step: how to make your website accessible
1. Ensure sufficient colour contrast
Text must stand out clearly from its background. The WCAG require a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (from roughly 18 pt, or 14 pt bold) and for interactive elements and meaningful graphics. Light grey text on a white background is the classic barrier — and often fixed with a few small changes.
Check your colour combinations with a contrast checker. And never rely on colour alone to convey information: an error message shouldn’t be only red — it needs an icon and text too. People with colour blindness would otherwise miss it.
2. Give images meaningful text alternatives (alt text)
Every image that carries information needs an alternative text describing its meaning — not the obvious, but its purpose in context. For a product photo, “red running shoe seen from the side” is more helpful than “image”. You can skip phrases like “photo of …” — the screen reader announces that anyway.
Purely decorative images get an empty alt attribute (alt="") so screen readers skip them. Functional images — a linked logo, a magnifier icon as a search button — describe the function (“Home”, “Open search”), not the appearance. For complex images like charts, a short alt text isn’t enough; add a longer description or provide the data as a table. For the details and lots of examples, see our guide on how to write alt text.
3. Make everything keyboard operable — with a visible focus
Many people use a website without a mouse: by keyboard, voice control or assistive tech. Anything clickable must also be reachable with the Tab key and triggerable with Enter or Space — in a logical order and without a “keyboard trap” you can’t tab out of.
Just as important: a visible focus indicator. Never remove outline: none without a clearly visible replacement, or you can’t see where you are when tabbing. A “skip to content” link at the top helps bypass the navigation. The simplest test: put the mouse away and operate the page using only Tab, Enter and the arrow keys.
4. Create a clear structure with headings and landmarks
Screen reader users jump from heading to heading — like using a table of contents. That’s why each page needs exactly one H1 and a logical hierarchy of H2s and H3s with no skipped levels. Never use a heading just to make text look bigger; use CSS for that.
In addition, landmarks structure the page: header, nav, main and footer tell assistive technologies where the main areas are. That makes it possible to jump straight to the content or the navigation instead of wading through everything.
5. Write understandable links and buttons
Link text should make sense out of context. “More about accessible forms” is good; “click here” is not — because screen readers can list all the links on a page, and “here, here, here” helps no one. Also mind the semantics: something that triggers an action is a button; something that leads to another page is a link (a). This affects how assistive technologies announce and operate the element.
6. Make your forms accessible
Forms are one of the most common hurdles — especially in checkout, where revenue is at stake. Every input field needs a visible, properly associated label. Placeholder text alone isn’t enough: it disappears as you type and often has too little contrast.
Error messages must clearly state what to do, be linked to the affected field, and not rely on colour alone. Mark required fields unambiguously, group related fields (for example with fieldset and legend), and use sensible autocomplete values so browsers can fill in names and addresses. This helps everyone — and especially people with motor or cognitive impairments.
7. Caption videos and respect motion
Videos need captions, audio content needs a transcript — this helps deaf and hard-of-hearing people and anyone reading along without sound. Avoid auto-playing media; if you can’t prevent autoplay, it must be pausable.
Motion can distract or even harm. Respect the prefers-reduced-motion setting and reduce animations for people who ask for it. Content that flashes more than three times per second is off limits — it can trigger seizures in sensitive people.
8. Mind readability, zoom and target sizes
Users must be able to enlarge text to 200% without content getting lost or overlapping — a responsive, flexible layout is half the battle here. Interactive elements should be big enough; WCAG 2.2 recommends at least 24 × 24 pixels for click and tap targets. Also set the page language correctly (<html lang="en">) so screen readers pick the right pronunciation, and write clearly: short sentences, unambiguous terms, no unnecessary jargon.
How do I test my website’s accessibility?
Best in three layers. First, automated tools like axe, WAVE or Lighthouse: they quickly find typical problems but only cover part of the picture — realistically around 30 to 50 percent. Second, manual tests that no tool replaces: operate the whole site using only the keyboard, test with a screen reader (NVDA is free, VoiceOver comes with Apple devices), check contrast, and view the page at 200% zoom. Third, where possible, involve real users with different needs.
Be honest with yourself here: no automated test makes a site “compliant”, and a green tool result is no guarantee. Automated scans are a good starting point for finding the biggest issues — the fine work stays manual. The Welcoma scanner (coming soon) will show you the issues it finds and point straight to the affected code, so you can fix them at the root.
WordPress and WooCommerce specifics
If your site runs on WordPress, accessibility starts with the theme: favour themes that take accessibility seriously, and review plugins critically — page builders, sliders and pop-ups are common sources of barriers. If you run a shop, pay special attention to checkout, product pages and filters. How to add Welcoma to WordPress is shown on the accessibility plugin for WordPress page.
The biggest mistake: “compliance at the click of a button”
A word of warning about overlay widgets that promise to make your site “legally compliant with one click”: it doesn’t work. Such overlays lay themselves over the page and cover up problems instead of solving them — at worst they interfere with the screen readers people already use. Legally they’re no free pass; abroad there are numerous lawsuits against sites that relied on overlays alone.
That’s why we’re honest about our own product too: the Welcoma menu improves usability for your visitors right away, but no widget makes your site automatically compliant. Compliance only happens once the underlying issues are fixed in the code. That’s exactly what we want to help with — not pretend a script does the work.
Don’t forget PDFs and other documents
Accessibility doesn’t stop at your HTML pages. PDFs — price lists, forms, data sheets — fall under it too if they’re part of your offering. A scanned PDF without a text layer is simply unreadable for screen readers. So make sure there’s real, selectable text instead of images of text, a logical reading and heading structure (tags), alt text for figures, and properly labelled form fields. Often it’s easier and more accessible to offer content as an accessible HTML page rather than forcing it into a PDF.
Accessibility is an ongoing process
A website is rarely “finished”. Every new image, post and feature can introduce fresh barriers. So anchor accessibility in your daily work: write alt text right when you upload images, briefly check new pages with the keyboard before publishing, and add the topic to your editorial and development checklists. That keeps the effort small and spread out, instead of letting it pile up into one big remediation project. Building accessibility in from the start saves time and money — and spares you from scrambling when a complaint or warning arrives.
Don’t forget the accessibility statement
If your offering falls under the EAA, an accessible website also includes an accessibility statement. What goes in it, and how it differs from the public-sector version, is covered in the accessibility statement guide.
Quick checklist
- Colour contrast: 4.5:1 (text), 3:1 (large text, interactive elements)
- Never convey information through colour alone
- Alt text for informative images, empty
altfor decorative ones - Fully keyboard operable, visible focus, skip link
- Exactly one H1, clean heading hierarchy, landmarks
- Meaningful link and button text, correct semantics
- Forms with visible labels and clear, linked error messages
- Captions for videos, transcripts for audio
- Respect
prefers-reduced-motion, no strong flashing - Zoom to 200%, target sizes ≥ 24 px,
langattribute set - Tested with keyboard, screen reader and an automated tool
- Accessibility statement published (if you fall under the EAA)
How Welcoma helps
Welcoma works on two fronts. The on-screen menu gives your visitors tools right away — contrast, text size, read-aloud, reading aids and ready-made profiles for different needs. And the WCAG scanner (coming soon) will track down the actual causes in the code and show you where to fix them. What it costs is shown transparently on the pricing page. The honest part stays: responsibility for the implementation remains with you — we just make it much easier.
Guides that go deeper
Focused guides on the individual steps:
- How to test accessibility — automated tools, manual checks and their limits.
- Keyboard accessibility — operate a site without a mouse, and the WCAG criteria behind it.
- Writing alt text — meaningful text alternatives for images.
- Accessible web design — design and development fundamentals.
- WordPress accessibility — what plugins and themes can and cannot do.
- Plain vs easy language — when simpler language is required, and when it is a value-add.
- What an accessible website costs — the cost factors and the biggest lever.
Frequently asked questions
How long does it take to make a website accessible?
It depends on size and starting point. The most common issues — contrast, alt text, form labels — are often fixed in days. A full alignment with WCAG 2.1 AA can take weeks depending on scope. The important thing is to start early.
Is a plugin or widget enough to make my website accessible?
No. A widget or menu improves usability, but accessibility only happens once the underlying causes are fixed in the code. Be wary of providers promising “automatic compliance”.
What does it cost to make a website accessible?
Much of it can be done at no cost with your own effort. Costs come mainly from working time, and possibly audits or developer hours. Tools like Welcoma reduce the ongoing effort.
Which standard applies?
The benchmark is the WCAG, in practice Level AA, anchored legally through the EAA and the EN 301 549 standard. Details in the WCAG guide.
What’s the first step?
Get an overview: operate your site using only the keyboard and run an automated test. Then work through the findings using the checklist above.
This guide is not legal advice. For a binding assessment of your specific case, consult a qualified professional.
Where does your site stand?
Check your website and see which barriers are worth fixing first.