Web accessibility: why it matters (and how to do it right)

More than a billion people worldwide live with some form of disability. Add to that everyone who has low vision due to age, who browses under the harsh sunlight on a phone, who uses only the keyboard, who has dyslexia or sensitivity to motion — and it becomes clear that accessibility is not a niche. It is the condition for a website to serve everyone.

Building for this audience is neither charity nor a technical ornament. It is a right, it is reach, and, in practice, it is software quality. This piece sums up why this matters and how to apply it — with the official sources at the end.

Why it matters

It is a right. In Brazil, the Brazilian Inclusion Law (LBI, Law No. 13.146/2015) makes digital accessibility an obligation, not a courtesy.
It is reach. Every barrier is a person who gives up. Weak contrast, a button that only works with the mouse, an image without a description — each one silently excludes someone.
It is quality. Almost everything that makes a website accessible also makes it better for everyone: semantic HTML, good contrast, keyboard navigation, clear text. Accessibility and usability go hand in hand.

The four principles (POUR)

The international guidelines (WCAG) are organized around four principles. A website must be:

Perceivable — the content can be perceived through all the senses (e.g., images have descriptions, videos have captions, the contrast is sufficient).
Operable — it can be used in various ways (e.g., everything works with the keyboard, without depending on the mouse; nothing flashes in a dangerous way).
Understandable — the language and the way it works are predictable and clear.
Robust — it works with assistive technologies, such as screen readers.

Concrete practices

Without needing to be an expert, you can cover the essentials:

Sufficient contrast between text and background (the common target is a 4.5:1 ratio for normal text).
Alternative text (alt) describing informative images; decorative images marked so the screen reader ignores them.
Keyboard navigation: every link, button, and field reachable by Tab, with visible focus and a logical order.
Semantic HTML: use <button>, <nav>, <main>, headings (<h1>…<h2>) in the right hierarchy — not <div> for everything.
Forms with labels (<label>) tied to the fields, with errors described in text and announced.
Respecting motion: honor the prefers-reduced-motion preference for people who have vestibular sensitivity or photosensitivity.
Not relying on color alone to convey information (an error cannot be "the field just turned red").
ARIA in moderation: the first rule of ARIA is not to use ARIA when native HTML already solves the problem. When needed, use aria-live to announce dynamic changes.

How to test

Navigate the site using only the keyboard (Tab, Shift+Tab, Enter, Space). If you get lost, other people get lost too.
Increase the browser font to 200% and see if anything breaks.
Run an automated checker (such as WAVE or axe) — they catch some of the problems; the rest is human testing.
If possible, test with a screen reader (NVDA on Windows, VoiceOver on Mac).

Official sources

When in doubt, go straight to the source:

W3C WAI — Web Accessibility Initiative — the official starting point on web accessibility.
WCAG 2.2 (Web Content Accessibility Guidelines) — the worldwide reference standard.
WCAG Quick Reference — the criteria in a practical, filterable format.
WAI-ARIA Authoring Practices — patterns for interactive components.
MDN — Accessibility — a technical reference for developers.
e-MAG — Accessibility Model for Electronic Government (gov.br) — the Brazilian reference.

Accessibility is not a box you check once. It is an ongoing care — the same care, in fact, that we try to give the body: noticing who was left out and making room.