maptime/map-accessibility-guidelines

A set of guidelines for developers, cartographers, GIS specialists, geographers, and civic hackers to consider when creating projects that include web maps

Map Accessibility Guidelines

A set of guidelines for developers, cartographers, GIS specialists, geographers, and civic hackers to consider when creating projects including web maps.

Check out a summary of some Best Practices and accompanying code snippets. Our Wiki site contains additional background information about accessibility and some additional web and print resources you may want to check out.

Want to help contribute to this repo? Visit our 'How to Contribute' page for information on how to get started!

Project History

This project originated in Feburary 2015 as part of the Hennepin County Geo:Code event in Minneapolis, Minnesota. Other groups who have supported or contributed to this project include:

• Open Twin Cities
• Maptime MSP
• Maptime HQ

2015 NACIS Conference

Kitty Hurley, Alison Link, and Mitch Schaps conducted a 20-minute presentation on Thursday, Oct. 15th, 2015 at the NACIS Conference in Minneapolis. Our abstract was titled Starting Conversations for More Accessible Maps and presented in the Community-Oriented Cartography session.

Check out our Slide Deck!

Minnesota Standards and Tools

Since 2016, the State of Minnesota, the University of Minnesota, and MetCouncil has spearheaded an effort which has resulted in a set of standards and tools on maps for:

• Map Design
• Static Maps (e.g., PDF and PNG)
• Interactive Web Maps

The standards and tools can be found on Minnesota's Office of Accessibility webpage.

map-accessibility-guidelines's Issues

Add me as a contributor

I think I have some things I could add. Let me know if you'd rather have me run things by you first, though.

Focus in-action gif

Create an awesome .gif that shows the use of a :focus in-action for the focus.md document. Try and use it on an existing map so visitors can see how to apply it to an interactive map.

Add mobile examples

Add examples such as @media css queries, or ways for the interactive map to be responsive.

Include before and after shots showing the weird things that happen on a mobile screen that we don't see in our browser.

Add navigation structure to bestpractices.md

Add navigation to the code snippets on the bestpractices.md file.

Add a map legend example

Add a few map legend examples. A before shot where the legend isn't expanded, and difficult for the user to understand your map, and an after shot that shows an expanded legend.

Also explain this solution isn't perfect for mobile devices, and some workarounds for mobile devices.

Add readme.md navigation

Add navigation to the wiki, BestPractices.md, and code snippets from the main readme.md.

Edit the Wiki homepage

Edit the Wiki homepage so visitors can navigate through our Wiki. 😺

DOT link

Thought you might be interested in this one if you don't have it already: http://www.dot.state.mn.us/mediaroom/graphicstandards/maps.html

Add table and list images

Add a few examples (preferably images) that showcase a table and list accompanying an interactive map.

Edit the Leaflet accessible zoom control code snippet

Edit the code snippet, so it includes the actual code and gets rid of the * in the <img class>. See commit ba72c5d for additional details.

Upload Final Powerpoint

We should post our PowerPoint slides somewhere in the repo so everyone can follow along while we are presenting. If we need to update it after we present, it should be, in theory, 'easy'.

We should also create a short url to direct people to it at the beginning of our presentation.

Update contribution wiki page

Provide a more detailed contribution guide in the wiki (re: a recent comment). 👍

Update color images

Include self-made color images as opposed to using what the Googles puts out there.

Map legend expanded by default

Having the Map legend expanded by default means that keyboard-only users have to tab through each item as opposed to having the option to skip the content within the component. The advice I think is contradictory to the WCAG 2.1 technique Using an expandable and collapsible menu to bypass block of content (the technique satisfies Success Criterion 2.4.1: Bypass Blocks).

Highlighting some relevant information from Understanding Success Criterion 2.4.1: Bypass Blocks:

This is in contrast to a sighted user's ability to ignore the repeated material either by focusing on the center of the screen (where main content usually appears) or a mouse user's ability to select a link with a single mouse click rather than encountering every link or form control that comes before the item they want.

Benefits
When this Success Criterion is not satisfied, it may be difficult for people with some disabilities to reach the main content of a Web page quickly and easily:

• People who use only the keyboard or a keyboard interface can reach content with fewer keystrokes. Otherwise, they might have to make dozens of keystrokes before reaching a link in the main content area. This can take a long time and may cause severe physical pain for some users.

Consolidate wiki 'Home' to BestPractices.md

Now that we've got the BestPractices.md file in our repo, it might be a good idea to consolidate the takeaways from the Geo:Code event with the Best Practices Markdown document. This way we can organize the Wiki home to be a navigation page throughout our Wiki site.

If you agree, @linkalis, would you be willing to consolidate the key points within one of the three sections (key takeaways, accessibility principles, or accessibility techniques)?