The document provides an overview of prototyping accessibility for a workshop presentation. It includes instructions for group exercises to prototype user interface elements and develop personas. It also covers various accessibility topics like disability types, user experience models, technical accessibility standards around text alternatives, typography, links, color contrast, labeling fields, document structure, and keyboard/screen reader support. The goal is to educate attendees on inclusive design practices through hands-on exercises and discussions.

1. Prototyping Accessibility
Presented by Adrian Roselli for Booster 2019
Slides from this workshop will be available at rosel.li/booster19

2. PLEASE BREAK INTO GROUPS OF FIVE (5)
Stragglers may be assigned a group.

3. Introductions

4. • I’ve written some stuff,
• Member of W3C,
• Building for the web
since 1993,
• Learn more at
AdrianRoselli.com,
• Avoid on Twitter @aardrian.
About Adrian Roselli

5. Group Exercise!

6. Group Exercise!
• Decide on a user interface element. Examples:
• Login form,
• Disclosure widget,
• Data grid,
• Search,
• etc.
• Quickly describe or draw it on paper (no code).
• 15 minutes.

7. Primer

8. What is a11y?
• A numeronym for “accessibility”:
• The first and last letter (accessibility),
• The number of characters omitted (a11y).
• Prominent on Twitter (character restrictions):
• #a11y
• Examples:
• l10n → localization
• i18n → internationalization

9. Disability is not just a health problem. It is
a complex phenomenon, reflecting the
interaction between features of a person’s
body and features of the society in which
he or she lives.
— World Health Organization

10. Agenda
 Exercise: UI Component
• Primer
• Disability Types
• Who Else?
 Exercise: Overlapping Needs
• User Experience Models
 Exercise: Proto-Persona
• Technical Bits
 Exercise: Prototype
• Wrap-up

11. Disability Types

12. Disability Types
• Physical
• Epilepsy
• Mobility
• Fine motor skills
• Hearing
• Deaf
• Hard of Hearing
• Vision
• Color blindness
• Low vision
• Blind
• Cognitive
• ADD/ADHD
• Autism
• Dyslexia/Dyscalculia
• Learning and Language
• Speech
• Stuttering
• Non-verbal
• Cluttering
• Apraxia of speech (AOS)

13. Disability Types
• Blindness
• Low Vision (including color blindness)
• Deaf and Hard of Hearing
• Speech
• Physical
• Intellectual & Cognitive

14. Blindness
• Screen reader user
• Keyboard-only user
• Relies on:
• Headings
• Form Elements
• Links
• Landmarks

15. Low Vision
• May use high contrast modes
• May not be able to differentiate colors
• May scale fonts
• May use a screen magnifier
• May use a screen reader
• Relies on:
• Scaling fonts
• Good contrast

16. Deaf and Hard of Hearing
• Cannot hear audio cues
• Will struggle if captions are not synchronized
• First language may be sign language
• Relies on:
• Good captions
• Visual cues
• Color cues
• Haptic cues

17. Speech
• May speak less clearly
• May be non-verbal
• Can be stymied by voice interfaces
• Phone interaction may not be possible
• May use assistive technology
• Relies on:
• Other interactions

18. Physical
• Temporary to permanent
• Slight to severe
• Can change throughout a day
• May use specialized hardware
• May use a screen reader
• May use dictation software
• Relies on:
• Generous hit areas
• Simple interactions

19. Intellectual & Cognitive
• May use a screen reader
• May use dictation software
• May benefit from any/all considerations already listed
• Relies on:
• Well-structured content
• Plain language
• Good context

20. Who Else?

21. Everyone Else!

22. Getting Older
• Affects (nearly) everyone,
• Carries risks and side effects,
• Is not for the young.

23. Rising Damp on Flickr.

24. Darren Baldwin on Flickr.

25. Accidents
• Broken limbs,
• Eye injuries,
• Hearing injuries,
• Head trauma.

26. Rev Stan on Flickr.

27. Let Ideas Compete on Flickr.

28. Paul Townsend on Flickr.

29. But I’m Invincible!
• Multi-tasking,
• Sunlight,
• Eating at your desk,
• No headphones handy,
• Content is not in your native language.

30. Mariëlle on Flickr.

31. Seb on Flickr.

