FrontendHaltARIA widget patterns and color contrast
Apply an established interaction pattern for custom widgets and meet contrast ratios that keep text and UI perceivable.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain aria widget patterns and color contrast in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Explain it simply
When no native element covers a custom widget like a combobox, tree, or slider, the WAI-ARIA Authoring Practices define an established pattern of roles, states, and keyboard behavior for it — using that pattern, not inventing your own, is what makes the widget actually usable with assistive technology. Color contrast is the separate, measurable requirement that text and meaningful UI stand out enough from their background to be read.
One-line definition: Apply an established interaction pattern for custom widgets and meet contrast ratios that keep text and UI perceivable.
02Mental model
ARIA patterns exist because assistive technology and users have learned specific expected behaviors for each widget type — a listbox is expected to respond to arrow keys a specific way, a combobox another way. Deviating breaks the mental model those users already have, even if your custom behavior seems reasonable in isolation. Contrast is a numeric, testable ratio — WCAG defines 4.5:1 for normal text and 3:1 for large text and meaningful UI components — not a subjective 'looks readable to me.'
03Step by step
- Check the WAI-ARIA Authoring Practices for an existing pattern before inventing custom widget behavior.
- Implement the pattern's exact roles, states, and keyboard interactions, not just its visual look.
- Verify the widget's accessible name, states, and behavior with actual assistive technology, not just automated tools.
- Check text and meaningful UI contrast ratios against their actual background, including on hover and focus states.
- Never convey required information through color alone — pair it with text, icon, or pattern.
04Working example
/* WCAG AA: 4.5:1 for normal text, 3:1 for large text (24px+ or 19px+ bold) */.button-primary { background: #1d4ed8; /* blue-700 */ color: #ffffff; /* contrast ratio ~8.6:1 — passes AA and AAA */}.button-primary--low-contrast { background: #93c5fd; /* blue-300 */ color: #ffffff; /* contrast ratio ~1.9:1 — fails even AA */}The two buttons look like a reasonable lighter and darker variant pair visually, but the lighter background drops white text contrast far below the 4.5:1 minimum — a contrast checker catches this precisely, while eyeballing a mockup often doesn't.
05Where it is used
- Building custom select, combobox, tabs, or accordion widgets that need real keyboard support
- Auditing a design system's color tokens for AA compliance before they're locked in
- Form error and success states that shouldn't rely on red or green alone
- Reviewing hover, focus, and disabled states for contrast, not just the resting state
06Common mistakes
- Inventing custom keyboard behavior for a widget instead of following the established ARIA pattern
- Adding ARIA roles without implementing the keyboard interaction the role implies, which is worse than no ARIA at all
- Checking contrast only on a component's default state and missing a low-contrast hover or disabled variant
- Using only color, such as a red border, to indicate a form error with no text or icon
07Interview answer
Cite the specific pattern, or exact contrast ratio, rather than a general 'we tested with a screen reader' claim — specificity is what separates real accessibility experience from a checklist mention.
Why is adding role="listbox" and role="option" to a custom dropdown without implementing arrow-key navigation potentially worse than leaving the ARIA out entirely?
The roles tell assistive technology to expect listbox keyboard behavior, such as arrow keys moving selection and typeahead, so a screen reader user will try those interactions expecting them to work; without the actual keyboard handling implemented, the widget now advertises behavior it doesn't have, which is more confusing than a plain unstyled control with no false promises.
DDConcept deep dives
Deep dive 1
ARIA roles are promises the widget must keep
Declaring role="listbox" or role="tablist" tells assistive technology, and the users who rely on it, to expect a specific, well-known set of keyboard interactions and announcements for that role. The role itself implements nothing — it's purely a declaration. A widget with the role but without the matching keyboard behavior is worse than one with no ARIA at all, because it actively advertises capabilities that don't exist, actively misleading users who reasonably try the expected interaction.
- Check the WAI-ARIA Authoring Practices pattern before adding a role, not after.
- A role without matching keyboard behavior is a regression, not a partial improvement.
- Real assistive-technology testing is the only way to confirm a pattern was implemented correctly.
Deep dive 2
Contrast is a measurable ratio, not a subjective judgment
WCAG defines exact numeric thresholds — 4.5:1 for normal text, 3:1 for large text and meaningful non-text UI components — computed from the relative luminance of foreground and background colors. This precision is what makes contrast auditable and testable in a way 'does this look readable' never can be, and it's why a design system should verify every color pairing against these thresholds before it ships, including states like hover, focus, and disabled that are easy to forget.
- A component passing contrast at rest can still fail on a lighter hover or disabled variant.
- Large text gets a relaxed ratio only above a specific size and weight threshold, not just visual prominence.
- Automated contrast checkers can verify this reliably, unlike full keyboard-interaction correctness.
Deep dive 3
Redundant encoding protects against a single channel failing
Any single way of conveying information — color alone, an icon alone, position alone — can fail for some portion of users or circumstances: color vision deficiency, a black-and-white printout, a screen reader that doesn't render icons meaningfully, a glance in bright sunlight. Pairing color with text or an icon, or a position cue with an explicit label, means the information survives even when one channel doesn't get through, which is the practical reasoning behind the 'don't rely on color alone' rule rather than an arbitrary checklist item.
- A red input border needs an accompanying error message, not just the color change.
- A status dot needs an accessible label describing the status, not just a color.
- This principle generalizes beyond color to any single-channel-only signal.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Intermediate · Conceptual · 1 min · Question 1Why should a custom widget follow an established ARIA pattern instead of a team inventing its own keyboard behavior?Open model answer
Model answer
Assistive technology users have learned specific expected interactions for each widget type from using them elsewhere. Deviating from the established pattern breaks that existing mental model, even if the custom behavior seems reasonable in isolation.
Open question page →Intermediate · Conceptual · 1 min · Question 2Why can adding ARIA roles without the matching keyboard behavior make a widget worse than having no ARIA at all?Open model answer
Model answer
A role tells assistive technology to expect a specific set of interactions for that role. Without the actual keyboard handling implemented, the widget advertises capabilities it doesn't have, which is more confusing than an honest plain control.
Open question page →Beginner · Conceptual · 1 min · Question 3What are the WCAG AA contrast ratio requirements?Open model answer
Model answer
At least 4.5:1 for normal text, and at least 3:1 for large text, defined as roughly 24px regular or 19px bold or larger, and for meaningful non-text UI components such as icons and input borders that convey information.
Open question page →Intermediate · Conceptual · 1 min · Question 4Why must contrast be checked on hover, focus, and disabled states, not just the default state?Open model answer
Model answer
A component that passes contrast at rest can easily fail on a lighter hover background or a muted disabled color, and those states are just as often relied upon by users as the resting state, so they need the same verification.
Open question page →Intermediate · Conceptual · 1 min · Question 5Why is automated tooling insufficient to confirm a custom widget is accessible?Open model answer
Model answer
Automated checks can catch structural issues like missing labels or insufficient contrast, but they can't verify that a complete keyboard interaction actually works end to end or that a screen reader announces state changes sensibly — that requires manual testing.
Open question page →Intermediate · Conceptual · 1 min · Question 6Why shouldn't a required piece of information be conveyed by color alone?Open model answer
Model answer
Users with color vision deficiencies, or anyone viewing the page in poor lighting or on a low-quality display, may not reliably perceive the color difference, so the same information needs a redundant channel such as text, an icon, or a pattern.
Open question page →Advanced · Conceptual · 1 min · Question 7What is the difference between aria-label and visible text content for naming a control?Open model answer
Model answer
aria-label supplies an accessible name directly as a string when no suitable visible text exists, while visible text content is both seen by sighted users and used as the accessible name — aria-label should not be used to override visible text with different wording, since that creates a mismatch.
Open question page →Advanced · Conceptual · 1 min · Question 8What contrast ratio does WCAG require for a focus indicator itself?Open model answer
Model answer
WCAG 2.2 introduced a requirement that the focus indicator have sufficient contrast against both its unfocused and focused-state backgrounds, treating the indicator itself as UI that needs to meet a contrast minimum, not just the text near it.
Open question page →Advanced · Conceptual · 1 min · Question 9Why is aria-activedescendant sometimes used instead of moving actual DOM focus in a composite widget?Open model answer
Model answer
It lets a single focusable container, like a combobox input, retain real DOM focus while announcing a different descendant as the active option, which can be simpler to manage than moving focus between many individual option elements.
Open question page →Intermediate · Conceptual · 1 min · Question 10Does a large heading automatically qualify for the relaxed 3:1 large-text contrast ratio?Open model answer
Model answer
Only if it meets the actual size threshold — roughly 24px (18pt) regular weight or 19px (14pt) bold — being visually prominent or styled as a heading doesn't by itself qualify text for the large-text contrast exception.
Open question page →SCScenario questions
Scenario 1
A custom dropdown component was built with role="listbox" and role="option" attributes, but only supports mouse clicks — no arrow-key navigation, no typeahead.
- Identify that the ARIA roles promise listbox keyboard behavior the widget doesn't implement.
- Check the WAI-ARIA Authoring Practices listbox pattern for the exact expected keyboard interactions.
- Implement arrow-key movement, Home/End, and typeahead selection matching the pattern.
- Verify the result with actual keyboard-only and screen-reader testing, not just automated checks.
Reveal worked answer
The roles alone are actively misleading without matching behavior — a screen reader user will expect arrow keys to move selection and be confused when they don't. I would implement the full listbox pattern from the ARIA Authoring Practices: roving focus or aria-activedescendant, arrow-key movement, Home and End, and typeahead, then verify manually with a keyboard and a screen reader rather than trusting an automated audit alone.