Compelling UI design is not only about polish. It is about helping people understand where they are, what they can do, and how to complete the task with the device, browser, input method, eyesight, language skill, and attention they have today. That is especially important for image-rich editorial sites and submission flows: the visual experience may be beautiful, but the structure still has to work when someone navigates by keyboard, zooms the page, listens with a screen reader, or turns motion down.

The examples below are instructional patterns, not customer test results. Use them as a practical checklist while designing portfolios, archives, landing pages, forms, and product screens.

1. Structure the page before styling it

Start with a clear title, one main topic, and headings that describe the sections a reader will actually use. The WAI headings tutorial explains that headings communicate organization and help browsers and assistive technologies provide in-page navigation. In practice, that means your visual hierarchy should match the HTML hierarchy.

  • Use one page title that names the current page or task.
  • Use heading elements for real sections, not just for large text.
  • Avoid jumping from an h2 directly to an h4 inside the same section.
  • Use lists when you are presenting a sequence, set of options, or group of related items.

How to verify: scan only the headings. If the outline does not explain the article, submission form, or gallery page, the layout is doing work the markup should do.

2. Use native controls for native jobs

The fastest way to make an interface more robust is to stop rebuilding controls the browser already provides. Use links for navigation and buttons for actions. The MDN button element reference documents the native button control; the reason it matters is practical: native controls already expose expected roles and keyboard behavior.

<a href="/collections/">View collections</a>
<button type="button">Open filter panel</button>

Do not make a clickable div when a button or link would do. If a custom component is unavoidable, it must still provide a name, role, state, keyboard behavior, and visible focus. ARIA can expose semantics, but it does not add click, keyboard, or focus behavior by itself.

How to verify: disable your mouse for five minutes. If you cannot activate every menu, filter, form action, and close control with the keyboard, the pattern is not finished.

3. Make keyboard focus obvious and logical

People who use keyboards, switches, screen readers, voice tools, or alternative input devices need to know where the current point of interaction is. The MDN keyboard accessibility guide says interactive elements must be focusable, keyboard-operable, and visibly styled when focused. WCAG also explains in WCAG Focus Appearance that focus indicators need enough size and contrast to be easy to spot. Focus Appearance is a Level AAA criterion; it is a useful stronger design target, not a statement that every AA interface must meet its exact area rule.

a:focus-visible,
button:focus-visible,
input:focus-visible {
  outline: 3px solid #1f6feb;
  outline-offset: 3px;
}
  • Keep focus order the same as reading order.
  • Avoid positive tabindex; fix source order instead.
  • Never remove outlines unless you provide a stronger replacement.
  • After a modal closes, normally return focus to the control that opened it. For a disclosure, move focus back to its trigger if focus would otherwise be left inside the newly hidden content.

How to verify: press Tab from the browser address bar to the footer. You should always see where you are, and the next focus target should feel predictable.

4. Treat contrast and color cues as content, not decoration

Low-contrast captions, pale metadata, and color-only status labels can make an otherwise beautiful interface unusable. WCAG Contrast Minimum states that normal text needs at least 4.5:1 contrast against its background, while large-scale text can use 3:1. WCAG Use of Color also requires meaning to be conveyed by more than color alone.

  • Underline inline links or give them another non-color cue.
  • Pair red error styling with text such as “Email is required.”
  • Use icons, labels, or patterns in charts instead of relying only on hue.
  • Test text over photographs, gradients, and cards in every responsive state.

How to verify: run a contrast checker on body text, metadata, buttons, form hints, focus indicators, and error states. Then view the design in grayscale to catch color-only meaning.

5. Give forms persistent labels and recoverable errors

Forms are where many attractive UIs fail. A placeholder is not a label because it disappears when the user types and often has weak contrast. The WAI form labeling tutorial recommends labels that identify all controls, preferably with a for attribute matching the input id. The WAI form validation tutorial also emphasizes clear required indicators, accessible notifications, and server-side validation in addition to client-side checks.

<label for="email">Email address (required)</label>
<input id="email" name="email" type="email" required aria-describedby="email-help">
<p id="email-help">Enter an address like [email protected].</p>
  • Keep labels visible.
  • Place error text near the field it explains. After validation fails, set aria-invalid="true" and associate the specific error using aria-describedby; remove the invalid state when corrected. The example above shows a persistent hint, not an error state.
  • Use forgiving formats when possible, especially for phone numbers, names, and addresses.
  • For high-risk actions, provide confirmation or undo instead of immediate irreversible submission.