32. Steve Rhodes on Flickr.

33. SuperFantastic on Flickr.

34. Lars Kristian Flem on Flickr.

35. Tech Support
• Think of your family!
• Think of your time spent helping them!
• Think of the wasted holidays!

36. Robert Simmons on Flickr.

37. Group Exercise!

38. Group Exercise!
• Each person in your group must pick a disability type:
1. Low vision
2. Blindness
3. Hearing and Speech
4. Physical
5. Cognitive
• Within your group, discuss where each of your types overlap in:
• Barriers, abilities, needs, etc.
• 15 minutes.

39. User Experience Models

40. Personas
Book Excerpt: A Web for Everyone, by Sarah Horton, Whitney Quesenbery

41. Personas
Adrian
• Works when he should be relaxing, relaxes when he should be
working.
• Lives between motorcycles.
• Works late at night with the TV on.
• Uses sub-titles in Netflix.
• Keeps all screens as dark as possible.

42. User Stories
• Components:
• User,
• Outcome,
• Value.
• Writing:
• As user, I want outcome.
• As user, I want outcome so that value.
• In order to get value as user, I want outcome.

43. Selfish User Stories
• As a user on a sun-lit patio, I want to be able to read the
content and see the controls.
Add beer and as a user I may have trouble focusing.

44. Selfish User Stories
• As a user in bed with a sleeping spouse, I want to watch a
training video in silence so that I can get caught up at work.
As a user who doesn’t want to get punched for having slacked off at work.

45. Selfish User Stories
• In order to click links as a user with no elbow room in coach
class with a tiny trackpad, I want click areas to be large enough
and adequately spaced.
As a user in coach class who also paid too much for the drink he’s spilling on his keyboard.

46. Selfish User Stories
• As a user distracted by the TV, I want clear headings and labels
so that I don’t lose my place.
As a user who really should be finishing his work in the office.

47. Group Exercise!

48. Group Exercise!
• Develop a (proto-) persona.
• Develop user stories for your persona.
• As user, I want outcome.
• As user, I want outcome so that value.
• In order to get value as user, I want outcome.
• Consider the UI element you created.
• 15 minutes.

49. Technical Bits

50. Text Alternatives for Images
• Can you still make sense of the page?
• Is content missing?
• Can you still use the site?
• Is your alt text useful?
• Do you account for CSS background images?
• What about SVGs?
• Or CSS-generated symbols / icons?
http://www.4syllables.com.au/2010/12/text-alternatives-decision-tree/
http://dev.w3.org/html5/alt-techniques/#tree

51. Text Alternatives for Images

52. Text Alternatives for Images

53. Typography Matters
• Leading / line height at least 1.5× font size (WCAG 2.1),
• Space after paragraphs at least 2× font size (WCAG 2.1),
• Letter spacing / tracking at least 0.12× font size (WCAG 2.1),
• Word spacing at least 0.16× font size (WCAG 2.1),
• Avoid justified text,
• Avoid italics,
• Use larger text (lean on browser default),
• Use good contrast,
• Use clear, concise writing.

54. Typography Matters

55. Hyperlinks!
• Is there any “click here,” “more,” “link to…”?
• Are you using all-caps, URLs, emoticons?
• Do you warn before opening new windows?
• Do links to downloads provide helpful info?
• Are you using pagination links?
• Are your links underlined (or otherwise obvious)?
• Is there alt text for image links?
• Is the link text consistent?

56. Hyperlinks!
• You are not Google:
• Users know Google’s layout,
• Users probably don’t visit your site daily.
• Relying on color alone will not suffice (WCAG 1.4.1 [A], 1.4.3 [AA]),
• Necessary contrast values:
• 4.5:1 between text and its background for copy,
• 3:1 between text and its background for larger text,
• 3:1 between surrounding text and a hyperlink, plus an additional visual cue
(G183).
http://adrianroselli.com/2014/03/i-dont-care-what-google-did-just-keep.html

57. Hyperlinks!
http://www.sitepoint.com/15-rules-making-accessible-links/

