Web accessibility means building pages that people with disabilities can perceive, operate and understand, and the W3C’s WCAG standard turns that goal into testable success criteria that site builders can check one by one.
It belongs alongside every other topic in front-end web development, because most accessibility outcomes are decided by ordinary HTML, CSS and JavaScript choices made while building the page.
What WCAG is and how it is organised
The Web Content Accessibility Guidelines are published by the W3C’s Web Accessibility Initiative. Its overview page says the documents “explain how to make web content more accessible to people with disabilities”. It also points out that WCAG is a technical standard rather than a beginner’s guide: “WCAG is not an introduction to accessibility.”
The structure is simple enough to hold in mind. According to the WCAG overview, “The WCAG 2.2 has 13 guidelines. The guidelines are organized under 4 principles: perceivable, operable, understandable, and robust.” Each guideline has testable success criteria, and the overview states that “The success criteria are at three levels: A, AA, and AAA.” Conformance means meeting the success criteria, not just reading the guidelines.
The levels matter when reading a requirement. The W3C labels the minimum contrast criterion covered below as Level AA, so a team that sets AA as its goal takes on that rule along with the others at levels A and AA.
The four principles in plain terms
The W3C’s page on accessibility principles describes each principle with examples. They give a useful checklist of questions for any page.
| Principle | Question it asks | Everyday example |
|---|---|---|
| Perceivable | Can people take in the information through at least one sense? | Text alternatives for images |
| Operable | Can every control be used, including without a mouse? | Full keyboard access |
| Understandable | Is the content and interface predictable and readable? | A declared page language and clear form labels |
| Robust | Does it work with browsers and assistive technology? | Valid markup and named controls |
The principle names and examples are drawn from the W3C’s accessibility principles page.
The same page explains the keyboard point directly: “Many people do not use the mouse and rely on the keyboard to interact with the Web.” For robustness it says “Robust content is compatible with different browsers, assistive technologies, and other user agents.” These two sentences account for a large share of day-to-day accessibility work.
Text alternatives for images
Images carry meaning that screen reader users cannot see, so each one needs an equivalent in text. The W3C’s guidance on non-text content gives the short version of what to do: “Create a text alternative for visual and auditory content.” The criterion itself requires that content “has a text alternative that serves the equivalent purpose”, with exceptions for decoration and a few other cases.
In practice, this is the alt attribute on image elements. A useful alt text describes the purpose of the image in context, not its pixels. A chart needs a description of what it shows, a linked logo needs the destination, and a purely decorative flourish gets an empty alt value so assistive technology skips it. Photographs used to illustrate an article usually need a short description of what the photograph conveys to the reader.
Controls matter too. The same criterion says that if non-text content is a control, it needs “a name that describes its purpose”. An icon-only button with no accessible name is announced as just “button”, which tells a screen reader user nothing.
Colour contrast and target size
Low contrast is one of the most common failures on the web and one of the easiest to measure. The minimum contrast criterion states that “The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: Large Text Large-scale text and images of large-scale text have a contrast ratio of at least 3:1”. That is the requirement, as laid out in the W3C’s contrast explanation. Body text needs the higher ratio, and large headings are allowed the lower one. Text that is pure decoration or part of an inactive control has no contrast requirement.
A further rule covers touch and pointer targets. The W3C’s page on minimum target size says “The size of the target for pointer inputs is at least 24 by 24 CSS pixels”, with exceptions for inline links in sentences, controls the browser itself sizes, and targets that have enough spacing around them. The rule helps people with tremors, people using a thumb on a small phone, and anyone who has tapped the wrong link by accident.
Both rules interact with layout. A responsive design that shrinks text or packs buttons together on narrow screens can break them at small sizes, which is one reason to review the patterns in the guide to css media queries with accessibility in mind.
Keyboard operation and visible focus
Everything that can be done with a mouse needs a keyboard route. The keyboard criterion reads: “All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes”, with an exception for input that depends on the path of a movement, such as freehand drawing. The keyboard explanation covers the details.
Native elements make this easy. Links, buttons, form fields and select menus are reachable and operable by default, with the right roles and behaviours built in. Problems begin when a clickable div or span stands in for a button, because it has no focus, no key handling and no role. Reaching for the correct element first removes most of the work.
Keyboard users also need to see where they are. According to the W3C, “Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.” Removing the focus outline for looks, with nothing to replace it, breaks that rule. A custom focus style that stands out against the background keeps both design and access intact; the criterion is explained on the W3C’s focus visible page.
Language, labels and forms
Two small criteria prevent a lot of confusion. The first is the page language: “The default human language of each web page can be programmatically determined.” A lang attribute on the html element lets screen readers choose the right pronunciation rules instead of reading everything with a default voice. The W3C describes it on the language of page page.
The second concerns forms. The W3C’s criterion for labels states that “Labels or instructions are provided when content requires user input.” Every field needs a visible label tied to it in the markup, so that clicking the label focuses the field and a screen reader announces it on arrival. Placeholder text alone disappears as soon as someone types, and is a weak substitute. The wording is on the labels or instructions page.
Building accessibility into a testing routine
Automated scanners cannot judge everything, so a routine combines several methods: scan for missing alt text and contrast failures, tab through the page using only the keyboard, zoom the browser and try a screen reader on key journeys. Testing with real browsers and devices belongs in the same pass, which is why many teams fold these checks into their cross browser testing checklist rather than treating them as a separate project.
It helps to catch issues early. A heading that is only styled large rather than marked up as a heading, or a form built from unlabelled divs, is cheap to fix during development and expensive after launch. Semantic HTML does a great deal of the work for free.
Frequently asked questions
Which WCAG level should a site aim for?
Level AA is a common target. The minimum contrast criterion is labelled Level AA by the W3C, and a team that adopts AA works to the criteria at levels A and AA together, including the keyboard, focus and label requirements covered above.
Does WCAG apply to mobile sites and apps?
Yes. The W3C overview says WCAG applies to dynamic content, multimedia, web on mobile, and AI web interfaces, and it can be applied to native apps and documents through related guidance.
Are automated accessibility checkers enough?
No. They are good at spotting missing attributes and low contrast, but they cannot judge whether alt text is meaningful or whether a keyboard journey makes sense. Manual keyboard and screen reader checks complete the picture.
Is a lang attribute really necessary?
It is part of the success criteria, and it costs a few characters. Without it, assistive technology may pronounce text with the wrong language rules.
