Accessibility as a design quality bar

Accessible web design basics are a definition of done, not a phase you schedule after the visual design. Contrast, keyboard focus, accessible names, and a reduced-motion path belong in the same pass as layout and type. A screen that only works for a person who can see well, use a mouse, and tolerate animation is an unfinished screen.

W3C's Web Content Accessibility Guidelines, WCAG 2.2, are the reference for that bar. The W3C overview describes WCAG as a shared technical standard, organized as four principles: perceivable, operable, understandable, and robust. Under those principles sit guidelines and testable success criteria at levels A, AA, and AAA. Conformance means the relevant criteria are met. It does not mean a studio has handed you a certificate. Hanabi designs and builds to that standard as a quality bar. We do not pretend a page is certified because it was made carefully.

Contrast, so the interface can be seen

Perceivable starts with contrast. Under WCAG 2.2, the AA success criterion for ordinary text asks for a contrast ratio of at least 4.5 to 1 against its background. Large text, roughly 18 point and up, or 14 point bold, can meet AA at 3 to 1. Interface parts that are not text, such as a field border or an icon that carries meaning, have their own AA criterion at 3 to 1.

Treat these as build checks, not as inspiration. Pick the body color and the background as a pair and record the ratio. Then check the pairs people forget: placeholder text, disabled buttons, text on a photograph, a white label on a pale brand tint, a focus ring against both the button and the page. A palette that looks refined at full size on a designer's monitor can fail on a phone in daylight.

Do not rely on color alone to carry a state. A red border and a green border are invisible to some people, and ambiguous to everyone else in a hurry. Pair the color with a word: "Email is missing," "Saved," "Overdue." If a brand color fails as text, keep it for a shape or a rule, and set the words in a color that passes.

Focus and keyboard, so the interface can be operated

Operable means a person can reach the controls. Many people use a keyboard, a switch, or a screen reader that follows keyboard order. WCAG's AA criterion for visible focus asks that keyboard focus be visible. A focus ring that you removed because it looked unfinished is a missing feature. Design the ring. Give it a color that passes against the controls it lands on, and a thickness you can see at arm's length.

Walk every flow with the mouse unplugged. Tab from the top. The order should follow the order of the work, not the order the components were appended to the page. Shift-tab should return along the same path. Enter or Space should activate the control that looks focused. Escape should close a dialog and return focus to the button that opened it.

Dialogs, menus, and custom selects are where this fails. A pretty dropdown that only opens on click, and traps no focus, is a mouse widget. Use a control that already has a name, a role, and keyboard behavior, or build those on purpose. Use a shared control for that behavior instead of a new unlabeled element on every screen.

Also check that focus is not hidden behind a sticky header or a cookie bar. WCAG 2.2 added criteria so focused items are not fully obscured. A sticky bar that covers the field you just tabbed to is a defect, even when the ring itself is beautiful. Headings in a real order help the same person move through the page. A heading that is only large type, with no heading level in the markup, looks like structure and is not.

Names, so the control can be understood

Robust and understandable meet at the name of a control. WCAG requires that the name, the role, and the value of interface components be available to assistive software. A button whose only content is an icon needs a text name. "Close," "Search," "Delete lead." The visible label and the accessible name should agree. If the screen shows "Save" and the accessible name says "Submit form," you have two products.

Placeholder text is not a name. It disappears. Label the field in text that stays visible. Group related fields with a legend when the individual labels would be ambiguous: two fields both called "Date" need "Start" and "End," or a group label that makes the pair clear.

Write errors in text, beside the field, and move focus to the summary or the first error on submit. A shake animation is not an error message. The words should say what failed and how to fix it, in the same noun the label used.

Images that carry meaning need a description. Images that are purely decorative should be marked so assistive tech skips them. Alt text describes the picture. If the image disappeared, the description is the sentence a person would still need. Listen to the primary flow once with a screen reader. Unnamed buttons and labels that do not match the screen are fixes for this pass, not a later audit.

Reduced motion, so movement is a choice

Animation is part of operable and perceivable content. WCAG includes criteria for moving content: a person should be able to pause, stop, or hide motion that starts on its own and runs long enough to interfere, and interaction-triggered motion should be something they can disable unless the motion itself is essential to the meaning.

The practical version is two deliveries of the same moment. The full version moves to show that a panel opened, a row was added, or a view changed. The reduced version appears in place, instantly or with a simple fade that does not travel. The person's operating system already has a preference for this. Respecting prefers-reduced-motion is how the interface hears that preference.

Essential motion is rare. A progress indicator that something is still working can be essential. A card that swoops in from the side is not. When you are unsure, ship the still version for anyone who asked for less motion, and keep the expressive version for everyone else. Both are part of done. A ticket that says "animation" without the reduced case is half a ticket. On Hanabi work, that pair is part of the craft, on the marketing site and in the product.

Make the bar a checklist, not a speech

Put four lines on the definition of done for every screen.

1. Text and meaningful icons meet the contrast pairs you recorded. State is not color alone.
2. A keyboard can reach, see, and leave every control, including dialogs.
3. Every control has a name that matches its visible label, and errors are text.
4. Motion has a reduced version wired to the system preference.

Check the lines on the blank state, the error, and the success, not only on the full page. Those screens are where unlabeled icons and red-only warnings hide. Check at the phone width. Check once with a screen reader on the primary flow.

If a criterion is genuinely impossible this release, write the exception and the person it blocks. AA is the level most product teams mean when they say accessible. Some AAA criteria, including the one about disabling motion from interaction, are still worth meeting when the fix is small. Say which level you are aiming at. A conformance claim is a separate, formal step. "We care about accessibility" is a value. "These pages meet WCAG 2.2 AA" is something you say only after the criteria have been checked.

When you want that bar built into the interface rather than audited at the end, see Hanabi's services. Bring the flow you are about to ship. Contrast, focus, names, and motion can be reviewed against the job you already have.

The motion half of the checklist has its own decisions: which moves to keep, and how the still version should behave. Reduced motion as part of the craft is the next piece if that is the gap in the current build.