58. Hit Areas
• Make areas large enough to tap,
• Leave space between hit areas to avoid mis-taps/clicks,
• Fitts’ Law (time to target as function of size of target),
• Apple: 44pt × 44pt,
• Microsoft: 48px × 48px (spaced 2mm apart),
• Android: 48dp × 48dp (spaced 8dp apart),
• BBC: 7mm × 7mm (inside an exclusion zone of at least 7mm × 7mm)
• WCAG 2.1 Success Criterion 2.5.5 Target Size (AAA).

59. Hit Areas

60. Hit Areas

61. Hit Areas

62. Hit Areas

63. Color Contrast
• Is there enough contrast?
• Are hyperlinks, menus, etc. still visible?
• WCAG 2.0:
• 4.5:1 for normal text
• 3:1 for large text (14+pt & bold, or 18+pt)
• WCAG 2.1:
• 3:1 for UI components, graphical objects

64. Color Contrast
• WCAG 2.1 has broadened it,
• Typography,
• Icons and glyphs,
• Form elements, error messages,
placeholders,
• Hover, focus, selected states.

65. Label Your Fields
• Provide instructions for the entire form,
• Provide a programmatic indication of required fields,
• Provide formatting advice,
• Use ARIA to associate formatting advice,
• Avoid placeholder text,
• Associate error messages with fields.

66. Label Your Fields
• Match the for attribute to the corresponding field’s id
attribute.
• Label text provides a larger hit area for mouse / touch,
• Label text should appear above or the left of text inputs or
menus (for LTR languages),
• Label text should appear after checkboxes / radio buttons (for
LTR languages).
• Label grouped fields (<fieldset> / <legend>)

67. Label Your Fields

68. Structure Your Document
• Sectioning elements already have accessibility built in. Use
them.
• <header>
• <nav>
• <main> (one per page)
• <aside>
• <footer>
• <form> (a search form)

69. Structure Your Document

70. Structure Your Document
<header role="banner">
<nav role="navigation">
<aside role="complementary">
<form role="search">
<footer role="contentinfo">
<main role="main">

71. Structure
Your
Document
“Mobile” often means narrow screen
in RWD, as well as this context.

72. Structure
Your
Document
<header role="banner">
<nav role="navigation">
<aside role="complementary">
<form role="search">
<footer role="contentinfo">
<main role="main">
“Mobile” often means narrow screen
in RWD, as well as this context.

73. Structure Your Document
• Use only one <h1> per page,
• Don’t skip heading levels,
• Use appropriate nesting,
• There is no Document Outline Algorithm:
• Don’t use <h1> within every new <section> nor <article>,
• This will not affect your SEO.
http://adrianroselli.com/2013/12/the-truth-about-truth-about-multiple-h1.html

74. Structure Your Document

75. Structure Your Document
1. Ordered lists
2. …
3. …
Description lists
As statement and
their description
Key
Value
• Unordered lists
• …
• …

76. Structure Your Document
1. Boil water
2. Add pasta
3. Drain water
Pasta
1 pound
Water
4 quarts
Olive oil
Not 4 quarts
• Pasta
• Water
• Olive oil

77. Display vs Source Order
• CSS techniques allow visual order to break from DOM order:
• Floats,
• Absolute positioning,
• Flexbox (see 5.4.1 of ED for a11y note),
• Grid (read Rachel Andrew on subgrid).
• WCAG 1.3.2 and 2.4.3 describe meaningful sequence and tab
order matching visual flow,
• Different behavior among different browsers, MQs.
http://adrianroselli.com/2015/09/source-order-matters.html
http://200ok.nl/a11y-flexbox/

78. Display vs Source Order
http://codepen.io/aardrian/full/MavVeb/
Firefox
Chrome

79. Be Keyboard Friendly
• tabindex="-1"
• Use to set focus with script,
• Does not put it in tab order of page.
• tabindex="0"
• Allows user to set focus (eg: via keyboard),
• Puts in tab order of page (based on DOM).
• tabindex="1" (or greater)
• Do not do this,
• Messes with natural tab order.
http://adrianroselli.com/2014/11/dont-use-tabindex-greater-than-0.html

80. Be Keyboard Friendly
https://www.digitalgov.gov/2014/11/17/user-experience-impossible-the-line-between-accessibility-and-usability/

81. Be Keyboard Friendly
• Do you have scrolling content boxes?
• Keyboard users cannot access it.
• Do you have content that displays on hover?
• Keyboard users probably cannot access it.
• A technique:
• <div role="region" aria-label="[if appropriate]"
tabindex="0">
http://adrianroselli.com/2016/02/keyboard-and-overflow.html

