Interface Guidelines I Actually Use.

This started as an adaptation of Vercel's Web Interface Guidelines, but rewritten from my point of view, re-ordered to match how I think, and tightened around the kind of product, accessibility, and design systems work I actually do. It lives somewhere between How I Do Design and my Design Systems Checklist: less process than the first, less implementation inventory than the second.

I keep it short on purpose. These are defaults, not commandments. On accessibility, my target is WCAG 2.2 AA at minimum and AAA when the product, timeline, and platform let me get there without breaking the work. Where a line item maps cleanly to WCAG, I cite it inline.

Interaction.

• Keyboard works everywhere. I treat WCAG 2.2 SC 2.1.1 as the floor and aim for SC 2.1.3 when the interaction allows it. If I have to build a custom widget, it should follow an established keyboard pattern instead of inventing a new one.
• No keyboard traps. Dialogs, drawers, menus, and custom widgets need a clear exit path and should respect WCAG 2.2 SC 2.1.2.
• Focus has to be obvious. I prefer :focus-visible over :focus, use :focus-within for grouped controls, meet SC 2.4.7 at minimum, and push toward SC 2.4.13 when I can.
• Focused UI should stay visible. Sticky bars, drawers, and overlays should not cover the active control; that is the floor of SC 2.4.11 and the enhanced version in SC 2.4.12.
• Manage focus on purpose. When something opens, closes, or changes mode, focus should move intentionally and return where it makes sense.
• Match visual and hit targets. I use 24 by 24 CSS pixels as the WCAG 2.2 AA minimum and try to approach the stricter Target Size (Enhanced) bar when space allows.
• If the visual target is small, the hit area should still be generous.
• Mobile text inputs stay at 16px or larger. I do not want iOS zoom hacks to become part of the interaction.
• Respect zoom and reflow. I never disable zoom and I expect the layout to hold up under WCAG 2.2 SC 1.4.10 and SC 1.4.4.
• Inputs cannot lose focus or value during hydration or client-side updates.
• Never block paste.
• Loading buttons keep their original label. I add a progress cue, but I do not replace meaning with a spinner alone.
• Loading states should avoid flicker. If I use a spinner or skeleton, I give it a short delay and a minimum visible duration.
• State that matters belongs in the URL.
• Deep-link filters, tabs, pagination, and expanded panels. If someone can arrive there, share it, or come back to it, I try to encode it.
• Optimistic updates need a rollback path. Success can appear early, but failure still needs a clear recovery route.
• Follow-up actions and active processing states end with ….
• Destructive actions need confirmation or a forgiving Undo window.
• Tap-heavy controls usually get touch-action: manipulation.
• I set -webkit-tap-highlight-color deliberately.
• Design forgiving interactions. That usually means larger hit areas, fewer finicky gaps, and clearer states.
• Delay the first tooltip, then speed up peers. If hover or focus reveals extra content, it also needs to respect WCAG 2.2 SC 1.4.13.
• Use overscroll-behavior: contain intentionally. Especially in modals and drawers.
• Back and Forward should restore useful scroll positions.
• Autofocus only when it genuinely speeds up the primary task. Usually desktop, rarely mobile.
• No dead zones. If part of the control looks clickable, it should be clickable.
• Drag interactions need cleanup. I disable accidental selection and side interactions while something is being dragged.
• Links are links. Navigation gets <a>, not a fake button.
• Async updates should be announced. Toasts, inline validation, and important background changes should respect WCAG 2.2 SC 4.1.3.
• Shortcut systems need to respect locale and speech input. If I use printable-character shortcuts, they still have to satisfy WCAG 2.2 SC 2.1.4.

Forms.

