Your SlideShare is downloading. ×
  • Like
FUD-Free Accessibility for Web Developers - Also, Cake.
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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



Published in Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    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
  •—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


  • 1. FUD-free Accessibility for Web Developers Also, cake.Brian P. Hogantwitter:
  • 2. about me I write books I build things I teach peopleBrian P. Hogantwitter:
  • 3. What is Accessibility?Brian P. Hogantwitter:
  • 4. We often think of Blind people Low vision or colorblind people Deaf people Physically impaired people Cognitively impaired peopleBrian P. Hogantwitter:
  • 5. We often think of Blind people Low vision or colorblind people Deaf people Physically impaired people Cognitively impaired peopleBrian P. Hogantwitter:
  • 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:
  • 7. Making things available toBrian P. Hogantwitter:
  • 8. Accessibility isn’t expensive...Brian P. Hogantwitter:
  • 9. as long as you plan from the start.Brian P. Hogantwitter:
  • 10. We need to understand peoples accessibility issuesBrian P. Hogantwitter:
  • 11. Dont underestimate peoples abilitiesBrian P. Hogantwitter:
  • 12. Empathize, not sympathizeBrian P. Hogantwitter:
  • 13. BlindnessBrian P. Hogantwitter:
  • 14. Screen Readers beta/Brian P. Hogantwitter:
  • 15. They rely on annotated videos or alternative contentBrian P. Hogantwitter:
  • 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:
  • 17. Low VisionBrian P. Hogantwitter:
  • 18. Screen magnificationBrian P. Hogantwitter:
  • 19. High contrast modeBrian P. Hogantwitter:
  • 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:
  • 21. ColorblindnessBrian P. Hogantwitter:
  • 22. ProtanopiaBrian P. Hogantwitter:
  • 23. DeuteranopiaBrian P. Hogantwitter:
  • 24. TritanopiaBrian P. Hogantwitter:
  • 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:
  • 26. Hearing ImpairmentsBrian P. Hogantwitter:
  • 27. Videos need good transcriptsBrian P. Hogantwitter:
  • 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:
  • 29. People with physical impairmentsBrian P. Hogantwitter:
  • 30. Brian P. Hogantwitter:
  • 31. They navigate with head wands and tubesBrian P. Hogantwitter:
  • 32. They need to easily identify and click interface elementsBrian P. Hogantwitter:
  • 33. Just like someone on a tablet!Brian P. Hogantwitter:
  • 34. Supporting the Physically Impaired Ensure click targets are large enough to be easily accessed Ensure click targets are easily identified.Brian P. Hogantwitter:
  • 35. Cognitive Impairments and Learning DisabilitiesBrian P. Hogantwitter:
  • 36. Brian P. Hogantwitter:
  • 37. DyslexiaBrian P. Hogantwitter:
  • 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:
  • 39. Coding For Accessibility is Coding For UsabilityBrian P. Hogantwitter:
  • 40. Progressive EnhancementBrian P. Hogantwitter:
  • 41. CakeBrian P. Hogantwitter:
  • 42. You should progressively enhanceBrian P. Hogantwitter:
  • 43. Your applications should degrade gracefullyBrian P. Hogantwitter:
  • 44. Crafting Accessible FormsBrian P. Hogantwitter:
  • 45. Use labels Especially for radio buttonsBrian P. Hogantwitter:
  • 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:
  • 47. Avoid Tabindex unless absolutely necessaryBrian P. Hogantwitter:
  • 48. AJAX FormsBrian P. Hogantwitter:
  • 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:
  • 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:
  • 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:
  • 52. TablesBrian P. Hogantwitter:
  • 53. Good tables Have table headers defined Have captions that explain their purposeBrian P. Hogantwitter:
  • 54. Use <th> tags.Brian P. Hogantwitter:
  • 55. Use header attributes when its ambiguousBrian P. Hogantwitter:
  • 56. Tables can be OK for formsBrian P. Hogantwitter:
  • 57. Popups and OverlaysBrian P. Hogantwitter:
  • 58. Make them regular links <a href="" class="popup" data-height="400" data-width="400">Search Google</a>​​Brian P. Hogantwitter:
  • 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. Hogantwitter:
  • 60. Add JS-only behavior with JS! var closer = $("<button>Close</button>");{ mywindow.dialog("close"); }); $("#window").append(closer); var mywindow = $("#window").dialog();Brian P. Hogantwitter:
  • 61. ARIA Accessible Rich Internet ApplicationsBrian P. Hogantwitter:
  • 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:
  • 63. ARIA-Roles banner navigation main document application complementary contentinfo search ... lots moreBrian P. Hogantwitter:
  • 64. Use display:none with care!Brian P. Hogantwitter:
  • 65. Static ContentBrian P. Hogantwitter:
  • 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:
  • 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:
  • 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:
  • 69. Testing AccessibilityBrian P. Hogantwitter:
  • 70. First, does it validate?Brian P. Hogantwitter:
  • 71. WCAG 2.0 P. Hogantwitter:
  • 72. wave.webaim.orgBrian P. Hogantwitter:
  • 73. Manual testing Jaws http:// fs/jaws-product-page.asp WindowEyes Window-Eyes/ NVDA OSX VoiceOver (built-in)Brian P. Hogantwitter:
  • 74. Color Oracle P. Hogantwitter:
  • 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:
  • 76. Perfect is the Enemy of Good. - Commonly attributed to VoltaireBrian P. Hogantwitter:
  • 77. The world will be a better place.Brian P. Hogantwitter:
  • 78. Thank you! P. Hogantwitter: