Accessibility: Navigation, Forms, & Multimedia

Editor's Notes

• #2: ### What Is It? 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, which aims to keep web technologies available to the those with disabilities, and to cover Section 508, which is a checklist of similar rules that the US Federal Government uses as a standard.
• #3: ### So a little bit of History  Section 508, with which you may be familiar is generally required by Federal agencies developing, procuring, or using electronic information technology. It’s also undergoing a refresh. Section 508 as it existed for the last ten or so years is out-dated given the new trends of the web. Therefore, it is moving away from being a technical checklist and moving towards the general guidelines as outline in WCAG 2.0 AA. Comments for the revised Section 508 closed May 2015, but we’re still in the about year-long window of it getting finalized.
• #4: ### Who does it help?  General audiences to consider are 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 might just have very low vision. For me personally, I believe in making the web a better experience for those with disabilities. It is true that this may be a smaller audience segment for your organization, but unlike folks on older browsers, we can’t just say “please upgrade” and forget about support since this is their life. So as able-bodied web designers, developers, content editors, and managers we should try to make the web more inclusive. 
• #5: We, at Esri, are trying to make our products more inclusive as well. Across the board, we’re trying to disseminate more information about the guidelines to our designs and developers working on the various platform applications. We have point-of-contact folks, who are act as references for the company in specific areas of accessibility. My niche is web, but we have desktop folks too and more people are getting involved. I’ve talked with folks in Storymaps, ArcGIS Pro, ArcGIS Online, GeoEvent Manager, Open Data, and several others who are all involved in accessibility initiatives. Now I’m going to start getting into the nitty-gritty of some of the guidelines. I’m not covering them all. That would take more time than I’ve got, but I’m going to speak about some of the usual trouble spots I encounter when I evaluate apps.
• #6: I would say that the most challenging aspect of meeting the WCAG guidelines are those related to keyboard navigation.
• #7: If you are retrofitting an application, this will by far take the most work because not only do you have to make sure components are navigable by the sighted keyboard user who will probably be using tab and shift tab to navigate links and form elements, you also have to account for assistive technologies (such as screenreaders like VoiceOver & NVDA) that may actually use an entirely different set of keys. NVDA overlaps a little bit with the keys of a sighted user, but VoiceOver uses different keys to navigate and JAWS as I recall, also uses a unique set.
• #8: In Open Data, including keyboard navigation has become a requirement in building new features. We’ve been diligently working towards meeting WCAG 2.0 AA in http://opendata.arcgis.com and making sure everything works.
• #9: These same accessibility features will be rolled out to customer sites around April. Included will be a new table with pagination and properly labeled filters; both which now support keyboard navigation. [Demo sighted user keyboard navigation of table pagination & skip nav.] http://opendata.arcgis.com/datasets/3c7b25e759a643cb9ef7d8caf6f5db21_0/data?geometry=-79.367%2C37.352%2C-78.824%2C37.447
• #10: For the guideline Bypass Blocks, which allows assistive technologies to more easily jump around a webpage, we've included a skip-navigation link, which is only available by keyboard focus, and ARIA landmark roles, which act as quick menu access for screen readers. VoiceOver is pictured here. To open the landmarks menu in VoiceOver, you’d user Ctrl + Option + U and escape to close. This menu lets a user jump quickly to sections of the page, whether the header for navigation, the main, which is the core content, our search bar, or contentinfo, which usually refers to the footer. Demo VoiceOver
• #11: As it’s important for sighted keyboard users to be able to see where they are at on a page, all links, form elements, and buttons should have a definitive focus state or outline.
• #12: Related to navigation, but more part to color requirements, links cannot be designated with color alone. So you will see in our header that the hover-state of navigation items now includes a visual indicator of the bar at the top or and inline text links use an underline on hover. This helps us pass Use of Color 1.4.1.
• #13: Color contrast requirements are probably the bane of most designers, especially if your employer’s brand colors were not considered with accessibility in mind. While we, in Open Data, scraped by with relatively few major color adjustments, we did have to adjust our link/button blues and I used a gray that would work on a white background for our search placeholder text.
• #14: You’d be surprised, but this is one of the sore spots I see when I analyze apps for compliance, because generally the light gray text - like you see in search fields - is supposed to indicate form text that a user shoulder consider secondary. However, due to luminance contrast ratios, this might be too light for those with low vision. Even if you set the color via CSS, browsers can affect the color. Firefox reduces the opacity and makes it even lighter! So you have to set opacity to 1 for Firefox.
• #15: The good news is that there are some very good automated tools that help you check color contrast ratio requirements. I’m going to demo Chrome’s Tota11y Extension on our Open Data marketing page: http://www.esri.com/software/arcgis/arcgisonline/arcgis-open-data Having worked to meet contrast requirements in the past, I know using orange is notoriously difficult, especially with white, and I want to trigger an error.
• #17: Let’s start with how you get a form error. Generally, you get an error by not filling out the form correctly, right? So looking at this form, how do we know what fields are required? I’m sure your thinking, “This is a bad form because there are no indicators."
• #18: So I’ve added asterisks to indicate required fields. This is much better, right?
• #19: Sorta. I've helped sighted users, but considering NVDA (one of the screenreaders I mentioned before) does not read single asterisks, a non-sighted user is going to hear this form…
• #20: …just as we saw the previous form and they are going to think it’s a bad form.
• #21: That’s why it’s important to add both aria-required=“true” and required into your input tag. This will prompt the screen reader to read “required edit text” for each required field.
• #22:  But let’s say for the sake of the argument, I haven’t added any of these code indicators and as a non-sighted user using NVDA, I fill in the first field because clearly I don’t hear the asterisks and all the fields are optional, navigate down to the submit button (you can see it has keyboard focus), and then I submit it.
• #23: What does this look like to you? Nothing? A black screen? Well that’s exactly what a non-sighted user hears if you don’t include an error summary.
• #24: The simplest way to do this is to add a message at the top of the form “You have form errors” and transfer keyboard focus to that message programmatically. If you don’t transfer keyboard focusthe non-sighted user is just sitting on that submit button thinking you have a shoddy form that’s broken.
• #25: Now onto the actual inline errors themselves...The WCAG guidelines for error identification and error suggestion also indicate that errors should be described to the user in text and if we come back to use of color, information cannot be conveyed solely through color.
• #26: In this example, this guarantees that if the label has been associated with its proper form field, you will hear the label say “Phone Number", then the error “Invalid format", then the input field, which will say “phone number required edit text.” It leaves less room for confusion. If you look at the second graphic, it would sound like “phone number required edit text, invalid format, state.” We can see which field is affected by proximity. Non-sighted users don’t hear that extra bit of white space.
• #27: In this example, this guarantees that if the label has been associated with its proper form field, you will hear the label say “Phone Number", then the error “Invalid format", then the input field, which will say “phone number required edit text.” It leaves less room for confusion. If you look at the second graphic, it would sound like “phone number required edit text, invalid format, state.” We can see which field is affected by proximity. Non-sighted users don’t hear that extra bit of white space.
• #28: Which brings us to associated labels….
• #29: One of the ways to convey information on form inputs is to make sure that there is a label associated with each form field. This isn’t just your placeholder text. Generally, the best system is to use the “for” attribute on the <label> tag with a matching “ID” attribute on the input tag. What this does is make sure that assistive technologies read out the label in conjunction with the input, so instead of hearing “required edit text” on an input with no associated label, you might hear “first name required edit text.” There is another method, which you might see that wraps the <label> around the input. This actually recently caused us a headache, because we did this with a bunch of dynamically generated checkboxes. Unfortunately, while this method is a totally viable solution for assistive technologies, for the sighted keyboard user, they can’t tab to the label. We actually had use tabindex=“0” to get focus onto spans around the label and then javascript to make both enter and space keys select them.
• #31: I am to going switch into multimedia and non-text equivalents now, but conclude the section on forms by touching briefly on CAPTCHAS because they are also included in this guideline.
• #32: While generally everything I’ve ever read says CAPTCHAs are a terrible user-experience, I still use them on my contact form, because otherwise I’d get an insane amount of spam. I also think there are decent CAPTCHAs and bad CAPTCHAs. Because most CAPTCHAs are innately visual, they are generally not very accessible. The only one that I’ve really ever liked over the years is Google’s ReCAPTCHA. You’ve probably seen it. It’s the red one. They actually released a new version (on the bottom), which is even more awesome, in my opinion. You merely check a box. If the interface isn’t sure about you, you have to chose from a selection of pictures, or enter a serious of numbers read via audio if you can’t see the pictures. ReCAPTCHA is the only intelligible audio CAPTCHA I have ever heard.
• #33: The other big piece of non-text equivalents is, of course, regular images. If you aren’t using a background image and don’t include an alt attribute or a empty alt attribute, assistive technologies will read the entire file-name. Looking at the image on the screen, if I were going to describe the screenshot I might use alt=“map showing oyster habitat in the Chesapeake Bay.” But the problem that we had with the live site was that we had 16 basemap tiles with no alt set and the generic file name being read image_8.png, image_9.png.We resolved this by adding an alt=“”. This tells assistive technologies (like screen readers) that this image is decorative or irrelevant and they should skip it. While the basemap tiles are not irrelevant, there is no good way at this time to communicate the visual information of a basemap tile to a non-sighted user. In Open Data, our table conveys the same information as the visual map data, so that’s our text equivalent. 
• #34: If you do use background images or the rather popular image sprite method, you’ll run into a different issue. Background images don’t allow alt attributes. So how do you describe a background image? I’d recommend adding an aria-label to it. This’ll describe it to assistive technologies. However, there is one caveat. This helps non-sighted users, but if someone is using a high contrast skin on Windows Vista or XP, background images don’t show up at all.
• #35: Another popular method at the moment might be an icon-font. The benefit to using an icon-font is that the icons are easily resizable and colors can be changed all through the magic of CSS. The downside is that assistive technologies don’t necessarily read the icon - they will sometimes read the character underneath. However, this may depend on version, because when I tested this recently in both VoiceOver and NVDA, they completely ignored the icon/character, and by adding an aria-label to the font icon, I am able to describe what the icon represents. Using SVGs is another alternative - SVG allows all the same benefits of an iconfont without the worry of inheriting other font styles. It is only backwards compatible to IE9, but offers more flexibility, in some ways, than an iconfont. To make an SVG accessible, I recommend using inline code, placing <title> tags inside, and if you want to be extra safe, using an aria-label. The other benefit of SVGs is that if someone needs to replace the font (say someone who is Dyslectic and would prefer to use a more readable font) SVGs will remain present; iconfonts may render as an empty box.