UI Design: Covering Every Interactive State and the Accessibility Requirement That Applies

You are here because a button, a form, a menu, or a whole screen you are responsible for has to work for every person who can reach it, on every device they can bring to it, and it has to meet the specification that makes that true. This hub routes by what you are trying to do. If you are building a component, know every state it can be in and the WCAG 2.2 success criterion that applies to that state before you style the first pixel. If you are commissioning one, speak the language of focus indicators and target sizes so you are not sold mystique. If you are the only design-literate person in the room, you need the external authority to cite. UI design interactive states accessibility is a checklist before it is an aesthetic. Every guide beneath this hub covers that checklist: default, hover, focus, active, disabled, loading, empty, and error, and the specific WCAG 2.2 or platform HIG requirement that applies to each.

The contract of this section is plain. Each guide answers a question you actually have. The reader who asks “how do I make sure my dropdown is not a trap for keyboard users” is routed to the guide on keyboard navigation. The reader who asks “what is the minimum size for a touch target that will not fail an audit” is routed to the guide on target sizes, where the WCAG 2.2 number and the platform number are named and the difference between them is settled. The reader who asks “why does my contrast checker say pass when the text is still unreadable” is routed to the guide on contrast ratio, where the antialiasing failure mode is documented. Every guide is organised the same way: the state, the requirement, the failure, the fix. No inspiration, no trends, no portfolios. Just the constraints and the specification that makes the work professional.

What You Get on Each Route

The routes from this page are built on the vocabulary of the craft. When you land on the guide for user interface design fundamentals, you are not getting a history lesson. You are getting the minimum viable rules that prevent work from looking amateur: the CSS box model that governs spacing, the separation of content and presentation that keeps HTML for structure and CSS for appearance, and the logical resolution of 72 ppi for screen design that tells you why your 300 px logo fails. When you land on the guide for accessible UI components, you are getting the states that every interactive element must cover, and the specific success criterion that applies. The WCAG 2.2 focus indicator minimum area of 2 CSS px thick perimeter or 4 px along the shortest side. The target size minimum of 24 by 24 CSS px. The non-text contrast requirement of 3:1 against adjacent colours for UI components and graphical objects. That is the language of the audit, and it is the language of the brief.

Every State a Component Must Cover

UI state management is where the design system lives or dies. Default state is the resting condition, the one that meets the 4.5:1 contrast minimum for normal text. Hover state is the mouse-only affordance. Hover does not exist on a touch screen, so it can never be the only place a function is revealed. Focus state is the keyboard and screen reader equivalent, and the WCAG 2.2 requirement is that the focus indicator is visible. Active state is the moment of engagement, the press on a touch target or the mousedown on a button, and it must not be confused with focus. Disabled state is the one where the control is present but not operable. Disabled controls must still be perceivable, with a contrast ratio that does not fall below the 3:1 non-text threshold for the component itself. Loading state is the one where the interface is waiting. The guide covers the difference between a skeleton screen and a spinner, and which one the user perceives as faster even when the data arrives at the same time. Empty state is the one where there is no data. An empty state is a design decision, not an absence of one. Error state is the one where something went wrong. The guide covers the difference between inline validation and a modal, and why the WCAG 2.2 success criterion for error identification requires that the error is described, not just indicated by colour.

Designing for Interaction: The Difference Between a Control and a Decoration

Designing for interaction is about making clickability predictable. The guide that answers this question names the platform standards and where they diverge. Apple Human Interface Guidelines define hit-target sizes in points, with 44 pt as the recommended minimum for a touch target. A point is not a CSS pixel, and the difference matters when you are designing for both iOS and the web. Material Design 3 defines states through its elevation and overlay system, with hover, focus, and pressed states expressed through tonal overlays. The guide explains how to read the M3 state layer tokens so you are not guessing at the alpha values. The guide also covers the failure mode of template over-customisation, where a user modifies a Canva or similar tool beyond its structural limits and cannot export a consistent result, because the abstraction layer hides the underlying layout model from the user. The professional standard: know the box model, know the platform, and then decide.

Keyboard Navigation and Screen Readers

The keyboard navigation guide is where the disabled state and the focus state meet. Keyboard navigation is not a feature; it is a baseline. WCAG 2.2 requires that all functionality be operable through a keyboard interface. The guide walks through the tab order, the visible focus indicator, and the ARIA label that names the control for a screen reader. The guide also names what is not acceptable: removing the focus outline because it is ugly, using a hover state as the only reveal for a menu, or hiding focusable elements with display:none instead of properly managing the tab order. The failure mode here is the contrast-failure rejection, where a design passes a contrast checker but fails usability testing because the checker sampled an antialiased edge pixel. Verify visually at actual rendering size. Do not trust the automated tool. The screen reader is not a separate experience; it is the experience for a user who cannot see the screen. If the ARIA label does not match the visible text, the user is lost.

