More Related Content


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

  1. FUD-free Accessibility for Web Developers Also, cake. Brian P. Hogan twitter: @bphogan
  2. about me I write books I build things I teach people Brian P. Hogan twitter: @bphogan
  3. What is Accessibility? Brian P. Hogan twitter: @bphogan
  4. We often think of Blind people Low vision or colorblind people Deaf people Physically impaired people Cognitively impaired people Brian P. Hogan twitter: @bphogan
  5. We often think of Blind people Low vision or colorblind people Deaf people Physically impaired people Cognitively impaired people Brian P. Hogan twitter: @bphogan
  6. But that's too narrow People on small screens People without Flash People without JavaScript People on slow connections People on limited connections Brian P. Hogan twitter: @bphogan
  7. Making things available to Brian P. Hogan twitter: @bphogan
  8. Accessibility isn’t expensive... Brian P. Hogan twitter: @bphogan
  9. as long as you plan from the start. Brian P. Hogan twitter: @bphogan
  10. We need to understand people's accessibility issues Brian P. Hogan twitter: @bphogan
  11. Don't underestimate people's abilities Brian P. Hogan twitter: @bphogan
  12. Empathize, not sympathize Brian P. Hogan twitter: @bphogan
  13. Blindness Brian P. Hogan twitter: @bphogan
  14. Screen Readers beta/ Brian P. Hogan twitter: @bphogan
  15. They rely on annotated videos or alternative content Brian P. Hogan twitter: @bphogan
  16. Supporting Blind People Ensure you have no spelling errors Ensure your popup windows don't result in dead-ends for screenreaders Remove dependencies on JavaScript Provide keyboard navigation Brian P. Hogan twitter: @bphogan
  17. Low Vision Brian P. Hogan twitter: @bphogan
  18. Screen magnification Brian P. Hogan twitter: @bphogan
  19. High contrast mode Brian P. Hogan twitter: @bphogan
  20. Supporting Low Vision Be aware of issues with contrast Don't 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 clicked Brian P. Hogan twitter: @bphogan
  21. Colorblindness Brian P. Hogan twitter: @bphogan
  22. Protanopia Brian P. Hogan twitter: @bphogan
  23. Deuteranopia Brian P. Hogan twitter: @bphogan
  24. Tritanopia Brian P. Hogan twitter: @bphogan
  25. Supporting Colorblindness Don't use color as the only method to draw attention to elements Be aware of contrast issues Don't instruct users to identify things by color Brian P. Hogan twitter: @bphogan
  26. Hearing Impairments Brian P. Hogan twitter: @bphogan
  27. Videos need good transcripts Brian P. Hogan twitter: @bphogan
  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. Hogan twitter: @bphogan
  29. People with physical impairments Brian P. Hogan twitter: @bphogan
  30. Brian P. Hogan twitter: @bphogan
  31. They navigate with head wands and tubes Brian P. Hogan twitter: @bphogan
  32. They need to easily identify and click interface elements Brian P. Hogan twitter: @bphogan
  33. Just like someone on a tablet! Brian P. Hogan twitter: @bphogan
  34. Supporting the Physically Impaired Ensure click targets are large enough to be easily accessed Ensure click targets are easily identified. Brian P. Hogan twitter: @bphogan
  35. Cognitive Impairments and Learning Disabilities Brian P. Hogan twitter: @bphogan
  36. Brian P. Hogan twitter: @bphogan
  37. Dyslexia Brian P. Hogan twitter: @bphogan
  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 grammar Brian P. Hogan twitter: @bphogan
  39. Coding For Accessibility is Coding For Usability Brian P. Hogan twitter: @bphogan
  40. Progressive Enhancement Brian P. Hogan twitter: @bphogan
  41. Cake Brian P. Hogan twitter: @bphogan
  42. You should progressively enhance Brian P. Hogan twitter: @bphogan
  43. Your applications should degrade gracefully Brian P. Hogan twitter: @bphogan
  44. Crafting Accessible Forms Brian P. Hogan twitter: @bphogan
  45. Use labels Especially for radio buttons Brian P. Hogan twitter: @bphogan
  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. Hogan twitter: @bphogan
  47. Avoid Tabindex unless absolutely necessary Brian P. Hogan twitter: @bphogan
  48. AJAX Forms Brian P. Hogan twitter: @bphogan
  49. Accessible JavaScript solutions Build your app without JS first Use your own API! Don't add content with JavaScript use JS to show and hide it Separate Behavior from content Brian P. Hogan twitter: @bphogan
  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. Hogan twitter: @bphogan
  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. Hogan twitter: @bphogan
  52. Tables Brian P. Hogan twitter: @bphogan
  53. Good tables Have table headers defined Have captions that explain their purpose Brian P. Hogan twitter: @bphogan
  54. Use <th> tags. Brian P. Hogan twitter: @bphogan
  55. Use header attributes when it's ambiguous Brian P. Hogan twitter: @bphogan
  56. Tables can be OK for forms Brian P. Hogan twitter: @bphogan
  57. Popups and Overlays Brian P. Hogan twitter: @bphogan
  58. Make them regular links <a href="" class="popup" data-height="400" data-width="400">Search Google</a>​​ Brian P. Hogan twitter: @bphogan
  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");, title, "width="+ + w + ",height=" + h); });​​ Brian P. Hogan twitter: @bphogan
  60. Add JS-only behavior with JS! var closer = $("<button>Close</button>");{ mywindow.dialog("close"); }); $("#window").append(closer); var mywindow = $("#window").dialog(); Brian P. Hogan twitter: @bphogan
  61. ARIA Accessible Rich Internet Applications Brian P. Hogan twitter: @bphogan
  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. Hogan twitter: @bphogan
  63. ARIA-Roles banner navigation main document application complementary contentinfo search ... lots more Brian P. Hogan twitter: @bphogan
  64. Use display:none with care! Brian P. Hogan twitter: @bphogan
  65. Static Content Brian P. Hogan twitter: @bphogan
  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. Hogan twitter: @bphogan
  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. Hogan twitter: @bphogan
  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. Hogan twitter: @bphogan
  69. Testing Accessibility Brian P. Hogan twitter: @bphogan
  70. First, does it validate? Brian P. Hogan twitter: @bphogan
  71. WCAG 2.0 Brian P. Hogan twitter: @bphogan
  72. Brian P. Hogan twitter: @bphogan
  73. Manual testing Jaws http:// fs/jaws-product-page.asp WindowEyes Window-Eyes/ NVDA OSX VoiceOver (built-in) Brian P. Hogan twitter: @bphogan
  74. Color Oracle Brian P. Hogan twitter: @bphogan
  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 played Brian P. Hogan twitter: @bphogan
  76. Perfect is the Enemy of Good. - Commonly attributed to Voltaire Brian P. Hogan twitter: @bphogan
  77. The world will be a better place. Brian P. Hogan twitter: @bphogan
  78. Thank you! Brian P. Hogan twitter: @bphogan

