Split out of #72. Too large for that issue and not targeted for the next release.
Both sections have the same root cause: Leaflet and its drawing and clustering plugins (Leaflet.draw, Leaflet.markercluster, Leaflet.Deflate) give vector features no keyboard or ARIA support. Leaflet builds that support into markers and controls: marker icons get a tabindex and role="button", and the zoom, popup-close, and tooltip controls get roles and labels. Shape geometry, by contrast, is created as a bare <path> with no tabindex, role, or aria-label, and no option to add them. So neither section has a configuration fix; fully addressing either depends on the mapping library and its plugins themselves.
Edit: keyboard placement of shapes
Drawing shapes on the edit and Contribution maps is mouse-only via Leaflet.draw. There's no non-mouse way to place a polygon or line, comparable to how the "find a location" address search already places a point. Markers are already keyboard-placeable via that search, so this is specifically about lines and polygons.
Likely won't-do as a bespoke build: keyboard drawing is fundamentally a Leaflet.draw limitation, not really the plugin's own. Supporting it would mean building a full accessible input path to work around the library, and Leaflet.draw was last released in 2017 (1.0.4) and is effectively unmaintained.
Better path to explore first: evaluate replacing Leaflet.draw with a maintained drawing library (for example Leaflet-Geoman or Terra Draw). That would give an actively-maintained API and let us assess whether such a library offers better keyboard and accessibility support than Leaflet.draw. It's a larger architectural decision affecting all drawing (mouse included), so it would be its own evaluation, not just this item.
Related: Leaflet.draw puts a tool's action links (Finish/Cancel) after all the tool buttons in tab order, so keyboard users tab past everything to reach them (noted in #71). It's the same keyboard limitation and would be swept up by this evaluation, so it's not tracked separately.
Show: keyboard navigation of features on public maps
Raised in #71 testing, tracked in #72. On the public item and browse maps there's no way to tab through the features on the map itself. Point markers are focusable, but drawn shapes aren't in the tab order at all, and markers drop out of it when clustered or deflated. So a keyboard user can't move feature to feature on the map, and shapes also have no accessible name, unlike markers, which get the location label, then the item title, then a generic "Map location".
Partly addressed by the location list (commit ccab423): each feature has a named, focusable list row that frames it and opens its popup, including when a shape is clustered or deflated. This gives keyboard and screen-reader users a reliable way to reach and identify every feature, and it satisfies the "list affordance" option from #72.
Still open: navigating the features on the map itself, rather than through the list. Like the edit side, this is a library limitation rather than something worth hand-building on the current stack. It's a question for the display side of the mapping stack, in the same spirit as the drawing-library evaluation above: whether a maintained, accessible mapping library and plugins give vector features keyboard focus and accessible names out of the box.
Split out of #72. Too large for that issue and not targeted for the next release.
Both sections have the same root cause: Leaflet and its drawing and clustering plugins (Leaflet.draw, Leaflet.markercluster, Leaflet.Deflate) give vector features no keyboard or ARIA support. Leaflet builds that support into markers and controls: marker icons get a
tabindexandrole="button", and the zoom, popup-close, and tooltip controls get roles and labels. Shape geometry, by contrast, is created as a bare<path>with notabindex,role, oraria-label, and no option to add them. So neither section has a configuration fix; fully addressing either depends on the mapping library and its plugins themselves.Edit: keyboard placement of shapes
Drawing shapes on the edit and Contribution maps is mouse-only via Leaflet.draw. There's no non-mouse way to place a polygon or line, comparable to how the "find a location" address search already places a point. Markers are already keyboard-placeable via that search, so this is specifically about lines and polygons.
Likely won't-do as a bespoke build: keyboard drawing is fundamentally a Leaflet.draw limitation, not really the plugin's own. Supporting it would mean building a full accessible input path to work around the library, and Leaflet.draw was last released in 2017 (1.0.4) and is effectively unmaintained.
Better path to explore first: evaluate replacing Leaflet.draw with a maintained drawing library (for example Leaflet-Geoman or Terra Draw). That would give an actively-maintained API and let us assess whether such a library offers better keyboard and accessibility support than Leaflet.draw. It's a larger architectural decision affecting all drawing (mouse included), so it would be its own evaluation, not just this item.
Related: Leaflet.draw puts a tool's action links (Finish/Cancel) after all the tool buttons in tab order, so keyboard users tab past everything to reach them (noted in #71). It's the same keyboard limitation and would be swept up by this evaluation, so it's not tracked separately.
Show: keyboard navigation of features on public maps
Raised in #71 testing, tracked in #72. On the public item and browse maps there's no way to tab through the features on the map itself. Point markers are focusable, but drawn shapes aren't in the tab order at all, and markers drop out of it when clustered or deflated. So a keyboard user can't move feature to feature on the map, and shapes also have no accessible name, unlike markers, which get the location label, then the item title, then a generic "Map location".
Partly addressed by the location list (commit
ccab423): each feature has a named, focusable list row that frames it and opens its popup, including when a shape is clustered or deflated. This gives keyboard and screen-reader users a reliable way to reach and identify every feature, and it satisfies the "list affordance" option from #72.Still open: navigating the features on the map itself, rather than through the list. Like the edit side, this is a library limitation rather than something worth hand-building on the current stack. It's a question for the display side of the mapping stack, in the same spirit as the drawing-library evaluation above: whether a maintained, accessible mapping library and plugins give vector features keyboard focus and accessible names out of the box.