Progressive Enhancement

Progressive enhancement is the strategy that makes the accessible UI component work when the modern feature does not. Progressive enhancement is not graceful degradation; it is the opposite. Start with the semantic HTML that works on a 20-year-old browser. Then add the CSS for the styling. Then add the JavaScript for the interaction. The guide covers the failure mode where a component is built with JavaScript as a dependency, so when the script fails to load, the user is left with a blank screen. Content and presentation are separated, and the HTML for structure is the floor. The guide also covers the relationship to the CSS box model, where the width property with box-sizing set to border-box includes padding and border, so the component does not break when the type size changes. The guide is not a recommendation to avoid modern features. Make the feature a layer, not a requirement.

How the Guides Are Organised

Every guide beneath this hub answers one question. The question is the title of the guide. The guide on target sizes answers “how small is too small for a touch target”. The guide on contrast answers “why does my text pass the checker but still fail the test”. The guide on focus answers “where is my keyboard user looking when the page loads”. The guide on ARIA answers “how do I name this thing for a screen reader without changing what it says”. The guide on state management answers “what states does this component have to cover before I ship it”. The guide on progressive enhancement answers “what happens when the JavaScript does not load”. The guide on user interface design fundamentals answers “what do I have to know before I open the tool”. Each guide is a single subject, a single set of constraints, and a single failure mode to avoid. This hub exists so you can route to the guide that answers the question you have right now, without wading through a page written for someone else’s question.

Who Needs This Hub

The reader who comes here is one of three people. The first is the adjacent professional, the developer, marketer, or content writer who has to speak the specification language without being sold mystique. The second is the small-business operator producing their own materials, who needs the minimum viable rules that prevent work from looking unprofessional and failing basic accessibility. The third is the in-house designer at a non-design organisation, the only design-literate person in the room, who needs the external authority to cite when advocating for process. All three need the same thing: the constraint named, the requirement stated, and the failure mode documented. This hub is not for the reader seeking design inspiration, portfolio critique, or stylistic trend analysis. This site documents constraints and specifications, not visual examples or aesthetic movements. It is not for anyone looking for the work or opinions of named studios or individual designers. This site treats design as a craft body of knowledge, not a personality-driven field.

The Vocabulary of the Specification

The vocabulary of the subject is the vocabulary of the specification. The WCAG 2.2 success criteria are the law of the land, and the guide names them precisely. The minimum contrast for normal text is 4.5:1. The minimum contrast for large text is 3:1. The enhanced contrast for normal text is 7:1, and for large text it is 4.5:1. The non-text contrast requirement for UI components is 3:1 against adjacent colours. The focus indicator must be at least 2 CSS px thick along the perimeter or 4 px along the shortest side. The target size minimum at Level AA is 24 by 24 CSS px. These numbers are evidence, not advertising. The platform guidelines may demand more. The Apple Human Interface Guidelines recommend 44 pt for touch targets, and the Material Design 3 state layers use specific alpha values for hover, focus, and pressed states. The two units are not equivalent. The guide that routes you here tells you which one applies to your context.

Standards and Legal References

The ISO 30071-1:2019 standard is the international accessibility standard for human-system interaction. The guide names it so you have the citation. Legal enforcement varies by jurisdiction. WCAG is a W3C standard, not a law, but it is referenced by the United States ADA and Section 508, the European Union European Accessibility Act and EN 301 549, the United Kingdom Equality Act 2010, the Canadian Accessible Canada Act, and the Australian Disability Discrimination Act. The guide is not a legal opinion; it is a pointer to the standards that the law references. The failure mode is the accessibility law, which is not a single thing. Check the jurisdiction that governs your product. Do not assume that one standard applies everywhere. The guide also names what is not accessibility: a 3:1 contrast ratio for text that is not large, a focus indicator that disappears on a dark background, a touch target that is 20 px because the design calls for it.

Stable Facts You Can Rely On

