Digital Accessibility – An Introduction, presented by Joshua Randall to the Cleveland Accessibility Meetup on February 16, 2021

1. Digital Accessibility –
an introduction
by Joshua Randall
for the Cleveland Accessibility Meetup
February 16, 2021

2. The Always Asked For Slide Deck
tinyurl.com/A11yCLE2021Intro

3. Cleveland Accessibility Meetup
• Our mission: To raise awareness of digital
accessibility, inclusive design, and assistive
technologies in Northeast Ohio in a setting of
sharing, learning, and networking.
• Our leader: Tom Babinszki
• What we are: a Meetup to talk about accessibility
• What we are not: political, nor an advocacy organization

4. We can’t do this without YOU!
• Spread the word
• Suggest topics or events…
• … or better yet, organize or present
• Help us find sponsors
• Promote accessibility at your company or organization

5. And Now, Back to the Presentation
• 10 minutes – Introduction to Digital Accessibility
• 10 minutes – Assistive Technology Demos
• 20 minutes – the Web Content Accessibility Guidelines (WCAG)
• 5 minutes – Summary
• 5 minutes – Questions and Answers

6. Introduction

7. Disclaimers
• I am not a lawyer.
• This is an informational presentation, not a how-to.
• I need to explain this one weird abbreviation….

8. This One Weird Abbreviation…
accessibility
a + 11 letters + y
a11y

9. What are digital accessibility, inclusive design,
and universal design?
ADA or 508
conformance
web accessibility
digital accessibility
inclusive design
universal design
Source: adapted from Matt May, Adobe

10. What is digital accessibility?
Digital accessibility is the ability of a website,
mobile application, or electronic document to be
easily navigated and understood by a wide
range of users, including those users who have
visual, auditory, motor, or cognitive disabilities.
Source: Web Accessibility Initiative

11. What is inclusive design?
Inclusive design means design that considers
the full range of human diversity with respect to
ability, language, culture, gender, age, and other
forms of human difference.
Inclusive Design Principles are about putting
people first. It's about designing for the needs of
people with permanent, temporary, situational, or
changing disabilities.
Source: Inclusive Design Research Centre at OCAD U; inclusivedesignprinciples.org

12. Who is affected by digital accessibility?
17.6% of United States population, or over 55 million
people, have a severe disability according to Social
Security Administration definitions.
Out of all Americans surveyed,
• 5.1% have serious difficulty seeing.
• 7.1% have serious difficulty hearing.
• 2.1% have difficulty having their speech understood.
• 5.6% have difficulty grasping objects.
• 9.7% have cognitive difficulties.
Worldwide: about 15%, or over 1 billion people.
Sources: United States Census; World Health Organization; Bruce Tognazzini

13. How 15% compares to other minority groups
Races
• 13% Black or African American
• 6% Asian
Sources: United States Census; Wikipedia
Ethnicity
• 18% Hispanic or Latino
Web Browser Use
• 16% Safari
• 4.3% Firefox

14. Who is affected by digital accessibility?
Disabilities affect customers and employees.
All of us will be affected eventually.
Also think about temporary and situational
disabilities.
Sources: United States Census; World Health Organization; Bruce Tognazzini

15. Temporary and Situational Disabilities
 or anyone in bright sunlight
 or anyone who needs to
keep their volume down
Source: Microsoft inclusive design toolkit

16. Why should we care about accessibility?
• It’s the right thing to do.
• A11y improves your brand.
• A11y is a quality issue.
• A11y affects your business-to-business work.
• A11y helps with search engine optimization (SEO).
• A11y supports low-bandwidth users.
• A11y reduces legal risk.
Sources: Karl Groves; Seyfarth Shaw; David Berman; International Telecommunications Union; Jupiter Research;
American Federation for the Blind

17. Federal Title III & Web A11y Lawsuits (2013-2019)
2,722
4,436
4,789
6,601
7,735
9,936 10,206
ADA Title III Lawsuits Web Accessibility Lawsuits
Source: Seyfarth Shaw (adatitleiii.com), Level Access, and UsableNet
15 19 57
262
814
2,235
2,285

