Designing for Accessibility: Beyond Compliance

The word "accessibility" in web design conversations tends to produce a specific, slightly defensive reaction. Developers think: compliance burden. Legal requirement. Checklist item. Something we handle at the end of the project by running an automated scanner and fixing the flagged issues.

This framing is both morally limited and strategically incorrect.

Web accessibility is not about passing an audit. It is about building for the actual range of human experience — the full diversity of how people see, hear, move, think, and navigate the web. And when you do it well, the result is a website that is measurably better for everyone.

The Business Case, First

Before making the design and ethical arguments, it is worth stating the commercial reality plainly.

In the Netherlands, an estimated 2.3 million people have some form of disability that affects how they use the internet. Globally, that number is approximately 1.3 billion. When you build a website that excludes these users — through poor color contrast, unlabeled interactive elements, inaccessible forms, or animations that trigger vestibular disorders — you are literally choosing not to serve a large market segment.

Beyond the user population, search engine optimization has strong overlap with accessibility best practices. Google's crawlers are, in many respects, the most sophisticated "assistive technology" on the web. They cannot see images, cannot execute JavaScript reliably, and navigate your site like a screen reader would. A website with clean semantic HTML, meaningful alt text, logical heading hierarchies, and well-labeled interactive elements is both accessible and highly crawlable.

The European Accessibility Act (EAA) comes into full effect across EU member states in 2025. For commercial products and services with digital touchpoints, compliance with EN 301 549 (which references WCAG 2.1 Level AA) is legally required. The consequences for non-compliance include fines, enforcement actions, and reputational damage. This is not a distant hypothetical — it is the current regulatory reality.

Understanding WCAG: The Four Principles

The Web Content Accessibility Guidelines (WCAG) are organized around four core principles, known by the acronym POUR:

Perceivable — Information must be presentable in ways all users can perceive, including those who cannot see or hear. This means providing text alternatives for images, captions for video, and ensuring that color is not the only way information is communicated.

Operable — All functionality must be operable through a keyboard. This is perhaps the most commonly violated principle on creative websites. Every interactive element — links, buttons, form fields, modal openers, navigation items — must be reachable and activatable via Tab, Enter, and Space. Custom interactive elements that are only usable with a mouse exclude the millions of users who rely on keyboards, switch devices, or eye-tracking technology.

Understandable — Content and interface must be understandable. This includes writing in clear language, providing helpful error messages in forms, ensuring consistent navigation patterns, and warning users when actions have significant consequences.

Robust — Content must be interpretable by a wide variety of user agents, including assistive technologies. This is primarily a technical requirement: use semantic HTML, avoid proprietary browser features, and ensure your content degrades gracefully.

The Semantic HTML Foundation

The single most impactful accessibility improvement you can make to most websites is using correct semantic HTML. This sounds basic. It is, in fact, the area where the majority of websites fail most consistently.

A <div> has no semantic meaning. A screen reader user navigating a page built entirely of nested <div> elements hears a flat, undifferentiated stream of content with no structure, no landmarks, and no way to navigate efficiently.

Correct semantic structure gives screen reader users the ability to skip directly to the main content, jump to navigation, identify sections as headings (and navigate between them), recognize form fields and their labels, and understand the purpose of interactive elements.

<!-- Wrong: Semantically meaningless -->
<div class="nav">
  <div class="nav-item">About</div>
  <div class="nav-item">Services</div>
</div>

<!-- Right: Semantically meaningful -->
<nav aria-label="Main navigation">
  <ul>
    <li><a href="/about">About</a></li>
    <li><a href="/services">Services</a></li>
  </ul>
</nav>

The visual output of these two examples can be identical. Their accessibility profile is entirely different.

Color Contrast: The Most Common Failure

WCAG 2.1 AA requires a contrast ratio of 4.5:1 between text and its background for normal text, and 3:1 for large text (18pt and above, or 14pt bold). This seems low — a 4.5:1 ratio is not particularly high-contrast to the typical sighted developer sitting at a calibrated display in a dimly lit studio.

But consider who else is reading your website: someone with cataracts, viewing your site on a low-quality monitor, in direct sunlight, on a phone screen at its minimum brightness. For these users, low contrast is not an inconvenience — it is a barrier.

The dark-mode aesthetic that defines premium creative websites presents particular challenges here. Very dark backgrounds with dark gray text — a common styling choice for supporting copy in dark contexts — frequently fails the contrast ratio test. At Ruberio, we use the browser's built-in contrast checker (in Firefox DevTools) to verify every color combination in our design system.

Our dark backgrounds are #0A0A0A. Our primary body text is rgba(255,255,255,0.85), giving a contrast ratio of approximately 17:1. Our secondary text is rgba(255,255,255,0.55), giving a ratio of approximately 7:1. Both pass Level AA. The secondary text would fail if we dropped below rgba(255,255,255,0.40) for normal-sized body copy.

Animation and Vestibular Disorders

This is perhaps the least-discussed accessibility requirement in creative web design, and arguably the most important one to understand for agencies building animation-heavy websites.

Vestibular disorders affect the inner ear's ability to sense balance and spatial orientation. For people with these conditions, large-scale motion on screen — particularly parallax effects, zooming, and rotational animations — can trigger immediate physical symptoms including nausea, dizziness, and headaches. The severity of these reactions can be significant; some users have reported symptoms persisting for hours after viewing a heavily animated website.

The prefers-reduced-motion CSS media query allows users to signal that they prefer reduced animation. It is supported in every modern browser and can be set through the operating system's accessibility settings. Using it is straightforward:

@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;
  }
}

In GSAP, you can check this preference via window.matchMedia('(prefers-reduced-motion: reduce)').matches and skip or simplify animations accordingly. This ensures the experience remains functional without triggering physical discomfort.

At Ruberio, we include a global prefers-reduced-motion override in every project and build each component to degrade gracefully when animations are disabled. The visual experience changes; the functionality never does.

Forms: Where Accessibility Gets Practical

Contact forms are among the most important accessibility targets on a marketing website, because they are the conversion mechanism. An inaccessible form loses you leads.

The most common form accessibility failures are:

Missing or detached labels: A <label> must be programmatically associated with its <input> via a for attribute matching the input's id. Placeholder text is not a label substitute — it disappears when the user types and provides no persistent context.

Unclear error messages: Form validation errors must identify exactly which field has an error and what the user needs to do to fix it. "This field is required" is minimally acceptable. "Please enter your email address in the format name@company.com" is good.

Missing required field indication: Not just visual asterisks, but aria-required="true" on each required input so screen readers announce the requirement.

No focus styles: Many designers remove the browser's default focus outline because it looks inelegant. This is a serious error. Users who navigate via keyboard need visible focus indicators to know where they are on the page. The solution is to replace the default outline with a styled one, not to remove it entirely.

Our Commitment

We believe accessibility is a dimension of quality — not a constraint on it. A website that excludes users with disabilities is not fully designed. It is incomplete.

In practice, our accessibility standard for every project is WCAG 2.1 Level AA. We test with keyboard navigation, with VoiceOver on macOS, and with automated tools like Axe-core. We ship prefers-reduced-motion support as a default. We write semantic HTML from the first component.

This work does not make our websites less beautiful. In several cases, the discipline of building accessibly has forced us to make our designs cleaner, our typography more legible, and our interactions more intentional.

Build for everyone. It makes everything better.