• Enter submits when there is one obvious next step.
• Inside a textarea, Enter adds a line and Cmd/Ctrl+Enter can submit.
• Every control needs a real label. That is baseline WCAG 2.2 SC 3.3.2.
• Clicking the label should activate the control.
• I keep submit enabled until submission actually starts. Then I disable it, show progress, and use idempotency protection when duplicate submissions would hurt.
• Do not block typing just because validation is strict. Let people enter, then explain the problem in text.
• Do not pre-disable submit. A submitted form is often the clearest place to surface validation feedback.
• Checkboxes, radios, and toggles need generous shared hit areas.
• Errors belong next to the field. On submit, I also move focus to the first relevant error and align with WCAG 2.2 SC 3.3.1 and SC 3.3.3.
• Use autocomplete and meaningful name values. That supports autofill and lines up with WCAG 2.2 SC 1.3.5.
• Disable spellcheck selectively. Emails, codes, usernames, and token fields usually should not be "helped".
• Use the right type and inputmode.
• Placeholders mean empty. They usually end with … and show an example, not a label.
• Placeholder content should model the expected pattern.
• Warn before someone loses unsaved work.
• Password managers and one-time codes need to work. I do not fight them, and I always allow pasting authentication codes.
• Do not accidentally trigger password managers on unrelated fields.
• Trim trailing whitespace before validation. Invisible junk should not generate visible confusion.
• On Windows, native <select> elements get explicit foreground and background colors.
• Ask for the minimum information you actually need.
• Read-only values should usually still be selectable and copyable.

Motion.

• Honor prefers-reduced-motion. That is both a product rule for me and a direct path toward WCAG SC 2.3.3.
• I start with CSS for animation. My preference is CSS > WAAPI > JavaScript libraries.
• Favor compositor-friendly properties. transform and opacity usually age better than layout-driven animation.
• Animation should earn its keep. If it does not clarify state, continuity, or hierarchy, I usually cut it.
• Easing should fit the subject. Size, weight, distance, and trigger all matter.
• Animations should be interruptible.
• Motion should usually be input-driven, not autoplay spectacle.
• Set transform-origin on purpose.
• Never use transition: all.
• SVG transforms still deserve cross-browser testing.

Layout.

• Optical alignment beats mathematical alignment when the two disagree.
• Everything should align with something on purpose.
• Text and icons need balancing, not just centering.
• Test responsive behavior across mobile, laptop, and very wide screens. I also care about how it behaves at 400% zoom under WCAG 2.2 SC 1.4.10.
• Respect safe areas and platform insets.
• Only render useful scrollbars. Accidental overflow is usually a layout bug.
• Let the browser size things. I prefer flex, grid, and intrinsic sizing over JavaScript measurement when possible.
• Avoid magic numbers. Spacing and offsets should describe a relationship, not a lucky guess.

Content and semantics.

• Inline help comes first. Tooltips are a fallback, not the primary way to understand the interface.
• Skeletons should mirror the final layout.
• Page titles should match the current context. That is basic WCAG 2.2 SC 2.4.2.
• No dead ends. Every screen should give people a next step or a recovery path.
• Design all the states. Empty, sparse, dense, loading, and error all count.
• I prefer typographic quotes when the context supports them.
• Avoid widows and ugly line breaks.
• Use tabular figures when people are comparing numbers.
• Do not rely on color alone. Status, charts, and selection states should satisfy WCAG 2.2 SC 1.4.1.
• Icons need text equivalents. Decorative icons get hidden, meaningful icons get names, and icon-only controls need a real accessible name.
• Even if the visual UI omits a visible label, the accessible name still has to exist. That is part of SC 4.1.2.
• When there is a visible label, the accessible name should contain it. That keeps speech interaction aligned with WCAG 2.2 SC 2.5.3.
• Use the ellipsis character …, not three full stops.
• Anchored headings need scroll-margin-top.
• Layouts should survive short, average, and extremely long user-generated content.
• Dates, times, numbers, and currency should match locale.
• Language should come from language settings, not guessed location.
• Verify accessible names, hidden decoration, and region structure in the accessibility tree.
• Semantics come before ARIA. I want native elements, then enhancement, not role soup.
• Headings should be hierarchical and pages should have a skip link. That supports WCAG 2.2 SC 2.4.1 and SC 2.4.6.
• The logo should do something useful. At minimum it should get you home, and if brand resources matter, it can be the place to surface them.
• Use non-breaking spaces for glued terms. Units, shortcuts, and names often benefit from  .