18. Legal Underpinnings of Accessibility
(totally not legal advice)
• 1990 – Americans with Disability Act passed
• Title III prohibits discrimination on the basis of disability in
the activities of “places of public accommodation”
(businesses that are generally open to the public).
• 2017 – Department of Justice (DOJ) withdraws rulemaking
• 2018 – DOJ letter to Congress writes that “absence of a specific
regulation does not serve as a basis for noncompliance”
• even though DOJ doesn’t specify WCAG, that’s no excuse
• 2019 Domino’s Pizza case
• 9th Circuit Court of Appeals says ADA covers sites and apps
• Supreme Court elects not to hear case (lower ruling stands)
• Outside the U.S.A. – WCAG are included in accessibility laws in
many countries (Canada, Australia, New Zealand, the E.U., etc.)

19. How to Sue Someone
(still not legal advice) (also please don't do this)
1. Pick an industry
2. Identify companies in that industry
3. Run a web accessibility tool on the web pages of those companies
4. Send a demand letter with a summary of the findings
5. Wait for responses
6. File a batch of lawsuits
Source: adapted from Seyfarth Shaw and Level Access presentation

20. Every part of an organization shares
responsibility for digital accessibility
Legal
Business
• sales, marketing, merchandizing, advertising, branding
User Experience
• user researchers, content strategists, interaction designers,
visual designers, usability testers, et al.
Content Authors
• anyone who uses a content management system (CMS)
Information Technology
• quality assurance (QA), business analysts (BAs), developers
• last but not least, and also… last but certainly not only

21. Assistive Technologies

22. Assistive Technology (AT) Overview
Software
• Screen Readers (Text-to-Speech)
• Voice Recog. (Speech-to-Text)
• Screen Magnifiers (virtual)
• Ergonomic Aids to avoid
Repetitive Strain Injury (RSI)
• Mind Mapping & Org. Aids
• Proofing Tools, Note-taking, and
Literacy Aids
• Optical Character Recog. (OCR)
• Software for creating Braille
• Software for creating and reading
sound files
Hardware
• Keyboards
• Mice & Pointing Devices
• Headsets, Mics & Recording
Devices
• Equipment to support hearing
impaired users (for F2F mtgs)
• Screen Magnifiers (physical)
• Large monitors and monitor arms
• Ergonomic Support Equipment
• Braille Devices
• Scanners
• Personal printers
• Hardware specifically to enable a
user to work while out of office

23. Assistive Technology Demos
Focus Indicator
sighted, keyboard only users (example: hand tremor)
Speech-To-Text (example: Dragon Naturally Speaking)
sighted users who can’t use a keyboard (example: paralysis)
Screen Reader (example: VoiceOver on iPhone)
non-sighted users (example: blindness)

24. Use Assistive Technologies Yourself
Keyboard
• browse only with keyboard (don’t use your mouse)
Mouse
• use in opposite hand
Pointing Device
• hold a pen in your mouth, or rubber band it to your hand
Screen Readers
• NVDA (best with Firefox) – nvaccess.org
• JAWS (best with Internet Explorer) – freedomscientific.com
• VoiceOver (MacOS and iOS) and Talkback (Android)
Screen Magnification
• built into most operating systems (ex. “Magnifier” in Windows)
• Magic or ZoomText

25. Web
Content
Accessibility
Guidelines

26. WCAG (Web Content Accessibility Guidelines)
Perceivable
1.1 Text Alternatives
1.2 Time-based Media
1.3 Adaptable
1.4 Distinguishable
Operable
2.1 Keyboard Accessible
2.2 Enough Time
2.3 Seizures
and Physical Reactions
2.4 Navigable
2.5 Input Modalities
Understand-
able
3.1 Readable
3.2 Predictable
3.3 Input Assistance
Robust
4.1 Compatible
Source: Web Accessibility Initiative (w3.org/WAI)
Version 2.0 since 2008
Version 2.1 in June 2018
(Version 2.2 working draft in August 2020)

27. WCAG (Web Content Accessibility Guidelines)
Perceivable
1.1 Text Alternatives
1.2 Time-based Media
1.3 Adaptable
1.4 Distinguishable
Operable
2.1 Keyboard Accessible
2.2 Enough Time
2.3 Seizures
and Physical Reactions
2.4 Navigable
2.5 Input Modalities
Understand-
able
3.1 Readable
3.2 Predictable
3.3 Input Assistance
Robust
4.1 Compatible
Source: Web Accessibility Initiative (w3.org/WAI)
…
2.4.6 Headings and Labels
2.4.7 Focus Visible
2.4 8 Location
…

28. The WCAG Documents Are Interrelated
Source: Web Accessibility Initiative (www.w3.org/WAI/intro/wcag20)

29. Example of a WCAG Success Criterion

30. WCAG Levels A, AA, and AAA
A – basic a11y
AA – address most
common barriers
AAA – highest
level of a11y
industry standard: WCAG 2.1 AA

31. WCAG: P for Perceivable
Perceivable
• Available to the senses (primarily vision and hearing)
either through browser, or through assistive
technologies (screen readers, magnifiers, etc.)
What To Do
• Text alternatives for images
• Captions and transcripts for video / audio
• Present content in different ways
• Design with proficient color contrast
• Avoid unnecessary movement or distractions
Source: Dennis Lembrée

32. WCAG: O for Operable
Operable
• Users can interact with all controls and interactive
elements using either mouse, keyboard, or AT.
What To Do
• All functionality available through keyboard
• User-controlled timing and limits
• Don’t cause seizures (don’t flash > 3 / sec)
• Multiple ways to determine where you are, to
navigate, and to find content
Source: Dennis Lembrée

33. WCAG: U for Understandable
Understandable
• Content is clear, unambiguous, and not confusing.
What To Do
• Use plain language (“writespeak”)
• Supplement text with illustrations, videos, etc.
• Consistent, obvious navigation and structure
• Pages operate in predictable ways
• Help users avoid and correct mistakes
Source: Dennis Lembrée

34. WCAG: R for Robust
Robust
• Wide range of technologies can access the content
(including both old and new UAs and ATs).
What To Do
• Provide name, role, value, and state for non-standard
user interface components
• Adhere to W3C standards
• Use semantic markup
• Use progressive enhancement
Source: Dennis Lembrée

35. WCAG Conclusion
WCAGuidelines, not WCARules
Use the WCAG Quick Reference…
w3.org/WAI/WCAG21/quickref
… or the WebAIM WCAG 2 Checklist…
webaim.org/standards/wcag/checklist

36. Summary

37. Summary
Accessibility is the right thing to do and part of quality.
Empathize with others. Disabilities affect everyone,
sometimes or eventually.
Assistive Technologies (ATs) help people use the web.
The Web Content Accessibility Guidelines (WCAG) are
the standards we follow.

38. Ready for more?
Web Accessibility Initiative (WAI), w3.org/WAI
Slack, web-a11y.slack.com
book recommendations
• Accessibility for Everyone, Laura Kalbag (2017, A Book Apart)
• A Web for Everyone, Sarah Horton and Whitney Quesenbery (2014, Rosenfeld)
• Inclusive Components, Heydon Pickering (2018, self published e-book)
• Inclusive Design Patterns, Heydon Pickering (2016, Smashing Magazine)
Twitter hashtag #a11y
many free webinars from the top consultancies
• Deque Systems
• Level Access
• The Paciello Group
• Tenon

39. Questions and Answers

40. Stuff to Read While I Take Questions
Want to take some next steps?
• Experience your site using assistive tech (keyboard, screen reader)
• Use WAVE, aXe, or similar on your website
• Understand the WCAG and ARIA
• Read a book (Accessibility for Everyone; Inclusive Design Patterns)
• Explore the Twitter hashtag #a11y
• Bake accessibility into your design process!

41. from the home office in Brooklyn, Ohio:
Top 10 A11y Things
(not on the W3C websites)
1. inclusive-components.design
2. BBC’s Mobile Accessibility Guidelines
3. WebAIM mailing list archive
4. ADATitleIII.com
5. Deque Systems
6. Level Access / Simply Accessible
7. The Paciello Group (TPG) / Interactive Accessibility (IA)
8. Tenon.io and Karl Groves’ blog
9. NVDA screen reader
10. WAVE tool

42. Name Dropping
in no particular order
Steve Faulkner (TPG, Technical Director)
Léonie Watson (consultant; formerly TPG, Dir. of Communication)
Henny Swan (TPG, author)
Heydon Pickering (consultant)
Dennis Lembrée (consultant; Deque; WebAxe)
Jennie Lay-Flurrie (Microsoft, Chief Accessibility Officer)
Karl Groves (consultant, Tenon founder)
Adrian Roselli (consultant)
Lainey Feingold (lawyer, author)
David Berman (consultant)

43. What You Can Do Today
1. Hide your mouse and navigate using keyboard only
2. Turn on high contrast mode
3. Turn off images
4. Verify that captions or transcripts exist for video / audio
5. Click on field labels
6. Turn off CSS (Cascading Style Sheets)
Source: “The 6 simplest accessibility tests anyone can do.” karlgroves.com

44. Appendices

45. HTML, CSS, JS, ARIA

46. HTML, CSS, JS, ARIA: The Acronyms
HTML:
HyperText Markup Language
CSS: Cascading Style Sheets
JS: JavaScript
ARIA:
Accessible Rich Internet Applications
Content,
Semantics
Style
to enhance
Behavior
Accessibility
helper

47. HTML, CSS, JS, ARIA: How They Fit Together

48. HTML: Semantics
Use HTML element that describes the content
(not the presentation)
Benefits of doing this:
• Accessibility
• Graceful degradation
• Future-proofing
• Easier to maintain
• Professionalism
• SEO (search engine optimization)

49. HTML: Foundational Advice
Use <strong>/<em> for importance or emphasis, not CSS.
Never use an element for its design; for example:
• Never use <blockquote> for the indent
• Never use <Hx> for size and bolding
Forms
• Placeholder text is not a substitute for labels
• If exactly one selection is required, use radio buttons,
not checkboxes
• Label the groups of radio inputs / checkboxes

50. CSS: Styling
Readability (text size, line length, white space, proximity)
Color Contrast (WCAG 1.4.3)
Ample Hit Areas (tap/touch targets)
(44x44 CSS px minimum)
Be careful with SVG and CSS-generated content
(support is inconsistent)

51. JavaScript (JS): Behavior
Don’t use it unless you need it
Always manage focus!
(essential for a11y and usability)
Tabindex
• 0 makes it tab-able
• -1 makes it tab-able only with JS
• otherwise, don’t use it (under normal circumstances)
Use native components when at all possible

52. Accessible Rich Internet Applications (ARIA)
The first rule:
If you can use a native HTML element or attribute instead
of an ARIA role, state, or property, then do so.
ARIA provides no functionality, so you must build it with
scripting.
3 main features of ARIA:
• roles override native role semantics.
− widget, landmark, document structure
• properties express characteristics or relationships of objects.
• states define current conditions or data values of an element.
More? patrickhlauke.github.io/aria/presentation

53. ARIA: A Simple Example (on a form field)
<label for=“address”>Address</label>
<input name=“address” id=“address”
type=“text” aria-describedby=“hintAddr”
/>
<p id=“hintAddr”>Your primary
residence.</p>
Address
“Your primary residence”

54. Putting (Most of) It Together
I’ll show you an example of accessible, well styled radio
buttons.
Please excuse the crudity of the model. I didn’t have time to
built it to scale nor to paint it.

55. Visual Design
Make a style guide.
• focus indicator, link styling, elements, widgets, etc.
Use elements properly.
• Links are not Buttons, and Buttons are not Links
HTML headings (H1 thru H6) aren’t for visual presentation.
They are for structure, like an outline.
Use labels on form fields, not placeholder text.
Are images decorative, or do they convey content?

56. Visual Design
Don’t embed text in images.
Appropriately use color.
• cannot use color alone to convey differences
• foreground to background contrast ratio must be at least 4.5 to 1
Never use carousels.
• terrible for usability
• terrible for accessibility
• terrible for click-through and conversion
Test your designs!

57. Front-End Development
The two most important resources:
• the WCAG themselves (w3.org/WAI/WCAG21/quickref)
• ARIA authoring practices (w3.org/TR/wai-aria-practices)
Dennis Lembrée, “Web Accessibility Training for
Developers” (eastersealstech.com/a11y)
Other great resources:
• W3C Web A11y Tutorials (w3.org/WAI/tutorials)
• Heydon Pickering’s inclusive-components.design
• A11y Style Guide & Pattern Library (a11y-style-guide.com)
• Dev’s Guide to Better A11y (tinyurl.com/24a11yDevGuide)
Test your code!

58. More Front-End Dev Resources
Patrick Lauke (of The Paciello Group) - epic 161 slide deck
patrickhlauke.github.io/aria/presentation
Marcy Sutton (of Deque Systems) – Egghead.io short
courses
egghead.io/courses/start-building-accessible-web-applications-
today
Udacity and Google – 2 week course
udacity.com/course/web-accessibility--ud891
Did I mention the Dennis Lembrée presentation? Because it’s
great.
eastersealstech.com/a11y

59. Wireframing

60. Interaction Design and Wireframing
What is the organizing principle for your site or app?
Keep your workflows logical and concise.
It’s never too early to think about how someone will
physically interact with your product, website, or app.
Wireframing
Aidan Tierney, “Early prevention of a11y issues” (SlideShare)
Stack Exchange: “Designing wireframes keeping a11y guidelines in
mind”
Test your prototypes!

61. What To Look For in Your Wireframes
Source: Aidan Tierney, “Early prevention of accessibility issues” (SlideShare)

62. Example: Airline Flight Booking App
Source: Tierney, “Early prevention of accessibility issues”

63. The Wireframe for the Flight Booking App
Source: Tierney, “Early prevention of accessibility issues”

64. Wireframing Exercise
You’ll work as one big group.
6-7 minutes: review the wireframe, keeping in mind the
principles we’ve discussed.
You can refer to the WCAG or other resources (but don’t
look up Aiden Tierney’s source presentation).
2 minutes: report out.
1 minute: the answers (?)

66. Example of a Wireframe with A11y Notes
Source: Tierney, “Early prevention of accessibility issues”

67. Accessibility During
the Design Process

68. A Design Process
• Design Strategy
− a brief detour into Inclusive Design
• Content Strategy and Content Authoring
• User Research and Usability Testing
• Interaction Design and Wireframing
• Visual Design
• Front-End Development
− a brief detour into ARIA (Accessible Rich Internet
Applications)
• Quality Assurance

69. What kind of old-fashioned process is this?!

70. Quality Assurance
Testing Approach: you’re doing it wrong.
• You must shift your testing upstream.
• You must do manual testing, in addition to automated testing.
Testing Tools
• WAVE (Web Accessibility Evaluation tool, by WebAIM)
• aXe (Accessibility Engine, by Deque Systems)
• IA Toolkit (by Interactive Accessibility)
• Tenon.io
• W3C’s HTML validator (validator.w3.org)
− because proper markup is inherently accessible
Use those assistive technologies!
Source: Karl Groves, “Everything you know about accessibility testing is wrong” (karlgroves.com/blog)

71. Testing for Accessibility
The best testing tool is your keyboard.
Source: Elle Waters, “Lean Accessibility”, Level Access webinar, 31 July 2018
Lean UX testing:
1. Contrast
2. Images
3. Structure
4. Proximity
5. Everything else
Lean dev testing:
1. Keyboard handling
2. Images
3. Forms
4. Dynamic content
5. Everything else
Start as novices; learn as you go.
Automate what can be automated from the beginning.

72. User Research and Usability Testing
Recruitment of people with disabilities (PWD):
challenging, but worth it.
− disability advocacy orgs, universities, social media,
perhaps your friendly local accessibility meetup
Include PWD in your user research.
− as early as possible
− focus groups, card sorts, user interviews, contextual inquiry
− go to them
Include people of varying abilities in your personas.
− search “Personas for Accessible UX” (sourced from A Web for
Everyone by Horton and Quesenbery)
− Design for Real Life by Eric Meyer and Sara Wachter-
Boettcher

73. Personas should be diverse

74. Design Strategy
“Behind every great site or app lies thought, empathy,
and inclusion. This doesn’t happen by accident; it
happens by design.” (Henny Swan)
Who is your target audience?
Good design is still good design.
• Useful (Dieter Rams #2)
• Understandable (Rams #4)
• Unobtrusive (Rams #5)
• As little as possible (Rams #10)

75. Inclusive Design Principles
1. Prioritize content
2. Consider situation
3. Be consistent
4. Give control
5. Offer choice
6. Provide comparable experiences
7. Add value
Source: inclusivedesignprinciples.org

76. Content Strategy and Content Authoring
Content is still king.
• Write the way you would speak, say what you mean,
avoid jargon.
Content authors are responsible for words.
• anything visually-hidden, form fields, transcripts
and captions, alt-text, headings, link labels, button
labels
“Accessibility as an Editorial Task”, Corey Vilhauer
Test your content!

77. Interaction Design and Wireframing
What is the organizing principle for your site or app?
Keep your workflows logical and concise.
It’s never too early to think about how someone will
physically interact with your product, website, or app.
Wireframing
• Aidan Tierney, “Early prevention of a11y issues” (SlideShare)
• Stack Exchange: “Designing wireframes keeping a11y guidelines in mind”
Test your prototypes!