Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Why the Bad Rap? Accessibility doesn’t have to be a dirty word (3/15/17)

854 views

Published on

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/

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Why the Bad Rap? Accessibility doesn’t have to be a dirty word (3/15/17)

  1. 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. 2. Introduction Who we are and why we're here
  3. 3. Who We Are Dana Douglas User Experience Specialist Silver Spring, MD www.userworks.com (301) 431 - 0500 Tristan Wilson User Experience Specialist
  4. 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. 5. The Basics Web accessibility fundamentals
  6. 6. Disabilities related to web accessibility Impairment Categories 6 Vision Impairments Auditory Impairments Mobility Impairments Cognitive Impairments
  7. 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. 8. Disabilities related to web accessibility Impairment Categories 8 Auditory Impairments Common Assistive Technologies ▪ Captions & subtitles ▪ Sign language accompaniments ▪ Audio/video transcriptions
  9. 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. 10. Disabilities related to web accessibility Impairment Categories 10 Cognitive Impairments Common Assistive Technologies ▪ Memory Aids ▪ Accommodation Software ▪ Organizational Tools
  11. 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. 12. Do I really have to? Arguments against accessibility
  13. 13. “It isn’t worth the trouble for just a few users.” Anti-Accessibility Argument #1
  14. 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. 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. 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. 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. 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. 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. 20. “It isn’t worth the trouble for just a few users.” Anti-Accessibility Argument #1
  21. 21. “It’s too expensive and too much work.” Anti-Accessibility Argument #2
  22. 22. “It will ruin the design. ...I can’t do anything cool.” Anti-Accessibility Argument #3
  23. 23. A Few Solutions Accessibility can be easy and cool
  24. 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. 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. 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. 27. ARIA Example: aria-expanded - JAWS 17 - Chrome 27
  28. 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. 29. ARIA Example: role="alert" - JAWS 17 - Internet Explorer 29
  30. 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. 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. 32. Sectioning Elements Example - JAWS 17 - Internet Explorer 32
  33. 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. 34. Input Restrictions Example: Required - JAWS 17 - Chrome 34
  35. 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. 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. 37. Figure & Figcaption Example - JAWS 17 - Chrome 37
  38. 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. 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. 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. 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. 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. 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. 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. 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. 46. In Conclusion…
  47. 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. 48. Thank you! Dana Douglas ddouglas@userworks.com Silver Spring, MD www.userworks.com (301) 431 - 0500 Tristan Wilson twilson@userworks.com

×