Colour Contrast
Colour contrast is one of the most fundamental principles of visual accessibility. When text and interactive elements have sufficient contrast against their backgrounds, they become perceivable for all users, especially those with low vision, colour deficiency, or viewing on suboptimal displays. The Web Content Accessibility Guidelines define specific contrast ratios that serve as a baseline for accessibility compliance.
WCAG 2.2 establishes the following minimum contrast requirements: 4.5:1 for normal text and 3:1 for large text (18pt or larger regular text, or 14pt or larger bold text). These ratios compensate for vision loss equivalent to approximately 20/40 vision (the typical visual acuity reported for people around age 80). This mathematical relationship ensures that text remains legible across a broad spectrum of visual abilities.
Test your colour combinations using the WebAIM Contrast Checker, which allows you to input hex colours and instantly verify whether your combinations meet AA or AAA standards.
| Element Type | Normal Text | Large Text (18pt+) |
|---|---|---|
| Body text, paragraphs | 4.5:1 | 3:1 |
| Headings, labels | 4.5:1 | 3:1 |
| UI controls (buttons, inputs) | 4.5:1 (focus indicator) | 3:1 (focus indicator) |
| Graphical elements | N/A | 3:1 (informational graphics) |
Understanding the Contrast Categories
Not all content requires the same contrast ratio. WCAG categorizes elements into groups, each with specific requirements designed to balance accessibility with design flexibility.
Information-bearing elements include body text, headings, and any content that communicates essential information. These demand 4.5:1 contrast to ensure legibility. UI controls and graphical objects require 3:1 contrast (sufficient to distinguish interactive elements but allowing for greater colour flexibility in design). Decorative elements and disabled form fields are typically exempt from specific contrast requirements, though we still recommend maintaining reasonable visual distinction even for disabled states.
The 4.5:1 ratio wasn't chosen arbitrarily. Research shows it provides adequate legibility for users with moderate vision loss. Designing with this standard in mind doesn't just meet compliance. It benefits everyone, from users viewing on bright outdoor screens to those with age-related vision changes.
Designing for Colour Deficiency
Colour blindness affects approximately 8% of males and 0.5% of females. The most common types are red-green deficiencies (deuteranomaly, protanopia) and blue-yellow deficiencies (tritanomaly). A smaller percentage experience complete colour vision deficiency (monochromacy).
The cardinal rule: never use colour as the only signal to convey information. If an error state is communicated by red text, add an icon or text label. If success is green, include a checkmark symbol. Status indicators should use colour alongside patterns, labels, or icons. Users with colour deficiency and those viewing on greyscale displays both need alternative visual cues to understand your content.
Test your designs in greyscale. Firefox and Chrome browser extensions allow you to view websites in greyscale mode. If your interface remains clear without colour, you've designed inclusively.
Non-Text Contrast
WCAG 1.4.11 extends contrast requirements beyond text. UI components (buttons, form fields, focus indicators) and graphical objects must maintain 3:1 contrast with adjacent colours. This applies to:
- Button outlines and borders distinguishing them from the background
- Form field borders and focus indicators
- Toggle switch tracks and handles
- Icon-only buttons and their surrounding space
- Chart elements, status icons, and other meaningful graphics
Many designers overlook non-text contrast because they focus primarily on text legibility. But a low-contrast button border, subtle focus ring, or faint icon is just as problematic as barely readable text. All interactive and informational elements must stand out sufficiently from their surroundings.
Signifiers & Interactive States
A signifier is a visual cue communicating that an element is interactive and what it will do. Effective signifiers combine three aspects: wording, styling, and interactive states.
For wording, use action verbs. "Save Changes" is infinitely clearer than "OK" or "Submit". In destructive dialogs, position the positive outcome first. Users typically expect to move forward, and placing the primary action first reduces cognitive load. Never force users to interpret vague "Yes/No" options; spell out what each choice means.
Styling must signal interactivity through visual distinction. Use underlines for links, buttons with distinct backgrounds or borders, and form fields with clear boundaries. Interactive states (hover, focus, active, disabled) provide feedback as users interact. A focus indicator must be clearly visible; browser defaults are often sufficient, but custom focus styles should maintain 3:1 contrast and remain easily distinguishable.
Error Message Design
Accessible error messages share five characteristics: they say what happened, explain why it happened, provide reassurance, offer a way out, and help users fix it. Avoid technical jargon; users need plain language they can understand and act on.
From an accessibility standpoint, error messages must use colour combined with text and icons, never colour alone. Associate errors with their form fields using aria-describedby, linking the error message to the relevant input. Use role="alert" to announce errors immediately to screen reader users, or aria-live="polite" for less urgent updates.
Many forms colour error text red without accompanying icons or text labels. A user with red-green colour blindness or someone viewing on a greyscale display might not perceive the error at all. Always combine visual indicators with explicit text.
Tab Order & Keyboard Navigation
Keyboard navigation enables access for users who cannot or prefer not to use a mouse. Logical tab order (following a left-to-right, top-to-bottom reading flow) is essential. Users should navigate through headers, main content, then footer in sequence.
In HTML, interactive elements (links, buttons, form inputs) are focusable by default. Non-interactive elements can be added to the tab order using tabindex="0", or removed using tabindex="-1" for JavaScript-controlled focus. Never use positive tabindex values (1, 2, 3, etc.). They override the natural tab order and create confusion.
The focus indicator must be clearly visible. Test keyboard navigation manually: Tab through the page using Tab and Shift+Tab keys, verify the focus ring is obvious, and confirm you can activate all interactive elements using Enter or Space bar. Every interactive element must be reachable by keyboard, and the focus indicator must never disappear.
Accessible Data Tables
Data tables require semantic HTML to be accessible. Use proper <th> elements for table headers with a scope attribute indicating whether the header applies to a row, column, or group. Right-align numeric data to aid comparison. For sortable tables, use aria-sort to indicate the current sort direction (ascending, descending, or none).
Complex tables benefit from progressive disclosure: show core data by default, allow users to expand rows or toggle additional columns as needed. Ensure touch targets are at least 44×44 pixels for interactive table elements. Screen reader users must be able to understand table structure and navigate between headers and data cells efficiently.
<table>
<thead>
<tr>
<th scope="col">Product</th>
<th scope="col" aria-sort="ascending">Price</th>
<th scope="col">Availability</th>
</tr>
</thead>
<tbody>
<tr>
<td>Keyboard</td>
<td style="text-align:right">$79.99</td>
<td>In stock</td>
</tr>
</tbody>
</table>