# Interface Quality Checklist This reference is a compact construction and review baseline for product interfaces. It complements the deeper local references rather than replacing them. Apply only rules relevant to the current artifact and cite primary standards for conformance claims: - [WCAG 2.2](https://www.w3.org/TR/WCAG22/) - [WAI-ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/) - [Apple Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/) - [Material Design 3](https://m3.material.io/) ## Visual hierarchy and composition - Give each surface one clear primary task and make its heading, primary action, and current state discoverable without relying on decoration. - Encode hierarchy with a small, repeatable set of type, spacing, surface, and emphasis tokens. Adjacent levels must be visibly different; peer items must look like peers. - Align related content to shared edges and use proximity to express grouping. Avoid decorative cards, separators, and containers that do not clarify structure. - Keep scan order consistent with DOM/reading order. Reordering content visually must not create a different keyboard or screen-reader sequence. - Constrain long-form measure and keep dense data aligned to a stable grid. Use whitespace to separate concepts, not to hide weak information architecture. - Test empty, loading, error, long-content, and maximum-density states; a composition is not complete when it works only with ideal sample data. ## Typography and content - Use a defined type scale and line-height system. Body text must remain readable at supported zoom and system-text sizes without clipping or overlap. - Keep labels visible; placeholders are examples, not labels. Use sentence case and concrete verbs that describe the result of an action. - Pair error text with cause and recovery. Avoid generic messages such as “Something went wrong” when a safe, actionable explanation is available. - Preserve localization expansion, plural rules, locale-aware dates/numbers, right-to-left layout, and scripts with different line metrics. - Do not rasterize essential text. When an image contains meaningful text, provide equivalent accessible text and avoid making the image the only usable source. ## Color and themes - Use semantic tokens such as surface, text, border, focus, success, warning, and danger; map them independently for light, dark, and high-contrast modes. - Audit rendered pairs, not isolated swatches. WCAG 2.2 requires at least 4.5:1 for normal text, 3:1 for large text, and 3:1 for graphical objects or UI-component boundaries needed to identify controls and states. - Never use color as the only carrier of status, validation, selection, or chart-series identity. Add text, icon shape, pattern, position, or another programmatic cue. - Keep focus, hover, pressed, selected, disabled, error, and success states distinguishable in every supported theme. Disabled appearance does not excuse unreadable essential explanatory text. - In forced-color modes, preserve semantic boundaries and visible focus rather than forcing authored colors that override user settings. ## Interaction and feedback - Use native buttons, links, inputs, and disclosure elements when they express the behavior. Custom widgets must implement the relevant keyboard, focus, name/role/state, and pointer contracts from the APG pattern they claim. - Every action needs prompt visible feedback and a stable completion/error state. Prevent duplicate submission while preserving recovery and user-entered data. - Keep motion interruptible and avoid blocking input during animation. Respect reduced-motion preferences and use motion to explain continuity, not decorate every state change. - Do not move surrounding layout on hover or press. Keep the actual hit area stable, and make hover-only information reachable by focus or activation. - Destructive actions require clear wording and proportionate protection: undo for reversible actions, confirmation when consequences are hard to reverse, and separation from routine actions. - Preserve keyboard and browser conventions, including Tab order, Escape where the component contract defines it, Back/history, copy/paste, selection, and zoom. ## Forms and error recovery - Associate every control with a visible label, instructions when needed, and programmatic name. Group related controls with an appropriate fieldset/legend or native equivalent. - Use correct input types and autocomplete tokens; allow paste and password managers. Validate authoritatively on the server as well as providing safe client-side feedback. - Announce errors, connect field messages programmatically, move focus to an error summary or first invalid field when appropriate, and preserve all valid input. - Mark required fields consistently in text and semantics. Do not make users infer requirements from color or an unexplained symbol. - Protect state-changing requests against CSRF where the architecture requires it, keep secrets out of client code/logs, and rate-limit abuse without making inaccessible challenges the default. - For long or fragile flows, save drafts when safe, disclose timeout behavior, and warn before dismissing unsaved changes. ## Navigation and responsive layout - Keep primary navigation stable and visible. Search, command palettes, gestures, and breadcrumbs are supplements chosen for the information architecture, not replacements for a discoverable path. - Preserve deep links, browser/system Back behavior, current-location indication, scroll/form state, and a clear route out of nested or modal flows. - Reflow around content and input capability. Avoid device-name breakpoints, horizontal page scrolling, controls hidden by fixed bars, or desktop navigation merely scaled down for mobile. - Respect safe areas, browser chrome, window resizing, orientation, large text, and long localized labels. Test the smallest supported width and the widest readable content region. - After full-page navigation, place focus at a meaningful new-page location; after dismissing a temporary surface, follow that component's specific focus-return contract. ## Data visualization - Match chart form to the question: position/length for precise comparison, lines for ordered trends, and area/angle only when lower precision is acceptable. - Provide a text summary and an accessible table or equivalent route to exact values. Interactive marks must be reachable without hover and expose series/category/value in their accessible name. - Label axes and units, format values for locale, and keep legends adjacent to the data. Use direct labels when they reduce lookup effort. - Distinguish series with more than hue and audit graphical-object contrast. Do not use red/green alone, and do not claim a palette is accessible without testing the rendered combinations. - Simplify or recompose at narrow widths; avoid shrinking labels until unreadable. For large datasets, aggregate with a disclosed drill-down path rather than rendering every point. - Show loading, empty, stale, and failed-data states explicitly so an empty chart is never mistaken for a zero result. ## Pre-delivery checklist - [ ] The primary task, heading, action, and current state are evident. - [ ] DOM/reading order matches the visual sequence and all actions work from the keyboard. - [ ] Text, non-text contrast, focus, zoom/reflow, large text, reduced motion, and forced colors are verified where applicable. - [ ] Loading, empty, error, permission-denied, offline/timeout, long-content, and maximum-density states are covered. - [ ] Forms preserve valid input, announce actionable errors, support autofill/paste/password managers, and validate on the server. - [ ] Navigation preserves Back/deep-link/state behavior and overlays follow their exact Escape/Tab/focus contract. - [ ] Light, dark, responsive, localized, and platform-specific states use semantic tokens rather than ad hoc values. - [ ] Claims attributed to WCAG, APG, HIG, or Material are checked against the current primary source.