[Accessibility] Audit and improve experience for blind / screen-reader users

[accius]

Is your feature request related to a problem?

A blind ham operator reached out noting that very few ham radio applications are accessible to blind users — and asked whether OHC has been audited for screen-reader compatibility. The honest answer is: not systematically.

This isn't a single bug. It's a tracking/umbrella issue for a structured accessibility pass across the whole app, with the explicit goal of making sure blind and low-vision hams get a usable, dignified experience — not just a stripped-down "lite" version.

Describe the Solution You'd Like

A structured audit and follow-up improvements covering, at minimum:

Screen reader support

• Verify every interactive element has an accessible name (aria-label, associated <label>, or visible text)
• Add aria-live regions for status changes — band changes, new spots, WSJT-X decodes, satellite pass alerts, lightning proximity alerts, etc. — so screen-reader users get notified of important events without polling the UI
• Ensure landmark roles (<nav>, <main>, <aside>, etc.) are correct
• Verify every panel is reachable and operable via keyboard alone

Keyboard navigation

• All controls reachable via Tab in a logical order
• All interactive elements operable via Enter / Space
• Visible focus indicators that are not removed by outline: none
• Standard shortcuts considered (e.g. / to focus a search, ? for help)

Visual / non-screen-reader accessibility

• Color contrast meets WCAG AA in all themes (Dark, Light, Retro, custom)
• Information not conveyed by color alone — band-color heatmaps, propagation maps, status indicators all need text/icon alternatives
• Charts and data visualizations have textual summaries available to screen readers

Data tables / spot lists

• Use semantic table markup where appropriate so screen readers can navigate by column / row
• Frequency and time announced in human-readable forms (e.g. "fourteen point zero seven four megahertz, three minutes ago")

Map

• A non-map view of the same data for screen-reader users (e.g. a list of spots with bearing + distance from DE)? Or at least an aria-described summary of what's currently on the map?

Describe Alternatives You've Considered

• Linking to a separate screen-reader-friendly site would let other dashboards remain "the accessible one" while OHC stayed "the rich/visual one". Not preferred — we want OHC to be the inclusive option, not delegate.

Use Case

Every ham deserves access to propagation data, contest info, satellite passes, and POTA/SOTA spots — regardless of vision. Blind ops are a small but vibrant part of the community, and the "ham radio software is hostile to screen readers" complaint comes up regularly enough that addressing it well would be a real differentiator.

• General HF operation
• VHF/UHF operation
• Satellite operation
• Contesting
• POTA/SOTA
• DXing
• Emergency communications
• Other: every use of the app

Would you be willing to help implement this?

• Yes, I can submit a PR
• Yes, I can help test
• No, but I'd use it!

Call for testers

If any blind or low-vision operators in the community would be willing to test and give feedback during the audit, please comment here. That direct lived-experience feedback is hugely more valuable than running automated WCAG checkers in isolation — automated tools catch the easy stuff but miss the friction that only a real screen-reader user can describe.

Additional Context

Filed in response to feedback from a blind operator. Expect this umbrella issue to spawn smaller sub-issues for individual panels or interaction patterns as the audit progresses. Tagging help wanted because community testing input is essential to doing this well.

[accius]

First pass landed on Staging in f2d292c. What's in it:

• Global :focus-visible rule with a 2px cyan keyboard-focus outline (matches whichever theme's accent-cyan is active). Mouse clicks don't draw the ring — only keyboard navigation does, matching native browser behaviour.
• aria-label added to icon-only buttons in DXClusterPanel, ActivatePanel (the parent of POTA / SOTA / WWFF), and PSKReporterPanel.
• aria-pressed added to all toggleable buttons in those panels so screen readers announce their state correctly (filter on/off, map on/off, path-lines on/off, etc.).
• New controls added in this Staging cycle ([FEATURE] Toggle visibility of spotter info in DX Cluster panel #995 spotter toggle, [FEATURE] Sort DX Cluster and activations panels by frequency #998 sort selectors) shipped with aria-label from the start.

What's still open — spawned as focused sub-issues so contributors / volunteers / blind testers can pick them up independently:

• [Accessibility] Add aria-live regions for status changes #1000 — aria-live regions for status changes (band changes, new spots, satellite passes, lightning proximity, relay state)
• [Accessibility] Screen-reader spot list announcements + semantic table markup #1001 — screen-reader spot list announcements + semantic table markup on the DX / POTA / SOTA / WWFF / PSK panels
• [Accessibility] Non-map alternative view of map data for screen-reader users #1002 — a non-map alternative list view of map data (bearing, distance, age) for blind operators
• [Accessibility] Complete the aria-label audit across remaining panels #1003 — complete the aria-label audit across the rest of the panels (Weather, Header, Settings, Band Conditions, Space Weather, MeshCom, APRS, etc.) — tagged good first issue since it's mostly mechanical pattern-following

Keeping this umbrella open as the tracking issue. Still very much want to hear from any blind or low-vision operators — the sub-issues are educated guesses about what matters; your lived-experience friction list would be much more valuable than mine.

73 de K0CJH