Making a website accessible: how to ensure everyone can use your site
A website can look perfectly fine on your laptop and still be almost unusable for someone else. Think of a visitor who doesn’t use a mouse, enlarges text heavily, browses with a screen reader, can’t play audio, or can temporarily use only one hand. Making a website accessible means taking such situations into account in your design, content and code.
That doesn’t have to start with a legal dossier or a long list of technical terms. The best first step is much simpler: try using your own website in a different way than you’re used to. Where do you get stuck? What information disappears? Which button can only be operated with a mouse? Such small tests quickly make it clear where the real barriers are.
Short answer An accessible website can be used by as many people as possible, including those with a visual, auditory, motor or cognitive impairment. Start with keyboard operation, visible focus, logically structured headings, sufficient contrast, useful alt texts, clear forms and accessible interactive elements. An automatic checker is useful, but by itself it does not prove that your website is accessible.
What does it mean to make a website accessible?
Digital accessibility isn’t about a separate, simplified version of your website. The goal is that the same website can be used by more people, with different devices and assistive technologies.
For someone who is blind or visually impaired, this can mean that a screen reader can read the page aloud in a logical order. For someone with a motor impairment, the site must be usable without a mouse. Captions help deaf and hard-of-hearing people, but also someone watching a video on a train without sound. Good contrast helps people with reduced vision as well as anyone viewing a bright screen outdoors.
The international WCAG guidelines bring such requirements together in four principles: content must be perceivable, operable, understandable, and robust. WCAG 2.2 is the current W3C version and adds, among other things, additional criteria around focus, touch targets, dragging, and accessible authentication.
First, do this quick accessibility check
You don’t have to be a developer to find the first issues. Open your website and try the following checks:
- Put your mouse aside. Can you navigate through menus, buttons, forms, and pop-ups using Tab, Shift+Tab, Enter, and Escape?
- Zoom the page to 200%. Does the text remain readable and does important content remain usable without parts overlapping or disappearing?
- View the page on your phone and increase the text size there too. Can you still access the menu, the cookie buttons, and the most important actions?
- Open a form and deliberately make a mistake. Is it clear which field is incorrect, why, and how to fix it?
- Turn off the sound on a video. Does the message remain understandable through captions or a text alternative?
- Look at links and buttons. Do you still understand their function if you would only hear the link text or button text?
If you want to follow a neutral first check, W3C Easy Checks offers a set of simple manual tests. See this as an initial screening, not a full audit.
1. Make sure the entire website works with a keyboard
One of the most useful tests is surprisingly simple: use your website without a mouse. Using the Tab key, you should be able to move from one interactive element to the next. With Enter or Space you should be able to perform actions, and with Escape you should, for example, be able to close an open menu or dialog box when that makes sense.
Pay special attention to navigation menus, cookie banners, filters, forms, sliders and pop-ups. These are often the places where a website looks good visually, but where keyboard users get stuck.
Anyone who wants to make a website accessible for blind and visually impaired visitors benefits from this too: screen readers work much better when the underlying controls and order are logical.
2. Always show where the keyboard focus is
When you tab through a page, you should be able to see which element is active. A clear focus outline around a link, button or input field prevents the user from having to guess where they are on the page.
So don’t remove the default focus style just because a designer doesn’t like the outline. You can style the focus to match your brand, as long as it remains visible and has sufficient contrast with its surroundings.
WCAG 2.2 pays extra attention to focus: an active element must not disappear completely behind other content. This is, for example, relevant with sticky headers, cookie panels and fixed chat buttons.
3. Structure your page with real, logical headings
An H1, H2 or H3 is not a way to make text bigger. Headings describe the structure of the page. This allows visitors to scan quickly and allows screen readers to jump from heading to heading.
Use one clear page title and then work hierarchically. An H3 belongs under an H2, not because the font size turns out nicer, but because content-wise it is a part of that H2.
That same discipline is also good for search engines: Google recommends descriptive titles, clear headings, and semantic HTML. That doesn’t mean WCAG compliance in itself is a ranking factor. Accessibility is first and foremost for users; some good practices simply overlap with good SEO.
4. Check contrast, text size, and zooming
Light gray text on a white background may look elegant, but for many people it is hard to read. The same applies to text on top of a photo or a button where the text and background barely differ from each other.
WCAG uses measurable contrast criteria. For regular text, 4.5:1 is a well-known AA threshold; for large text, 3:1 generally applies. Also, don’t let color be the only way you communicate an error, status, or choice.
Also test what happens when someone enlarges text. The visitor should not lose important information because elements fall out of view, slide over each other, or are only readable with horizontal scrolling.
5. Write alt text that explains the function of an image
Alt text is not a place to stuff extra keywords. It is a text alternative for someone who doesn’t see the image. Therefore, describe what the image contributes in this specific context.
A photo that is purely decorative usually doesn’t need descriptive text and can be given an empty alt value. A chart with important figures, on the other hand, requires more explanation than one short sentence. Put the essence in the regular text as well, or provide a longer description.
Good alt text can be useful both for accessibility and for Google Images, but write it for the user first. A string of keywords helps no one.
6. Make link and button text understandable without visual context
A screen reader user can have a page summarized as a list of links. Ten times ‘click here’ then says nothing. Use texts that describe the destination or action: ‘View our webmaster services’ is, for example, clearer than ‘More info’.
The same goes for icon buttons. A magnifying glass is recognizable to many sighted visitors as search, but a screen reader needs an accessible name. Where possible, use real HTML buttons with clear text or a clear name.
7. Make sure forms remain understandable even when there are errors
Contact and checkout forms are commercially important parts of a website. Accessibility issues often hit hard there: invisible labels, unclear required fields, error messages that only turn red, or a form that after an error starts again at the top without explanation.
Give each field a real label, make it clear what information is expected, and describe errors in plain language. ‘Invalid input’ is less helpful than ‘Enter a valid email address, for example name@company.be’.
Also check whether the error message is programmatically linked to the correct field. That is technical work, but it makes a big difference for screen readers.
8. Provide alternatives for video and audio
If important information is only spoken, you exclude people who cannot hear the sound. Good captions help deaf and hard-of-hearing people and are also useful in environments where sound is undesirable.
For audio, a transcript can be a good solution. For video in which relevant information appears only visually, additional description may be needed. The right alternative depends on the content; one automatically generated set of captions without review is not always sufficient.
9. Don’t forget menus, pop-ups, and cookie banners
A website can be quite accessible on the regular pages and still break down on a single overlay. A cookie banner that blocks the entire page but can’t be closed with the keyboard makes the rest of the website practically unreachable.
Therefore, test navigation menus, modals, chat windows, filters, cookie preferences, and other layers separately. Focus should move to an opened dialog, the user must understand what has opened, and after closing should be able to continue in a logical way.
These are typical issues you won’t solve with just a few extra alt texts. Sometimes the HTML structure or JavaScript interaction needs to be adjusted.
10. On mobile, consider tapping, rotating, and zooming
Accessibility doesn’t stop at desktop. Small buttons placed close together are difficult for someone with limited fine motor skills, but also for anyone navigating on the go with one hand.
WCAG 2.2 includes an AA criterion for the minimum size of many touch targets, with exceptions. In practice, the message is simple: give buttons and links enough space and avoid requiring a user to aim at a tiny icon.
Also check whether important functions keep working when the screen is rotated and when text is set larger via the accessibility options of iOS or Android.
11. Write clearly and predictably
Technical accessibility is important, but comprehensibility is just as much a part of it. Use consistent labels in your navigation, don’t hide important information in long paragraphs, and make buttons do what their text promises.
Avoid instructions that refer only to color or position, such as ‘click the green button on the right’. That guidance doesn’t work for everyone and may even be factually incorrect on mobile.
A calm structure, clear error messages, and plain language not only make a website more accessible, but also reduce hesitation for visitors who just want to quickly find something or place an order.
12. Use semantic HTML and only use ARIA where it is needed
A lot of accessibility starts in the source code. A real button, a correct form label, a nav element, and a logical heading level already contain meaning that browsers and assistive technologies understand.
ARIA attributes can provide extra information when standard HTML is not sufficient, but they are not a band-aid for bad markup. A visual element that behaves like a button is preferably built as a real button, rather than a generic div with a stack of extra attributes.
This is also why an accessibility widget can never automatically solve all of a website’s problems. If the basic structure, forms, or interactions are built incorrectly, the underlying website must be adjusted.
What do WCAG 2.2 and the EAA mean for Belgian companies?
WCAG and the European Accessibility Act (EAA) are not the same. WCAG is an international technical standard for web accessibility. The EAA is European legislation that imposes accessibility requirements on certain products and services.
In Belgium, the rules have been relevant since 28 June 2025 for, among other things, e-commerce services and banking services for consumers. FPS Economy states that micro-enterprises — fewer than ten employees and an annual turnover or balance sheet total below 2 million euros — get five extra years to adapt to the new Belgian regulations.
That does not mean that every standard business website automatically falls under the EAA in exactly the same way. The answer depends on what your company offers, who you provide services to, and which parts of the regulations apply to your situation. An online store that sells to consumers, for example, requires a different assessment than a simple B2B information site.
If your company falls under the rules, it’s not only about color contrast or alt texts. FOD Economie also points to clear information about the service, usable digital platforms, and compatibility with assistive technologies.
This paragraph is general information and not legal advice. If you are unsure about your company’s legal obligations, it is wise to check the current guidelines of FOD Economie or seek specialized advice.
Important for online stores If you sell online to consumers, since the EAA accessibility is not only a UX question. Therefore, don’t just have individual pieces of content checked, but also the entire customer journey: search, product information, shopping cart, account, payment steps, error messages, and confirmations.
Can an automatic WCAG checker tell whether your site is accessible?
No. An automated scan is useful to quickly find certain technical errors, but a green scoreboard is not proof that real people can use your website without barriers.
For example, a tool can flag missing alt attributes or some contrast issues. But it does not automatically understand whether an alt text is substantively good, whether an error message is understandable, whether the focus order feels logical, and whether a complex checkout is actually workable with a screen reader.
W3C therefore recommends a broader evaluation. Combine automated checks with manual keyboard tests, zooming, form checks, screen reader testing and — where possible — feedback from people who use assistive tools themselves.
When do you need technical help?
Content managers can improve a lot themselves: clear headings, better link texts, usable alt texts, subtitles and understandable form texts. But some issues run deeper in the theme, the page builder, plug-ins or custom code.
Bring in technical help when keyboard operation doesn’t work, focus disappears, menus or modals get stuck, form labels are missing in the HTML, the reading order is incorrect or the website falls apart when zoomed in. A checkout or customer portal also deserves extra attention because a single blocker there can directly cost an enquiry or a sale.
Sometimes an accessibility check shows that the existing site is technically difficult to fix. In that case, having your website redesigned may be wiser than continuing to pile on individual patches. For targeted adjustments and follow-up, you can also look at Moonbeetle’s webmaster services.
Frequently asked questions about an accessible website
How do I know whether my website is accessible?
Start with manual checks: use the site without a mouse, enlarge text, check forms and try key parts with a screen reader. An automatic scanner can find additional issues, but for a reliable assessment a broader audit is needed.
Does every Belgian website have to comply with the EAA?
Not automatically in the same way. The EAA and Belgian implementation focus on certain products and services. Specific rules apply to e-commerce and consumer-facing banking services. The exact obligations depend on your activity and company.
Is WCAG 2.2 mandatory for my website?
WCAG 2.2 is the current W3C standard and a strong practical target for new or updated websites. Which version or standard legally applies depends on the relevant legal framework. So use WCAG as a technical basis, but check legal obligations separately.
Does accessibility help you rank higher in Google?
Accessibility is not a general ranking factor that lets you predict a position. There is overlap with good SEO: for example, Google uses alt text to better understand images and recommends semantic HTML, clear titles, and descriptive links. The main reason to build accessibly remains that more people can use your website.
Can an accessibility plugin make my website WCAG-compliant?
A plugin or widget can improve certain features, but it cannot automatically solve structural issues in HTML, forms, keyboard operation, or interactive components. Treat such a tool as possible support, not as a replacement for good design, development, and testing.
Do I have to update my entire website all at once?
Not always. Start with the most important user journeys: navigation, contact form, quote request, login, and—if you run an online store—the product page, cart, and checkout. Resolve blockers first and then continue systematically.
Conclusion: accessibility is part of the entire user experience
Making a website accessible is more than adding alt texts or installing a widget. It’s in the way someone navigates, reads, fills in forms, recovers from errors, and operates interactive elements.
So don’t start with the question of whether your website gets a ‘good score’, but with a simpler question: can someone with a different way of seeing, hearing, or operating complete the same task as you?
Sources for further checking
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2
- W3C — Easy Checks: A First Review of Web Accessibility
- FPS Economy — Directive on accessibility: a step closer to an inclusive society
- Belgian Web Accessibility — information and tools about digital accessibility
Do you want to know which accessibility issues on your website need to be resolved technically?
Moonbeetle can review the most important pages and user flows and implement improvements through the webmaster services. For a larger structural adjustment, you can also make an appointment.
