Web accessibility: the basics for a more inclusive site
Keyboard navigation, contrast, images, and forms: learn web accessibility through concrete examples and start by removing the barriers blocking your visitors.
Sur cette page6 sections
You have filled out a form. You click "send". Nothing happens, except for a small red frame around a field, with no explanation. You re-read, try another format, start again. After a while, you leave.
This kind of detail can annoy anyone. For someone who cannot distinguish certain colours or uses a screen reader, it can completely prevent the request from going through. Web accessibility starts there: does the site actually let people do what they came to do?
It primarily meets the needs of people with disabilities, but its benefits extend beyond this audience. Readable text also helps on a phone in bright sunlight. A keyboard-usable journey can be useful after an injury. These situations are not all equivalent; they show that we cannot demand a single way of reading and using a site.
WCAG recommendations provide measurable benchmarks. For level AA, the contrast of body text should generally reach 4.5:1; for large text, 3:1, with the definitions and exceptions provided by the criterion. The W3C explains these thresholds. No need to calculate them by eye: you can check colours with a tool.
Colour should not be the sole carrier of important information. "Red fields are mandatory" is less useful than clearly naming the required fields. For an error, you can keep the red, but add "Enter a full email address". The person then knows what they need to correct.
I prefer a site where you can read effortlessly to one that deserves a screenshot but then requires you to squint.
If it disappears, you are moving blindly. If it gets stuck in a menu, you can no longer reach the form. These are real obstacles for people using a keyboard or certain assistive technologies.
Try a complete journey: open the menu, choose a service, reach the form, fill it in, send it. Controls must respond with the keys appropriate to their function: Enter for links, Enter or Space for standard buttons, for example. Tab is not for everything; a complex component may use other keys, but its operation must remain consistent.
The keyboard and focus visible criteria set these foundations. A button designed from an element that doesn't know how to be a button sometimes requires more fixes than an HTML component that was suitable from the start.
Take a project photo: "Wooden terrace around a swimming pool, with integrated steps" provides information. "Image", the file name, or a list of cities for SEO do not. And if the image shows a plan with essential dimensions, a short description is not enough: this information must also be available in a usable textual form.
Conversely, a purely decorative image can have an empty alt to avoid cluttering the reading. An icon in a button must allow the action to be identified: a magnifying glass that starts a search should not just be announced as "magnifying glass".
The W3C image guide explains this difference. The right question remains quite simple: what would the person miss if the image wasn't there?
The field name must remain understandable. So must the requirements. If you expect a specific format, explain it before submission. If something blocks it, indicate where and why, without erasing all the information already entered.
And after sending? "Thank you, your request has been sent" answers a real question. A button that briefly changes colour is not enough to say the message has gone. Notifications must also be perceivable by assistive technologies.
This work is detailed in the W3C guide on form labels. It benefits your customer relations: a person should not have to call simply because they cannot understand the form.
The reflow criterion addresses this subject. A test on your own phone is not enough to cover all situations, but it helps identify a layout that only works at a specific size.
Text structure also matters: headings that announce their subject, links that indicate where they lead, a correctly declared page language. For videos, necessary equivalents for audio information must be provided. For animations, check if they hinder reading and what means of pausing or reduction are appropriate. You don't help the visitor by constantly moving what they are trying to read.
An automated audit helps find repetitive errors. It cannot tell on its own if a description is relevant or if an instruction is understandable. These tests are a start, not a certification and not a complete answer to potential legal obligations.
At Cadarsir, the focus is on distinguishing what can be fixed in the existing site from what comes from a deeper structure. It is not always necessary to redo the entire site. However, when a redesign becomes useful, it is better to avoid rebuilding the same obstacles with newer colours.
This kind of detail can annoy anyone. For someone who cannot distinguish certain colours or uses a screen reader, it can completely prevent the request from going through. Web accessibility starts there: does the site actually let people do what they came to do?
It primarily meets the needs of people with disabilities, but its benefits extend beyond this audience. Readable text also helps on a phone in bright sunlight. A keyboard-usable journey can be useful after an injury. These situations are not all equivalent; they show that we cannot demand a single way of reading and using a site.
Light grey is not more elegant when you cannot read it
In a mockup on a large screen, discreet text can look very polished. On a visitor's phone, the same text gets lost in the background. If it explains a booking condition or a surcharge, it is no longer a graphic detail.WCAG recommendations provide measurable benchmarks. For level AA, the contrast of body text should generally reach 4.5:1; for large text, 3:1, with the definitions and exceptions provided by the criterion. The W3C explains these thresholds. No need to calculate them by eye: you can check colours with a tool.
Colour should not be the sole carrier of important information. "Red fields are mandatory" is less useful than clearly naming the required fields. For an error, you can keep the red, but add "Enter a full email address". The person then knows what they need to correct.
I prefer a site where you can read effortlessly to one that deserves a screenshot but then requires you to squint.
Put down the mouse and try to book an appointment
The Tab key normally allows you to move between links, buttons, and fields. The visible marker around the active element is called the focus. It is, in a way, your position on the page when you don't have a mouse pointer.If it disappears, you are moving blindly. If it gets stuck in a menu, you can no longer reach the form. These are real obstacles for people using a keyboard or certain assistive technologies.
Try a complete journey: open the menu, choose a service, reach the form, fill it in, send it. Controls must respond with the keys appropriate to their function: Enter for links, Enter or Space for standard buttons, for example. Tab is not for everything; a complex component may use other keys, but its operation must remain consistent.
The keyboard and focus visible criteria set these foundations. A button designed from an element that doesn't know how to be a button sometimes requires more fixes than an HTML component that was suitable from the start.
Describing an image is not about filling a field for Google
Alternative text, often called alt, is used to convey what the image provides when it cannot be seen. It therefore depends on its role, not just what it represents.Take a project photo: "Wooden terrace around a swimming pool, with integrated steps" provides information. "Image", the file name, or a list of cities for SEO do not. And if the image shows a plan with essential dimensions, a short description is not enough: this information must also be available in a usable textual form.
Conversely, a purely decorative image can have an empty alt to avoid cluttering the reading. An icon in a button must allow the action to be identified: a magnifying glass that starts a search should not just be announced as "magnifying glass".
The W3C image guide explains this difference. The right question remains quite simple: what would the person miss if the image wasn't there?
A form should guide, not test
In a field, the grey text "Your phone" disappears as soon as you type. This placeholder can provide an example, but it does not replace a clearly identifiable label correctly linked to the field.The field name must remain understandable. So must the requirements. If you expect a specific format, explain it before submission. If something blocks it, indicate where and why, without erasing all the information already entered.
And after sending? "Thank you, your request has been sent" answers a real question. A button that briefly changes colour is not enough to say the message has gone. Notifications must also be perceivable by assistive technologies.
This work is detailed in the W3C guide on form labels. It benefits your customer relations: a person should not have to call simply because they cannot understand the form.
Enlarging text should not hide half the site
A page must support a narrow screen and the visitor's reading settings. When enlarged, headings must remain readable, buttons accessible, and information present. For standard content, having to scroll the page left and right for every line quickly becomes tedious; some tables or content requiring two dimensions have specific constraints.The reflow criterion addresses this subject. A test on your own phone is not enough to cover all situations, but it helps identify a layout that only works at a specific size.
Text structure also matters: headings that announce their subject, links that indicate where they lead, a correctly declared page language. For videos, necessary equivalents for audio information must be provided. For animations, check if they hinder reading and what means of pausing or reduction are appropriate. You don't help the visitor by constantly moving what they are trying to read.
Start with a user journey, without claiming imaginary compliance
On a small site, I would start with the most important action: contact, request a quote, or book. We test it with a keyboard, on a small screen, and with appropriate tools, then fix the blockages.An automated audit helps find repetitive errors. It cannot tell on its own if a description is relevant or if an instruction is understandable. These tests are a start, not a certification and not a complete answer to potential legal obligations.
At Cadarsir, the focus is on distinguishing what can be fixed in the existing site from what comes from a deeper structure. It is not always necessary to redo the entire site. However, when a redesign becomes useful, it is better to avoid rebuilding the same obstacles with newer colours.
