Launch your accessible vibe.

The gap is real. Mobile H1s feel enormous on desktop. Don't just scale down: rethink the whole stack per context.

Arbitrary spacing makes screens feel unsteady. When everything snaps to the grid, the spacing becomes invisible, which is the goal.

Long lines force the eye to hunt for the next line. Short columns increase jumps per paragraph. 45–75 chars is where reading becomes effortless.

Color and size aren't the only tools. Weight creates hierarchy even in a single color. Use 400 for body, 600 for labels, 700 for headings: avoid everything in between.

Tight headings look intentional. Tight body text looks like a bug. Body needs room to breathe; headings are short enough that tight spacing reads as designed.

Padding changes the element's feel; margin changes its relationship to neighbors. Use padding to make a button feel spacious. Use margin to create breathing room in a layout.

Every level you add competes with the others. Primary, secondary, and body. That's the hierarchy. Adding a fourth level usually means the third was doing too much.

Space is not empty: it's structure. Generous spacing reduces cognitive load. The gaps between elements tell users which things belong together and what's a separate thought.

Centered multi-line text is the hallmark of amateur design. The ragged left edge forces the eye to hunt for the start of each new line. Left-align everything longer than a headline.

Each typeface carries a personality: mixing them creates noise. Two typefaces in clear roles feel like a system. Three or more feel like you couldn't decide.

Static type forces awkward breakpoints. Fluid type scales continuously: no sudden size jumps as the window resizes. Set a min, max, and a viewport-relative middle value with clamp().

Tight letter spacing on big type is a design move. Tight spacing on small type is illegible. The smaller the text, the more spacing it needs: not less. Never tighten body text.

A label 8px from its field looks owned. A label 16px away looks like a heading. The gap between things signals their relationship: closer means "these belong together."

UI placed in the notch or behind the home indicator isn't just ugly: it's unusable. Use CSS env() safe-area variables so your layout always respects the device's hardware edges.

Color alone fails for colorblind users. Pair every color-coded state with a second signal: an icon, label, or shape. This isn't accessibility extra credit; it's baseline UX.

Missing a state isn't neutral. No disabled state feels broken when nothing happens. Each state signals what's possible right now.

What happened. Why. What to do. Three sentences max. Plain language. No stack traces. Never blame the user.

Blank screens feel broken; spinners feel slow. Use skeleton loaders for content-heavy loads. Spinners for <2s actions. Progress bars when the user needs to know how long.

Make the danger legible. Red button, explicit label, and a cost statement. "Are you sure?" without consequences doesn't create real friction: specifics do.

Silence after a successful action breeds doubt. Confirm what happened, to whom, and what comes next. The user's mental model needs closure.

Dialogs steal focus because they have to. If the user can ignore it, use a toast. If they must choose, use a dialog. Never use a dialog to say something they don't need to act on.

Showing errors while someone is mid-thought is hostile. Wait for blur (field exit) to validate. Only re-validate on keystroke after the first error appears. Never on every character.

Most requests succeed. Assume success, update the UI immediately, sync in the background. Roll back only on actual failure. The app feels instant even when it isn't.

Confirms interrupt flow. Undo restores agency. Let users act immediately, then give them a short window to reverse it. They feel more in control, not less.

Without feedback, users tap twice. Response within 100ms feels instantaneous. 100–300ms feels fast. Beyond 300ms, users start to doubt. Give visual feedback first, everything else second.

Progress without context is just anxiety. Show step number, percentage, or time estimate. Giving users a frame of reference reduces perceived wait time by 40%.

Touch has no cursor. Any interaction hidden behind hover is invisible on mobile. If your content needs additional actions, make them visible, not discoverable via pointer proximity.

A grayed button with no explanation creates confusion. Tell users what they're missing. The block becomes a guide, and prevents them from abandoning the form in frustration.

Gestures are invisible until taught. On first use, animate a partial swipe. Use destructive actions only on one side: left for danger is a convention users already know.

The wrong keyboard is a tiny betrayal of trust. A number pad for phone numbers, @ key for emails: set inputmode or type correctly and the keyboard is already optimized.

Modals trap thumbs. On mobile, a centered dialog requires two-handed use. A bottom sheet rises from where thumbs already live. Same intent. Opposite ergonomics.

Thumb reach dictates nav placement. Bottom tabs stay in the natural grip zone on mobile. Sidebars use the screen width that desktop has to spare. Never swap them.

Two columns on mobile means two columns of tiny inputs. Users skip fields accidentally and make more errors. Single column, full width. One field, one decision at a time.

Toggles are instant actions. Checkboxes are selection within a form. If the setting takes effect the moment you flip it (like dark mode), use a toggle. If it's part of a group submitted together, use checkboxes.

Cards invite exploration; lists support comparison. Use cards when each item has rich media or requires its own visual weight. Use lists when users are scanning for a specific item quickly.

Custom dropdowns fight the OS. Native selects trigger the platform's built-in scroll picker: optimized for touch. Only build custom when the native control genuinely fails the need.

