Elissavet.dev

When we build digital products, it is easy to get caught up in the pursuit of perfect Lighthouse scores, seamless API integrations, and lightning-fast page transitions. But a high-performance web is only truly successful if it is available to everyone.

In a previous post, we explored the mechanics of accessible navigation—ensuring that the underlying map of a website can be traversed without a mouse. But navigation is just the journey; the content is the destination. To truly engineer with empathy, we have to look at the entire ecosystem of a user’s experience.

The Public Health Standard: Lessons from pfy.dypede.gr

Developing platforms for the public health sector fundamentally changes how you view users. You aren’t just building for tech-savvy early adopters; you are building for citizens who are navigating critical health services, often under stress, and utilizing a wide spectrum of assistive technologies.

When developing the pfy.dypede.gr portal, accessibility was treated as a core pillar of the architecture, not an afterthought.

• Clean, Validated Code: The foundation of the portal was built on strict, passing semantic HTML. Browsers and screen readers are incredibly smart, but they rely on the developer to provide a clean DOM structure to interpret the page correctly.
• Integrated Accessibility Widget: To assist users with visual impairments or reading difficulties, the portal utilizes the AccessiYes Accessibility Widget plugin. This free, lightweight tool injects a highly customizable accessibility overlay directly into the frontend. It provides preset profiles tailored to specific needs—such as visual, cognitive, or motor impairments—allowing users to apply complex settings with a single click. With it, citizens can customize font weight, swap to dyslexia-friendly fonts, adjust color contrast, and even utilize a built-in page reader that reads content aloud on click or keyboard focus.

“Accessibility is not a checklist you complete at the end of a project. It is a lens through which you must view every architectural decision from day one.”

Validating Accessibility During Development

How do you know your code is actually accessible while you are writing it? You cannot rely solely on automated tools to catch everything, but integrating them into your workflow is mandatory. Here is the modern stack for validating accessibility during development:

• Lighthouse & WAVE for Quick Checks: Google Lighthouse is built directly into Chrome DevTools and provides quick, single-page audits alongside performance and SEO. However, my absolute favorite for visual debugging is the WAVE Browser Extension. Instead of abstract code reports, WAVE injects icons directly onto your rendered layout, showing exactly where structural issues, missing labels, or contrast errors live.
• axe DevTools for Zero False Positives: For developers looking for strict code analysis, axe DevTools is the industry standard. Its core engine is designed with a “zero-false-positive” philosophy, meaning if it flags an issue, it is a real failure.
• Pa11y for CI/CD Pipelines: If you want to automate checks across multiple URLs or wire them into your deployment pipelines, Pa11y is an open-source CLI tool that excels at ongoing monitoring.

Pushing the Boundaries: Visual & Cognitive Design

Even with clean code and narration tools, accessibility is an ongoing practice. As we transition to headless architectures and highly dynamic interfaces, we must handle advanced cognitive and visual triggers.

1. Cognitive Clarity

Cognitive accessibility focuses on making interfaces predictable. This means writing micro-copy that explicitly explains how to fix a form error (rather than just stating “Invalid Input”), and ensuring that focus states never jump unpredictably across the DOM.

2. The prefers-reduced-motion Media Query

As we add modern, app-like transitions to our Jamstack sites, we must protect users with vestibular motion disorders (which can trigger dizziness or nausea). Operating systems allow users to turn off animations. We can respect this natively in our CSS using the prefers-reduced-motion media query:

.hero-header { 
  animation: slidein 1s ease-in-out; 
}

/* Tone down or disable the animation to avoid vestibular motion triggers */
@media (prefers-reduced-motion: reduce) {
  .hero-header { 
    animation: none; /* or use a simple, subtle fade */
  }
}

How to test it: You don’t need to dive into your OS settings every time to test this. In Chrome or Edge DevTools, open the Command Menu (Ctrl+Shift+P or Cmd+Shift+P), type reduced, and select “Emulate CSS prefers-reduced-motion” to instantly test your fallbacks.

Dynamic ARIA Live Regions in React/Gatsby

In modern decoupled applications (like Gatsby or Next.js), content often updates dynamically on the screen without a full page reload—like submitting a search filter or fetching dynamic data. A sighted user sees this instantly, but a screen reader user might miss it entirely.

We solve this using aria-live regions. However, there is a crucial implementation detail in React: for screen readers to announce changes, the entire ARIA live region must already exist in the DOM before the message is dispatched. You cannot conditionally render the wrapper div for the first time at the exact moment the text updates.

import React, { useState } from 'react';

// CORRECT: The container is permanently in the DOM, only the text changes
const LiveAnnouncer = ({ message }) => (
  <div aria-live="polite" className="visually-hidden">
    {message}
  </div>
);

export default function SearchComponent() {
  const [status, setStatus] = useState('');

  const handleSearch = () => {
    // ... fetch data
    setStatus('Search completed. 5 results found.');
  };

  return (
    <section>
      <button onClick={handleSearch}>Search</button>
      <LiveAnnouncer message={status} />
    </section>
  );
}

The Empathy Metric

Behind every API call and every React component is a human being trying to accomplish a task. By committing to deep, systemic accessibility, we ensure that the digital spaces we build are open doors, not walled gardens.