Editor's Notes

  1. \n
  2. I&apos;m a web developer, author, book editor, and I teach programming at Chippewa Valley Technical College. I&apos;ve written a few books on web development and I&apos;m very passionate about accessibility. I was actually born with bilateral cataracts and as a result, I have low vision.\n
  3. What does accessibility mean to you?\n
  4. 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
  5. I want to point out here that these are not &amp;#x201C;users&amp;#x201D; or &amp;#x201C;customers&amp;#x201D;. These are people, and I think it&amp;#x2019;s really important that we keep that in the back of our minds.\n
  6. But here&amp;#x2019;s another group of people to think about. Accessibility isn&amp;#x2019;t just about disabled users. \n
  7. It&apos;s about making our products, services, and information available to anyone who wants it.\n
  8. I hear people telling me all the time that they can&amp;#x2019;t afford to make their solutions accessible because it&amp;#x2019;s too expensive. I&amp;#x2019;ve heard product owners flat out tell me &amp;#x201C;we&amp;#x2019;re not concerned about the disabled users.&amp;#x201D; The thing is, accessibility isn&amp;#x2019;t that expensive to implement...\n
  9. as long as you build it in from the beginning.\n
  10. In order to plan ahead, you need to think about people&apos;s needs. You already do that with your target audience anyway.\n
  11. I often hear the argument &quot;We don&apos;t have to worry about making our mobile site accessible - a blind person won&apos;t use an iPad or an iPhone&quot; 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
  12. Once you understand the accessibility issues your customers face, you can start planning how you&apos;ll support them. So let&amp;#x2019;s talk about how people with traditional disabilities use computers.\n
  13. Blind users typically use either a Braille display or a screen reader.\n
  14. Screen readers read the text on the page, including alternate text and captions.\n
  15. Captions are useful for the blind in cases where they don&apos;t have the ability to load the video.\n
  16. \n
  17. Low vision users present another challenge. These uses also use screenreading software, but use other technologies as well\n
  18. 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 &quot;tunnel vision&quot; - a zoomed in user might miss something outside.\n
  19.;#x2014;google-chrome-accessibility &lt;;\n
  20. \n
  21. \n
  22. a difficulty in distinguishing differences between red, yellow, and green, as they can often appear all to be yellow or brow\n
  23. Difficulty in distinguishing differences between red and green.\n
  24. \n
  25. \n
  26. We all-too-often forget about the hearing-impaired users because we view the web as a visual medium\n
  27. Especially if there&apos;s a lot of audio. If you&apos;re putting videos of a talk or presentation online, having a transcript is very helpful.\n
  28. \n
  29. These people may not have enough motor skills to operate a keyboard or mouse and will use other input devices.\n
  30. 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&amp;#x2019;t use your hands?\n
  31. 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
  32. We need to be mindful of these users and how they navigate when we place interface elements\n
  33. \n
  34. This will also help users of touchscreen devices.\n
  35. A lot of this comes down to reading comprehension.\n
  36. With any kind of writing, we want to say more with less.\n
  37. Dyslexic users often have trouble interpreting words, and you can help that by using fonts that are easier for them to read.\n
  38. \n
  39. 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&apos;ll gain some points there. But let&apos;s take it farther.\n
  40. We want to make it work first, then make it better.\n
  41. 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
  42. \n
  43. \n
  44. Forms are pretty much everywhere. We want to make forms easy to use.\n
  45. 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
  46. 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
  47. 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
  48. Today&apos;s applications need to use AJAX to provide decent user interfaces. When you build on a good foundation, this isn&apos;t a problem\n
  49. \n
  50. 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
  51. Then change the URL - maybe append a .js on it and handle it on the server side.\n
  52. Use tables where they make sense\n
  53. \n
  54. \n
  55. That&amp;#x2019;s pretty much all there is to it. Modern browsers and screen reading software have figured this out.\n
  56. If the forms are actually tabular, and the table is properly structured.\n
  57. In the past, popups and overlays were dangerous. And they still can be if we don&amp;#x2019;t implement them properly.\n
  58. We can use custom data attributes to embed properties. No need to override the rel attribute. We also don&amp;#x2019;t include the onclick on the element.\n
  59. 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
  60. When the content doesn&apos;t load in a popup, you don&apos;t want to show that control. Instead, add it with JavaScript. \n
  61. It&amp;#x2019;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
  62. Screenreaders see the polite region and know that not only does it update, but that updates shouldn&amp;#x2019;t interrupt the reader when it&amp;#x2019;s reading other areas.\n
  63. Really handy way to help screenreader users find elements. &amp;#x201C;Documents&amp;#x201D; are static documents we read. Screenreaders have shortcut keys for navigating. &amp;#x201C;Application&amp;#x201D; role tells screenreaders to turn off the shortcut keys so that the apps can use those shortcut keys instead.\n
  64. 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
  65. 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&amp;#x2019;s really the best solution.\n
  66. We&amp;#x2019;ll create a &amp;#x201C;hiddenWhileLoading&amp;#x201D; selector in CSS that hides the element with display:block.\n
  67. Then we&amp;#x2019;ll apply this to the main element on our page, the HTML tag. This will hide everything on the page.\n
  68. Then we&amp;#x2019;ll load jQuery. Then in Document Ready we&amp;#x2019;ll kick off our code. At the end of it all we&amp;#x2019;ll remove the class from the page and everything shows up.\n
  69. \n
  70. You want valid markup. Invalid markup can cause all sorts of trouble.\n
  71. \n
  72. \n
  73. Automated testing can only go so far. We have to test things manually, and thankfully there are many free options.\n
  74. Color Oracle is a free cross-platform app that will let you see your screen as a person with various types of colorblindness.\n
  75. \n
  76. 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&amp;#x2019;ll already do more good.\n
  77. When you do it right, people won&amp;#x2019;t think you&amp;#x2019;ve done anything at all.\n
  78. \n