Why the Bad Rap? Accessibility doesn’t have to be a dirty word (3/15/17)
•Télécharger en tant que PPTX, PDF•
1 j'aime•1,584 vues
Dana Douglas, Tristan Wilson UserWorks, Inc. www.userworks.com Prepared for the NoVA UX meet-up on March 15, 2017. https://www.meetup.com/nova-ux/events/237735584/
Recommandé
Recommandé
Contenu connexe
En vedette
Plus de UserWorks
Plus de UserWorks (6)
Dernier
Dernier (20)
Why the Bad Rap? Accessibility doesn’t have to be a dirty word (3/15/17)
- 1. Why the Bad Rap? Accessibility doesn’t have to be a dirty word Dana Douglas Tristan Wilson ddouglas@userworks.com twilson@userworks.com @UserWorks @NoVAUXMeetup NoVA UX Meetup March 15, 2017
- 2. Introduction Who we are and why we're here
- 3. Who We Are Dana Douglas User Experience Specialist Silver Spring, MD www.userworks.com (301) 431 - 0500 Tristan Wilson User Experience Specialist
- 4. Why We're Here 4 We aren't developers - we just work with them to make websites accessible We hope to convince you that accessibility doesn't have to be such a dirty word This makes us sad We believe in accessibility, but often it gets a bad rap We love developers ... but sometimes it seems like they don't love us Feels like some people think our average day goes like this: 1. Wake up 2. Ruin everyone's fun 3. Give developers more work to do
- 5. The Basics Web accessibility fundamentals
- 6. Disabilities related to web accessibility Impairment Categories 6 Vision Impairments Auditory Impairments Mobility Impairments Cognitive Impairments
- 7. Disabilities related to web accessibility Impairment Categories 7 Vision Impairments Common Assistive Technologies (AT) ▪ Screen readers ▪ Magnification tools ▪ Braille displays ▪ High contrast tools ▪ Large-print / tactile keyboards
- 8. Disabilities related to web accessibility Impairment Categories 8 Auditory Impairments Common Assistive Technologies ▪ Captions & subtitles ▪ Sign language accompaniments ▪ Audio/video transcriptions
- 9. Disabilities related to web accessibility Impairment Categories 9 Motor Impairments Common Assistive Technologies ▪ Keyboards ▪ Speech recognition tools ▪ Head / Eye trackers ▪ Mouth sticks / Head wands
- 10. Disabilities related to web accessibility Impairment Categories 10 Cognitive Impairments Common Assistive Technologies ▪ Memory Aids ▪ Accommodation Software ▪ Organizational Tools
- 11. Disabilities related to web accessibility Impairment Categories 11 Temporary ImpairmentsPermanent Impairments Long-term; expected to last for the majority, or entirety of a person's life. Short-term; expected to last for a limited period of time
- 12. Do I really have to? Arguments against accessibility
- 13. “It isn’t worth the trouble for just a few users.” Anti-Accessibility Argument #1
- 14. People with permanent disabilities, of course Who Benefits From Accessibility? 14 ~ 19% of the U.S. population (56.7 mil) have some type of disability 1 > 50% of U.S. adults 65 and older have a disability 1 1. US Census Bureau (2012) Profile of America; Facts for Features [Link] 19% 50%
- 15. Who Benefits From Accessibility? People with temporary impairments, too 15 Helps users with permanent vision impairments read text on the screen Also helps users outside on a sunny day read text on the screen Examples of low contrast and high contrast text
- 16. Who Benefits From Accessibility? People with temporary impairments, too 16 Allows users with permanent hearing impairments to access audio information Also allows users in a loud (or quiet) environment view videos without sound Example captions displayed on a video player
- 17. Who Benefits From Accessibility? Everyone else, too 17 Easier for screen reader users to navigate and understand Easier for users with cognitive impairments to decipher Easier and faster for everyone to comprehend Simple tables with clear structures
- 18. Who Benefits From Accessibility? Everyone else, too 18 Essential for keyboard users to be able to access interactive elements on the page Essential for keyboard-driven assistive technology (screen readers, speech recognition, etc.) users to access elements on the page Super helpful for people who hate to use the mouse or trackpad and prefer tabbing through a formKeyboard accessible elements
- 19. Who Benefits From Accessibility? Everyone else, too 19 Essential for screen reader users to know what information to enter in a form field Increases the target area for people with mobility impairments who struggle to use a mouse or trackpad Increases the target area for everyone using a touch screen Input fields with associated labels
- 20. “It isn’t worth the trouble for just a few users.” Anti-Accessibility Argument #1
- 21. “It’s too expensive and too much work.” Anti-Accessibility Argument #2
- 22. “It will ruin the design. ...I can’t do anything cool.” Anti-Accessibility Argument #3
- 23. A Few Solutions Accessibility can be easy and cool
- 24. WAI-ARIA The accessibility band-aid 24 WAI-ARIA = Web Accessibility Initiative; Accessible Rich Internet Applications ARIA is a technical specification published by the World Wide Web Consortium (W3C) ▪ Guidelines on how to increase the accessibility of web pages ▪ Allows role, property, and state information to be added dynamic web applications ▪ Helps assistive technologies to parse non-standard markup ARIA provides accessibility features that aren't (yet) possible with HTML alone ▪ ARIA has been around longer than HTML5, so support from assistive tech is more complete We sometimes think of ARIA as an "accessibility band-aid" ▪ This is an oversimplification, but the analogy has some truth to it ▪ ARIA is often used as a way of making existing websites accessible after the fact ▪ However, it is often successfully included as part of initial development 1. W3C (2014) Accessible Rich Internet Applications 1.0 [Link] 2. Featherstone, D. (2011) Real World Accessibility: HTML5, ARIA and the Modern Web [Link]
- 25. WAI-ARIA The accessibility band-aid 25 Landmark Roles ▪ Method for describing the structure/function of major "landmark" elements ▫ Ex. role="navigation", role="main", role="banner", etc. ▪ Landmark roles are the older brother to HTML5's semantic elements ▪ Helpful to ensure accessibility even in older browsers that may not be compatible with HTML5 <body> <div> ... </div> <div> ... </div> <div> ... </div> </body> With ARIA: <body> <div role="banner"> ... </div> <div role="navigation"> ... </div> <div role="man"> ... </div> </body> Without ARIA:
- 26. WAI-ARIA The accessibility band-aid 26 Expand/Collapse State ▪ Indicates expandable regions of content and their present state ▫ Ex. aria-expanded="false", aria-expanded="true" Expandable Panel with ARIA: <h3 class="panel-title"> <a data-toggle="collapse" href="#panel1" aria-expanded="false">Example Title</a> </h3> <div id="panel1" class="panel-collapse collapse in" aria-expanded="true"> <div class="panel-body"></div> </div>
- 27. ARIA Example: aria-expanded - JAWS 17 - Chrome 27
- 28. WAI-ARIA The accessibility band-aid 28 ARIA Labels ▪ Provide AT-only descriptions of various elements ▫ Ex. aria-label="External Link" Alert Role ▪ Prioritizes and communicates important messages to AT's ▫ Ex. role="alert"
- 29. ARIA Example: role="alert" - JAWS 17 - Internet Explorer 29
- 30. Now with more accessibility! HTML5 30 HTML5 isn't perfect, but it's the most accessible markup language ever 1 ▪ W3C actually created an Accessibility Task Force specifically for HTML 5 2 Built-in accessibility features make authoring accessible content easier than ever ▪ Improved semantics and sectioning ▪ More granular form construction ▪ Native validation / error handling ▪ Better support for media & media alternatives 1. Mark Sadecki (2014) Accessibility Features of HTML5 [Link] 2. W3C WAI (2010) HTML Accessibility Task Force Work Statement [Link]
- 31. HTML5 Now with more accessibility! 31 Sectioning Elements ▪ HTML5 includes additional descriptive replacements for generic <div>'s and <span>'s Ex. <header>, <footer>, <nav>, <aside>, <main>, <section> ▪ Used to label the major sections of a typical webpage ▪ Essentially forces specific aria landmark roles to be added to each element ▪ Makes it more convenient for authors to communicate page structure to AT's 1. W3schools. HTML5 Semantic Elements [Link] 2. WebAIM (2010) Future Web Accessibility [Link] 3. Peterson, C. (2012) Accessibility in HTML5 [Link]
- 32. Sectioning Elements Example - JAWS 17 - Internet Explorer 32
- 33. HTML5 Now with more accessibility! 33 Input Restrictions ▪ Native control over common input constraints with a few new attributes ▫ required = field must be completed prior to form submission ▫ pattern = field will only accept a certain pattern of input (checked against regular expression) ▫ max = sets a maximum value that the field will accept ▫ min = sets a minimum value that the field will accept ▪ These attributes can be parsed by assistive technologies, helping the disabled user to understand what is required of them before they attempt to submit the form ▪ Allows for simple control over user input that everyone can understand
- 34. Input Restrictions Example: Required - JAWS 17 - Chrome 34
- 35. Input Types ▪ Simple, granular definition of input purpose ▫ Ex. type="tel", type="email", type="date", type="URL", etc. Now with more accessibility! HTML5 35 <label for="field-a"> Date </label> <input id="field-a" type="text"> ... </input> Without HTML5: With HTML5: <label for="field-a"> Date </label> <input id="field-a" type="date"> ... </input> Native Error Handling
- 36. HTML5 Now with more accessibility! 36 Programmatic Captions ▪ HTML5 allows captions to be programmatically associated with corresponding figures ▫ Ex. <figure>, <figcaption> 1. Sadecki, M. (2014) Accessibility Features of HTML5 [Link] 2. W3C WAI (2010) HTML Accessibility Task Force Work Statement [Link]
- 37. Figure & Figcaption Example - JAWS 17 - Chrome 37
- 38. HTML5 Now with more accessibility! 38 New Global Attributes ▪ In HTML5, the tabindex and hidden attributes can be applied to any element ▫ In HTML 4.01, these were limited to: <a>, <area>, <button>, <input>, <object>, <select>, and <textarea>. ▪ Helpful in various ways, such as forcing focus to shift to a non-link element Native Media Handling ▪ Browser-only media without plugins (e.g. Flash, Java) ▫ <audio>, <video>, <source> <p tabindex="1"> Lorem ipsum dolor </p> <video> <source src="mov.mp4" type="video/mp4"> <track src="subtitles.vtt" kind="subtitles" srclang="en"> </video>
- 39. ARIA and HTML5 39 In general, using HTML5 alone (according to standards) is a great start ▪ However there are still some compatibility problems, both for browser and assistive technologies ARIA goes above and beyond what HTML is currently capable of If you want to be sure you're doing the most you can, use ARIA in conjunction with HTML5
- 40. Frameworks & Libraries Let other people do the work for you! 40 Many modern web development libraries and frameworks now include accessibility features These resources can help make web accessibility less of a chore None of them are perfect, and they won't magically make your site accessible, but they can help
- 41. Frameworks & Libraries Let other people do the work for you! 41 Bootstrap [Website] [GitHub] Free | Open-Source | MIT License ▪ Popular front-end web framework; initial release 2011 ▪ HTML & CSS templates, optional JavaScript extensions ▪ Includes various HTML & CSS snippets/templates that are accessible out of the box Foundation [Website] [GitHub] Free | Open-Source | MIT License ▪ Front-end framework emphasizing responsive design; initial release 2011 ▪ All components & examples are screen reader and keyboard accessible ▪ Optional JavaScript extensions add accessible attributes and improve keyboard navigation
- 42. Frameworks & Libraries Let other people do the work for you! 42 U.S. Web Design Standards [Website] [GitHub] Free | Open-Source | MIT License ▪ Library of UI components & styles developed by 18F for government websites ▪ Every asset offered is designed to meet Section 508 standards Turret [Website] [GitHub] Free | Open-Source | MIT License ▪ Self described as "styles and browser behavior normalization framework" ▪ HTML templates are largely written accessibly ▪ Includes some CSS tailored specifically toward screen readers [GitHub]
- 43. Frameworks & Libraries Let other people do the work for you! 43 Assorted Libraries/Plugins for Accessibility ally.js [Website] [GitHub] ▪ JavaScript library intending to make implementation of various accessibility features easier Bootstrap Accessibility Plugin [Website] [GitHub] ▪ JavaScript library designed by the PayPal team that adds accessibility markup to Bootstrap v3 accessifyhtml5.js [GitHub] ▪ JavaScript plugin that mitigates browser incompatibility with HTML5 by inserting aria 'role' attributes automatically
- 44. Accessibility Tools Free utilities to aid in accessible web development 44 Color Safe [Website] ▪ Simple, customizable tool for generating color palettes that meet WCAG contrast guidelines tota11y [Website] ▪ JavaScript plugin that highlights accessibility related elements on your site Accessify [GitHub] ▪ Assorted tools for generating accessible markup including tables, skip navs, popups/modals, forms, etc. W3C's Accessibility Tool List [Website] ▪ A list of hundreds of tools for developing accessible content and checking it for accessibility
- 45. Make accessibility affordable, easy, and fun Strategies 45 Implement accessibility early ▪ Avoid post-hoc remediation costs Simplify and standardize page elements ▪ Use standard elements, existing frameworks, and simple layouts; and use them consistently Be creative and open-minded when coming up with accessible solutions ▪ Start with the goal (“The user needs to know this information at this time”) and then determine various possible solutions; often the simplest solution is the best
- 46. In Conclusion…
- 47. Accessibility can be a good word 47 Worth the investment Easy to implement Can work seamlessly with design Can actually be kind of cool
- 48. Thank you! Dana Douglas ddouglas@userworks.com Silver Spring, MD www.userworks.com (301) 431 - 0500 Tristan Wilson twilson@userworks.com
Notes de l'éditeur
- D
- D We are User Experience Specialists at UserWorks in Silver Spring, and as part of our job designing and evaluating user experiences, we consider whether the experiences are accessible to people of all abilities. So “accessibility” to us means that all users, regardless of their abilities, are able to access the information and complete the tasks that are intended to be completed on a website.
- (TW) We wanted to start off by giving a little bit of context on how this presentation came to be. First off - We want to emphasize the fact that we aren't developers. We just work with developers to help make their websites accessible. Second - We love developers, but sometimes it seems like they don't feel the same way. It's a pretty one sided relationship. It feels like some people think our average day goes like this: 1. Wake up, bright and early 2. Ruin everyone's fun 3. Give developers a whole lot of work to do ...and that makes us kind of sad. We really believe in accessibility, and it bums us out when it gets a bad rap. We're hoping that we can convince you that accessibility doesn't have to be a dirty word
- D Obviously, accessibility can go far beyond just the Internet, but this evening, we’re going to focus on web accessibility. The tips, techniques, and tools that we’re talking about are for making websites accessible to all users – including, and especially, those with disabilities.
- D – So, first let’s talk about the disabilities that may be affecting people who are visiting your website. There are four main categories of disabilities. We’ll go through each one briefly.
- D - Vision impairments include more than just blindness. This could include color blindness or any kind of less than perfect vision. Now, how do people with vision impairments access websites? Users with lots of different disabilities often make use of tools called assistive technologies (sometimes referred to as “AT”) to help them access information and navigate a website. Some assistive technology tools used by people with visual impairments when they’re using the web include:
- (TW) Next we have auditory impairments Obviously this includes total hearing loss, but it can also be any sort of less-than-perfect hearing. Some of the most common assistive technologies for auditory impairments are: - Captions and subtitles for media - usually video - Sign language accompaniments - Full transcriptions of audio or video
- D - Motor impairments include a wide array. Could include tremors, paralysis, limited reach, loss of fine motor control. Users with these types of impairments may access the web using assistive technologies: The standard keyboard can be very useful for users who cannot effectively use a mouse. And even if they’re not interacting directly with the keyboard, they often are using another assistive tool that translates their input into keyboard commands. For example, speech recognition software allows users to use their voice to type or navigate a screen.
- (TW) Cognitive impairment refers to a range of deficits or impairments, including things like: - dyslexia - memory loss - intellectual disability - neuropsychological deficits Some of the most common assistive technologies are - Memory aids - Accommodation software (like text readers & notetakers) - Organizational Tools (both analogue and electronic)
- D - Now, each of these impairments we’ve discussed can fall into one of two additional categories: permanent or temporary. Permanent impairments are long-term and can last the majority or entirety of a person’s life. Additionally, as people age, they tend to develop permanent impairments. These types of impairments are probably what you think of when you think of people with disabilities. However, there are also temporary impairments: these can include temporary injuries or simply impairments due to circumstance or situation – like low lighting, or bright lighting, or loud environments, or distractions. So, really anyone can have a disability at some point or another.
- D - So, hopefully we’ve driven home the point that when we talk about web accessibility, we’re not just talking about screen readers or people with vision impairments. But next, we’re going to talk about some of the arguments against accessibility that seem to exist – and hopefully convince you that they’re not very strong arguments. And before we get into those, we’ll first mention that yes, sometimes you are legally required to make your website accessible. If your site is a federal government site, it needs to be compliant with the Section 508 guidelines. But since no one enjoys doing something they HAVE to do, tonight we want to focus on some other motivations for implementing accessible designs on your sites because we want everyone to make their sites accessible – not just the ones that HAVE to.
- (TW) The first anti-accessibility argument that we often encounter, is "It just isn't worth the trouble for such a small number of affected users" Essentially saying that accessibility is such an edge case, that it's not worth the effort. Maybe we’ve already debunked this one in our last few slides, but we’ll tackle this one a bit more.
- (TW) So, let's talk about who actually benefits from accessibility. The obvious answer, of course, is people with permanent disabilities. And it's as small of a group as you might think. The US Census Bureau reports that about 19% of Americans have some type of disability. That's almost 57 million people. And for adults who are 65 years or older, more than half have some sort of disability. That's a lot of people. But even if it wasn't - even if only 1% of the population had a disability - we say put yourself in their shoes. How would you feel if you couldn't have access to the media that everyone else enjoys?
- D
- D
- (TW) Lets talk about tables. Simple tables.
- (TW) Next up is web elements that are accessible with the keyboard. Of course it's helpful for keyboard-only users, and essential for keyboard-driven assistive technologies, but it's also just awesome for people who think tabbing through forms is way better than having to click on each item with the mouse.
- (TW) Finally, lets talk about labels. Having labels that are associated with input elements is a must for screen readers users - it's really difficult to know what an input is for if the label is automatically read for you. It
- T – So, to re-iterate argument #1 – we hope you agree that implementing accessible designs isn’t just for those “few users.”
- D Moving on to another anti-accessibility argument. Basically, this argument says “ok, we understand we should do it, but we don’t have money in the budget for all that extra work it’s going to take to make this site accessible.” This is probably the most common argument… but we’re going to try to prove it wrong.
- D – While we’re at it, another common argument is: “I’ll have to use ugly colors and I won’t be able to do that cool map I was envisioning or use expanding panels.” Again, we’re going to try to prove this argument wrong. We’re going to tackle these last two arguments (that it’s too expensive or too much work and that it will ruin the design) together because their solutions often go hand in hand.
- T
- T
- T We wanted to go through a few examples of how you can use ARIA to make a website element more accessible.
- D
- D We have a video of the JAWS screen reader interacting with two expandable panels – one without any ARIA and one using ARIA. [Go through code for each] For those who have never heard a screen reader, what you’ll hear is a funny voice reading the page elements as we navigate to them with the Tab or arrow key. The difference that you’ll hear between the two examples is that in the first, we will just be told that there is a link; we won’t be told that it’s expandable or whether it’s collapsed or expanded. In the second example, we will hear the current state. So, as you can imagine, it can be very useful information to a screen reader user to know whether the panel is expanded or collapsed. Without that knowledge, the user could miss the information in the panel.
- T
- D This ARIA feature is extremely useful for screen reader users in that their focus is directed immediately to the error message. In many cases, screen reader users can miss important information is their focus is not directed there.
- T
- D
- D
- T
- D
- T
- D
- D
- T
- T
- D
- T
- T
- T
- T
- D [Mention simple solution examples]
- D – We hope we have convinced you that accessibility isn’t such a dirty word, but can be quite the opposite. Hopefully you agree that accessibility is: