Designing for Intent and Preference

In the previous parts of this series, I explored how to structure a site for the Accessibility Tree, how to manage interactive logic, and how to automate these patterns in the content pipeline. Those decisions were about building structural integrity. I initially approached accessibility as a structural problem, but this part forced me to rethink something less visible: who ultimately controls behaviour.

Context: Beyond Aesthetics#

Design is often framed as a visual discipline. We choose colours, typography, and spacing to create a specific aesthetic. Accessibility literacy expands that view. A site does not exist in isolation; it runs inside an operating system configured by the user.

Because this site operates as a static export, we can’t detect user preferences at request-time. Instead, we must delegate that logic entirely to the browser using native CSS features and media queries. When someone enables high contrast, reduces motion, or navigates exclusively by keyboard, they are not expressing a preference in the abstract. They are defining constraints for how software should behave. Those settings shape how accessible a system actually is in practice.

Approach: Respecting System-Level Preferences#

1. Focus Indicators as Navigation Infrastructure#

For a keyboard user, the focus indicator is navigational infrastructure. It indicates location within the document in the same way a cursor indicates position in a text editor.

Relying on browser defaults can be inconsistent, and in some colour combinations the default outline has insufficient contrast. To make the behaviour predictable across themes, I defined a global focus style in web/app/globals.css:

/* Accessible focus indicators */
:focus-visible {
  @apply outline-none ring-2 ring-primary ring-offset-2 ring-offset-background;
}

Using :focus-visible ensures the indicator appears when navigation occurs via keyboard, without introducing unnecessary visual noise for mouse or touch interactions. The ring uses theme tokens, ensuring it remains visible in both light and dark modes.

The goal is not aesthetic enhancement. It is to guarantee that keyboard navigation is always observable.

2. Reduced Motion as a First-Class Constraint#

Transitions and smooth scrolling can introduce motion that some users explicitly opt out of at the operating system level. When prefers-reduced-motion: reduce is enabled, that preference should be treated as authoritative.

The following global rule removes non-essential animation when the user has opted out:

/* Reduced motion support */
@media (prefers-reduced-motion: reduce) {
  *,
  ::before,
  ::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

This approach is intentionally broad. It prioritises eliminating unexpected motion over preserving decorative transitions. In this architecture, it is the most reliable way to align behaviour with user configuration. For some users, unexpected motion can trigger physical discomfort like dizziness or nausea; the operating system preferences exist for a reason.

3. Outbound Context and Predictable Navigation#

Unexpectedly opening a new tab can be disorienting, particularly for users relying on assistive technology. If a link changes browsing context, that behaviour should be communicated before activation.

For external links, I include both a visual indicator and screen-reader-only context:

<a
  href="https://github.com/edwardsmatt" 
  target="_blank"
  rel="noopener noreferrer"
  className="inline-flex items-center gap-1"
>
  GitHub
  <ExternalLink aria-hidden="true" className="w-3 h-3" />
  <span className="sr-only">(opens in a new tab)</span>
</a>

The visible icon signals context change for sighted users. The screen-reader text ensures the same information is conveyed non-visually. The objective is predictability. Navigation should behave as described.

Trade-offs: Visual Control vs Behavioural Guarantees#

Respecting system-level preferences can constrain visual control. A high-contrast focus ring may sit outside a tightly curated brand palette. Removing motion may flatten carefully designed transitions. Adding outbound indicators may introduce additional visual elements in minimalist layouts.

In a design system with rigid token definitions or strict brand rules, accommodating these behaviours may require expanding the token set or negotiating exceptions.

The trade-off is deliberate. Predictable interaction and alignment with operating system settings take precedence over aesthetic purity. A system that behaves unpredictably under common accessibility configurations is not robust.

Literacy Gained#

Working within these constraints changed how I approach styling. The shift for me was realising that accessibility is not just about semantics—it is about accepting that the user’s configuration outranks my design preferences. When operating system settings are treated as authoritative constraints, the site becomes more predictable. That predictability is the real outcome.

In the final part of this series, I will look at how to prevent regression and make these behaviours durable at the architectural level.