Maps & Charts: Making Visual Interfaces Accessible
•Download as PPTX, PDF•
0 likes•64 views
Learn about good UX techniques for designing web accessible maps, what we're improving in the JSAPI 4 for keyboard navigation, and how to interact with maps using assistive technologies. We'll also take a look at best practices for making charts accessible and what other solutions exist beyond using tables for everything.
Recommended
More Related Content
Similar to Maps & Charts: Making Visual Interfaces Accessible
Similar to Maps & Charts: Making Visual Interfaces Accessible (20)
Recently uploaded
Recently uploaded (20)
Maps & Charts: Making Visual Interfaces Accessible
- 1. Maps & Charts: Making Visual Interfaces Accessible Klara Schmitt
- 2. • WCAG = Web Content Accessibility Guidelines - 2008: W3C publishes WCAG 2.0 - 2010: Adopted by ISO as Int’l Standard • Section 508 = Federal Government Standard - 1998: Established - 2017: Revised Rule Published • ADA = Americans with Disabilities Act - Dept. of Justice ruled that Title III includes websites WCAG vs. Section 508 vs. ADA
- 3. Revised Section 508 includes: Top to Bottom: Asana, Issuu, Twiter • Web Software + Mobile - Web apps, LMS, project management software - Websites, web pages, blogs • Digital Content - Electronic documents - .doc, .pdf, .xls, etc - Agency communications - Social media - Intranet
- 4. From the Department of Justice The Department first articulated its interpretation that the ADA applies to public accommodations’ websites over 20 years ago. This interpretation is consistent with the ADA’s title III requirement that the goods, services, privileges, or activities provided by places of public accommodation be equally accessible to people with disabilities. ...the Department has consistently taken the position that the absence of a specific regulation does not serve as a basis for noncompliance with a statute’s requirements.
- 5. 20% of Americans are d/Deaf or hard of hearing. That’s 48 million Americans. - World Health Organization 10% of all adult Americans have some degree of vision loss. That’s 23.7 mullion American adults age 18+. - World Health Organization Photo Credit: Luis Miguel Justino
- 6. Maps
- 7. • 1.4.1 Use of Color - Color is not used as the only visual means of conveying information, indicating an action, an action, prompting a response, or distinguishing a visual element. (Level A) • 1.4.3 Contrast (Minimum) - The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except least 4.5:1, except for the following: large text, incidental, logotypes. (Level AA) • 1.4.5 Images of Text - If the technologies being used can achieve the visual presentation, text is used to convey to convey information rather than images of text. (Level AA) • 1.4.11 Contrast (Minimum) - The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent against adjacent color(s): User Interface Components, Graphical Objects. (Level AA) WCAG Guidelines
- 8. <img src=“religious-divserity-map.jpg” alt=”Map of religious diversity using simpson’s index to show likelihood of 2 individuals in same county belonging to different religious groups” /> <img src=“religious-divserity-map.jpg” alt=”Map of religious diversity using simpson’s index to show likelihood of 2 individuals in same county belonging to different religious groups” longdesc=“#moreInfo” aria- describedby=“#moreInfo” /> <p id=“moreInfo”>The analyzed groups included Latter-day Saints, Catholicism, Protestantism, Islam, Judaism, other Christians, and other religions. The high proportion of Protestants in the central states and the high proportion of Latter-day Saints in the mountain west create areas of low religious diversity.</p>
- 10. Tools • WCAG Chrome Extension • WebAIM.org • ColorOracle • Color Brewer
- 12. • Tab moves forward • Shift + Tab moves backward • These keys only jump between links & form elements • Space = select form elements • Enter = select links Keyboard Nav • Ctrl + Option = VO keys • VO + Shift = enter into page groups • VO + arrows = navigating entire page • Space = select form elements • Enter = selects links VoiceOver Nav • Insert = NVDA key • Same tab and shift/tab functionality as keyboard • Same form control keys as keyboard NVDA Nav
- 13. JSAPI 4 a11y Prototype DEMO in Safari
- 14. Charts
- 15. • Use a hidden table for screen readers • Use aria-labels or aria-labelledby to support SVGs • Use <summary> if possible (easier for static charts) • Support keyboard navigation Accessible Charts
- 18. • 1.3.1 Info and Relationships - Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A) • 1.3.3 Sensory Characteristics - Sensory Characteristics: Instructions provided for understanding and operating content do content do not rely solely on sensory characteristics of components such as shape, size, shape, size, visual location, orientation, or sound. (Level A) • 2.1.1 Keyboard - All functionality of the content is operable through a keyboard interface without requiring interface without requiring specific timings for individual keystrokes, except where the where the underlying function requires input that depends on the path of the user's user's movement and not just the endpoints. (Level A) WCAG Guidelines
Editor's Notes
- ### Intro Hi - My name is Klara Schmitt. I am a UI/UX Designer on the Hub team at Esri, and I have a passion for web accessibility. I’ve been doing accessibility related things as some part of my job for about 6 years now. ### What Is It? If you’re not familiar with accessibility, I will be using it as an umbrella term to cover WCAG 2.1, Section 508, and Title III of the ADA.
- ### Let’s cover a little background first as I want to make sure we’re all on the same page in terms of vocabulary and understanding. WCAG stands for Web Content Accessibility Guidelines and WCAG is the international web accessibility standard produced by the W3C. It is used as the baseline for a number of accessibility regulations including policies by Canada, Germany, New Zealand, Israel, and Spain. It is also the foundation for Section 508, which is used by US Federal Government. Section 508 is generally required by federal agencies developing, procuring, or using electronic information technology. Section 508 went through a revision process that brought it more inline with WCAG 2.0 and the final rule was published by the Federal Register on Jan. 18, 2017. Then there was a 12 month grace period before compliance and enforcement began. WCAG itself is now at version 2.1.
- This new variation of Section 508 covers all types of public facing content, as well as 9 categories of non-public-facing content that communicate agency business. This includes web sites, intranet, documents, social media, and project management software. With very few exceptions, the refresh aims to conform these types of software to WCAG 2.0 Level A and AA success criteria. The good news is that in setting your sights on AA, you’re automatically doing most of work to get yourself through single A.
- The ADA refers to the Americans with Disabilities Act. Within the ADA, we have Title III, which specifically prohibits discrimination on the basis of disability in activities within places of public accommodations. In a 2018 letter to Congressman Ted Budd - one of 103 members of Congress who had asked the Dept. of Justice to issue ADA regulations, the DOJ responded: The Department first articulated its interpretation that the ADA applies to public accommodations’ websites over 20 years ago. This interpretation is consistent with the ADA’s title III requirement that the goods, services, privileges, or activities provided by places of public accommodation be equally accessible to people with disabilities. ...the Department has consistently taken the position that the absence of a specific regulation does not serve as a basis for noncompliance with a statute’s requirements. So while there are still no specific regulations around what constitutes ADA compliance and there are unlikely to be any in the immediate future, the popular recommendation by most accessibility firms is to adhere to WCAG.
- ### But first things first. Why are we doing this and who does it help? When building accessible apps, we want to consider individuals with visual, hearing, cognitive, or motor impairments. In each of these categories, there is a also a wider range of conditions. For example, visual impairment could pertain to someone blind or colorblind, whereas hearing impairments could pertain to deaf individuals, the elderly, or people with tinnitus. ### How I got involved? Section 508 was initially introduced to me in college, at which point I realized things that I took for granted like being able to watch a projection screen while my javascript instructor talked, were so much more challenging for my deaf classmate who had to watch her interpreters and couldn’t be looking at the examples on screen at the same time. I believe in making the web an inclusive experience for those with disabilities because I am a designer and I spend a lot of time on the internet myself. I think it’s possible to do this without making a plain text website that has no aesthetics. This is actually why I like WCAG. While the documentation for 2.0 is really dry, the guidelines themselves do allow for flexibility, and I appreciate that it permits modern website the affordance to render with both CSS and Javascript as required. Statistics Source: https://www.3playmedia.com/accessibility-online-video-stats/
- ### So…maps… I’ve been speaking at FedGIS about accessibility for about 4 years now, and each year during the question and answer period, you all have asked, “but how do we make the maps accessible?” In the past, I haven’t exactly known how to answer that question because there isn’t an established pattern around making maps accessible. For years, mapping technology had been exempt from Section 508 regulations because it was deemed “too visual." But in the revised Section 508, the authors didn’t make any exceptions. They did this hoping technology companies would rise to the occasion and start solving the hard problems. Esri is trying. We have a cross-product working group of designers, developers, and product managers that meet to share best practices, and improve accessibility across the platform. I’m actually going to break making accessible maps into two parts. Static maps and dynamic maps.
- Let’s start with the easier of these two types first. With static maps, it’s easier to convey visual insights, because you can usually provide a textual alternative that describes what is occurring in the map. The challenge lies in the actual design of the map and how you use color and symbology. There are four WCAG guidelines that are worth considering: 1.4.1 Use of Color 1.4.3 Contrast (Minium) 1.4.5 Images of Text 1.4.11 Non-Text Contrast The intent behind “Use of Color” is that you should not use color alone to convey information. As a designer, this is a criterion that I encounter quite often while doing product interface design because there are lots of times that color would be the easiest way to indicate status, and yet, we have to be more creative to reach all audiences. Now this is trickier with maps.
- Here’s a map that I took from an article in the Washington Post that shows religious diversity by county in the United States in 2010. This map uses a legend containing a numerical count for diversity index associated with a particular color that is then represented by colored polygons on the map. If we were to look at just the map and disregard the caption at the bottom, we’d dependent on color to understand context. Methods that can help us avoid using color alone, might be using shapes, patterns, or labels to indicate information. However, doing any of those on this map in addition to the color would probably be unrealistic as it would make the map cluttered and hard to read. This is why including a caption that summarizes the map is a reasonable fall back plan. The downside is that in general we want to avoid using images of text, because there’s a guideline around avoiding that too. We could put the caption in the alt text on the image, but several screen-readers will truncate alt text at 125 characters, so unless it’s a very short caption, we might not get enough space. We could use a long description attribute on the image tag, which associates the image with text that might be further down the page, but VoiceOver (the Apple OS screen-reader) doesn’t register that attribute, so we'd might also want to use the ARIA role aria-describedby as well to support multiple screen-readers.
- Now if this map were a PDF instead of a JPEG image, it is actually easier to indicate insights. This is because we can tag multiple “images” in a single PDF and for each one of those blocks we could write unique alt text. PDFs are also a little bit better about handling text on screen and not making it into a flat image. If you need more help on how to make accessible PDFs, I wrote a tutorial on the Esri’s Accessibility GeoNet group, where I go step by step taking an ArcMap PDF export and using Acrobat Pro to make it accessible.
- The last two guidelines that I haven’t yet mentioned are about color contrast. Text and symbols need to pass certain color contrast requirements. For regular text, this is a 4.5:1 luminance ratio and for large text and graphical objects, the ratio is 3:1. There are several tools that can help with color contrast testing. I personally like using webaim.org’s color contrast tool, but I also have a Chrome extension for WCAG Luminosity Color Ratio Analyzer, which was built by Esri Canada. The authors of ArcMap have also recommended using a tool called Color Brewer to find an accessible color ramp or you install Color Oracle for desktop software. We can use Color Brewer in conjunction with a tool like the Color Ratio Analyzer, which lets us see issues like using red for roads. I’m going to actually open that and do a quick demo of both. http://colorbrewer2.org/ https://webaim.org/resources/contrastchecker/ https://colororacle.org/ https://chrome.google.com/webstore/detail/wcag-luminosity-contrast/lllpnmpooomecmbmijbmbikaacgfdagi?hl=en
- Now dynamic maps a bit harder, mainly because unlike static maps, you cannot describe visual observations except at a high level because the interactions between a user and the data on the map may change the context - for example, a heat map showing a high density of crime might not be visible until you zoom into a certain area. There are ways around this, of course. The most widely known method is to include a dynamically controlled table, which remains a recommended practice. But in addition, we could aggregate data up to a single marker on the map that contains a number to represented the collection of points. This also helps keyboard users navigate around markers without having to tab to literally every marker on the map in order to get anywhere. Markers should be able to receive keyboard focus, and they should contain structured data. All map tools should be keyboard navigable and there is also an advantage to having a search bar within the the map to narrow down by location. In a couple minutes, I’ll demo a prototype for our mapping engine the JSAPI 4, which contains an accessibility mode featuring many of these improvements. This dynamic map prototype was built by a developer on our configurable apps team who has spearheaded the effort, but the pattern itself comes from a joint effort between Google and Deque (an accessibility auditing firm) that was built into the Google Maps UI.
- I’ll be demoing the feature using VoiceOver, which is the built-in screenreader on my Mac. I’ve slowed VoiceOver down a bit, but for reference, anyone who wants to try VoiceOver at home, CMD+F5 is a keyboard shortcut to turn it on and off, unless you have a touch toolbar like I do, in which case you’ll have to do it through the accessibility utility settings. If you have a Windows machine and are using Edge for you primary web browser, Narrator is the built-in screen-reader for Windows. Or you can install NVDA for free. NVDA works best with Windows and Firefox. Back to our demo. I’m going to load up this map in Safari since Safari and VoiceOver work best together, but since it’s hard to talk over VoiceOver, I’m going to explain what I’ll be doing ahead of time. This map is an application. Therefore, I will need to hold down Shift + the VO Keys (Option + Ctrl) + Down Arrow to enter into the application. Applications are allowed to change how screen-readers interact with a page by using different keyboard commands. Both NVDA & VoiceOver support tabbing to links and buttons, which is how you activate the hidden toggle that contains the accessibility mode; however, tabbing is not VoiceOver’s normal method of accessing links and form elements, so be forewarned, you will have to tab to be able to see it. Once the accessibility mode button has focus, I will hit enter, I will be provided with an extent tile that overlays a portion of the map. When the extent overlays data points, VoiceOver will associate numbers 1-9 with any overlaid markers and their associated labels. This will allow me to directly select a number from my keyboard to find out more information about the point. I will also be using plus and minus to zoom in and out of the map, and I can use the i key to find out more location information about what region is currently located under my extent.
- https://github.com/Esri/a11y-map https://esri.github.io/a11y-map/ That concludes the demo. There is a Github page for this project, so if you have ideas for improvement, we’re open to feedback. Now for when this functionality will be released…we’re hoping to get it into the JSAPI4 by Q2-Q3 this year, but ahead of that we will be releasing a configurable app template by Q2 that will contain the same functionality. If either of these features are something you need, please reach out to us on the Section508 alias, which I’ll include on the last slide. Your voice is what drives product decisions.
- On the charts side of the house, there is nothing wrong with including a table. In fact, I was told last year that from the assistive technology perspective, charts that correspond with tables are still preferable. But I do like the way that some charting technologies are doing a better job to describe axis and the information usually found in tooltips via way of aria roles. ArcGIS Hub sites use amCharts, which utilizes this technology and allows you to tab into the chart and hear tooltip information. Unfortunately, there are still a few kinks, for instance from the design perspective, I would expect that a sighted keyboard user be able to see the tooltip on keyboard focus, and right now only non-sighted users hear the information. Grommet, which is a design style guide made for React.js, produced another type of accessible chart, wherein you can tab to the chart in order for the container to receive focus and then you use the arrow keys to move through the data points within the chart. Highcharts is another company that is also focused on improving accessibility in charts and like amCharts they are doing most of it through keyboard focus of chart sections and aria-roles. And like static maps, if you have a static chart, it is recommended you include a summary or caption with your chart that explains on a high level what is occurring visually.
- That is all I have. I know I covered quite a lot, but hopefully I have given you a few ideas on how to improve your visualizations. If you have any other questions, or want to pick my brain about resources, just reach out. Slides are available at
- Relevant Guidelines