Accessibility: Why It Affects More Users Than You Think

1. Why accessibility affects more users than you think

Accessibility is treated in many projects as a compliance topic for a small, clearly defined group: people with a permanent visual impairment who use a screen reader. That view is not technically wrong, but it is dangerously incomplete. It ignores the fact that the overwhelming majority of situations in which accessibility features are actually needed have nothing to do with a permanent disability, and everything to do with ordinary daily life: a phone screen in bright sunlight, one-handed use while carrying grocery bags, or a form that is barely readable right after eye surgery.

For Magento and Hyvä stores, this means: treating accessibility purely as a legal obligation under the European Accessibility Act (EAA) misses the actual business case. High-contrast buttons, large touch targets, and clear focus states lower cart abandonment for every customer, not just the users who are officially considered the accessibility target group. The following sections show how wide the real user spectrum actually is, and how that translates concretely into code, design, and testing strategy.

2. The spectrum: permanent, temporary, situational

Microsoft's Inclusive Design team coined a model that turns out to be remarkably useful in practice: the same functional limitation can occur permanently, temporarily, or situationally. A user with one arm has a permanent limitation. Someone with a broken arm in a cast has the exact same functional limitation temporarily. A parent carrying a child with one arm has the same functional limitation situationally, for a few minutes. All three need the same solution: an application that can be fully operated with one hand.

This model is valuable precisely because it shifts the target audience for accessibility from a small minority to practically every user who at some point in their life visits a website under less than ideal conditions. A blind user, a user recovering from cataract surgery, and a user squinting at their display in bright sunlight all benefit from the exact same contrast ratio. Once a team understands this overlap, it stops treating accessibility as an edge case and starts treating it as a quality trait of robust interfaces.

3. Situational impairments in everyday life

Situational impairments do not arise from a health condition but from context: glaring sunlight makes weak contrast unreadable, a noisy environment makes audio without captions useless, and carrying a bag forces one-handed thumb-only interaction. In mobile commerce especially, these situations are the rule, not the exception: a significant share of Magento sessions happen on the go, often with one hand, often with a fluctuating connection and changing lighting.

The practical lever lies in reachability of key actions and contrast ratio. Primary actions like "Add to cart" belong in the lower half of the screen, within the natural thumb zone, rather than at the top of the header where they are hard to reach with one hand. A skip link that jumps straight to the main content helps not only keyboard users, but anyone who wants to get to the actual content quickly without scrolling past navigation and banners.

<!-- Hyva phtml: skip link and thumb-reachable primary action -->
<a href="#main-content"
   class="sr-only focus:not-sr-only focus:absolute focus:top-2 focus:left-2
          focus:z-50 focus:bg-white focus:text-black focus:px-4 focus:py-2 focus:rounded-lg">
    Skip to main content
</a>

<main id="main-content" tabindex="-1">
    <!-- Sticky add-to-cart bar in the lower thumb zone, not in the header -->
    <div class="fixed bottom-0 inset-x-0 z-40 bg-white border-t border-gray-200 p-4 sm:hidden">
        <button
            type="submit"
            form="product_addtocart_form"
            class="w-full min-h-[44px] bg-black text-white font-bold rounded-lg
                   focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2"
        >
            Add to cart
        </button>
    </div>
</main>

4. Temporary impairments: from a cast to eye surgery

Temporary impairments differ from situational ones in that they persist for days or weeks rather than disappearing after a few minutes. A broken wrist in a cast, recent eye surgery with temporarily reduced vision, a severe migraine with light sensitivity, or a bad flu with shaky hands: in every one of these cases, users need exactly the same accommodations as users with a corresponding permanent impairment, just for a limited period of time.

The difference for development is still minimal. A form that can be operated by keyboard helps the user with RSI just as much as the user with a freshly operated shoulder who avoids the mouse. Large touch targets of at least 44 by 44 pixels per WCAG 2.2 help both the user with essential tremor and the user with a cast on their index finger. It is also important to avoid strict time limits in checkout forms, or to make them generously extendable, because anyone who types more slowly needs more time, regardless of the reason.

/* Touch targets and focus states that help every user */
.btn,
.form-input,
.nav-link {
  min-height: 44px;
  min-width: 44px;
  padding: 0.75rem 1rem;
}

/* Clearly visible focus ring instead of removing the browser default */
:focus-visible {
  outline: 2px solid #18181b;
  outline-offset: 2px;
}

/* Less motion for users with migraines or vestibular disorders */
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

/* High contrast for bright ambient light or low vision */
@media (prefers-contrast: more) {
  .btn-primary {
    background-color: #000000;
    color: #ffffff;
    border: 2px solid #000000;
  }
}

5. The aging user base: vision and motor skills over time

Demographic change makes accessibility a growing topic rather than a shrinking one. As people age, visual acuity, contrast perception, and fine motor control gradually decline, long before anyone would classify themselves as a "person with a disability." Presbyopia, or age-related farsightedness, affects practically everyone from their mid-forties onward and turns small text without zoom support into a real obstacle, not a marginal one.

For Magento stores with a broad, aging customer base, this is a direct revenue factor: purchasing power is disproportionately concentrated among older user groups, while their tolerance for hard-to-use interfaces simultaneously decreases. The practical consequences are concrete and usually cheap to implement: font sizes in relative units (rem) instead of fixed pixel values so users can zoom in the browser without breaking the layout, generous line spacing for better readability, and form fields with clearly visible, permanently displayed labels instead of vanishing placeholder text that causes confusion while filling out a form.

6. Accessibility meets good UX: shared design principles

Most accessibility measures cannot be cleanly separated from general UX quality, because both solve the same underlying problems: unclear structure, poor contrast, unpredictable behavior. A dropdown menu that closes on Escape and returns focus to the triggering button afterward is simultaneously a WCAG requirement and simply better interaction design. This is exactly where Hyvä with Alpine.js pays off: focus management can be built directly into a component without any additional library.

The decisive mistake in many modal implementations is a missing focus trap: keyboard focus wanders out of the visible dialog into the hidden background when pressing Tab, which is confusing for screen reader users and any keyboard power user alike. A clean focus trap that moves focus to the first interactive element on open, keeps it inside the dialog while tabbing, and returns it to the triggering element on close is one of the single most impactful accessibility patterns there is.

// Alpine.js: accessible modal dialog with focus trap
document.addEventListener('alpine:init', () => {
  Alpine.data('accessibleModal', () => ({
    open: false,
    triggerEl: null,

    openModal() {
      this.triggerEl = document.activeElement;
      this.open = true;
      this.$nextTick(() => {
        this.$refs.dialog.querySelector('[autofocus], button, a, input')?.focus();
      });
    },

    closeModal() {
      this.open = false;
      // Return focus to the button that opened the dialog
      this.triggerEl?.focus();
    },

    trapFocus(event) {
      if (event.key !== 'Tab') return;
      const focusable = this.$refs.dialog.querySelectorAll(
        'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
      );
      const first = focusable[0];
      const last = focusable[focusable.length - 1];

      if (event.shiftKey && document.activeElement === first) {
        event.preventDefault();
        last.focus();
      } else if (!event.shiftKey && document.activeElement === last) {
        event.preventDefault();
        first.focus();
      }
    }
  }));
});

7. The WCAG principles (POUR) in the Magento checkout

The Web Content Accessibility Guidelines summarize all requirements under four principles that can be remembered with the acronym POUR: Perceivable, Operable, Understandable, and Robust. In the Magento checkout, this becomes very concrete. Perceivable means that form errors are not signaled by color alone, but also by text and icon, so colorblind users can recognize them too. Operable means that every step of checkout can be completed without a mouse, using only the keyboard.

