Accessibility

Accessibility

dalMap is built to meet WCAG 2.2 AA for contrast and keyboard access, and to work with a screen reader, a keyboard alone, magnification, or a switch device. This page says what currently holds for that, states the limit a live map puts on the non-visual case, and says what is still a goal rather than a finished claim.

What dalMap currently meets

• Every control is reachable and shows where you are. Buttons, links, and form controls carry a visible focus ring as you tab through them; a marker you have tabbed to on the map gets its own ring drawn around the marker itself. Decorative map geometry — labels, arrows, footprints — is left out of the tab order on purpose, so tabbing moves between things you can act on rather than through everything drawn on the canvas.
• Opening a panel moves your focus to it. A detail card, a planner, or a result opens with your focus already inside it, rather than only announcing it from a distance and leaving you to go find it.
• Contrast that is measured against the standard. Interface text, status colors, marker casings, borders, and the focus ring itself hold at least what WCAG requires in both Light and Dark — 4.5:1 for text, 3:1 for a functional indicator like a ring or a marker casing — at narrow and wide layouts alike. The figures are remeasured on every change rather than assumed to still hold after one.
• A name for every control, including icon-only ones, and a hidden heading or label where visible text was intentionally left off, so the page still has a name and a structure for a screen reader.
• Announcements scoped to what changed. A live update is announced when something actually changes, rather than as a running commentary on everything the map is doing.
• Reduced motion, and reduced transparency, are honored. The transitions dalMap uses are removed if you have asked your system for less motion, and the map jumps straight to a new result instead of animating there when you have asked for that. A panel that would otherwise sit on a translucent background uses a solid one if you have asked your system to reduce transparency too.

The map itself

Two of the map’s overlay layers — the Maidenhead grid lines and the CQ, ITU, and DXCC zone boundaries — are drawn faint on purpose, below the contrast a functional indicator would need, because they are reference scaffolding meant to sit quietly under the activity on top of them rather than compete with it. Markers, the focus ring, and anything you are meant to act on are held to the full standard; these two are the narrow exception to it.

What is still a goal

The running map has no skip link of its own today — this guide does, but the map you actually operate does not yet. A list or table view of what a layer is currently showing, so the map’s content is not locked behind tabbing through it one marker at a time, is the larger goal behind that. Automated checks catch what they are built to catch, not everything a screen reader, a switch device, or magnification would surface; nothing on this page is a claim that every layer has been walked through with assistive technology by a person.

If something is in the way

Tell us. The Support page says how to report a problem with dalMap, and an accessibility barrier is reported the same way as anything else that is not behaving: what you were trying to do, what you were using — a screen reader and its version, a switch device, keyboard only, magnification, your browser and operating system — and what happened instead.

dalDesk, dalMap, and dalSDR hold to one shared accessibility standard — see the family’s accessibility page for what all three commit to.