Accessibility in HealthTech Apps: A Web Developer’s Checklist

In healthcare, accessibility isn't a nice-to-have—it’s a must. But for developers, that often raises a tough question: What does accessibility actually look like in code? What do we need to do, exactly, to make sure our apps work for people with disabilities—and meet compliance requirements while we're at it?

This article is built around practical insights from one of our developers at Momentum. It's not theory. It's not marketing fluff. It's a clear, actionable breakdown of the exact steps and code-level details that go into building accessible HealthTech products.

Whether you're optimizing for screen readers, improving touch target sizing, or baking accessibility into your component library—this is the technical checklist you’ll want on hand.

TL;DR: Quick Checklist Summary

If you’re short on time, here’s what you need to hit:

• Use semantic HTML
• Test with screen readers
• Keep touch targets large
• Meet WCAG contrast ratios
• Ensure keyboard navigation
• Support text resizing

These are the high-level goals. The rest of this article breaks down how to achieve them.

Essential Front-End Development Considerations

Accessibility starts at the front-end layer. Many of the biggest blockers for users—especially those using assistive tech—are rooted in HTML structure, visual design, or input behavior. Let’s dig into each one.

Screen Reader Compatibility

Screen readers rely on clean, semantic markup to parse content. If you skip that step, everything else falls apart.

Semantic HTML Structure

Use proper HTML elements for their intended purposes:‍

<!-- Instead of this -->
<div class="button" onclick="submitForm()">Submit</div>

<!-- Use this -->
<button type="submit">Submit</button>

Meaningful Alt Text

Provide descriptive alternative text for all images, describing images with alt text that captures what users need to know:‍

<img src="pill.jpg" alt="Red oval pill with score line, 10mg Lisinopril">

ARIA Attributes

Use ARIS only when standard, native HTML elements aren't sufficient:‍

<div role="button" aria-pressed="false" tabindex="0"
     aria-label="Mark medication as taken">Mark as taken</div>

Focus Management

Make sure users know where they are and what they're interacting with—at all times. Tab order matters. Focus visibility matters.

Touch Targets and Motor Control

Think about your most dexterity-challenged user. Now ask: can they use this comfortably?

Many developers overlook this—especially if they’re designing for desktop-first. In HealthTech, that’s a big mistake. Large touch targets (at least 44×44 pixels, but preferably larger for healthcare applications) and forgiving spacing reduce frustration and boost accuracy for everyone, but especially for older or motor-impaired users.

Visual Accessibility: Color and Contrast

Good contrast isn’t about branding. It’s about legibility in real-world lighting and vision conditions.

Make sure:

• You maintain a minimum contrast ratio of 4.5:1 for normal text (WCAG AA standard)
• Color isn’t the only signal (use icons, text, labels to convey information)
• You test using color blindness simulators
• You provide high-contrast mode options‍

.alert-message {
  color: #d42020; /* Ensure this passes contrast checks */
  border: 2px solid #d42020;
}

/* High contrast mode */
@media (prefers-contrast: high) {
  .alert-message {
    color: #000000;
    border: 3px solid #000000;
  }
}

Responsive Text and Layouts

Users will change their system font size. Your UI needs to adapt, not break.

This means:

• Use rem or % instead of px‍
• Support system font size adjustments without breaking layouts
• Avoid fixed-sized containers that clip text when enlarged
• Consider offering in-app text size adjustments

body {
  font-size: 100%; /* Base font size */
}

.medication-name {
  font-size: 1.25rem; /* REM scales with user preferences */
  line-height: 1.5;
}

.medication-card {
  min-height: fit-content;
  height: auto;
  overflow: visible; /* Prevents clipping */
}

For in-app text size adjustment:‍

function adjustTextSize(sizePreference) {
  const root = document.documentElement;

  switch(sizePreference) {
    case 'small': root.style.fontSize = '90%'; break;
    case 'medium': root.style.fontSize = '100%'; break;
    case 'large': root.style.fontSize = '120%'; break;
    case 'extra-large': root.style.fontSize = '150%'; break;
  }

  localStorage.setItem('textSizePreference', sizePreference);
}

Keyboard Navigation

If a user can’t tab through your app—they can’t use your app. Period. Ensure your HealthTech app is fully navigable without a mouse: ‍

// Add keyboard support for custom components
document.querySelectorAll('.med-toggle-btn').forEach(button => {
  button.addEventListener('keydown', (event) => {
    if (event.key === ' ' || event.key === 'Enter') {
      event.preventDefault();
      toggleMedicationStatus(button.dataset.medicationId);
      const isPressed = button.getAttribute('aria-pressed') === 'true';
      button.setAttribute('aria-pressed', !isPressed);
    }
  });
});

This is especially important when working with custom components.

WCAG Compliance Implementation

The WCAG framework (Web Content Accessibility Guidelines) helps ensure apps are usable by people with diverse abilities. Here’s how to implement the four core principles:

Perceivable

Provide text alternatives for visual content. Generate descriptive alt text for medication images that include important visual characteristics like color, shape, and dosage information.

Operable

Allow users to adjust timing for critical interactions. Implement customizable timers for important actions with clear visual countdowns and options to extend time limits, particularly beneficial for users who need more time to process information.

