FUD-Free Accessibility for Web Developers - Also, Cake.


Published on

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • \n
  • I'm a web developer, author, book editor, and I teach programming at Chippewa Valley Technical College. I've written a few books on web development and I'm very passionate about accessibility. I was actually born with bilateral cataracts and as a result, I have low vision.\n
  • What does accessibility mean to you?\n
  • When the topic of accessibility comes up, we usually think of disabilities. Specifically, these kind. Blind and low vision users are the ones who are obviously affected, and the hearing impaired have trouble with videos without captions. The physically impaired may have trouble working mice, and cognitive impairments can be anything from reading comprehension to dyslexia, which means you need to make wise choices about your fonts and spacing.\n
  • I want to point out here that these are not “users” or “customers”. These are people, and I think it’s really important that we keep that in the back of our minds.\n
  • But here’s another group of people to think about. Accessibility isn’t just about disabled users. \n
  • It's about making our products, services, and information available to anyone who wants it.\n
  • I hear people telling me all the time that they can’t afford to make their solutions accessible because it’s too expensive. I’ve heard product owners flat out tell me “we’re not concerned about the disabled users.” The thing is, accessibility isn’t that expensive to implement...\n
  • as long as you build it in from the beginning.\n
  • In order to plan ahead, you need to think about people's needs. You already do that with your target audience anyway.\n
  • I often hear the argument "We don't have to worry about making our mobile site accessible - a blind person won't use an iPad or an iPhone" The iPad has some great accessibility features, and so do Android phones. And there are kits that make it perfectly possible to use both of these devices. Plus I know blind people who program.\n
  • Once you understand the accessibility issues your customers face, you can start planning how you'll support them. So let’s talk about how people with traditional disabilities use computers.\n
  • Blind users typically use either a Braille display or a screen reader.\n
  • Screen readers read the text on the page, including alternate text and captions.\n
  • Captions are useful for the blind in cases where they don't have the ability to load the video.\n
  • \n
  • Low vision users present another challenge. These uses also use screenreading software, but use other technologies as well\n
  • OSX and Compiz offer amazing full screen zooming. Windows is very far behind so people use third-party products like ZoomText instead. Unfortunately this creates "tunnel vision" - a zoomed in user might miss something outside.\n
  • www.paciellogroup.com—google-chrome-accessibility <http://www.paciellogroup.com/blog/2008/09/google-chrome-accessibility/>\n
  • \n
  • \n
  • a difficulty in distinguishing differences between red, yellow, and green, as they can often appear all to be yellow or brow\n
  • Difficulty in distinguishing differences between red and green.\n
  • \n
  • \n
  • We all-too-often forget about the hearing-impaired users because we view the web as a visual medium\n
  • Especially if there's a lot of audio. If you're putting videos of a talk or presentation online, having a transcript is very helpful.\n
  • \n
  • These people may not have enough motor skills to operate a keyboard or mouse and will use other input devices.\n
  • What if that was you? Have you taken good care of your hands, those tools you use to build the things you build? How would you write code if you couldn’t use your hands?\n
  • Head wands let them touch a screen with a wand that extends from the forehead or jaw. Sip and blow tubes can control a mouse pointer with pressure/ Both are very difficult to operate.\n
  • We need to be mindful of these users and how they navigate when we place interface elements\n
  • \n
  • This will also help users of touchscreen devices.\n
  • A lot of this comes down to reading comprehension.\n
  • With any kind of writing, we want to say more with less.\n
  • Dyslexic users often have trouble interpreting words, and you can help that by using fonts that are easier for them to read.\n
  • \n
  • By addressing the issues these groups have, we can make our sites better for all our users. If we use good colors and icon placement, and we keep our text simple and easy to follow, we'll gain some points there. But let's take it farther.\n
  • We want to make it work first, then make it better.\n
  • Web apps without js are still cake. They may not be as awesome as cake without frosting, but they can still be quite tasty if done right\n
  • \n
  • \n
  • Forms are pretty much everywhere. We want to make forms easy to use.\n
  • Labels help screen reading software associate form fields with the text that identifies them. In the case of radio buttons, they do even more.\n
  • Especially important for helping screen readers find fields, but it also lets people click the label to activate the checkbox or the radio button.\n\n
  • A browser will, by default, will let you tab through the forms. If you structure the form in a linear fashion and use CSS to style it, you can avoid tabindex most of the time.\n
  • Today's applications need to use AJAX to provide decent user interfaces. When you build on a good foundation, this isn't a problem\n
  • \n
  • Build solid forms that work with regular posts. Use jQuery to unobtrusively submit the form. Look for a data attribute and then intercept the submit.\n
  • Then change the URL - maybe append a .js on it and handle it on the server side.\n
  • Use tables where they make sense\n
  • \n
  • \n
  • That’s pretty much all there is to it. Modern browsers and screen reading software have figured this out.\n
  • If the forms are actually tabular, and the table is properly structured.\n
  • In the past, popups and overlays were dangerous. And they still can be if we don’t implement them properly.\n
  • We can use custom data attributes to embed properties. No need to override the rel attribute. We also don’t include the onclick on the element.\n
  • We can grab everything we need from the markup to make the popup work, and this can be global. When no JavaScript is enabled, the popup is displayed on a new page.\n
  • When the content doesn't load in a popup, you don't want to show that control. Instead, add it with JavaScript. \n
  • It’s not enough to have static pages anymore. We need to interact with users, and that makes it harder or us to be accessible. ARIA gives us a hand.\n
  • Screenreaders see the polite region and know that not only does it update, but that updates shouldn’t interrupt the reader when it’s reading other areas.\n
  • Really handy way to help screenreader users find elements. “Documents” are static documents we read. Screenreaders have shortcut keys for navigating. “Application” role tells screenreaders to turn off the shortcut keys so that the apps can use those shortcut keys instead.\n
  • Use JavaScript to hide the content. This way if JS is disabled, but CSS is enabled, the content can still be read by the screenreader.\n
  • There are lots of cases where you want to improve the user experience by loading content with JavaScript. However, if that content is simply static content, loading with JS, we need to figure out of that’s really the best solution.\n
  • We’ll create a “hiddenWhileLoading” selector in CSS that hides the element with display:block.\n
  • Then we’ll apply this to the main element on our page, the HTML tag. This will hide everything on the page.\n
  • Then we’ll load jQuery. Then in Document Ready we’ll kick off our code. At the end of it all we’ll remove the class from the page and everything shows up.\n
  • \n
  • You want valid markup. Invalid markup can cause all sorts of trouble.\n
  • \n
  • \n
  • Automated testing can only go so far. We have to test things manually, and thankfully there are many free options.\n
  • Color Oracle is a free cross-platform app that will let you see your screen as a person with various types of colorblindness.\n
  • \n
  • One huge mistake people make when talking about accessibility is assuming that it has to be an all-or-nothing approach. THe tiniest little things help, and just by going out and taking one thing from this talk and incorporating it into what you do, you’ll already do more good.\n
  • When you do it right, people won’t think you’ve done anything at all.\n
  • \n
  • FUD-Free Accessibility for Web Developers - Also, Cake.

    1. 1. FUD-free Accessibility for Web Developers Also, cake.Brian P. Hogantwitter: @bphoganwww.bphogan.com
    2. 2. about me I write books I build things I teach peopleBrian P. Hogantwitter: @bphoganwww.bphogan.com
    3. 3. What is Accessibility?Brian P. Hogantwitter: @bphoganwww.bphogan.com
    4. 4. We often think of Blind people Low vision or colorblind people Deaf people Physically impaired people Cognitively impaired peopleBrian P. Hogantwitter: @bphoganwww.bphogan.com
    5. 5. We often think of Blind people Low vision or colorblind people Deaf people Physically impaired people Cognitively impaired peopleBrian P. Hogantwitter: @bphoganwww.bphogan.com
    6. 6. But thats too narrow People on small screens People without Flash People without JavaScript People on slow connections People on limited connectionsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    7. 7. Making things available toBrian P. Hogantwitter: @bphoganwww.bphogan.com
    8. 8. Accessibility isn’t expensive...Brian P. Hogantwitter: @bphoganwww.bphogan.com
    9. 9. as long as you plan from the start.Brian P. Hogantwitter: @bphoganwww.bphogan.com
    10. 10. We need to understand peoples accessibility issuesBrian P. Hogantwitter: @bphoganwww.bphogan.com
    11. 11. Dont underestimate peoples abilitiesBrian P. Hogantwitter: @bphoganwww.bphogan.com
    12. 12. Empathize, not sympathizeBrian P. Hogantwitter: @bphoganwww.bphogan.com
    13. 13. BlindnessBrian P. Hogantwitter: @bphoganwww.bphogan.com
    14. 14. Screen Readers http://webanywhere.cs.washington.edu/ beta/Brian P. Hogantwitter: @bphoganwww.bphogan.com
    15. 15. They rely on annotated videos or alternative contentBrian P. Hogantwitter: @bphoganwww.bphogan.com
    16. 16. Supporting Blind People Ensure you have no spelling errors Ensure your popup windows dont result in dead-ends for screenreaders Remove dependencies on JavaScript Provide keyboard navigationBrian P. Hogantwitter: @bphoganwww.bphogan.com
    17. 17. Low VisionBrian P. Hogantwitter: @bphoganwww.bphogan.com
    18. 18. Screen magnificationBrian P. Hogantwitter: @bphoganwww.bphogan.com
    19. 19. High contrast modeBrian P. Hogantwitter: @bphoganwww.bphogan.com
    20. 20. Supporting Low Vision Be aware of issues with contrast Dont use fonts that are terribly small Place important information close to main content as possible Ensure spelling is correct and elements have enough space to be clickedBrian P. Hogantwitter: @bphoganwww.bphogan.com
    21. 21. ColorblindnessBrian P. Hogantwitter: @bphoganwww.bphogan.com
    22. 22. ProtanopiaBrian P. Hogantwitter: @bphoganwww.bphogan.com
    23. 23. DeuteranopiaBrian P. Hogantwitter: @bphoganwww.bphogan.com
    24. 24. TritanopiaBrian P. Hogantwitter: @bphoganwww.bphogan.com
    25. 25. Supporting Colorblindness Dont use color as the only method to draw attention to elements Be aware of contrast issues Dont instruct users to identify things by colorBrian P. Hogantwitter: @bphoganwww.bphogan.com
    26. 26. Hearing ImpairmentsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    27. 27. Videos need good transcriptsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    28. 28. Supporting the Hearing Impaired Provide useful accurate transcripts for audio content Ensure that audio tracks are normalized or have appropriate volume "Duck" background music or background sounds during voiceovers.Brian P. Hogantwitter: @bphoganwww.bphogan.com
    29. 29. People with physical impairmentsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    30. 30. Brian P. Hogantwitter: @bphoganwww.bphogan.com
    31. 31. They navigate with head wands and tubesBrian P. Hogantwitter: @bphoganwww.bphogan.com
    32. 32. They need to easily identify and click interface elementsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    33. 33. Just like someone on a tablet!Brian P. Hogantwitter: @bphoganwww.bphogan.com
    34. 34. Supporting the Physically Impaired Ensure click targets are large enough to be easily accessed Ensure click targets are easily identified.Brian P. Hogantwitter: @bphoganwww.bphogan.com
    35. 35. Cognitive Impairments and Learning DisabilitiesBrian P. Hogantwitter: @bphoganwww.bphogan.com
    36. 36. Brian P. Hogantwitter: @bphoganwww.bphogan.com
    37. 37. DyslexiaBrian P. Hogantwitter: @bphoganwww.bphogan.com
    38. 38. Supporting Cognitive Impairments Avoid font confusion ( 0 vs O, I vs l Target a 6th grade reading level Keep copy short - say more with less Ensure proper spelling and grammarBrian P. Hogantwitter: @bphoganwww.bphogan.com
    39. 39. Coding For Accessibility is Coding For UsabilityBrian P. Hogantwitter: @bphoganwww.bphogan.com
    40. 40. Progressive EnhancementBrian P. Hogantwitter: @bphoganwww.bphogan.com
    41. 41. CakeBrian P. Hogantwitter: @bphoganwww.bphogan.com
    42. 42. You should progressively enhanceBrian P. Hogantwitter: @bphoganwww.bphogan.com
    43. 43. Your applications should degrade gracefullyBrian P. Hogantwitter: @bphoganwww.bphogan.com
    44. 44. Crafting Accessible FormsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    45. 45. Use labels Especially for radio buttonsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    46. 46. Wrap with label, or use the “for” attribute! <label> <input type="radio" value="smal"> Small </label>​ <label for="name">Name</label> <input id="name">Brian P. Hogantwitter: @bphoganwww.bphogan.com
    47. 47. Avoid Tabindex unless absolutely necessaryBrian P. Hogantwitter: @bphoganwww.bphogan.com
    48. 48. AJAX FormsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    49. 49. Accessible JavaScript solutions Build your app without JS first Use your own API! Dont add content with JavaScript use JS to show and hide it Separate Behavior from contentBrian P. Hogantwitter: @bphoganwww.bphogan.com
    50. 50. Apply jQuery to forms unobtrusively $(function(){ $("form[data-remote=true]").submit(function(e){ e.preventDefault(); // prevent normal submit $.ajax({ type: "POST", url: ($(this).attr("action") + ".js"), dataType: json, data: $(this).serialize(), success: function(data){ $(#results).html(data["render"]); } }); }); });Brian P. Hogantwitter: @bphoganwww.bphogan.com
    51. 51. Apply jQuery to forms unobtrusively $(function(){ $("form[data-remote=true]").submit(function(e){ e.preventDefault(); // prevent normal submit $.ajax({ type: "POST", url: ($(this).attr("action") + ".js"), dataType: json, data: $(this).serialize(), success: function(data){ $(#results).html(data["render"]); } }); }); });Brian P. Hogantwitter: @bphoganwww.bphogan.com
    52. 52. TablesBrian P. Hogantwitter: @bphoganwww.bphogan.com
    53. 53. Good tables Have table headers defined Have captions that explain their purposeBrian P. Hogantwitter: @bphoganwww.bphogan.com
    54. 54. Use <th> tags.Brian P. Hogantwitter: @bphoganwww.bphogan.com
    55. 55. Use header attributes when its ambiguousBrian P. Hogantwitter: @bphoganwww.bphogan.com
    56. 56. Tables can be OK for formsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    57. 57. Popups and OverlaysBrian P. Hogantwitter: @bphoganwww.bphogan.com
    58. 58. Make them regular links <a href="http://google.com/" class="popup" data-height="400" data-width="400">Search Google</a>​​Brian P. Hogantwitter: @bphoganwww.bphogan.com
    59. 59. Add behavior with JavaScript $(".popup").click(function(e){ e.preventDefault(); var url = $(this).attr("href"); var title = $(this).html(); var w = $(this).attr("data-width"); var h = $(this).attr("data-height"); window.open(url, title, "width="+ + w + ",height=" + h); });​​Brian P. Hogantwitter: @bphoganwww.bphogan.com
    60. 60. Add JS-only behavior with JS! var closer = $("<button>Close</button>"); closer.click(function(e){ mywindow.dialog("close"); }); $("#window").append(closer); var mywindow = $("#window").dialog();Brian P. Hogantwitter: @bphoganwww.bphogan.com
    61. 61. ARIA Accessible Rich Internet ApplicationsBrian P. Hogantwitter: @bphoganwww.bphogan.com
    62. 62. ARIA-Live <h3>Tasks</h3> <form id="task_form"> <label>Task <input type="text" id="task" name="task" value=""> </label> <input type="submit" value="Add"> </form> <ul aria-live="polite" id="tasks"> </ul>Brian P. Hogantwitter: @bphoganwww.bphogan.com
    63. 63. ARIA-Roles banner navigation main document application complementary contentinfo search ... lots moreBrian P. Hogantwitter: @bphoganwww.bphogan.com
    64. 64. Use display:none with care!Brian P. Hogantwitter: @bphoganwww.bphogan.com
    65. 65. Static ContentBrian P. Hogantwitter: @bphoganwww.bphogan.com
    66. 66. Avoiding Flash of Unstyled Content <script> document.write( <style type="text/css" media="screen"> .hiddenWhileLoading {display:none;} </style> ); document.documentElement.className = hiddenWhileLoading; </script>Brian P. Hogantwitter: @bphoganwww.bphogan.com
    67. 67. Avoiding Flash of Unstyled Content <script> document.write( <style type="text/css" media="screen"> .hiddenWhileLoading {display:none;} </style> ); document.documentElement.className = hiddenWhileLoading; </script>Brian P. Hogantwitter: @bphoganwww.bphogan.com
    68. 68. Avoiding Flash of Unstyled Content <!-- load jquery from CDN or whatever --> <script src=”jquery.js”></script> <script> $(function(){} // your stuff $(document.documentElement) .removeClass("hiddenWhileLoading"); ); </script>Brian P. Hogantwitter: @bphoganwww.bphogan.com
    69. 69. Testing AccessibilityBrian P. Hogantwitter: @bphoganwww.bphogan.com
    70. 70. First, does it validate?Brian P. Hogantwitter: @bphoganwww.bphogan.com
    71. 71. WCAG 2.0 http://www.w3.org/TR/WCAG/Brian P. Hogantwitter: @bphoganwww.bphogan.com
    72. 72. wave.webaim.orgBrian P. Hogantwitter: @bphoganwww.bphogan.com
    73. 73. Manual testing Jaws http:// www.freedomscientific.com/products/ fs/jaws-product-page.asp WindowEyes http://www.gwmicro.com/ Window-Eyes/ NVDA http://www.nvda-project.org/ OSX VoiceOver (built-in)Brian P. Hogantwitter: @bphoganwww.bphogan.com
    74. 74. Color Oracle http://colororacle.cartography.ch/Brian P. Hogantwitter: @bphoganwww.bphogan.com
    75. 75. Content will be easy to read Things will be easy to see Elements will be easier to interact with on portable devices Transcripts for promotional material can be read where the video can’t be playedBrian P. Hogantwitter: @bphoganwww.bphogan.com
    76. 76. Perfect is the Enemy of Good. - Commonly attributed to VoltaireBrian P. Hogantwitter: @bphoganwww.bphogan.com
    77. 77. The world will be a better place.Brian P. Hogantwitter: @bphoganwww.bphogan.com
    78. 78. Thank you! http://spkr8.com/t/14841Brian P. Hogantwitter: @bphoganwww.bphogan.com