1mg – Accessibility Implementation (Healthcare Dashboard)

Frontend Developer – Individual Contributor · 2018 · 2 months · 1 person · 7 min read

Independently audited and retrofitted full WCAG accessibility compliance into an existing Angular healthcare dashboard — covering semantic HTML, keyboard navigation, screen reader support, ARIA implementation, and color contrast across the entire application

Overview

Led a focused, solo accessibility remediation engagement for 1mg — one of India's largest online healthcare platforms. The project involved a comprehensive audit and implementation of WCAG 2.1 accessibility standards across an existing Angular dashboard, ensuring the platform was usable by people with visual, motor, and cognitive disabilities. Working as an individual contributor, delivered end-to-end accessibility improvements covering semantic structure, keyboard operability, assistive technology compatibility, and visual contrast — within a tight two-month timeline.

Problem

1mg's dashboard had been built with a strong focus on visual design and feature delivery, but accessibility had not been part of the original development mandate. The result was a functionally rich application that was effectively unusable for people relying on screen readers, keyboard-only navigation, or high-contrast display settings. In the healthcare context, this was particularly significant — users managing medications, prescriptions, and health records include elderly users, users with visual impairments, and users with motor disabilities who depend on assistive technologies. Beyond the ethical imperative, accessibility gaps in healthcare software increasingly carry regulatory and reputational risk.

Constraints

  • Existing codebase must not be structurally refactored — accessibility improvements had to be additive and non-breaking
  • No dedicated design or QA resource — audit, implementation, and validation were sole responsibilities
  • Angular constraints limited some modern accessibility tooling options
  • Two-month timeline required prioritisation of highest-impact accessibility gaps first
  • Healthcare context demands particular care around form accessibility — prescription inputs, dosage selectors, and health data fields are critical interaction points

Approach

Began with a systematic accessibility audit of the full dashboard using a combination of automated tooling (Lighthouse) and manual testing with screen readers (NVDA, VoiceOver) and keyboard-only navigation. Categorised findings by severity and user impact, then worked through remediation in priority order — semantic HTML structure and keyboard navigation first, followed by ARIA implementation, focus management, and color contrast corrections. Validated each fix against WCAG 2.1 AA criteria before moving forward. Maintained close communication with the product owner throughout, sharing audit findings and demonstrating remediated flows at key checkpoints.

Key Decisions

Manual screen reader testing alongside automated tooling

Reasoning:

Automated accessibility scanners catch roughly 30–40% of real accessibility issues — they cannot evaluate the quality of ARIA label text, the logical flow of a screen reader experience, or whether focus management feels natural during complex interactions. Manual testing with NVDA and VoiceOver was essential to surface the issues that mattered most to actual assistive technology users, particularly on healthcare-critical flows like prescription management and health record navigation.

Alternatives considered:
  • Automated tooling only (Lighthouse)
  • Outsource testing to an accessibility audit service
  • User testing with disabled users (not feasible within timeline)

Additive ARIA implementation without structural refactoring

Reasoning:

Structurally refactoring an existing production codebase as an individual contributor within two months introduced unacceptable regression risk. An additive approach — enhancing existing markup with ARIA roles, labels, and live regions without changing component logic — allowed meaningful accessibility improvements to be delivered safely and verifiably within the timeline constraints.

Alternatives considered:
  • Full component-level refactor to use semantic HTML natively
  • Replace non-semantic components with an accessible component library
  • Defer structural fixes and implement workarounds only

Severity-based remediation prioritisation

Reasoning:

Not all accessibility issues carry equal weight in a healthcare context. Keyboard traps, missing form labels on prescription inputs, and screen reader-invisible error messages were treated as critical and addressed first. Color contrast issues and focus indicator styling — important but non-blocking — were addressed in the second phase. This ensured the most harmful barriers for users with disabilities were removed as early as possible within the two-month window.

Alternatives considered:
  • Fix issues in order of discovery
  • Address all issues simultaneously
  • Fix visual issues first (higher visibility to stakeholders)

Tech Stack

  • Angular
  • TypeScript
  • SCSS
  • ARIA (WAI-ARIA 1.1)
  • Lighthouse
  • NVDA
  • VoiceOver