Understandable

Create clear error identification systems. When form validation fails, provide specific error messages, visually highlight problematic fields, and use proper ARIA attributes to ensure screen readers announce the errors correctly.

Robust

Develop content that works across different browsers and assistive technologies. Use well-structured, semantically correct HTML that clearly defines relationships between elements and maintains proper hierarchy.

Testing Accessibility

Even with the best intentions, accessibility issues can slip through—unless you test like it matters.

Automated Testing

import { axe } from 'jest-axe';

describe('Medication Form', () => {
  it('should not have accessibility violations', async () => {
    document.body.innerHTML = `<form id="medication-form">...</form>`;
    const results = await axe(document.body);
    expect(results).toHaveNoViolations();
  });
});

Screen Reader & Keyboard Testing

You can’t automate everything. Manual testing is essential—especially for:

• Screen reader flows (VoiceOver, NVDA, TalkBack)
• Keyboard navigation through all interactive elements

Responsive Design Testing

Try it zoomed. Try it rotated. Try it on an older device. That’s what your users are doing.

Implementation Strategies

Accessibility shouldn’t be a last-minute QA pass. It should be built into how your UI components work from day one.

Component Accessibility Library

Create reusable, pre-tested accessible components:

class AccessibleComponents {
  static createToggleButton({id, labelText, initialState, onChange}) {
    const button = document.createElement('button');
    button.id = id;
    button.setAttribute('aria-pressed', initialState ? 'true' : 'false');
    button.textContent = labelText;

    button.addEventListener('click', () => {
      const newState = button.getAttribute('aria-pressed') !== 'true';
      button.setAttribute('aria-pressed', newState ? 'true' : 'false');
      if (onChange) onChange(newState);
    });

    return button;
  }
}

Focus Management Utility

Create a utility for managing focus in single-page applications:

const FocusManager = {
  previousFocus: null,

  saveFocus() {
    this.previousFocus = document.activeElement;
  },

  restoreFocus() {
    if (this.previousFocus?.focus) {
      this.previousFocus.focus();
      this.previousFocus = null;
    }
  },

  trapFocus(containerId) {
    const container = document.getElementById(containerId);
    if (!container) return;

    const focusableElements = container.querySelectorAll(
      'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
    );

    if (focusableElements.length === 0) return;

    const firstElement = focusableElements[0];
    const lastElement = focusableElements[focusableElements.length - 1];

    firstElement.focus();

    // Handle tab key navigation
    container.addEventListener('keydown', (e) => {
      if (e.key !== 'Tab') return;

      if (e.shiftKey && document.activeElement === firstElement) {
        e.preventDefault();
        lastElement.focus();
      } else if (!e.shiftKey && document.activeElement === lastElement) {
        e.preventDefault();
        firstElement.focus();
      }
    });
  }
};

Adaptive Interface Design

Develop interfaces that adapt to user preferences:

class AdaptiveInterface {
  constructor() {
    this.preferences = {
      fontSize: localStorage.getItem('fontSize') || 'medium',
      colorScheme: localStorage.getItem('colorScheme') || 'default',
      reducedMotion: localStorage.getItem('reducedMotion') === 'true' || false,
      highContrast: localStorage.getItem('highContrast') === 'true' || false
    };

    this.applyPreferences();

    // Watch for system preference changes
    this.setupMediaQueryListeners();
  }
}

Technical Recap: What to Build and Why

Imagine your product is live. A caregiver logs into the app on their tablet to update a loved one’s medication schedule—with one hand, while holding a cup of tea in the other. The buttons are large enough to tap confidently. They don’t need to squint—the font size adjusts to match their system preferences. The error messages are clear. The actions are labeled. They can do what they came to do.

Now picture someone else. A visually impaired patient opens the same app using a screen reader. Every button has a proper label. The navigation is logical. The app doesn’t trap them in modals or drop focus unpredictably. The text alternatives make sense. They get through the task—independently.

This is what accessible software looks like in production. And under the hood, here’s how it’s built:

• Semantic HTML creates a structure that’s understandable and screen-reader friendly
• ARIA roles are used only where native elements don’t suffice—no more, no less
• Keyboard support is built in, with every interaction operable using Tab, Enter, and Space
• Tap targets are comfortably large, spaced to avoid misclicks—even on small screens or with shaky hands
• Layouts flex with user preferences—rem, %, and min-content are doing the work, not pixel locks
• Components are modular, tested, and accessible by design—not hacked together after QA flags something
• Automated a11y tests run on CI. Manual screen reader flows are part of routine testing.

It’s not glamorous. But it’s dependable, inclusive, and production-ready.

Accessibility is infrastructure. Treat it like versioning, testing, or auth. It’s foundational.

Final Thoughts

Accessibility in HealthTech isn’t a side feature. It’s a build requirement. These aren’t theoretical guidelines—they’re proven implementation details used in real-world apps that serve aging populations and users with disabilities.

By embedding accessibility into your dev process, you’re not just making better software. You’re making software that actually works for the people who need it most.

Ready to level up your approach? Start with the checklist and build from there. Should you need help with that, drop us a line - we'd be glad to help.