Web Accessibility - We're All In This Together!


Published on

A lightning talk on web accessibility issues with quick tips and tricks...

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide

Web Accessibility - We're All In This Together!

  1. 1. WebAccessibility –Were All InThis Together!ThoughtWorks TeamMeeting – January 2013London, UKAndrew RonksleyDigital Accessibility Development OfficerRoyal National Institute of Blind People
  2. 2. Whats an “assistive technology”?And does anyone in the room use any?Sure, any specialist software / hardwaredesigned for disabled people counts, butdoes anything else count as well?
  3. 3. Despite it being smashed beyondbelief, my mobile to me (and toeveryone) is an “assistivetechnology”.Without it, I cant call my mumbecause human hearing doesntwork over a range of 200 or somiles.I need the technology to “extendmy capabilities as a human”.To that end, I see almost alltechnologies as “assistivetechnologies”.So I normally just refer to“technology” these days.
  4. 4. Simple steps to improving web accessibility...
  5. 5. Dont use fixed font sizes and colours... Designers want it “my way”. Let users take the “highway” if they want. Keep all styles in external CSS (avoid inline styles). Avoid “px” values for font-size and line-heights (Internet Explorer wont resize them). A style switcher is nice to have but not an essential feature.
  6. 6. Consistency is a virtue... Aim for consistency across your interface both in terms of locations and shape / colours of items. Give your design room to breathe but avoid large amounts of white space between related controls. Pure white space is difficult to traverse for screen magnification users. Consistency can really help disabled users once they become familiar with your site or application.
  7. 7. Give your mouse the day off......test with the keyboard only.
  8. 8. Be kind. Be semantic. Write great, descriptive HTML. Use <title>, <h1-h6>, <ul><li>, <label for=””>. Alt attributes – describe the purpose of the image. If it doesnt have a purpose, use alt=”” or a css background image instead. Link text – every time you use “Click here” something bad happens to my nieces kitten. If you have tabular data use table markup! <th>, <td> and scope. CSS – be careful with display: none. Screen readers parse this and wont always read content out (which may be what you want). Use absolute positioning off-screen if you want the content available though.
  9. 9. Test it with real end users......make sure its not a car crash!
  10. 10. JavaScript...doer of accessibility evil! Sensationalist and not true! Like any other web technology, it comes down to how you use it. To my knowledge, screen readers dont parse JavaScript directly. They rely on information given to them from the browser via the platform accessibility API for the operating system in use. Where JavaScript causes a problem is when it manipulates the DOM without a page reload and is used to create custom “widgets” that dont natively exist in HTML.
  11. 11. How does WAI-ARIA help? Despite being intrinsically linked with JavaScript, WAI-ARIA is actually a “semantic plaster / bandaid” for HTML (not bacon flavoured unfortunately!) ARIA markup is just additional attributes that you can add to your HTML document and manipulate through your scripts. Its super easy and already comes “baked-in” to a lot of popular JavaScript UI libraries.
  12. 12. How does WAI-ARIA help? ARIA allows you to specify what the role of something is, e.g. if you have a bunch of <div> elements faking a menu, use role=”menu” and role=”menuitem” to “repair” it. Using ARIA you can also mark an element of a page as a “live region” if it gets updated dynamically through DOM manipulation or the result of an AJAX call. Guess what? Most of this stuff needs both browser and screen reader support!
  13. 13. Whats the deal with WAI-ARIA and HTML5? HTML5 is incorporating elements of ARIA. For example, theres a native <menu> element which can be used rather than <div> and role=”menu” and <input type=”range”> can be used instead of role=”slider”. ARIA has support for more widgets than HTML5 native elements though. For example, tree views, modal dialogs and live regions. Its not dead as a specification yet. The HTML5 specification has a number of mapping tables that outline the relationship between the two specifications. Theyre definitely worth checking out. Finally, I dont need to tell you that HTML5 depends on browser support as well!
  14. 14. Thanks for listening! Any questions?
  15. 15. www.rnib.org.uk/wacwww.rnib.org.uk/professionals/softwareandtechnologywww.paciellogroup.com/blog/ (for the latest WAI-ARIA / HTML5information)www.linkedin.com/in/andrewronksley
  16. 16. Thanks to the following awesome Flickr users for letting me use their images:http://www.flickr.com/photos/altogetherfool/3543142490/http://www.flickr.com/photos/--sam--/4486809849/http://www.flickr.com/photos/guydonges/2649517251/http://www.flickr.com/photos/kenwilcox/3883031017/http://www.flickr.com/photos/functoruser/2437807188/http://www.flickr.com/photos/30998987@N03/5408763997/http://www.flickr.com/photos/eamoncurry/3335785800/http://www.flickr.com/photos/methodshop/6397366607/http://www.flickr.com/photos/arnehendriks/3360303148/http://www.flickr.com/photos/22290288@N03/5865026309/http://www.flickr.com/photos/11513812@N02/1394620294/http://www.flickr.com/photos/junit16/6036682072/http://www.flickr.com/photos/wwworks/4759535950/