Make complete tasks understandable and operable across input methods, text sizes, and visual preferences.
Accessibility depends on the complete interface: its structure, content, interactions, and feedback. Liquidify provides component behavior that can support this work. The application must supply meaningful names, preserve task continuity, and verify the result with assistive technology.
Use headings to describe the page and native controls for their intended purpose. A visual text style does not create a heading: Text defaults to a span, so choose as="h2" when a section heading is required. Use Button for actions and Link for destinations.
Give every control an accessible name. Prefer a visible label connected to the control; keep an icon decorative when nearby text already conveys its meaning. Name an icon-only action on the button itself. See Icons for the distinction between decorative and meaningful glyphs.
Test the actual task from entry to completion. People should be able to reach the controls, see which one has focus, operate them, recover from an error, and leave temporary content.
| Installed behavior | Application responsibility |
|---|---|
| A native Button supports keyboard activation | Choose the correct action and preserve its focus indicator |
| A disabled native Button leaves the tab order | Explain why the action is unavailable when necessary |
A loading Button suppresses activation and exposes aria-busy | Provide progress and outcome feedback that remains understandable without animation |
| Dialog contains focus and makes background content inert | Supply a useful title, a dismissal path, and a valid destination after closure |
| An unnamed Icon is hidden from assistive technology | Label meaningful standalone icons and the controls that contain them |
Figure in preparation
Focus through a confirmation
The trigger, first dialog action, and returned focus identify the active task.
Dialog attempts to return focus to the element active before it opened. If an operation removes that element, the application must choose the next useful destination. Read Dialogs before using it for a confirmation or editor.
Review foregrounds against their actual surfaces in both themes. Pair status color with text or another explicit signal. Glass needs checking against the changing content behind it, not only a neutral preview background.
The shipped styles contain focus indicators and reduced-motion rules for supported controls. The glass engine also reads browser preference signals. These behaviors do not automatically cover custom animations or application-owned surfaces. Motion and Themes explain the scope.
Keep the interface usable with enlarged text and narrow content areas. Allow labels and descriptions to wrap, and let containers grow. Evaluate control size and separation in the browser; native platform point measurements are not web sizing requirements.
State what happened and what people can do next. Associate validation instructions with the relevant field and preserve entered data when recovery is possible. Announcements, validation, persistence, and route changes are application work unless a component explicitly documents them.
Do not communicate essential information only through sound, motion, color, or a brief automatic dismissal. Use Content to plan messages for waiting, success, failure, and cancellation.
Review keyboard operation, screen-reader names and reading order, text enlargement, light and dark themes, contrast preferences, and reduced motion. Include the failure path, not only the successful demonstration. Automated checks can find some defects; manually review behavior and comprehension as well.
This guidance and the presence of accessibility-related APIs do not establish conformance for a product. Record the requirements, browsers, assistive technologies, and test results used for the application.