Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Joe Ortenzi: Inclusive Design for WordPress

Joe Ortenzi: Inclusive Design for WordPress

Carrying on from my presentation at WordCamp Sydney 2012, where I introduced Inclusive Design to an enthusiastic audience, this presentation aims to be more specific about how to apply accessibility principles across the WP spectrum, for designers, content authors and developers. I will present specific methods for creating accessible content and keeping it accessible, particularly for eCommerce, government and transactional sites.

073054d5848746e939c7165bc90a507b?s=128

WP Australia

April 28, 2013
Tweet

Transcript

  1. Inclusive Design

  2. WTF is

  3. what

  4. None
  5. None
  6. None
  7. what is inclusive?

  8. None
  9. None
  10. None
  11. accessibility a11y accessibility #a11y

  12. why is a11y

  13. “The UN Convention on Rights of Persons with Disabilities (2008)

    declares that Disability is a human rights issue and not a matter of discretion. The UN Convention affirms that all persons with all types of disabilities must enjoy all human rights and fundamental freedoms. The outcomes of the project are designed to uphold and promote the human rights of disabled people as enshrined in national and international law.”
  14. bad for business

  15. WCAG 2.0

  16. Perceivable Operable Understandable Robust 4 Guidelines 4 Guidelines 3 Guidelines

    1 Guideline 22 Criteria 20 Criteria 17 Criteria 2 Criteria
  17. Level AAA – 23 criteria Level AA – 13 criteria

    Level A - 25 criteria
  18. Visual map of Web Content Accessibility Guidelines 2.0 Designed by

    Stamford Interactive www.stamfordinteractive.com.au Based on World Wide Web Consortium documentation available at www.w3.org/TR/WCAG20 Licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License WCAG 2.0 Map V1.4 © 2012 Stamford Interactive WCAG 2.0 Map WCAG 2.0 4.1 Compatible 3.3 Input Assistance 3.2 Predictable 3.1 Readable Perceivable: Information and user interface components must be presentable to users in ways they can perceive. Operable: User interface components and navigation must be operable. Robust: Content must be robust enough that it can be interpreted reliably by a wide variety or user agents, including assistive technologies. Understandable: Information and the operation of user interface must be understandable. 1.4.1 Use of Colour 1.4.2 Audio Control 2.1.3 Keyboard (No exception) 2.1.1 Keyboard 2.1.2 No Keyboard Trap 2.2.1 Timing Adjustable 2.2.2 Pause, Stop, Hide 2.2.3 No Timing 2.2.4 Interruptions 2.2.5 Re-authenticating 2.3.1 Three Flashes or Below Threshold 2.3.2 Three Flashes 2.4.8 Location 2.4.9 Link Purpose (Link Only) 2.4.10 Section Headings 2.4.5 Multiple Ways 2.4.6 Headings and Labels 2.4.7 Focus Visible 2.4.1 Bypass Blocks 2.4.2 Page Titled 2.4.3 Focus Order 2.4.4 Link Purpose (In Context) 1.1.1 Non-text Content 1.2.1 Audio-only and Video Only (Pre-recorded) 1.2.2 Captions (Pre-recorded) 1.2.3 Audio Description 1.2.4 Captions (live) 1.2.5 Audio Description 1.2.6 Sign Language 1.2.7 Audio Description (Extended) 1.2.8 Full text alternative 1.2.9 Live Audio-only 1.3.1 Info and relationships 1.3.2 Meaningful Sequence 1.3.3 Sensory characteristics 1.4.3 Contrast (Minimum) 1.4.4 Resize Text 1.4.5 Images of Text 1.4.6 Contrast (Enhanced) 1.4.7 Low or No Background Audio 1.4.8 Visual Presentation 1.4.9 Images of text (No exception) 4.1.1 Parsing 4.1.2 Name, Role, Value A A A A A A A AA AA AAA AAA AAA AAA AA A A Principle WCAG 2.0 Map Key Guideline Success Criteria A 3.3.5 Help 3.3.6 Error Prevention (All) 3.3.3 Error Suggestion 3.3.4 Error Prevention (Legal, Financial Data) 3.1.3 Unusual Words 3.1.4 Abbreviations 3.1.5 Reading Level 3.1.6 Pronunciation 3.3.2 Labels or Instruction 3.2.3 Consistent Navigation 3.2.1 On Focus 3.2.2 On Input 3.2.5 Change on request 3.1.1 Language of Page 3.1.2 Language of Parts AAA AA A A A AAA AAA AA AA AAA AAA 1.2 Time Based Media 1.3 Adaptable 1.4 Distinguishable 1.1 Text Alternatives Understandable Robust 2.4 Navigable 2.3 Seizures 2.2 Enough time 2.1 Keyboard Accessible Perceivable Operable
  19. None
  20. how inclusive is WordPress?

  21. None
  22. quick wins

  23. alt=“”

  24. alt text to all images

  25. use headings and semantic markup

  26. None
  27. <b> or <strong>?

  28. skip to content

  29. link context •  A link should still be meaningful out

    of context •  A text link should be unique to the page on which it appears (i.e. don’t use the same link text for different resources) •  Never use “Click here” or “More” for link text •  Do not use a long URL for link text (screen readers will read it all out and annoy the user).
  30. link context Not helpful: •  To read more about awesome

    polar bear disguises, click here. •  To find out the 47 ways I can save you verbosity, click here. •  There’s loads of info at http://typingthevoid.com/inclusive-design/ Better: •  I wrote a post about awesome polar bear disguises. •  I spent a very long time researching the 47 ways you can reduce your verbosity. •  Joe has a long list of Inclusive design resources on his website
  31. don’t f#@k with nature

  32. don’t f#@k with nature •  preserve browser’s ability to show

    focus •  let links look like links, not hide and seek •  Don’t break browser history •  Preserve the document order in the visual presentation •  format text using em not px
  33. harder stuff

  34. Forms

  35. inform and assist

  36. honour HTML •  Use <button> or <input type=”button”> •  Ensure

    all form fields have meaningful labels and instructions before the field. •  Return focus to the first error message onError •  Ensure error messages are available to keyboard-navigating users •  don’t be captured by CAPTCHA !!
  37. Completely Automated Public Turing test to tell Computers and Humans

    Apart
  38. ?

  39. There are alternatives! TextCAPTCHA The last letter in “unrolled” is?

    4 plus two is what? Which of 3, twenty-nine, 70, 46 or 65 is the lowest? I have two, you have 2. How many is that?
  40. not everyone uses a mouse

  41. •  Do not use the double-click handler (onDblClick) because keyboards

    cannot execute this behavior. •  If you use the onMouseOver and onMouseOut JavaScript handlers, also use onFocus and onBlur to accommodate keyboards. •  If you must use JavaScript, then give the link a tabindex value of -1 to insert it in the tab order. A tabindex of 0 makes even divs accessible to the keyboard Keyboard usable
  42. None
  43. audio or video •  Full text version of all speech

    •  Captions, synchronised to the video •  Audio descriptions of events not spoken •  Text descriptions of sounds containing meaning
  44. test as a user •  use automated tests, but don’t

    rely on them •  navigate by keyboard •  run guerrilla test at a local meetup •  spend a day learning VoiceOver, or NVDA •  send your site out to online test services
  45. test test test test test test test test test test

    test test test test test test test test test test
  46. learn more •  WCAG 2.0: http://www.w3.org/TR/WCAG20/ •  Access-iQ: http://accessiq.org/ • 

    The Paciello Group Blog: http://blog.paciellogroup.com/ •  WordPress Codex Theme review: http://codex.wordpress.org/Theme_Review#Accessibility •  Make WordPress Accessible: http://make.wordpress.org/accessibility/useful-tools/ •  alt text decision tree: http://dev.w3.org/html5/alt-techniques/developer.html#tree •  My inclusive design resources list: http://typingthevoid.com/inclusive-design
  47. credits All images the author’s own, except for: 3, 6,

    16: Failblog.org: http://failblog.org 4, 5: Universal Design Style: http://www.universaldesignstyle.com 7: wikipedia: accessibility 8: Adactio on Flickr: http://www.flickr.com/photos/adactio/89778576 11 http://lawblogone.wordpress.com/tag/politiko/ 14: http://www.flickr.com/photos/inkytwist/4735121790/sizes/o/in/photostream/ 21: Web Standards Project: http://webstandards.org 35: YouTube HTML 5 project: http://youtube.com/html5
  48. ? Joe Ortenzi @wheelyweb typingthevoid.com