Result & Impact

  • WCAG 2.1 AA
    Compliance Target
  • Full dashboard
    Audit Coverage
  • Automated + manual screen reader
    Testing Methods
  • Delivered in 2 months
    Timeline

The engagement transformed 1mg's dashboard from an application that was inaccessible to a significant portion of its potential user base into one that met WCAG 2.1 AA standards. Screen reader users gained a coherent, navigable experience across all major flows. Keyboard-only users could operate every interactive element without encountering focus traps or unreachable controls. Healthcare-critical interactions — medication management, prescription inputs, and health record fields — were given particular care to ensure they were both accessible and error-resilient. For a healthcare platform serving users who disproportionately include elderly and disabled individuals, the impact extended well beyond compliance.

Learnings

  • Automated accessibility tools are a starting point, not a finish line — manual screen reader testing consistently surfaces high-impact issues that no scanner can detect
  • Accessibility retrofitting is significantly more expensive than building accessibly from the start — the two-month timeline on an existing codebase would have been two weeks on a greenfield project
  • In healthcare applications, accessible form design is not optional — label associations, error announcement, and input grouping directly affect whether users can safely manage their own health data
  • ARIA is powerful but dangerous when misapplied — incorrect roles and labels actively worsen the screen reader experience and require the same care as any other API
  • Severity-based prioritisation is essential on solo, time-boxed accessibility work — removing critical barriers for the most affected users delivers more real-world impact than achieving a perfect audit score
  • Accessibility work builds empathy for a wider range of users — the perspective gained from manual assistive technology testing changes how you approach UI decisions permanently

Accessibility Audit

Began with a thorough, systematic audit of the full dashboard before writing a single line of remediation code:

  • Automated scanning using Lighthouse to catalogue WCAG violations across all dashboard routes and components
  • Manual keyboard navigation testing traversing every interactive flow to identify focus traps, missing focus indicators, and unreachable controls
  • Screen reader evaluation using NVDA on Windows and VoiceOver on macOS to assess the quality of the announced experience across core user journeys
  • Color contrast analysis checking all text, icon, and interactive element combinations against WCAG AA contrast ratio thresholds
  • Prioritised findings report categorising issues by severity and user impact, forming the remediation roadmap for the two-month engagement

Semantic Structure & Keyboard Navigation

Established the foundational accessibility layer across the entire application:

  • Semantic HTML corrections replacing non-semantic div and span elements used as interactive controls with appropriate button, anchor, and form element equivalents
  • Logical heading hierarchy restructuring heading levels across dashboard views to produce a coherent document outline for screen reader navigation
  • Skip navigation links added to allow keyboard and screen reader users to bypass repetitive navigation and jump directly to main content
  • Full keyboard operability ensuring every interactive element — menus, modals, dropdowns, data tables, and form controls — was reachable and operable without a mouse
  • Focus trap resolution in modal dialogs and overlay panels, implementing correct focus lock and return-to-trigger behaviour on close

ARIA Implementation

Applied WAI-ARIA roles, properties, and live regions to bridge the gap between visual UI and assistive technology:

  • ARIA labels and descriptions added to icon-only buttons, form fields without visible labels, and complex interactive components throughout the dashboard
  • Live region announcements implemented on dynamic content areas — status updates, loading states, error messages, and success confirmations — ensuring screen reader users receive feedback without requiring focus movement
  • Role assignments for custom interactive components (tab panels, accordions, dropdowns) that used non-semantic HTML but required meaningful structure for assistive technologies
  • ARIA expanded, selected, and checked states wired to Angular component state for all interactive disclosure and selection patterns
  • Form error association linking validation messages to their corresponding inputs via aria-describedby, ensuring errors were announced in context on fields critical to healthcare data entry

Visual Accessibility & Color Contrast

Addressed the visual layer of accessibility across the full dashboard:

  • Color contrast remediation updating text, border, and icon color values to meet WCAG AA minimum contrast ratios across all themes
  • Focus indicator enhancement ensuring all interactive elements displayed a clearly visible focus ring, replacing default browser outlines that had been suppressed by global CSS resets
  • Non-color status communication adding text labels, icons, and patterns to status indicators that had previously relied on color alone to convey meaning
  • Responsive text sizing ensuring no content became inaccessible when browser font size preferences were increased by the user
All projects