The facts about the subject that are stable are the ones you can rely on. The leading range for body text is 120% to 145% of the type size, a ratio stable since the metal-type era. The minimum body text size for print is 9 pt. The minimum body text size for screen, WCAG-informed, is the 16 px browser default. The 72-ppi logical resolution for screen design and the 300-ppi minimum effective resolution for offset print are conventions, not physics, but they are industry-stable conventions. The box model in CSS is content, padding, border, and margin, with box-sizing controlling whether width includes padding and border. The separation of content and presentation, HTML for structure and CSS for appearance, predates the web and applies equally to InDesign paragraph styles and XML-based workflows. The A-series paper dimensions defined by ISO 216 are each half the area of the next, with a square-root of 2 aspect ratio that preserves proportions when folded. These are the facts that the guide uses. The guide states when it is estimating and when it is citing.

• WCAG 2.2 minimum contrast for normal text: 4.5:1
• WCAG 2.2 minimum contrast for large text (≥18pt or ≥14pt bold): 3:1
• WCAG 2.2 enhanced contrast for normal text (AAA): 7:1
• WCAG 2.2 enhanced contrast for large text (AAA): 4.5:1
• WCAG 2.2 minimum contrast for UI components and graphical objects: 3:1
• WCAG 2.2 focus indicator minimum area: 2 CSS px thick perimeter or 4 px along shortest side
• WCAG 2.2 target size minimum (Level AA): 24 × 24 CSS px
• Apple HIG recommended touch target size: 44 pt
• Leading range for body text: 120%, 145% of type size
• Minimum body text size for print: 9 pt
• Minimum body text size for screen (WCAG-informed): 16 px browser default
• ISO 30071-1:2019: Ergonomics of human-system interaction, Human-centred design for interactive systems

The Routes: What Each Guide Answers

The routes are organised by the question the reader is asking. The question is the title. The reader who wants to know the fundamentals of user interface design is routed to the guide that answers “what do I have to know before I open the tool”. The reader who wants to build accessible UI components is routed to the guide that answers “what states does this component have to cover before I ship it”. The reader who wants to manage state is routed to the guide that answers “what happens when the data is loading, empty, or wrong”. The reader who wants to design for interaction is routed to the guide that answers “how do I make the hover state not the only state”. Each route is a single question, and each guide is a single answer. The route does not send the reader to a page that covers the topic in general. It sends the reader to the page that covers the specific failure mode they are trying to avoid. That is the difference between a hub and a menu.

User Interface Design Fundamentals

The reader who lands on the guide for user interface design fundamentals is the one who needs the floor. The box model is the first thing to learn. Every layout is a nested set of boxes, and the margin and padding are not the same thing. The guide covers the logical resolution of 72 ppi for screen design, and why a 300 px logo fails at that resolution. The guide also covers the separation of content and presentation, and why designing to placeholder text length guarantees rework. The guide is not a course; it is a list of the constraints that make the work professional. The reader who has this floor can then build on it. Without the floor, the work will look amateur. The small-business operator producing their own materials is the one who feels this most acutely. The guide is the minimum viable rules, and the rules are not optional.

Accessible UI Components

The reader who lands on the guide for accessible UI components is the one who has to ship. Every interactive element has at least eight states, and each state has a requirement. The default state meets the 4.5:1 contrast minimum. The hover state is a mouse-only affordance. It can never be the only place a function is revealed. The focus state is the keyboard and screen reader equivalent. The WCAG 2.2 requirement is that the focus indicator is visible. The active state is the moment of engagement, the press on a touch target or the mousedown on a button. The disabled state is the one where the control is present but not operable. Disabled controls must still be perceivable, with a contrast ratio that does not fall below the 3:1 non-text threshold. The loading state is the one where the interface is waiting, and the guide covers the difference between a skeleton screen and a spinner. The empty state is the one where there is no data, and the guide covers the design decision that an empty state is. The error state is the one where something went wrong, and the guide covers the difference between inline validation and a modal.

The Failure Modes: What Goes Wrong Without the Constraint

The failure modes are the reason this hub exists. The contrast-failure rejection is the one where a design passes a contrast checker but fails usability testing, because the checker sampled an antialiased edge pixel. Verify visually at actual rendering size. The font license failure is the one where the listing page states no restrictions, but the file contains RGB images and unflattened transparency that a RIP cannot process, because the preset was selected but not verified by preflight. The image resolution failure is the one where the image was upsampled from a 72 ppi source in Photoshop, and the effective resolution at final size is below 150 ppi. The social media image dimensions failure is the one where the platform’s help page states a size, but the page was last updated 18 months ago and the current feed renderer crops to a different aspect ratio on Android. The variable font failure is the one where the web page loads the variable font but all text renders at the default axis position, because the axis values are specified in a syntax the browser does not yet support.