How to verify: submit the form empty, with invalid data, and with a keyboard only. The user should know what failed, where it failed, and how to fix it.

6. Write image alternatives based on image purpose

Image-rich pages need more than “photo” or keyword-stuffed alt text. The WAI Images tutorial explains that alt text depends on purpose: informative images, decorative images, functional images, images of text, complex graphics, groups of images, and image maps need different treatment.

  • For a decorative flourish, use empty alt text: alt="".
  • For an informative photograph, describe the information the surrounding text does not already provide.
  • For a linked image, describe the destination or action, not just the visual content.
  • For a complex diagram, provide a short alt plus nearby structured explanation.
<figure>
  <img src="darkroom-contact-sheet.jpg" alt="Contact sheet with six marked frames selected for sequencing">
  <figcaption>The circled frames show the editor's proposed sequence for the photo essay.</figcaption>
</figure>

How to verify: hide the images and read the page. If the story, task, or link purpose becomes unclear, the text alternative or surrounding copy needs work.

7. Design for zoom, reflow, and long real content

A compelling layout should survive real captions, translated labels, narrow screens, and browser zoom. WCAG Reflow explains the goal: content can be enlarged without increasing line length and without forcing two-dimensional scrolling in typical reading directions.

  • Use flexible containers instead of fixed-width text blocks.
  • Let cards wrap instead of shrinking text below readability.
  • Keep tables, galleries, and code examples readable at narrow widths.
  • Avoid fixed-height boxes that crop text when users increase font size.

How to verify: test text resizing at 200%, then test reflow at 320 CSS pixels wide (for example, a 1280px desktop viewport at 400% browser zoom). Text should not overlap, controls should remain reachable, and the user should not need horizontal scrolling for ordinary paragraphs.

8. Make motion optional and purposeful

Animation can guide attention, but it can also distract, nauseate, or block people who need a calmer interface. The MDN prefers-reduced-motion reference documents the CSS media feature for users who request less non-essential motion.

@media (prefers-reduced-motion: reduce) {
  html { scroll-behavior: auto; }
  .decorative-entrance {
    animation: none;
    transition: none;
    opacity: 1;
    transform: none;
  }
}
  • Use motion to confirm state changes, not to decorate every section.
  • Avoid autoplaying carousels and scroll hijacking.
  • Provide pause, stop, or reduced-motion behavior for repeated animation.
  • Do not hide essential content behind animation timing. Target known non-essential effects, as in the example; when disabling them, leave their content visible and ensure functionality does not depend on an animation-end event.

How to verify: enable “Reduce motion” in the operating system or browser environment and reload the page. The experience should remain complete, calm, and understandable.

9. Size targets for hands, tremors, and touch screens

Small controls look refined in a mockup and frustrating on a phone. WCAG Target Size Minimum requires pointer targets to be at least 24 by 24 CSS pixels or to have sufficient spacing, with specific exceptions. For important actions, larger targets are usually better.

  • Give buttons and menu items enough padding, not just a larger visual background.
  • Separate adjacent icon buttons so a tap does not trigger the wrong action.
  • Make the whole card clickable only when the destination is unambiguous.
  • Keep destructive actions away from routine actions such as “Save” or “Next.”

How to verify: test with a thumb on a phone, then with browser zoom. If a control requires precision or sits tightly beside another control, increase its active area or spacing.

10. Test the interface the way users will experience it

The W3C WAI accessibility principles are a useful reminder that accessibility is not one checkbox: content needs to be perceivable, operable, understandable, and robust. Before launch, combine automated checks with manual review.

  • Keyboard: reach and operate every control, menu, form field, and dialog.
  • Screen reader smoke test: check page title, heading outline, link text, image alt, labels, and error messages.
  • Visual review: inspect contrast, focus indicators, target size, and color-independent status cues.
  • Responsive review: test small screens, long captions, translated labels, zoom, and text resizing.
  • Failure review: load missing images, invalid forms, slow network states, and disabled non-essential JavaScript.

Good accessibility does not make a UI less compelling. It makes the strongest parts of the design — hierarchy, rhythm, imagery, action, and trust — available to more people in more conditions.