Non-visual map mode (no tiles or images), only feature / other HTML content

[prushforth]

For non-visual map (screen reader) users, and even perhaps sometimes for others, for bandwidth conservation reasons, it might be useful and user-friendly to be able to configure a map or layer to not load tiles and images, while still accessing feature / DOM content per normal, leaving map features in place to be announced by screen readers. The normal pan and zoom of the map might still be applicable, especially if features were to be queried and streamed appropriately. Tiles and images in a Web map are a cost but not an obvious benefit to non-visual users. Would be ideal to be able to avoid the cost where and for who that's appropriate.

This could be a browser option, akin to "Don't allow JavaScript to run" available in some browsers, perhaps on a per-domain basis or, it could be an option available from the map and/or layer context menu.

Please discuss.

[Malvoz]

Just to clarify: the precedent for this issue is that most/all popular maps hide images from ATs, because describing geographic images using alt text would not be very helpful.

This suggested capability is not essential to standardizing maps and should be tagged enhancement in the case it is included in the report.

[prushforth]

most/all popular maps hide images from ATs,

We're suggesting to not load them in the first place, which would avoid bandwidth costs, and improve performance.

[prushforth]

I believe this use case relates to supporting alternate forms of map content.

Specifically, a purely visual / image tile-based layer of an urban area, regardless of scale, conveys detailed visual semantics about the disposition of (often) text-labelled features. Should the user wish it, and should it be available from the server, a representation of the same data in purely textual form may be equally valuable to some users, and as such, the text-based alternate representation should be delivered automatically. The features in the text-based version might be the full representation, but more usefully I think they could be lightweight models of the feature that could be sorted (dynamically) in ascending order by distance from the centre of the map.

This should be possible to achieve, I believe, via media query, either presented up front via an efficient client hint header or embedded in a map document response, as a <link rel=alternate media="..." href="...">, per some interpretation and implementation of (something similar to) #43.

I would like to discuss the nature of the media query required in this thread, please.

This topic was discussed at TPAC 2022, and a presentation of a proof of this concept was shown by @boazsender , described as a browser intervention.