Accessibility: keyboard placement and navigation of line/polygon shapes

首先检查当前的 Leaflet.draw、Leaflet.markercluster 和地图显示集成，以及此处描述的位置列表和弹窗焦点行为。比较 Leaflet-Geoman 和 Terra Draw 在键盘和无障碍支持方面的表现，包括已识别出的放置、编辑、导航、命名和焦点方面的缺口。完成的标准是为地图技术栈形成一份评估和明确的实现方向。

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.

Two more edit-map keyboard gaps surfaced in #71 second-round testing, grouped here since they share the same edit-map/Leaflet.draw territory:

• Keyboard delete and edit of placed features. Removing or reshaping a placed point or shape is mouse-only (Leaflet.draw's edit/delete handles), with no keyboard path. Same Leaflet.draw limitation as placement, so it rides the same evaluation.
• Focus into a marker's popup on activation. On the edit and Contribution maps, keyboard focus currently moves through all markers before entering an open popup to reach the label input, then the close button. Focus should move directly into the popup on activation, and also when focus reaches a marker whose popup is already open.

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.

One related detail on the show side: when a popup opened from the list is closed, focus should return to the row it came from. Today the close handler tries to return focus to the feature element, which is null for a marker that has re-clustered and non-focusable for a shape's <path>, so focus drops to the top of the document. Restoring focus to the originating list row would fix it; grouped here with the clustered/shape keyboard work.

Accessible names for marker clusters. Raised in #56. When markers are clustered, the cluster bubble (the grouped "N" count) has no accessible name, so a screen reader can't identify it. Unlike the keyboard gaps above, there's a concrete fix already written upstream: Leaflet.markercluster added ARIA labeling for clusters but never shipped it in a release (the project hasn't cut one in a long time). Rather than wait, we can pull those changes in by hand, as @zerocrates suggested in #56.