The overprint white failure is the one where white text or objects set to overprint disappear entirely on press. This is a print failure mode, not a screen one. The template over-customisation failure is the one where a user modifies a Canva or similar template beyond its structural limits, then cannot export a consistent result. The platform’s abstraction layer hides the underlying layout model. The variable-font axis failure is the one where the page loads the variable font but all text renders at the default axis position, because the axis values are specified in a syntax the browser does not yet support, or the font-variation-settings declaration is omitted. These are the concrete failures that the guides document. Each guide names the cause and the fix. The guide is not a warning; it is a specification. The reader who knows the failure mode is the reader who does not ship it.

Who Should Start Here, and Who Should Not

Start here if you are about to build, commission, or implement a component and need to know the constraints before you start. Do not start here if you are looking for inspiration, because there is none. The reader who is shopping for tools will not find a comparison of subscription plans. Tools are named only where they define a file format or specification, and pricing is never current. The reader who wants colour psychology will not find it, because colour is addressed only where evidence exists, such as legibility and accessibility research. The reader who wants portfolio critique will not find it, because this site documents constraints and specifications, not visual examples or aesthetic movements. The reader who wants the work of named studios will not find it, because this site treats design as a craft body of knowledge, not a personality-driven field. This hub routes by what the reader is trying to do, and what the reader is trying to do is make something that works.

The Law, the Standard, and the Platform

The legal landscape is the reason the standards matter. WCAG is a W3C standard, but it is referenced by law in the United States, the European Union, the United Kingdom, Canada, and Australia. The ISO 30071-1:2019 standard is the international accessibility standard for human-system interaction. Legal enforcement varies. Check the jurisdiction that governs your product. Do not assume that one standard applies everywhere. The guide also names the platform specifications: Apple Human Interface Guidelines define hit-target sizes in points, and Material Design 3 defines states through its elevation and overlay system. These are not interchangeable. A point is not a CSS pixel. The reader who knows the legal landscape is the reader who can advocate for the budget to do the work right, because the cost of a lawsuit is higher than the cost of the fix.

The Numbers Are Evidence

The numbers in this guide are evidence, not advertising. The WCAG 2.2 contrast ratios are the minimums. A passing ratio on paper may fail on a dimmed mobile screen in sunlight. The enhanced ratios are what you aim for when the audience is likely to need them. The AAA standard is a goal, not a requirement at every level. The focus indicator minimum area is a floor. A larger indicator is better. The target size minimum of 24 by 24 CSS px is a floor. The platform guidelines may demand more. The 44 pt Apple recommendation is a point of contention for web designers. The guide settles it: the units are not equivalent, and you must know which one applies to your context. The reader who knows the numbers is the reader who can argue for the design.

Print Failure Modes for the Screen Designer

The print failure modes are the ones that the screen designer forgets. This hub covers them because the same reader commissions both. The RGB-only colour model is the recurring print-failure mode. A design that passes on screen fails on press because the export has no control over rendering intent. The D50 lighting under which printed colour must be evaluated is specified, and soft-proofing is not optional. The safe area is the millimetres inside trim. Text placed outside this zone is at risk of being trimmed off. The value is printer-specific and must be confirmed per job. The page count in print is not a quality attribute. A saddle-stitched booklet must have a page count divisible by 4, and a single-page error forces a blank spread. The glyph count is the number of characters in a font file. A font with 400 glyphs may cover Latin Extended, while one with 200 may fail on common diacritics.

Claimed Versus Real

The distinction between claimed and real is the heart of the guide. The claimed contrast compliance is what the checker says; the real compliance is what the user sees. The claimed font license is what the listing says; the real license is in the file metadata and the EULA. The claimed social media image dimensions are what the help page says; the real dimensions are what the renderer does. The claimed variable font efficiency is what the file size suggests; the real efficiency is what the browser loads when the axis values are not supported. The claimed print readiness is what the preset says; the real readiness is what the preflight reports. The numbers are not the same. Verify the real one. Do not trust the claimed one. The reader who verifies is the reader who ships. The reader who trusts is the reader who fails.

Where the Routes End

The routes from this hub end where the guides begin. The reader who wants to know the fundamentals of user interface design is routed to the guide that answers “what do I have to know before I open the tool”. The reader who wants to build accessible UI components is routed to the guide that answers “what states does this component have to cover before I ship it”. The reader who wants to manage state is routed to the guide that answers “what happens when the data is loading, empty, or wrong”. The reader who wants to design for interaction is routed to the guide that answers “how do I make the hover state not the only state”. The reader who wants to do it right is routed to every one of them, in order: fundamentals first, then components, then state management, then interaction design. That is the order, and the order is not optional.