Accessibility Principles

Accessibility concerns whether people can obtain information and complete tasks with different sensory, motor, cognitive, and technological conditions. A browser application may be operated with a keyboard, read through a screen reader, enlarged, or used in a difficult environment.

The four accessibility principles

The Web Content Accessibility Guidelines organize requirements under four principles: perceivable, operable, understandable, and robust. The WCAG 2.2 quick reference connects those principles to specific success criteria.

Consider a document page. A reader needs to identify a report, choose an available format, and open it.

Perceivable: Is the information available in a form the person can perceive? A scanned report without a text alternative can make its information unavailable to a person using text-to-speech. An accessible text version carries that information in another form.

Operable: Can the person navigate and activate the controls? A styled element that responds only to a mouse click is not equivalent to a button. A tiny unlabeled icon can also be difficult to operate even when a click handler works.

Understandable: Are the purpose and result clear? A button labelled “Continue” may be ambiguous if it submits an irreversible request. An error should explain what needs correction rather than merely change the border color.

Robust: Can the content be interpreted by different user agents and assistive technologies? Native elements expose roles, names, and states that custom markup must otherwise reproduce correctly.

These questions overlap. A label can improve perception, comprehension, and the programmatic relationship between a control and its name.

A conformance reference describes requirements; your observations concern the pages, workflows, input methods and checks you examined. An automated check alone does not establish complete WCAG conformance.

Semantic headings and controls

Compare:

<div class="large-text">Reports</div>
<div class="clickable">Load older reports</div>

with:

<h1>Reports</h1>
<button type="button">Load older reports</button>

Open both browser views and use Tab to compare keyboard focus. The browser’s accessibility tree represents names, roles and states for assistive technology. Inspect it in the developer tools: the native heading and button supply semantics that the generic elements lack. The button has no action handler here, so activating it does not load reports.

CSS can change the appearance of the heading and button while preserving their semantics.

Do not choose a heading level because of its default font size. Choose it to describe the content hierarchy and style it separately. Likewise, use a link for navigation and a button for an action.

Adding tabindex="0" makes a generic element reachable with Tab; assigning role="button" describes it as a button. Neither supplies a button’s keyboard activation. When a control opens details, its exposed expanded state should indicate whether those details are visible.

Text alternatives for images

An image alternative is not necessarily a literal description of every pixel. Ask what purpose the image serves in this location.

A diagram explaining a route needs the equivalent route information in text. A decorative separator can have an empty alternative. An image-only link needs an accessible name describing the link’s destination or action. The WAI image tutorial provides a useful decision process.

A document-format icon should not be the only way to identify a download. Its surrounding link can name the report and format.

Text contrast and readability

A named control can still be difficult to see. Try this small text example in the browser preview, then use its Styles panel to change color from #aaa to #334155 while keeping the white background:

<p class="notice">The afternoon session starts at 13:00.</p>
<style>
.notice {
  color: #aaa;
  background: #fff;
  font-size: 1rem;
  padding: 1rem;
}
</style>

Inspect the computed foreground/background colors with the browser’s contrast inspector. The first pair is about 2.32:1; the darker text is about 10.35:1. WCAG’s text-contrast criterion uses at least 4.5:1 for ordinary text, with separate provisions for large text and exceptions. The change improves this text’s contrast without changing its meaning or relying on a color-only status. Use the actual adjacent background when making a similar repair in your application and observe the result.

Time, feedback, and recovery

Preserve input after validation errors, avoid unexpected focus changes, and keep feedback available long enough to read. The pending, accepted, and rejected request states from Part 4 help people understand what happened and give assistive technologies a stable state to communicate.

Check Your Understanding

1. How do perceivable, operable, understandable, and robust help turn a broad accessibility concern into concrete audit questions?
2. Why is a visually large paragraph not necessarily a heading?
3. When should a control be a link rather than a button?
4. Why does preserving form input matter beyond convenience?
5. Why is an automated accessibility score not a complete conformance claim?