The FAB is the most prominent tap target on screen. It implies "this is the thing you do most." If you can't name that one action, the FAB isn't the right pattern.

Chips have two distinct jobs: filtering and input. Don't mix them on the same surface. Filter chips are toggles. Input chips represent values the user has added. Styling should signal the difference.

Accordions create extra work for the user. Every collapsed section is a barrier. Use them when the content is genuinely optional: not to make a page feel shorter while hiding required reading.

There is no universal date picker. Picking a birthday is a different task than scheduling a meeting. The interface should match the cognitive model: not force a calendar view on every date type.

Every alert in red trains users to ignore red. Reserve error alerts for actual errors. Info banners for context. If everything is urgent, nothing is. Overused alerts become wallpaper.

If search is how most users navigate, it belongs at the top: always visible. If it's a power-user feature, tuck it in nav. Never make it a modal activation or a tiny corner icon on search-first apps.

Steppers work for small, bounded quantities. If someone might want 500 of something, don't make them tap 499 times. Offer a direct input. Steppers should cover ranges users reach in under 10 taps.

If users need a tooltip to use a feature, the feature needs better labeling. Tooltips are bonus context for experienced users: not a substitute for clear UI copy. And they don't exist on touch screens.

Infinite scroll removes the user's sense of location. If they need to return to a specific item or share a result, pagination gives them an address. Endless scroll is for consuming, not finding.

Every empty screen is a first impression of a feature. Tell them what belongs here, why it's empty, and exactly what to do next. Icon + headline + CTA. Three elements, every time.

The choice is really about whether the user is leaving their current task or pausing it. If they're leaving, push a new screen. If they're pausing, use an overlay that lets them see and return to where they came from.

Back is the most-used navigation action. When it teleports users somewhere unexpected, they lose their mental map of the app. Maintain a proper back stack: always. Test deep links specifically.

Users skip onboarding they haven't earned yet. Show guidance at the moment it becomes relevant: not before. Empty states, coach marks, and contextual tooltips teach while users are actually doing the thing.

If you can't link to it, you can't share it, bookmark it, or return to it. Every meaningful screen in your app should have a URL that restores its full state. This also forces you to design URL-safe navigation.

Beyond 5 tabs, labels disappear and icons carry everything. If you have 6+ destinations, restructure the IA: nest them, or use a different nav pattern. Tab bars are for top-level, equal-weight destinations.

Breadcrumbs tell you where you are in a hierarchy: not history. They're a map, not a back button. On mobile, replace with just a Back label showing the parent's name.

Settings is infrequently used. Reserve primary tab real estate for actions users take every session. Settings lives naturally under the profile: where every mobile convention has trained users to look.

Login walls at launch filter out users who haven't seen the value yet. Let users experience the app before asking for commitment. Gate only actions that genuinely require an account.

Gestures are invisible: they don't announce themselves. Animate a partial gesture on first load, show a hint overlay, or reveal a "Did you know?" prompt. Never rely on discoverability alone for critical actions.

Permission prompts fail when the user has no context for what they're agreeing to. Link the ask to a specific action the user just took. The value exchange is clear, and they're far more likely to say yes.

How users leave shapes how they remember you. Dark patterns at offboarding (roach motel UX) create resentment and reviews. A clean, honest exit is a final brand impression, and sometimes brings people back.

Dead ends destroy trust. Every error screen needs at minimum: what happened (briefly), and a clear path forward. A search field is a bonus. Never leave the user with only a browser back button.

The fold is not dead. On small screens, most users never scroll. Put the primary CTA in the viewport on load. Everything else can follow: but the first action the user should take must be immediately visible.

Users don't live inside your app. They switch apps, get interrupted, background it. Persist form data, scroll position, and filter state. Losing work is one of the fastest ways to lose users permanently.

AA is the legal baseline; AAA is the gold standard. Body text needs 4.5:1. Large text (18pt+ or 14pt+ bold) needs 3:1. UI components and icons need 3:1 against adjacent colors. Test with a real contrast checker: eyeballing fails.

A visually small element can still have a large hit area. iOS requires 44×44pt, Android recommends 48×48dp. Use padding to expand the tap zone without changing visual size. Crowded targets need 8pt spacing between them.

Keyboard users navigate entirely by focus ring. Never suppress it with outline: none without a custom replacement. Focus must meet 3:1 contrast against adjacent colors. Use :focus-visible to show it only for keyboard, not mouse.

Icon buttons are invisible to screen readers without labels. Add aria-label to every icon-only button. Use aria-labelledby when a visible label exists nearby. The label should describe the action, not the icon.

HTML elements carry meaning that assistive tech relies on. Use <button> for actions, <a> for navigation, and heading tags in sequential order. Screen readers use landmark elements (main, nav, aside) to let users jump between page sections.

Red/green distinctions are invisible to 8% of users. Always pair color with a second signal: an icon, a label, a pattern, or a shape. This applies to charts, status indicators, form errors, and any state communicated purely through hue.