82. Be Keyboard Friendly
http://adrianroselli.com/2016/02/keyboard-and-overflow.html

83. Be Keyboard Friendly
http://adrianroselli.com/2016/12/accessible-emoji-tweaked.html

84. Be Keyboard Friendly
• Do not use a <div> nor <span> as a control.
• Does the control take me to another URL?
• Use an <a href>.
• Note: does not fire on space-bar.
• Does the control change something on the current page?
• Use a <button type="button">.
• Does the control submit form fields?
• Use <input type="submit"> or <button type="submit">.
http://adrianroselli.com/2016/01/links-buttons-submits-and-divs-oh-hell.html

85. Be Keyboard Friendly
http://adrianroselli.com/2016/01/links-buttons-submits-and-divs-oh-hell.html

86. Be Keyboard Friendly
• Define :focus styles,
• Particularly if you removed link underlines,
• Everywhere you have :hover, add :focus,
• Look for :focus{outline:none;} in libraries:
• If you find it, remove it.
• Do not rely on browser defaults,
• Easy to test with the tab key.
http://adrianroselli.com/2014/06/keep-focus-outline.html

87. Be Keyboard Friendly

88. Be Keyboard Friendly
https://www.virginamerica.com/

89. Use Captions, Subtitles, Transcripts
• Everybody uses them:
• Working in public, in bed, at home,
• Surfing in public, in bed, at work.
• Should include audio descriptions,
• Should include speaker identification,
• Review auto-captions (“craptions”):
• NoMoreCraptions.com
http://adrianroselli.com/2013/11/captions-in-everyday-use.html

90. Use Captions, Subtitles, Transcripts
• Do video/audio clips have text alternatives?
• Are links to closed-captions or transcripts built into the player or
separate text links?
• Is there an audio description available?
• Tools:
• Media Access Australia YouTube captioning tutorial, Vimeo captioning
tutorial,
• Tiffany Brown’s WebVTT tutorial,
• DIY Resources for Closed Captioning and Transcription from 3 Play Media.
http://webaim.org/techniques/captions/

91. Use Captions, Subtitles, Transcripts
https://www.youtube.com/watch?v=V592VMJeXc8

92. Pattern Libraries
• Document all this for your custom widgets,
• Use this to build a larger pattern library,
• For many custom widgets: WAI-ARIA Authoring Practices 1.1,
• It is not perfect, but gets you started,
• Be wary of application-specific patterns.
• For truly custom widgets you have never seen before, consider
simplifying to an existing pattern.

93. Tab order indicated via numbers above
Accessibility requirements
See 3.1 Accordion in the WAI ARIA Authoring
Practices for requirements.
Focus and keyboard tab order
• Left/Up arrow moves to previous accordion
header
• Right/down arrow moves to next accordion
header
• Enter opens a panel when on the header
• When opened focus stays on the element, tab
moves to the first item in the header
Roles and states
• Accordion is a tablist
• Each header is a tab
• Use visibility hidden to hide content of tabs
Behavior
• Contents of accordion hidden from screen readers
when closed
• Contents remain open until closed by the user
• Header and arrow is a single touch target

96. Group Exercise!

97. Group Exercise!
• Take your user interface element and discuss how you might
design / spec / build / code it.
• Represent the disability category you championed earlier.
• Remember your personas, user story/ stories.
• Consider changing needs of users.
• 15 minutes

98. Wrap-up

99. Stairamp
Dean Bouchard on Flickrhttp://accessibility.net.nz/blog/the-problems-with-ramps-blended-into-stairs/

100. ≠ Checklist
• Accessibility is not a checklist.

101. Maintenance
Nicolas Steenhouthttps://twitter.com/vavroom/status/571092086365261824
“Wheelchair ramp at
pharmacy not only
hasn’t been cleared of
snow but has 2 potted
trees to ensure nobody
can pass.”

102. = Process
• Accessibility is not a checklist.
• Accessibility is an ongoing process.

103. Prototyping Accessibility
Presented by Adrian Roselli for Booster 2019
Slides from this workshop will be available at rosel.li/booster19