The document provides an introduction and agenda for the Cleveland Accessibility Meetup on January 15, 2020. The summary includes: - The meetup aims to raise awareness of digital accessibility, inclusive design, and assistive technologies in Northeast Ohio through sharing, learning, and networking. It is led by Melanie Bozzelli and Joshua Randall. - Upcoming meetup events are listed from February to December 2020, covering topics like lean accessibility, global accessibility awareness day, and inclusive design. - The presentation agenda includes introductions to digital accessibility and assistive technologies, demonstrations of assistive technologies, an overview of the Web Content Accessibility Guidelines, and a question and answer session.

1. Digital Accessibility –
an introduction
by Joshua Randall
for the Cleveland Accessibility Meetup
January 15, 2020

2. 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 leadership: Melanie Bozzelli (and Joshua Randall)
• What we are: a monthly (ish) Meetup to talk about accessibility
• What we are not: political, nor an advocacy organization

3. Upcoming Events
• February 12: Lean Accessibility (with Cleveland Agile Group)
• March: …
• April: …
• May 21: Global Accessibility Awareness Day (Progressive)
• June: …
• July: ----- (summer break)
• August: …
• September: …
• October : Inclusive Design 24
• November: …
• December: ----- (winter break)

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. Introduction: 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

10. Introduction: Obligatory Venn(ish) Diagram
ADA or 508
conformance
web accessibility
digital accessibility
inclusive design
universal design
Source: Matt May, Adobe

11. Who is affected by digital accessibility?
15.3% of United States population, or almost 50 million
people, have a disability that could affect their use of digital
products.
• 6.2% have difficulty hearing or seeing.
• 2.8% have difficulty grasping objects.
• 6.3% have cognitive difficulties.
Worldwide: also 15%, or over 1 billion people.
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

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

13. 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

14. ADA Title III Lawsuits, and Web Accessibility
Lawsuits, Brought in Federal Court (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,2352,285

15. 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.)

16. 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

17. 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

18. Assistive Technologies

19. 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

20. 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)

21. 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

22. Web
Content
Accessibility
Guidelines

23. 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

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

25. Example of a WCAG Success Criterion

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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
… or the Interactive WCAG (filter by role)
code.viget.com/interactive-wcag

32. Summary

33. 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.

34. 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 hashtags #a11y and #A11yCLE
many free webinars from the top consultancies
• Deque Systems
• Level Access
• The Paciello Group
• Tenon

35. Questions and Answers

36. 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 hashtags #a11y and #A11yCLE
• Bake accessibility into your design process!

37. 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

38. 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)

39. 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

40. HTML, CSS, JS, ARIA

41. 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

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

43. 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)

44. 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

45. 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)

46. 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

47. 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

48. 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”

49. 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.

50. 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?

51. 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!

52. 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!

53. 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

54. Wireframing

55. 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!

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

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

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

59. 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 (?)

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

62. Accessibility During
the Design Process

63. 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

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

65. 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)

66. 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.

67. 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

68. Personas should be diverse

69. 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)

70. 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

71. 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!

72. 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!