WebAIM - Web Accessibility In Mind

E-mail List Archives

for

From: Brandon Keith Biggs
Date: Jun 16, 2025 1:25PM


Hello Colton,

Yes, all features (points, polygons, and lines) need to be keyboard
accessible. Here is a webinar from the ADA Centers that talks more about
this topic <https://accessibilityonline.org/ada-tech/archives/111159>. Here
is a recent CSUN Journal article that evaluates different digital map tools
based on WCAG <http://hdl.handle.net/20.500.12680/qn59qf178>;.
Congratulations on tackling this topic, it is a difficult one!

1. On the ESRI application, yes in theory this meets 2.1.1 as long as
there are absolutely no other features on the map that have labels or are
clickable. Best practice would move a focus indicator on the map as the
user moves through the selected objects.

2. This is similar to the above example. If you wanted to improve the
user experience, use a first-letter navigable menu
<https://whatsock.com/Templates/Menus/External%20-%20Straylight/index.htm>
or a searchable menu
<https://whatsock.com/Templates/Comboboxes/Native%20Inputs,%20Editable%20with%20Substring%20Match/index.htm>.
Again, if it is at all possible to read labels or focus baselayer content,
then that needs to be added into the menu as well.

3. This also works, but that is a lot of tab stops and items to get
through. I would consider using a first-letter navigable menu or a search
box described above.



In summary:

1. All the panning and zooming functionality needs to be keyboard
accessible.

2. All the features with labels or any kind of interactive experience
need to be keyboard accessible.

3. Any drawing functionality needs to be keyboard accessible.



Although these examples seem to meet SC2.1.1, they do not fully meet
SC1.1:Non-Text
Content <https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html>.
Here is a blog post I wrote on how to evaluate SC1.1.1, which is one of the
most difficult success criteria to meet
<https://xrnavigation.io/how-to-systematically-evaluate-the-text-accessibility-of-a-map-with-examples/>
.

Here is a map evaluation tool based on WCAG criteria that may help in your
accessibility journey. <https://xrnavigation.io/map-evaluation-tool/>

Please let me know how else I can help.

Thank you,


Brandon Keith Biggs <http://brandonkeithbiggs.com/>;


On Mon, Jun 16, 2025 at 10:25 AM Hash, Colton via WebAIM-Forum <
<EMAIL REMOVED> > wrote:

> Hi, I have been researching ways to develop more accessible web maps where
> users can select map features with keyboard controls.
>
> Most web map platforms only allow users to pan and zoom in on a map using
> keyboard controls. However, many web maps have points and polygon features
> that users can click on using a mouse to display additional information.
> From my understanding of WCAG Success Criteria 2.1.1 , users should also be
> able to select and activate map features using keyboard only controls?
>
> Example 1: ArcGIS Map Application
> https://experience.arcgis.com/experience/f49f4168ba6842e2aecb21db3adc969d
>
> This simple ArcGIS web app allows users to click polygon regions or point
> features with a mouse to display relevant contact information. None of the
> points or polygons on the map are keyboard accessible, but there is a
> connected information window where you can select different features with
> arrow buttons. Is this acceptable to meet keyboard accessibility
> requirements?
>
>
> Example 2: Custom Leaflet Map Application
> https://mhpdojmtdev.wpenginepowered.com/accessible-map-test/
>
> This is a test map application to demonstrate the ability to select points
> and polygon features with Tab, and show information with Enter. Google Maps
> API and Leaflet allow easy implementation of point markers that are
> directly keyboard navigable. Modifying the DOM of Leaflet output, I was
> able make it so polygon features are selectable with TAB and Enter. I
> assume that this is closer to what a Keyboard Navigable map should look
> like?
>
>
> Example 3: Custom Google Maps Application
> https://mvdstg.wpengine.com/driver-license-exam-stations/
>
> As a final example, this work-in-progress map application has a list of
> accordion sections for each city, which highlights the location on the map
> when expanded. The points on the map are also keyboard navigable with Tab,
> and arrow keys to select between currently visible points on screen. When a
> point is activated from the map, the associated accordion section is
> focused. This approach offers an html / text-based alternative to navigate
> map information, but still allows keyboard users to fully interact with the
> map.
>
>
> So for a web map to be WCAG 2.1 AA compliant, is it necessary to have
> these elements be directly navigable with keyboard controls as in Example 2
> and Example 3? Or is it acceptable to have an interface where users can
> indirectly select points from an associated control, as in Example 1?
>
> Thank you for providing additional information and feedback, I am
> continually learning about web accessibility and have been working to
> improve our team's map applications.
> -Colton
>
>