Experience exit conditions
Candidate exit conditions for the Experience type. These apply when a feature has a user interface; a headless or API-only service strikes them as a group. See the catalog overview for how to adopt these.
Keyboard and focus accessibility
| Exit condition | What it checks |
|---|---|
|
Every interactive control is reachable and operable using only the keyboard. |
|
Keyboard focus can always be moved away from any component without a pointer (WCAG 2.1.2). |
|
A visible focus indicator is present on every focusable element when it receives focus (WCAG 2.4.7). |
|
Tab order follows a meaningful sequence that preserves reading and operational order (WCAG 2.4.3). |
|
The focused element is not entirely hidden by sticky headers, footers, or overlays (WCAG 2.4.11). |
|
A skip link or landmark mechanism lets keyboard users bypass repeated navigation blocks (WCAG 2.4.1). |
|
Open modal dialogs confine focus to the dialog and restore it to the trigger on close. |
|
No element uses a positive |
|
Focus moves to a sensible target after a client-side route change so keyboard context is not lost. |
|
Popovers, menus, and dialogs can be dismissed with the Escape key. |
Semantics, ARIA, and assistive technology
| Exit condition | What it checks |
|---|---|
|
All informative images expose meaningful text alternatives and decorative images are marked empty (WCAG 1.1.1). |
|
Page structure uses semantic landmarks (header, nav, main, footer) so regions are navigable. |
|
Headings are used in a correct, non-skipping hierarchical order that reflects document structure. |
|
Custom widgets expose an accessible name, role, and state to assistive technology (WCAG 4.1.2). |
|
ARIA roles, states, and properties are valid and used only where native semantics are insufficient. |
|
Asynchronous status changes are announced through an appropriate ARIA live region. |
|
Actions use buttons and navigation uses links so semantics match behavior. |
|
Icon-only controls carry an accessible label describing their action. |
|
Success, warning, and error messages are programmatically determinable without receiving focus (WCAG 4.1.3). |
|
Purely decorative content is hidden from the accessibility tree with |
Visual accessibility and color
| Exit condition | What it checks |
|---|---|
|
Body and large text meet the minimum contrast ratios of WCAG 1.4.3 against their background. |
|
UI components and meaningful graphics meet the 3:1 non-text contrast requirement (WCAG 1.4.11). |
|
Color is never the only means of conveying information, state, or distinction (WCAG 1.4.1). |
|
Content remains usable and readable when text is zoomed to 200% (WCAG 1.4.4). |
|
Content reflows without horizontal scrolling at a 320 CSS-pixel viewport width (WCAG 1.4.10). |
|
Layout tolerates increased line, letter, and paragraph spacing without clipping content (WCAG 1.4.12). |
|
Text is rendered as real text rather than baked into images except for logos (WCAG 1.4.5). |
|
Hover, focus, active, and disabled states preserve sufficient contrast and remain distinguishable. |
|
Content revealed on hover or focus is dismissable, hoverable, and persistent (WCAG 1.4.13). |
Forms and input UX
| Exit condition | What it checks |
|---|---|
|
Every form control has a programmatically associated, visible label (WCAG 1.3.1, 3.3.2). |
|
Validation errors identify the specific field and describe the problem in text (WCAG 3.3.1). |
|
When a fix is known, the interface suggests how to correct the input error (WCAG 3.3.3). |
|
Field-level validation feedback appears near its control rather than only in a summary. |
|
Required fields are indicated both visually and programmatically, not by color alone. |
|
Inputs collecting personal data declare correct HTML |
|
Inputs use appropriate types and |
|
On submit failure, focus and an error summary direct the user to the first invalid field. |
|
Destructive or irreversible submissions require explicit confirmation before proceeding (WCAG 3.3.4). |
|
Submit controls prevent duplicate submission while a request is in flight. |
|
User-entered data is preserved and not cleared when validation fails. |
Loading, empty, and error states
| Exit condition | What it checks |
|---|---|
|
Asynchronous operations show a loading indicator within a perceptible threshold. |
|
Loading placeholders reserve final layout dimensions to avoid content shift on resolution. |
|
Empty collections show an explanatory empty state with a next action rather than a blank region. |
|
Failed operations present a human-readable error with a retry or recovery path. |
|
Stack traces, status codes, and raw exception text are never surfaced to end users. |
|
Long-running or timed-out requests give feedback instead of hanging indefinitely. |
|
Optimistic UI updates roll back and inform the user when the underlying request fails. |
|
Partial failures in a composite view degrade gracefully without blanking the whole screen. |
|
Stale or cached data is signaled to the user when a refresh fails. |
Performance and Core Web Vitals
| Exit condition | What it checks |
|---|---|
|
Largest Contentful Paint meets the good threshold of 2.5 seconds at the 75th percentile. |
|
Interaction to Next Paint stays within the 200 millisecond good threshold at the 75th percentile. |
|
Cumulative Layout Shift stays at or below 0.1 across the page lifecycle. |
|
Time to First Byte remains within the defined server-response budget. |
|
Images and media declare explicit width and height or aspect ratio to prevent layout shift. |
|
Images are served in modern formats, responsively sized, and lazily loaded below the fold. |
|
Shipped JavaScript stays within the agreed transfer and execution budget. |
|
Web fonts use a display strategy that avoids invisible text and reflow on load. |
|
Render-blocking scripts and styles are deferred, inlined, or eliminated on the critical path. |
|
No single long task blocks the main thread beyond the defined responsiveness threshold. |
Responsive and cross-device
| Exit condition | What it checks |
|---|---|
|
Layouts produce no unintended horizontal scrolling at supported viewport widths. |
|
Layout remains coherent and usable across all declared responsive breakpoints. |
|
Interactive targets meet the minimum touch target size for pointer accessibility (WCAG 2.5.8). |
|
A responsive viewport meta tag is present and does not disable user scaling. |
|
Content is usable in both portrait and landscape orientations (WCAG 1.3.4). |
|
Layouts respect device safe-area insets such as notches and rounded corners. |
|
Functionality dependent on hover has an equivalent interaction on touch devices. |
|
Small-viewport layouts retain functional and content parity with larger viewports. |
|
Sticky or fixed elements do not overlap or obscure primary content on small screens. |
Internationalization and localization
| Exit condition | What it checks |
|---|---|
|
All user-facing copy is externalized to translation resources rather than hardcoded. |
|
The document and any language changes declare a correct |
|
Layouts mirror correctly and remain usable under right-to-left locales. |
|
Dates, times, numbers, and currencies render using the active locale’s formatting rules. |
|
UI accommodates translation length expansion without truncation or overlap. |
|
Translatable messages avoid concatenation and use parameterized, pluralized forms. |
|
Content renders non-Latin scripts and extended characters without mojibake. |
|
Mixed-direction text uses proper bidirectional isolation to prevent reordering errors. |
|
A chosen locale is applied consistently and persisted across navigation. |
Navigation, routing, and resilience
| Exit condition | What it checks |
|---|---|
|
Meaningful application state is reflected in a shareable, bookmarkable URL. |
|
Browser back and forward controls restore the expected view and scroll position. |
|
Direct navigation to any deep link resolves correctly without requiring prior in-app steps. |
|
Unknown routes render a helpful not-found state with a path back to valid content. |
|
Each view sets a unique, descriptive document title (WCAG 2.4.2). |
|
The current location is indicated within navigation without relying on color alone. |
|
Credentials, tokens, and sensitive personal data never appear in URLs or query strings. |
|
Links opening new contexts use safe |
|
Core content and navigation remain functional when JavaScript is unavailable or fails to load. |
|
Navigating away from unsaved changes prompts the user before data is lost. |
Visual quality, motion, and cross-browser
| Exit condition | What it checks |
|---|---|
|
Key screens match approved visual baselines within the allowed pixel tolerance. |
|
Content does not clip, overlap, or overflow its container at supported sizes. |
|
Animations honor the |
|
No content flashes more than three times per second (WCAG 2.3.1). |
|
Auto-playing or looping motion can be paused, stopped, or hidden (WCAG 2.2.2). |
|
If a dark theme is offered, all components render correctly with adequate contrast in it. |
|
The feature renders and behaves consistently across the supported browser matrix. |
|
Shared components render consistently with the design system rather than one-off styles. |
|
Rendering the feature produces no uncaught JavaScript errors in the browser console. |
|
Printable views apply styles that produce legible, non-truncated output when printed. |