Structure and meaning

Open your university's website and you're looking at three kinds of files working together. The HTML holds the content and says what each part is: this is the page's title, this is a heading, this is a list of courses, this is a link to the timetable, this is a button that opens the menu, and the whole page is in French. The CSS, a separate file of style rules, decides how each of those parts looks: fonts, colours, sizes, where things sit on the screen. JavaScript adds behaviour, such as a menu that unfolds or a search box that suggests answers.

The browser combines them into the page you see. Because the layers are separate, each can be right or wrong on its own. A designer can restyle the whole site without touching the HTML, and a page can look perfect while its HTML labels almost nothing, or labels things wrongly, which nobody notices by looking. To see the labels, right-click a page and choose "View page source". When you report a problem or read a quote, knowing which layer it belongs to tells you who should fix it.

Plenty of visitors never see the look. A blind student uses a screen reader, software that reads the page aloud. She doesn't listen from the top: she asks for the list of headings and jumps to the one she wants, or for the list of links, the way you skim with your eyes. A visitor who can't use a mouse, because of a tremor or a broken wrist, moves through the page with the Tab key, from link to link and button to button. The screen reader picks its voice and pronunciation from the language the page declares, so a French page declared as English is read with an English accent, and translation tools offer to translate it from English.

Machines read the same labels. Search engines use the headings and the page title (the name in the browser tab and in search results) to work out what each page is about. So do the AI assistants people now ask whether the town hall opens on Saturday. AI agents that fill in forms for someone look for real buttons and fields to act on.

You're comparing flats on a rental site and want to open five listings in new tabs. Ctrl-click does nothing. Each listing looks like a link, but in the HTML it's a plain box that a script makes clickable. That works with a mouse and nothing else: the Tab key skips it, a screen reader doesn't announce it as something you can use, and a search engine may never follow it to the listing.

HTML has a real element for each job, and the rule for choosing is short. A link goes somewhere, to another page or a spot further down. It has a real address, so it can be opened in a new tab, bookmarked and shared. A button does something on the page, such as opening the menu or sending a form. Both work with the keyboard and announce themselves to screen readers.

Headings follow the same logic. A section title made of large bold text looks like a heading to you and like any other paragraph to a screen reader. Real headings come in levels, one main heading per page and section headings under it, with their size left to the style rules.

Every picture can carry a short text that stands in for it, called alt text. A screen reader reads it aloud where the picture is, and the browser shows it if the picture fails to load. Without it, a blind visitor hears nothing, or a file name like "DSC_0712.jpg".

Write what the picture brings to this page, in one plain sentence, as you'd describe it over the phone. Your town hall's article on the new cycle path shows the first cyclists crossing the bridge: say that. In an article about the bridge's repairs, the same photo would need another sentence. No need to begin with "Photo of": the screen reader already says it's an image. A purely decorative picture, like a background of soft waves, gets an empty alt text, so screen readers skip it. Keywords stuffed in "for Google" help nobody: search engines treat them as spam, and people have to sit through them.

The hardest case is text inside a picture. Many town halls post the canteen menu as an image. Someone who can't see it misses the week's meals, and nobody can search, translate or enlarge it cleanly. It belongs in the page as real text.

You can check most of this yourself. Click in the address bar, then press Tab, again and again. Each link, button and form field should light up in turn, with a visible outline and in a sensible order, and Enter should open or press whatever is lit. If the outline vanishes or the menu can't be reached, keyboard users are stuck.

Then open the developer tools (F12). Lighthouse, a free audit built into Chrome, gives an accessibility score and lists missing alt texts, unlabelled buttons and pale text. The Elements panel has an accessibility view showing the page as a screen reader gets it: headings with their levels, links and buttons, or a pile of generic text. Your phone has a screen reader too (VoiceOver on an iPhone, TalkBack on Android), and five minutes with it teaches more than any report.

Be wary of accessibility widgets, the little icon that promises to make a site accessible in one line of code. They leave the HTML as it was, and many disabled users find them in the way. In France, public bodies and large companies must meet the RGAA, the official accessibility standard, and publish how well they comply.

Ask these in the brief, before anything is built: structure costs little at the start and a lot to repair later.

Write "semantic HTML, checked against the RGAA" into the brief. Semantic HTML means HTML that labels each part for what it is. Then ask how it will be checked, by whom, with which tools and on which pages. Ask whether every feature works with the keyboard alone, the menu and the forms included, and whether the outline showing where you are stays visible. Before you accept the site, ask for a short demo with a phone's screen reader.

Then ask about content. The developers build the structure, but the alt text and the headings in each news article are written by whoever publishes, usually in the CMS, the admin screen for editing the site. Ask who that will be, whether the CMS makes the alt text hard to skip, and whether a one-page guide for the people who publish is part of the delivery. If someone offers an accessibility widget, ask what it fixes that correct HTML wouldn't.