---
title: "Accessibility for real-time web apps"
description: "Accessibility for real-time web apps argues that accessibility should be treated as an ongoing design and engineering process rather than a late checklist, using blind developer Nolan Darilek’s experience to frame the subject. It explains why reducing interaction barriers benefits everyone, why disability can be temporary or acquired with age, and why teams should plan for access needs from the beginning. Recommended practices include automated checks such as Deque’s Axe DevTools, live audits, testing with people who have specific access needs, and hiring people with disabilities without making one employee solely responsible. The post then identifies Phoenix LiveView challenges in LiveBeats: dynamically loaded routes need transition announcements, live regions need careful updates, and dropdowns and modals require keyboard-accessibility work."
---

# Accessibility for real-time web apps

[Fly.io](https://yomu.fyi/company/fly-io) · Mar 3, 2022

**Type:** Explainer

## Summary

Accessibility for real-time web apps argues that accessibility should be treated as an ongoing design and engineering process rather than a late checklist, using blind developer Nolan Darilek’s experience to frame the subject. It explains why reducing interaction barriers benefits everyone, why disability can be temporary or acquired with age, and why teams should plan for access needs from the beginning. Recommended practices include automated checks such as Deque’s Axe DevTools, live audits, testing with people who have specific access needs, and hiring people with disabilities without making one employee solely responsible. The post then identifies Phoenix LiveView challenges in LiveBeats: dynamically loaded routes need transition announcements, live regions need careful updates, and dropdowns and modals require keyboard-accessibility work.

## Context

The post addresses accessibility barriers in web applications, with particular attention to real-time Phoenix LiveView applications. It argues that accessibility should be planned from the start because retrofitting access can create costly, difficult-to-fix mistakes, and notes that disability may be permanent, temporary, or acquired with age.

## Approach / What changed

The recommended process combines accessibility-focused planning, automated browser and development-tool checks, live audits, testing with people who have specific access needs, and hiring people with disabilities while avoiding assigning the entire responsibility to one employee. For LiveBeats, the planned work targets dynamic route announcements, accessible live updates, and keyboard-accessible dropdowns and modals.

## Takeaways

- Automated tools such as Deque’s Axe DevTools can catch common accessibility issues, but they do not replace live testing or feedback from people with access needs.
- Phoenix LiveView can introduce accessibility challenges when routes load dynamically, page regions update live, or dropdown menus and modals lack keyboard access by default.
- Hiring people with disabilities can help identify essential accessibility needs, but accessibility should remain a shared strategy rather than one employee’s sole responsibility.

**Tags:** [Accessibility](https://yomu.fyi/topic/accessibility), [Phoenix LiveView](https://yomu.fyi/topic/phoenix-liveview), [Testing](https://yomu.fyi/topic/testing)

- Source: [Fly.io](https://fly.io/blog/intro-to-accessibility)
- Source URL: https://fly.io/blog/intro-to-accessibility
- Ingested by Yomu: 2026-09-02T11:57:37.471Z

[Read original post](https://fly.io/blog/intro-to-accessibility)