Skip to main content
Policies & Legal
4 min read

Accessibility Features and Commitments

What's built in, what we're working on, and how to report accessibility issues

Last updated: May 27, 2026

This is the detailed companion to our Accessibility Statement. It lists what's currently in place, what's in progress, and what's not implemented — honestly, because over-claiming conformance helps no one.

Standards we work toward#

DailyWorship targets WCAG 2.2 Level AA. We do not claim full AA conformance today; we work toward it continuously and prioritize accessibility issues alongside functional bugs.

What's in place today#

Keyboard navigation#

The application is navigable by keyboard. Tab order follows visual order; focus indicators are visible; Escape closes dialogs; arrow keys work in lists and menus. See Keyboard Shortcuts.

Screen reader support#

Most pages use semantic HTML with appropriate ARIA labels. Loading states announce via role="status" and aria-busy; dialogs use role="dialog" and trap focus; form errors are linked to inputs via aria-describedby. We test with VoiceOver on macOS and iOS regularly; NVDA on Windows less frequently. Report screen-reader issues and we'll treat them as bugs.

Visible focus indicators#

Every interactive element has a visible focus indicator. We don't use outline: none without a replacement focus style.

Color contrast#

Text contrast targets WCAG AA ratios (4.5:1 normal text, 3:1 large text). The default theme is the accessible one.

Captions and transcripts#

Generated tracks include the full lyric text in machine-readable form on the track detail page — a deaf or hard-of-hearing user can read the lyrics while the music plays.

Reduced motion#

If your OS requests reduced motion (prefers-reduced-motion: reduce), animations are minimized across the app.

Form accessibility#

All inputs have associated labels. Required fields are marked visually and with aria-required. Validation errors are announced to screen readers.

What's in progress#

  • A formal external accessibility audit (not yet commissioned; planned before claiming AA conformance publicly).
  • Better support for Windows high-contrast / forced-colors mode.
  • Synchronized scrolling captions during playback (rather than static lyric display).
  • Native mobile-app accessibility (iOS VoiceOver and Android TalkBack first).

What's not implemented today#

  • A separate "accessibility mode" toggle — we aim to make the default experience accessible rather than gating it.
  • Audio descriptions for visual content — we have no video or image-only navigation that requires them.
  • Sign-language interpretation — out of scope for an audio-music platform.

How to report an accessibility issue#

  1. Email accessibility@dailyworship.net or Contact Support with the page URL, your browser and assistive technology, and a description of what didn't work.
  2. We treat accessibility issues as bugs and prioritize them.
  3. We follow up by email when the fix ships.

If you'd like to volunteer for accessibility user testing, please get in touch — we especially welcome worship leaders and team members who use assistive technology day-to-day.

Related Articles:

accessibility
wcag
screen reader
keyboard
aria

Was this article helpful?

Your feedback helps us improve our documentation.