Low-vision users regularly set system font size to 150–200%. Use relative units (rem, em): never px for font sizes. Test by bumping browser font size to 200% and checking for content loss, overflow, or broken layouts. Mobile: respect system dynamic type settings.

Parallax, auto-playing carousels, and screen-wide transitions can trigger vestibular disorders. Check prefers-reduced-motion and remove or minimize non-essential animation. Keep functional transitions (loading, focus)...eliminate decorative ones.

Placeholders vanish when users start typing. This breaks cognitive load for anyone who forgets what a field was, and breaks screen readers entirely. Use a persistent <label> element for every input. Placeholder text is fine for examples: not for labels.

Screen readers don't infer visual proximity. Use aria-describedby to link the error message to its input, and role="alert" so it's announced immediately when it appears. aria-invalid="true" also signals the field state.

Keyboard users Tab through every nav item on every page load. A skip link lets them jump directly to main content. Place it as the very first focusable element. Visually hide it until focused: don't remove it from the DOM or tab order.

Alt text should convey what the image communicates in context. If the image is pure decoration, use an empty alt attribute (alt="") so screen readers skip it. If it's a chart, describe the key insight: not the visual style.

Screen readers follow the DOM: not what's visible on screen. Using CSS order, float, or absolute positioning to rearrange visuals without reordering HTML creates a disjointed reading experience for keyboard and screen reader users.

The accessible name is what screen readers announce. For icon-only buttons the visual label is the icon: which is meaningless to AT. Pick the strategy that fits: aria-label for standalone icons, visually-hidden text when you need translatable strings, aria-labelledby when a visible label exists nearby.

AA is the target for most products, and what most accessibility laws require. AAA is aspirational and not required for entire sites. Start with AA conformance, document your approach, and layer in AAA where it meaningfully serves your users.

The wrong chart type doesn't just look off: it misleads. Use bars when comparing discrete values across categories. Use lines when showing how a single value changes continuously over time. Connecting discrete categories with a line implies continuity that doesn't exist.

Pie charts only answer one question: what share of the whole? They require slices to sum to 100%. Beyond 5 slices, human perception breaks down: angles are harder to compare than lengths. Use a bar chart if you want comparison; a pie if you want composition.

An empty chart with no explanation looks broken. Design the zero state: explain why there's no data, tell users what action produces data, and consider showing a ghost/preview of what the chart will look like. Every chart needs a zero state, a loading state, and an error state.

A chart without axis labels is a Rorschach test. Every axis needs a label and a unit. "Revenue" without "$" or "K" forces users to guess the scale. Never rely on tooltips alone: they're invisible on mobile and require interaction to reveal basic context.

When one chart gets more than 4–5 series, everything competes. Small multiples repeat the same chart structure for each category, letting users see patterns across dimensions at a glance. Same scale, same axes: shape differences become immediately readable.

Never rely on red vs. green to distinguish data series. Use palettes designed for colorblind users (IBM Carbon, ColorBrewer, Tableau colorblind). Pair color differences with shape, texture, or direct labeling so the chart works without color at all.

Charts reveal patterns; tables reveal values. If a user needs to look up a specific number, a table serves them better than a chart. If they need to understand a trend, distribution, or comparison across categories, a chart does what a table can't.

Sparklines pack trend context into a single row. They're not for precise reading: they're for direction and shape at a glance. Pair them with a KPI value. Omit axis labels; the shape is the message. Perfect for dashboards with many metrics in limited space.

Mobile screens are too narrow for complex chart layouts. Reduce the number of data points, consolidate time periods (months → quarters), increase label size, and favor horizontal bar charts over vertical ones where space is constrained. Link to a fuller view if detail matters.

Tooltips layer precise values onto a chart without cluttering it. Don't rely on them as the only access to important data: mobile users must tap to trigger them, and they're invisible until interaction. Design for the chart to communicate its core message without tooltip dependency.

Truncating a bar chart's y-axis turns minor differences into apparent crises. Bar height encodes quantity: cutting the baseline misrepresents proportions. Line charts can use non-zero baselines to show variance; bar charts cannot. If differences are small, consider a line chart instead.

The donut chart's hole is prime real estate. Use it for the single most important number: total, percentage complete, or a key KPI. Without a center value, a donut chart is just a pie with a hole: the center makes it meaningfully different.

Stacked bars only allow accurate comparison of the bottom segment and the total. Middle segments float on different baselines, making comparison nearly impossible. If comparing sub-categories matters, use grouped bars. Use stacked bars only when total and bottom segment are the story.

Most users want the headline; a few want the footnotes. Lead with the single most important number and its trend. Let users drill into breakdown views only if they choose. Showing everything at once creates dashboards that exhaust instead of inform.

A subject title labels the chart. An insight title does the analysis for the reader. Move the descriptive label to a subtitle. The title should complete the sentence: "The main thing this chart shows is ___." Users shouldn't have to read and interpret: they should arrive at the conclusion immediately.