Performance.

• Test across a real device and browser matrix. I care about lower-power mobile states and Safari, not just my development machine.
• Measure in a clean environment. Extensions and debug tooling can distort the numbers.
• Track re-renders and make them cheap.
• Throttle CPU and network when profiling.
• Minimize layout work. Batch reads and writes, and avoid unnecessary reflow.
• Write operations should feel fast. I like POST, PATCH, and DELETE paths to complete in under about 500ms when the product allows it.
• Keystrokes should stay cheap. Controlled inputs are fine when they are actually cheap enough.
• Virtualize large collections when it helps. I do not do it blindly, because accessibility and find-in-page still matter.
• Preload only what the first screen truly needs. Everything else should arrive later or lazy-load without getting in the way.
• Images should not cause layout shift. Reserve space up front.
• Preconnect to important origins.
• Preload critical fonts if they matter to layout or brand.
• Subset fonts to the scripts and ranges you actually use.
• Move expensive work off the main thread when needed.
• Measure before optimizing.

Visual design.

• Shadows work better in layers.
• Borders and shadows usually work better together than either one alone.
• Nested radii step down as layers move inward.
• Hue consistency matters. Borders, shadows, and text usually look better when they acknowledge the base surface hue.
• Charts need more than a pretty palette. They should use color-blind-safe choices and still satisfy SC 1.4.1 and SC 1.4.11.
• My contrast floor is WCAG 2.2 AA. That means at least SC 1.4.3 for text and SC 1.4.11 for UI. When I can, I push toward SC 1.4.6 and stronger focus styling.
• Interactive states should increase contrast, not weaken it.
• The browser's theme color should match the page background intentionally.
• Set color-scheme correctly. Native scrollbars and form controls should not fight the theme.
• If scaling text creates rendering artifacts, animate a wrapper instead of the text node.
• Watch for gradient banding, especially into dark surfaces.
• Hierarchy should come from contrast, spacing, scale, and proportion working together.

Copy and language.

• Prefer active voice.
• Be clear and concise. Fewer words usually make the interface stronger.
• Buttons and labels should say what happens. I want Create account, not Submit.
• Keep nouns consistent. Do not rename the same thing every two screens.
• I write to the person using the interface as you. On portfolio and service pages, I still use I when I am talking about my own practice.
• I default to sentence case for headings and buttons. If a product system uses another casing model, I keep it consistent.
• Choose between and and & deliberately. In my own body copy I usually spell it out; in tighter UI I may use & if space is real.
• Use consistent placeholders and examples.
• Use numerals where counts and scanning matter.
• Keep currency formatting consistent within a context.
• Separate numbers and units with a space. I usually make it a non-breaking one.
• Default to constructive language. Even error states should help, not just scold.
• Error messages need to explain the exit. If I know the fix, I should tell you.
• Avoid ambiguous labels. The more consequential the action, the more specific the label should be.

How I apply this.

• I name my practice areas plainly. Product design, accessibility, design systems, enterprise UX, front-end, and research each set different expectations.
• I try to name real deliverables. Audits, inventories, prototypes, documentation, and handoff-ready patterns are more useful than vague promises.
• I keep portfolio and service copy short. The proof should do most of the talking.
• I try to be honest about constraints. Scope, timelines, engineering reality, and team maturity are part of the design problem.
• I prefer plain language over agency language.
• I like connective tissue between pages. If you want the process version, read How I Do Design. If you want the implementation-side checklist, use the Design Systems Checklist.
• I write like a designer who has to ship. That usually means less theater, more clarity, and a stronger respect for front-end reality.

Put It to Work.

Read How I Do Design, run through the Design Systems Checklist, browse my Case Studies, or reach out if you want help applying this to a real product.

You can contact and connect with me through email, on Dribbble, or LinkedIn as well.