Understandable means error messages state exactly what is wrong and how to fix it, instead of just showing "Invalid input." Robust means the code works reliably across different assistive technologies, because semantic HTML is used instead of divs with click handlers. An aria-live region that automatically announces new error messages to screen readers without shifting the user's focus is a small detail with a large impact for anyone who cannot, or does not want to, rely on visual feedback while filling out a form.

<!-- Hyva phtml: checkout form field with full POUR support -->
<div class="form-field mb-4">
    <label for="street" class="block text-sm font-medium text-gray-900 mb-1">
        Street and house number
        <span class="text-red-600" aria-hidden="true">*</span>
        <span class="sr-only">(required)</span>
    </label>
    <input
        type="text"
        id="street"
        name="street"
        required
        aria-describedby="street-error"
        aria-invalid="{{$errors->has('street') ? 'true' : 'false'}}"
        class="w-full min-h-[44px] border rounded-lg px-3 py-2
               focus-visible:outline focus-visible:outline-2"
    >
    <!-- aria-live announces new errors without moving focus -->
    <p id="street-error" role="alert" aria-live="polite" class="text-red-600 text-sm mt-1">
        {{$errors->first('street')}}
    </p>
</div>

8. Testing with real constraints, not just checklists

Automated tools such as axe-core or Lighthouse reliably catch about a third of all accessibility issues, and systematically miss the rest, because they lack context: a decorative icon with no alt text is correctly left unflagged, while a misleading alt text on an informative product image is not caught at all. This is why any serious testing process also needs manual testing with real constraints: unplugging the mouse entirely and navigating the checkout with only Tab, Shift-Tab, and Enter, using a VoiceOver or NVDA screen reader for a while, or setting the display to minimum brightness in bright daylight.

In a CI pipeline, axe-core is still valuable as a first, automated line of defense that catches obvious regressions like missing form labels or insufficient contrast before a human even needs to test manually. Combining automated checks on every pull request with periodic manual testing using a keyboard and a screen reader covers the vast majority of real-world accessibility issues in practice, without requiring a full manual audit for every small change.

{
  "axeCoreConfig": {
    "runOnly": {
      "type": "tag",
      "values": ["wcag2a", "wcag2aa", "wcag22aa"]
    },
    "rules": {
      "color-contrast": { "enabled": true },
      "target-size": { "enabled": true },
      "label": { "enabled": true },
      "aria-required-attr": { "enabled": true },
      "focus-order-semantics": { "enabled": true }
    },
    "ciPipeline": {
      "failOn": ["critical", "serious"],
      "warnOn": ["moderate", "minor"],
      "testedRoutes": [
        "/checkout/cart",
        "/checkout",
        "/customer/account/login",
        "/catalogsearch/result"
      ]
    }
  }
}

9. Accessibility compared: myth versus reality

A central reason why accessibility is often addressed too late, or not at all, in projects is a mistaken assumption about who it actually affects. The table below contrasts everyday situations that look, at first glance, unrelated to accessibility, but very much are.

In all five cases, the technical solution is identical to what a user with a permanent disability would need anyway. Building accessibility deliberately for this broad, overlapping audience automatically improves the experience for users with permanent impairments too, rather than the other way around. That makes the investment economically more attractive, because the effect spreads across the entire user base.

10. Summary

Accessibility affects far more users than screen reader statistics alone would suggest. Permanent, temporary, and situational impairments lead to the same functional requirements: sufficient contrast, large touch targets, full keyboard operability, and clear error messages. Sunlight on a display, a cast on an arm, recent eye surgery, or simply the growing age of a store's own customer base are not edge cases, they are the daily reality of any Magento store with meaningful traffic.

The WCAG principles of perceivable, operable, understandable, and robust offer a concrete, testable framework for this, one that translates directly into Hyvä components with Alpine.js: focus traps in modals, aria-live regions for form errors, and contrast values that hold up even in bright ambient light. Automated tools like axe-core cover part of the problem, real testing with a keyboard and screen reader covers the rest. Teams that consistently build this combination into development gain not just EAA conformance, but measurably better usability for the entire user base.

11. FAQ: Accessibility on the Web