O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Booster 2017 - from accessibility n00b to pro in 1.5 hrs

271 visualizações

Publicada em

You have (probably?) heard about accessibility ("universell utforming" in Norwegian), but do you know what it is? How to use it and how to design, develop and test for it? No? Then this is the workshop for you! And even if you are experienced and know what a11y stands for, you might pick up a trick or two.

Publicada em: Software
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Booster 2017 - from accessibility n00b to pro in 1.5 hrs

  1. 1. FROM ACCESSIBILITY N00B TO PRO IN 1.5 HOURS BOOSTER 2017 VEGARD HAUGSTVEDT ITERA
  2. 2. «THE MAIN RULE IS THAT ALL IT-SOLUTIONS IN NORWAY MUST BE ACCESSIBLE. THIS INCLUDES BOTH WEBSITES, SELF-SERVICE MACHINES AND SIMILAR SYSTEMS. BOTH PRIVATE AND PUBLIC BUSINESSES, TEAMS AND ORGANIZATIONS MUST FOLLOW THE RULES.» – DIFI.NO
  3. 3. WCAG 2.0 • Principles • Guidelines • Success Criteria • Techniques 17.03.2017 / 3@IT_VEGARD / #BOOSTERA11Y
  4. 4. Core principals of accessibility – WCAG 2.0 • Perceivable • Operable • Understandable • Robust 17.03.2017 / 4@IT_VEGARD / #BOOSTERA11Y
  5. 5. 1. Perceivable 1. Text alternatives 2. Time-based Media 3. Adaptable 4. Distinguishable 17.03.2017 / 5@IT_VEGARD / #BOOSTERA11Y
  6. 6. 2. Operable 1. Keyboard accessible 2. Enough time 3. Seizures 4. Navigable 17.03.2017 / 6@IT_VEGARD / #BOOSTERA11Y
  7. 7. 3. Understandable 1. Readable 2. Predictable 3. Input assistance 17.03.2017 / 7@IT_VEGARD / #BOOSTERA11Y
  8. 8. 4. Robust 1. Compatible 17.03.2017 / 8@IT_VEGARD / #BOOSTERA11Y
  9. 9. WHO DO WE BUILD FOR? CONSEPT PHASE
  10. 10. «Why should we bother with accessibility? As far as we know, none of our users are blind…» - Anonymous client 17.03.2017 / 10@IT_VEGARD / #BOOSTERA11Y
  11. 11. Employment among people with significant vision loss • 38.3% of disabled users of screen readers are employed full-time* • 73.4% of non-disabled users of screen readers are employed full-time* WebAIM Screen Reader User Survey #6 (2015) 17.03.2017 / 11@IT_VEGARD / #BOOSTERA11Y
  12. 12. Who are your users? General – the average user • Demographics • Job responsibilities and tasks • Frequency of use • Hardware • Environment • Computer experience • Web application experience • Task knowledge 17.03.2017 / 12@IT_VEGARD / #BOOSTERA11Y
  13. 13. User group: Retirees • Age: 57-96 • 60% male, 40% female • Reduced vision • Reduced motor skills • … and so on Data from HRWeb (US) 17.03.2017 / 13@IT_VEGARD / #BOOSTERA11Y
  14. 14. Personas Vegard Haugstvedt 29 years old Developer Red-green colour blind Doesn’t leave home without his phone, and has a computer within reach whether he is at work or at home. Loves new gadgets, and has a dream of making his day-to-day life as automated as possible. He recently became a father, and therefore frequently has to use mobiles and laptops with only one hand while carrying his son. Uses his phone in bright daylight and while in dark rooms at night. 17.03.2017 / 14@IT_VEGARD / #BOOSTERA11Y
  15. 15. Who are your users? Specific – «real» users • Name • Image • Age • Profession • Personal traits 17.03.2017 / 15@IT_VEGARD / #BOOSTERA11Y
  16. 16. TASK 1: PERSONAS 17.03.2017 / 16@IT_VEGARD / #BOOSTERA11Y
  17. 17. Task 1: Personas • Create a persona that incorporates accessibility concerns • You should at least specify the following: – Nature of limitations – Special tools or assistive technology used – Experience and skills with the relevant tools and technologies – Frequency of use of relevant tools or assistive technologies 17.03.2017 / 17@IT_VEGARD / #BOOSTERA11Y
  18. 18. DESIGNING FOR A BETTER WEB DESIGN PHASE
  19. 19. Color contrasts • Normal text: 4.5:1 contrast • Large text: 3:1 contrast • Be wary of text overlaying images 17.03.2017 / 19@IT_VEGARD / #BOOSTERA11Y
  20. 20. Click areas • Buttons • Checkboxes • Links (also inside texts) • Make as large of an area as possible clickable • Make it intuitive what area is clickable 17.03.2017 / 20@IT_VEGARD / #BOOSTERA11Y
  21. 21. Text formatting 17.03.2017 / 21@IT_VEGARD / #BOOSTERA11Y
  22. 22. Sliders • Inherently inaccurate • Bad UX for touchscreens as well • Use as an enhancement – Provide alternative inputs – Make the slider-button accessible for keyboard users 17.03.2017 / 22@IT_VEGARD / #BOOSTERA11Y
  23. 23. Ease of navigation • “Every click or interaction should take the user closer to their goal while eliminating as much of the non-destination as possible.” * • Make sure focus is clearly shown! • Stop removing link underlining… * http://grundyhome.com/blog/archives/2009/01/31/breaking-the-law-the-3-click-rule/ 17.03.2017 / 23@IT_VEGARD / #BOOSTERA11Y
  24. 24. TASK 2: DESIGN REVIEW 17.03.2017 / 24@IT_VEGARD / #BOOSTERA11Y
  25. 25. Task 2: Design review 1. Have a look at http://nba.com/ 2. Discuss the following with the person next to you – Imagine how this page would be experienced if you could not see 3. Try navigating with a keyboard (using TAB) – Do you feel confident on where you will be taken if you click enter? 4. How would you have solved this functionality in a more accessible way? 17.03.2017 / 25@IT_VEGARD / #BOOSTERA11Y
  26. 26. SEMANTICS AND WAI-ARIA DEVELOPMENT PHASE
  27. 27. HTML5 Landmarks and sectioning elements • Main (main) • Section (region) • Header (banner) • Footer (contentinfo) • Nav (navigation) • Aside (complementary) • Form (form) 17.03.2017 / 27@IT_VEGARD / #BOOSTERA11Y
  28. 28. HTML Headings • H1, H2, H3, H4, H5, H6 • Provides structure to the page • Allows the user to navigate quickly through the page • How would your page would appear if you only heard the headings? • Don’t use heading levels for styling purposes! 17.03.2017 / 28@IT_VEGARD / #BOOSTERA11Y
  29. 29. Custom widgets vs. Native HTML elements? • Always use the native HTML elements if there exists one. • Avoid issues with browser compatibility, support for assistive technologies, and so on. 17.03.2017 / 29@IT_VEGARD / #BOOSTERA11Y
  30. 30. Images and videos • Non-textual content • Alt-attribute • Beware of text over images • … But do use them! 17.03.2017 / 30@IT_VEGARD / #BOOSTERA11Y
  31. 31. Links and buttons • Link- and button texts should be descriptive • Links should visually differentiate themselves from regular text – Underline and color • Buttons should also respond to keyboard interactions 17.03.2017 / 31@IT_VEGARD / #BOOSTERA11Y
  32. 32. Forms • Avoid keyboard traps! • Placeholders are not replacements for labels • Make sure placeholders satisfy contrast requirements 17.03.2017 / 32@IT_VEGARD / #BOOSTERA11Y
  33. 33. TASK 3: HTML5 SEMANTICS 17.03.2017 / 33@IT_VEGARD / #BOOSTERA11Y
  34. 34. Task 3: HTML5 and screen readers http://codepen.io/it-vegard/ 1. Try «viewing» images with screen reader 2. Try navigating links with screen reader What did you experience? 17.03.2017 / 34@IT_VEGARD / #BOOSTERA11Y
  35. 35. WAI-ARIA Version 1.0 was published in 2014 • Roles (describes type of widget or structure) • State • Live regions • Drag-and-drop sources and targets 17.03.2017 / 35@IT_VEGARD / #BOOSTERA11Y
  36. 36. WAI-ARIA roles • Used to declare user interface elements • Provides semantics for assistive technologies – how this element should be handled • Still needed even with HTML5 17.03.2017 / 36@IT_VEGARD / #BOOSTERA11Y
  37. 37. WAI-ARIA state • Used to communicate input states to assistive technologies • Most of them are handled natively by the user agents • Set values with JavaScript for custom elements 17.03.2017 / 37@IT_VEGARD / #BOOSTERA11Y
  38. 38. WAI-ARIA live regions • Used to define areas of the webpage that will change • Informs screen readers whether and how to interrupt users with changes • Auto-loading in comment fields, calculated values, conditional input elements, etc • ‘aria-live’ sets how often to alert the user of changes. • ‘aria-controls’ associates a control with the region it controls. • ‘role’ has some predefined live regions: – log, status, alert, progressbar, marquee and timer 17.03.2017 / 38@IT_VEGARD / #BOOSTERA11Y
  39. 39. AUTOMATIC VALIDATION AND USER TESTING TEST PHASE
  40. 40. Ways of doing accessibility testing • Browser validators • Command line tools • User testing 17.03.2017 / 40@IT_VEGARD / #BOOSTERA11Y
  41. 41. Browser validators • Chrome Developer Tools • Ainspector (Firefox) • WAVE 17.03.2017 / 41@IT_VEGARD / #BOOSTERA11Y
  42. 42. Automated tools 17.03.2017 / 42@IT_VEGARD / #BOOSTERA11Y
  43. 43. User testing 17.03.2017 / 43@IT_VEGARD / #BOOSTERA11Y
  44. 44. TASK 5: ACCESSIBILITY VALIDATION 17.03.2017 / 44@IT_VEGARD / #BOOSTERA11Y
  45. 45. Task 5: Accessibility validation 1. Download a browser accessibility testing tool for your browser: – Chrome: Accessibility Developer Tools – Firefox: Ainspector – IE (or Chrome): WAVE Evaluation Tool 2. Try to validate your company’s website – What did you find? 17.03.2017 / 45@IT_VEGARD / #BOOSTERA11Y
  46. 46. WHAT HAVE WE LEARNED?
  47. 47. Some useful resources • Difi: https://uu.difi.no/ • Blindeforbundet: https://www.blindeforbundet.no/universell-utforming • WCAG quick-reference: https://www.w3.org/WAI/WCAG20/quickref/ • Mozilla a11y resources: https://developer.mozilla.org/en- US/docs/Web/Accessibility • Integrating a11y in design: http://www.uiaccess.com/accessucd/ • Writing accessible HTML: https://medium.com/alistapart/writing-html-with- accessibility-in-mind-a62026493412 • WAI-ARIA: https://www.w3.org/TR/wai-aria/introduction • ARIA roles: http://www.informit.com/articles/article.aspx?p=2464970 • W3C a11y tutorials: https://www.w3.org/WAI/tutorials/ • Blindness statistics: https://nfb.org/blindness-statistics • WebAIM survey: http://webaim.org/projects/screenreadersurvey6/ • NVDA keyboard shortcuts: http://webaim.org/resources/shortcuts/nvda 17.03.2017 / 47@IT_VEGARD / #BOOSTERA11Y
  48. 48. THANK YOU FOR ATTENDING! 17.03.2017 / 48@IT_VEGARD / #BOOSTERA11Y

×