Switch access and magnifier support

Switch access, skip-links, and scan order

This is a nuanced area where theory and practice diverge. Skip links — including the map’s skip-to-pier links — work by moving focus (and sometimes scroll position) to a target when activated. For keyboard and screen-reader users that is effective, because their navigation follows DOM focus. Switch scanning is different, and the short answer is that in most cases scanning does not automatically jump to the target in a useful way. It depends heavily on the switch-access software.

How the main platforms behave

• iOS Switch Control does follow programmatic focus shifts, so activating a skip link moves focus to the target and scanning should resume there. It works reasonably well in practice, though the sudden context shift can be disorienting without auditory feedback.
• Android Switch Access is more problematic. It scans by visually walking the UI element tree, and its response to programmatic focus changes has historically been inconsistent: the scan may not resume at the target, and can restart from the top or carry on from where it was.
• Windows, with a Bluetooth switch driving software such as Grid 3, Communicator, or Tecla, typically routes through the keyboard and focus model, so a skip link that moves DOM focus should be followed. It generally works, but the behaviour is mediated by whichever AAC or scanning package is in use, and varies accordingly.

The deeper problem

Even when scanning does follow the focus jump, skip links carry usability friction for switch users. The link sits early in the scan order, so the user has to wait for it to come around — cognitively and physically effortful. There is no preview or confirmation of what is being skipped to. If they miss it, they have paid a timing cost and must wait for the next scan cycle. The load of anticipating the link in the sequence adds up across a page.

What helps switch users more

Landmark regions — main, nav, and the rest — combined with switch software that supports landmark-navigation shortcuts (some do, many do not) or item grouping, reduce the scan distance more elegantly than a skip link. On iOS, Switch Control’s scanning groups can be configured to skip whole regions. Proper heading structure helps too, where the scanning software exposes a heading-jump mode.

The practical implication is that skip links remain worth implementing — a low-cost, high-value win for keyboard and screen-reader users — but should not be counted on as the primary navigation accommodation for switch users. That population benefits more from good landmark structure, reduced overall DOM clutter, and logical grouping of interactive elements early in the scan order. The terminal map provides the first (landmarks and F6region cycling) but, because it draws everything as SVG, works against the second: its high node count is exactly the clutter that lengthens a switch scan. That tension is recorded honestly in the terminal map’s limitations.

Magnifiers and focus tracking

The same “it varies” applies to whether a screen magnifier moves its viewport to follow keyboard focus — which matters for the map’s “Find on map” button, which centres a result and moves focus to it. Here, though, the pattern is clearer than with switch access.

Magnifiers that reliably follow focus

• Windows Magnifier(built-in) tracks focus well in most cases, following the caret in text fields and keyboard focus on interactive elements. Its “Follow the keyboard cursor” and “Follow the text insertion point” settings need to be enabled — they are on by default but can be turned off. Tracking can lag on heavy pages, or when focus moves programmatically without a user gesture.
• ZoomText / Fusion (Freedom Scientific) is probably the most robust of any, with independent settings for tracking focus, caret, and mouse, and better handling of programmatic focus shifts than most. Fusion announces focus changes through its speech layer, a hybrid magnifier/screen-reader character that helps orientation after a jump.
• SuperNova (Dolphin) also tracks focus reliably, with configurable tracking modes, to a similar standard.

Weaker or conditional focus tracking

• macOS Zoom(built-in) follows keyboard focus within native AppKit apps reasonably, and Safari web content is generally fine, but it falls down on programmatic focus changes in web apps — focus moved by JavaScript does not always pull the viewport across, particularly outside Safari.
• iOS / iPadOS Zoom follows focus when used with a keyboard, but only if the app exposes focus to the accessibility layer; purely touch-driven apps that surface no keyboard focus give Zoom nothing to track.
• Android Magnificationis the weakest of the mainstream options — primarily gesture-driven, with limited focus-following, and it does not reliably track keyboard- or switch-driven focus.

The common failure mode

What breaks nearly every magnifier is focus moving to an off-screen or visually hidden element, or landing somewhere that does not visually reflow the page. A skip- link target that is technically in the viewport but at a position the user is not currently viewing can leave the magnifier either not moving (the element is, after all, “visible”) or snapping to a jarring location. This is why skip-link targets should sit at the actual start of meaningful content, and why a visible focus style matters especially for magnifier users.

What it means for the map

On the desktop, ZoomText/Fusion and SuperNova are the reliable baseline, Windows Magnifier is acceptable, and macOS Zoom is adequate for native apps and basic web use. On mobile, and especially on Android, magnifiers should not be relied on to follow focus automatically — those users more often pan manually. So the “Find on map” button does not depend on focus-following: its value is that it moves the result to a known, repeatable place — the centre of the viewport — that a magnifier user can reach predictably whether or not the viewport follows focus.

It also raises the bar for the visible focus indicator. A magnification user who does notget automatic viewport tracking still has to be able to find where focus landed, which means the indicator has to be large enough and high-contrast enough to be found on its own — the concern of WCAG 2.2 success criterion 2.4.13, Focus Appearance.

Reading on

• Terminal map — the demo these notes are about.
• Maps— the wider accessible-maps work.