Over the past decade, GreenInfo Network has developed a series of open source tools to help the California Department of Parks and Recreation with funding decisions. These tools have been used to direct almost $1.3 billion in park funding to communities that most need investments in new parks.

We built these tools using a range of open source software, including PostgreSQL/PostGIS, GDAL/OGR, Leaflet, Django and various JavaScript and Python libraries.

We recently overhauled the website hosting these tools, ParksforCalifornia.org, to meet accessibility standards. By far, the biggest accessibility challenges we faced were with four data-driven map applications that display maps, data, and charts on parks, demographics, and park access. To be fully accessible, all maps and graphics must be keyboard accessible, meet standards for color contrast and color blindness, and all data must be presented in a comparable way to users of assistive technology such as a screen reader.

We approached accessibility remediation of these tools in four discrete steps: Visual design phase, design review by an accessibility consultant, build phase, and final review of built products. We briefly describe these steps below and discuss what we learned through this process.

The design phase involved reviewing and revising the existing versions of the tools to make improvements in three areas: simplifying and improving the workflow of the tools, updating colors on the maps and graphics to ensure they meet standards for color contrast and color blindness, and improving information hierarchy and the presentation of search results.

There are significant design challenges in each of these areas. Maps with more than two or three colors, for example, often must employ borders and hatch patterns to ensure sufficient contrast. Another challenge is that maps must provide text alternatives for the visual information they convey, in figure captions or elsewhere on the page. Complete text descriptions of detailed map features can be difficult at scales larger than a neighborhood or city, which requires us to significantly rethink and overhaul how we present maps and statistics, e.g. lists of parks, that can potentially cover the entire state of California.

The next step was to iterate on the design mockups with an accessibility consultant and the client, to ensure our proposed remediations were both accessible and continued to meet the original intent of the tools.

Next was the build phase. This included writing new functions to calculate the proportions of important features visible in the client-side map, areas of parks and disadvantaged communities for example. These are reported back to the front end as the user interacts with the map, and are printed in dynamic captions and text areas below the maps. In certain cases, we also enumerate individual parks and provide these as a paginated list, as an alternative to the prior, less accessible method, where individual parks could only be queried through direct map click interaction.

The final phase involved an iterative review of the built products by the accessibility consultant to ensure accessibility compliance.

Through this process, we learned a number of important lessons that we think are generally helpful and applicable to any effort to make maps and data more accessible.

The first of these is the need to look carefully and critically at each map and really understand who it is for, what it means, and what it is most fundamentally expressing, so you can effectively present it as either a map or as text. While people are increasingly experimenting with using artificial intelligence for translating visual map data to text, we found this to be unnecessary. Through this process, we were able to identify a relatively short list of key attributes that the map is conveying, and each of these can be effectively expressed as text, albeit with some work to make this dynamically available as the user pans or zooms the map, or selects a new area.

An interesting and unexpected result of this process was the realization that improvements made for “accessibility” simultaneously make these products easier to use, understandable, and useful for users of all abilities. The very definition of “everybody wins”.