FedGIS 2017 Building Accessible Apps
•Download as PPTX, PDF•
2 likes•342 views
Maps, charts, visualizations…Learn what Web Content Accessibility Guidelines (WCAG 2.0) can help you make these often dynamic and very visual apps more accessible to those with disabilities. Have you ever navigated a map by keyboard or had a chart read by a screen reader? We will be looking at best practices for keyboard navigation, keyboard focus management, color contrast, and sensory characteristics within apps.
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
FedGIS 2017 Building Accessible Apps
- 1. Accessibility Building Accessible Apps Klara Schmitt
- 2. • WCAG = Web Content Accessibility Guidelines - 2008: W3C publishes WCAG 2.0 - 2010: Adopted by ISO • Section 508 = Federal Government Standard - 1998: Established - 2008: Proposed revisions - 2010/11: Open for public comments - 2015: Comments close - 2017: Final rule published WCAG 2.0 vs. Section 508
- 3. • Web Software + Mobile - Native apps, applications, learning & project management software - Websites, web apps, web pages • Digital Content - Electronic documents - .doc, .pdf, .xls, etc - Agency communications - Social media New Section 508 includes: Top to Bottom: Asana, Issuu, Twiter
- 4. • Published: Jan. 18, 2017 • Enforcement Date: Jan. 18, 2018 New Section 508 Dates
- 5. Those with… - Vision Issues - Hearing Issues - Cognitive Issues - Motor Impairments Who does it help?
- 7. • 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
- 9. 2.4.7 Focus Visible Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
- 10. How do I fix it? 2.4.7 Focus Visible • Don’t set outline: 0px for :focus • Watch out for reset.css files that set everything to 0 • Avoid a strictly color solution • For links add text-decoration: underline for :hover & :focus or make it decorative
- 11. 2.1.1 Keyboard All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.
- 12. How do I fix it? 2.1.1 Keyboard <div class="fake-btn more-work" role="button" tabindex="0" data-href=”http://"> Button Text </div> $(".fake-btn").click( function() { window.location = $(this).attr("data-href"); return false; }); $(".more-work").on('keydown', function(e) { var code = e.which; if ((code === 13) || (code === 32)) { window.location = $(this).attr("data-href"); }; }); Fake Button HTML Fake Button Javascript • Set tabindex=“0” on DOM to make focusable • Support appropriate keystrokes as if it were a native element (eg. space & enter on buttons)
- 13. Demo
- 14. How do I fix it? 1.1 Text Alternatives 2.4.1 Bypass Blocks • Add aria landmarks to key UI elements - <nav role=“navigation”>Links</nav> - <div role=“main”>Body Content</div> • Voice Over shortcut to menu Crtl+Opt+U• For base map tiles set alt=“” on <img> Web Spots
- 16. 1.3.3 Sensory Characteristics Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.
- 17. How do I fix it? 1.3.3 Sensory Characteristics • tab • tablist • tabpanel • aria-expanded • aria-selected • aria-hidden* • aria-controls WAI ARIA Accordion RolesWAI ARIA Tab Roles • tab • tablist • tabpanel • aria-expanded • aria-selected • aria-hidden* • aria-controls • aria-multiselectable • aria-labelledby *Pro-Tip: Always use aria-hidden and it’s true/false values rather than aria-visible, which has known bugs with screen readers.
- 18. 1.1 Text Alternatives Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech or simpler language.
- 19. How do I fix it? 1.1 Text Alternatives (Charts) • Use a hidden table for screen readers • Use aria-labels or aria-labelledby to support SVG graphics • Use <summary> if possible (easier for static charts) • Support keyboard navigation
- 20. 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 for large text (ratio of at least 3:1), incidental text, or logotypes.
- 21. 1.4.4 Resize Text Except for captions and images of text, text can be resized without assistive technologies up to 200 percent without loss of content or functionality.
Editor's Notes
- If you’re not familiar with accessibility, I will be using it as an umbrella term to cover WCAG 2.0, which is the international web accessibility standard produced by the W3C and to cover Section 508, which is a US Federal Government standard. Both aim to keep web technologies available to the those with disabilities. ### So a little bit of History Section 508 is generally required by Federal agencies developing, procuring, or using electronic information technology. It has also recently undergone a refresh to match it up more closely with the WCAG 2.0 AA guidelines. Section 508, as it existed for the last ten or so years has been severely out-dated.
- The new 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 such things as web sites, intranet, word docs, PDFs, 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 single A. But by making these changes towards WCAG 2.0 AA, the revised requirements adapt the existing 508 standards to reflect newer technologies (like smartphones with telecommunication functions) and address accessibility challenges that these technologies pose to individuals with disabilities.
- Comments for the revised Section 508 closed May 2015, with final revisions being made through 2016. The final rule was published by the Federal Register Jan. 18, 2017. However, there is a 12 month grace period before compliance and enforcement begin on Jan. 18, 2018. I’m giving you these dates, because even though I am a firm believer that accessibility is important rules or no rules, I am fully aware that it takes time to get forward movement in the software release cycle. Retrofitting an application for accessibility frequently takes a lower precedent than new software features, which is why we should all be building it in as we move forward. Today I hope to cover some of the core principles of WCAG that you can include as you build apps.
- ### But first things, first. Why are we doing this and who does it help? When building accessible apps, you’ll 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, colorblind, or an older adult who might be loosing their sight. For me personally, I believe in making the web a better experience for those with disabilities. Section 508 was 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’m going to be analyzing an Esri app called Tapestry. While Esri has been putting increased focus towards supporting accessibility within our software, this is an older version of the app. I’m using it because it is the perfect myriad of maps, charts, and visualizations and it shows the pitfalls you can run into from an accessibility perspective.
- The core WCAG 2.0 guidelines that I’d check in this app are going to be predominantly around keyboard navigation for sighted users and assistive technologies such as screen readers, color, and text. While tab and shift tab are means to navigate forward and backward through links and form elements, these keyboard commands are actually generally used by sighted users with motor control issues. Assistive technologies (ATs) - like screenreaders - have entirely different sets of keyboard commands. The good news is that if your app is coded semantically, the ATs will handle the keyboard interactions for you. But it’s still worth testing with one of them. I’ll demo VoiceOver in a bit.
- Okay, let me get Tapestry fired up for some keyboard testing. I’m going to start by tabbing through the interface. Source: http://www.esri.com/data/esri_data/ziptapestry
- Right away, I get keyboard focus on my form input. This is good. What is bad is that it’s probably really hard for you to see that my cursor is there and there’s a WCAG guideline called ‘Focus Visible’ specifically about me being able to see the focus.
- ###How could I improve focus? As a designer, it is my responsibility to make sure I don’t accidentally or intentionally set CSS outlines to 0px. If I do nothing, most browsers are equipped to give me a focus state by default. You need a focus state on all link or form elements as part of the ‘Focus Visible’ guideline. You can keep it simple with a text-decoration:underline on links and the native outline on form elements or make it more decorative. At the top, you can see we denote focus state on links by having the bar across the top. Either of these methods are fine, but you’ll want to avoid using strictly color to denote focus as there is another WCAG guideline called ‘Use of Color,’ which prohibits conveying information by color alone. So if I were to go back to Tapestry and change the border stroke of the form input to a 1px solid yellow border, that wouldn’t be good enough to pass muster.
- So continuing with keyboard navigation, I type in my zip code and press enter. The app loads my demographic information and I keep tabbing. Right away, I have some issues. Each of those three percent sections is a collapsed accordion, which in this case, should have the same focus as a button. Unfortunately, I can’t tab to any of them.
- If I right click, inspect element, we can see that this accordion is all divs so none of those native actions are going to occur naturally. In this case, we’d want to add some extra code to fake the ability to select these. By adding tabindex=“0” to the <div> along with role=“button”, we can surface these elements in the DOM as being keyboard focusable as well as telling the screen reader there is an action associated, but we still have to use Javascript for force the <div> to accept the enter and space keystrokes.
- Now I’m going to turn on VoiceOver. VoiceOver is the native screenreader for iOS and OSX, and I’m going to attempt to navigate this page using the VO keyboard commands, which are Shift+Ctrl+Option+arrow keys. VoiceOver also has a dialog so that you’re not sure what you’re hearing, you can follow along on screen.
- Unfortunately, this particular basemap does not have alt attributes on the image tiles, so in the absence of an alt tag, the screen reader will read the image filename. This is clearly a terrible user experience between maps and screen readers. Open Data uses the gray basemap, which we made accessible to screenreaders. In our case, since the map tile information cannot be accurately described in an alt attribute, the best scenario was to hide all map tiles from the screen reader. Using alt=“” on the <img> tag does that and having some kind of alt on an image is required in the ‘Alternative Text’ guideline. Had the map tiles been hidden on Tapestry, I could have easily still gleaned information about my zip code even if I was non-sighted as I was able to jump to the form input and then even navigate the tabs. But I sort of cheated. I hit Ctrl+Option+U, which brought me to a global menu in VoiceOver that let me navigate by form elements. In a perfect world, this app would also use ARIA landmarks (such as role=“navigation” and role=“main”). These would let me jump around by web spots via that menu. Using ARIA landmarks also helps you pass the WCAG 'Bypass Blocks’ guideline.
- ### Keyboard Navigation in Maps I’m going to briefly take a detour out of this app on the topic of maps. In the case of Tapestry, I would say hiding the map from a non-sighted user would be the best available experience. However, I have a colleague (Patrick Arlt) who has taken a stab at making the data points on a map accessible and I wanted to bring up his work as a possible alternative to simply hiding the map. http://patrickarlt.com/accessible-js-api-app/ The reason this map is accessible is that all the data points on the map show up this dynamic list in the sidebar and the auto-suggested search and the zoom to actions allow the user to refine the map to an address without panning around. By having this sidebar, all the content on the map that would be available to sighted users is now available to non-sighted users.
- ### ARIA Roles But back Tapestry, on the upside, had I continued with VoiceOver I would have been able to navigate those tabs across the top. In this case, the screenreader got me there. This was not something I was able to do with tabbing. That is another place to add the tabindex=“0” fix. However, there is another guideline to consider. To adhere to the ‘Sensory Characteristics’ guideline, you want non-sighted users to infer the same information as sighted users about whether an element is clickable, collapsed, or expanded. Tabindex won’t announce that to a screen reader.
- To assist screenreaders, you’ll want to use another set of ARIA tags called roles. For the tabs, there’s a whole set of roles including, tablist, tab, tab panel, and for the accordion, you want to indicate verbally that it’s selectable, and use aria-collapsed or aria-expanded to indicate whether it’s open or closed.
- ### Charts I’m not going to turn VoiceOver back on, but I do want to show one of Tapestry’s charts. Unfortunately, chart information can be pretty difficult to properly convey to screenreaders, especially it’s dynamic.
- To date, the easiest method to convey chart information to non-sighted users is to hide the chart components with an aria-hidden tag, and have a hidden table that provides the same information. It’s not the greatest UX, but it’s an established pattern. That being said, I want to show you a chart that IS keyboard navigable. This chart from Grommet, a design style guide made for React.js, allows you to navigate into the chart and then use arrow keys to move around. It’s really quite amazing.
- ### Color & Text Finally, I am going to wrap up by considering two final guidelines ‘Color Contrast’ and ‘Resizing Text.’ Both of which, this app does correctly. For color contrast, I’ve been at this long enough to know what color combos usually pass and Tapestry is in pretty good shape, but if I wanted to double check, I could use this Chrome Extension called WCAG Luminosity Contrast Ratio Analyzer that a colleague in Canada developed, that lets me compare foreground and background colors for passing contrast ratios.
- ### Color & Text To verify text resizing, you’ll just want to zoom your browser screen to 200% and make sure your app is still fully functional. As long as it works, then you’re good.
- So that’s all I have. I know I covered quite a lot, but hopefully I gave you a sense of which guidelines come into play and what you can do to make your app accessible. If you have any other questions, or want to pick my brain about resources, just let me know.