Leaving people out

Many design choices assume that every visitor sees well, hears the sound, uses a mouse, reads easily and owns a recent phone. Many visitors don't.

Blind people use a screen reader, which reads the page aloud and needs real text and labels to do it. People with low vision zoom in, and need strong contrast. Deaf and hard-of-hearing people need subtitles and transcripts. People who can't use their hands well move through a site with the keyboard, or with their voice. People with dyslexia, or who read French as a second language, need plain words.

It's not a small group. The WHO estimates that about one person in six lives with a significant disability. And many more are limited for a while: a broken arm, sun on the phone screen, a video watched in a noisy metro, a baby in one arm.

When a site shuts them out, they rarely complain. They leave, they call, they ask someone else, or they can't use the service at all. So you won't hear about the problem unless you search for it.

Accessibility isn't only good practice. For many sites, it's the law.

In France, public bodies, and companies with more than €250 million of turnover in France, must make their sites meet the RGAA, the official accessibility standard. The RGAA is based on WCAG, the international guidelines. These organisations must also publish an accessibility statement: a page that says how well the site meets the rules, what still fails, and how to contact someone about it.

Since June 2025, the European Accessibility Act has extended similar duties to most consumer services sold online, such as online shops, banking and transport, for all but the smallest companies. So a client who sells online now has a legal reason too.

The cost argument is just as strong. Accessibility is cheap to build in from the start, and expensive to add later, when the design, the components and the content all have to change. So write it into the brief, with a standard to check against, WCAG or RGAA. Then check it while the site is being built, not only at the end. A problem found in the design takes minutes to fix. The same problem found after launch can mean rebuilding pages.

And don't accept a widget instead. The lesson Structure and meaning explains why an icon that promises accessibility in one line of code doesn't fix the site underneath.

Automated tools such as Lighthouse are useful, but they find only part of the problems. They can check that a picture has alt text, but not that the alt text makes sense. They can't tell you whether someone can actually buy a ticket.

So spend ten minutes using the site the way other people do, while it's being built and again before launch. You don't need to read any code.

• The keyboard alone. Put the mouse away, press Tab from the top, and try to complete the main task. Each link and button should light up in a sensible order, and nothing should trap you.
• A screen reader. Every phone has one: VoiceOver on an iPhone, TalkBack on Android. Start it and listen to the main page. Does each button say what it does?
• Zoom. Enlarge the page to 200% in the browser, twice its normal size. Nothing should overlap or disappear.
• Sound off, and bright light. Watch the videos without sound, and read the page on your phone outside.
• An old phone on a slow connection. Does the page still load and work?

The example below shows a concert hall's ticket site. Its automated accessibility score was 96 out of 100. Ten minutes by hand found four problems that stop people from buying a ticket.

Do the same on your portfolio. Can a recruiter who uses the keyboard open each project? Does your project video have subtitles? Is your CV real text, or a picture of text?

Moving a service online helps most people and saves real money. The risk is making it the only way.

Some people don't have a smartphone, or have one too old for the app. Some have no data plan, or a poor connection. Some aren't at ease with digital tools, or with written French. INSEE found that in 2021, 15% of people in France, more than eight million, either didn't use the internet or lacked basic digital skills. Among people over 60, it was more than one in three.

Take a medical practice that decides to take appointments only online, to free its phone line. Most patients book in a minute. But the patients who struggle most with booking online, such as older people, people with a complicated case, or people who don't read French well, are often the ones who need the doctor most. Without another way in, they get no appointment.

So before any "online only" decision, ask two questions. Who are the users, really, and how many of them can't use the new channel? And what is the other way in for them: a counter, a phone line, paper, or a website as well as an app?

For public services, this is also a legal question. In 2022, France's Conseil d'État ruled that the State could make residence permit applications online only if people who can't use the online service are offered another solution.

Accessibility is often presented as a cost for a small group. In practice, what helps the people who struggle usually helps everyone.

Think of the lowered edge of the pavement at a pedestrian crossing. It was made for wheelchairs. Today, everyone who pushes a pram, a suitcase or a delivery trolley uses it. Websites work the same way:

• Subtitles help deaf people, and everyone watching in the metro without headphones.
• Plain words help people with dyslexia, and anyone reading in a second language.
• Bigger buttons help people with shaky hands, and anyone tapping on a moving bus.
• Real headings help screen reader users jump from part to part, and everyone who skims the page.
• A light page helps people with an old phone, and everyone on a weak connection.

So test with people who struggle, before launch rather than after. Ask an older relative to book an appointment on the site. Watch a classmate use your portfolio with the keyboard only. Try it on the oldest phone you can find. A few people who struggle teach you more than many who don't.

Ask these questions in the brief, again before launch, and whenever someone proposes to make a service online only.

In the brief, ask for accessibility against a standard, WCAG or RGAA, and say who will check it and how. Ask whether the client must publish an accessibility statement. Before launch, ask to see the main task done with the keyboard alone and with a phone's screen reader, and do the ten-minute check yourself. Ask what the automated report missed, and when each problem will be fixed.

For any "online only" plan, ask who the users really are, and how many of them can't use the new channel. Ask what the other way in is, and who pays for it. Ask whether the app works on an old phone and a weak connection, and whether it was tested with older people and with people who use a screen reader.

For your portfolio, ask yourself the same questions. Can a recruiter who uses the keyboard, a screen reader or an old phone see your work and contact you?