Presented by Dennis LembréeMay 9, 2018

INDATA

Web Accessibility Training

for Developers

Agenda 1/2

• About @DennisL

• About You

• Intro to Accessibility

▫ Disability & AT

▫ Business Case

▫ Guidelines & Law

▫ POUR

• Web Dev Foundations

▫ 4 Layers

▫ Semantics & Order

▫ Other

• Techniques

▫ Layout/Structure

▫ Headings

▫ Images/Alt Text

▫ Forms

▫ Links

▫ Keyboard Access

▫ Tables

▫ Audio & Video

▫ About Flash

▫ About Validation

2

• Techniques cont.

▫ Design & CSS

▫ JavaScript

▫ Single Page Apps (SPAs)

▫ ARIA

Agenda 2/2

• Writing

• Testing

• Checklists

• Tools

• Manual Techniques

• Screen Readers

• HCM

• More Tips

• Resources

• Contact

• Questions

3

About @DennisL

• Senior Accessibility Consultant at Deque Systems

• Formerly on eBay and PayPal accessibility teams.

• Author of @EasyChirp and @WebAxe.

• Presented at CSUN, AHG, HTML5 Dev Conf, CSS Dev Conf, AccessU, Accessibility Summit, etc.

4

About You

• Number attending?

• How many a developer, designer, accessibility specialist, or other?

• Years of experience?

5

About Accessibility

• Disability & Assistive Technology (AT)

• Business Case

• Guidelines & Law

• POUR

6

About Accessibility

• Global Accessibility Awareness Day

• Next Thursday, May 17

• http://www.globalaccessibilityawarenessday.org

• @gbla11yday #GAAD

7

About Accessibility – Disability & AT

• Visual

• Blindness, low vision, colorblindness

• Audio

• Deafness, HOH

• Motor

• Limited ability to use a mouse or keyboard, slow response time, limited fine motor control

• Cognitive

• Learning disabilities, reading level, impaired memory

• Neurological

• Prone to seizures due to flashing

8

About Accessibility – Disability & AT

• Temporary disabilities:

• Hand in cast

• Pupils dilated at optometrist

• Ear infection

• (or went to loud concert the night before!)

• Laryngitis

• Very fatigued

• Situational disabilities:

• Broken mouse, speakers

• Carrying baby

• Sunlight

• Loud train

• Distracted by pets, telemarketer

• Low-band connection

9

About Accessibility – Disability & AT

• Inclusive Design at Microsoft + Manual

• https://www.microsoft.com/en-us/design/inclusive

10

About Accessibility – Disability & AT

• 2 videos:

• Computers and People with Sensory Impairments

• Computers and People with Mobility Impairments

11

About Accessibility – Disability & AT

• Assistive Technology - Visual

• Eye glasses

• High-contrast mode

• Screen magnifier

• Screen reader

• Braille display

12

About Accessibility – Disability & AT

• Assistive Technology - Audio

• Hearing aid

• Transcriptions

• Captions

• CART (live transcription)

13

About Accessibility – Disability & AT

• Assistive Technology - Motor

• Alternative keyboard (high-contrast, large keys)

• Onscreen keyboard

• Alternative mouse

• Switches (button, sip-puff, eye-blink)

• Mouth stick

• Head wand

14

About Accessibility – Disability & AT

• Assistive Technology - Cognitive

• Speech recognitionEx: Dragon NaturallySpeaking

• Alternative and Augmentative Communication (AAC)Ex: Proloquo2Go

• Screen readers

• Reader view modes & screen magnifiers

• (to reduce distraction)

• Word prediction

• Talking calculators

• Timers and to-do lists

15

About Accessibility – Disability & AT

• Assistive Technology - Voice Recognition

• Echo, Siri, Google Home, etc.

• People with visual disabilities (typing on touch device)

• People with physical disabilities

• People with cognitive disabilities

• Convenience!

• NOTE:These services should also provide a text input alternative for people with a speech impairment.

16

Check on Learning

• What are the 5 types of disability?

• What are some examples of assistive technology?

17

• Video demos

• JAWS Screen Reader - Hear an Example

• How screen readers speak a simple HTML5 page

About Accessibility – Disability & AT

18

• Build empathy with simulation exercises:

• Keyboard only (unplug mouse!)

• Take off glasses or wear wrong prescription.

• Wear vision simulation goggles.

• Put rubber band on your off-hand; use with mouse.

• Wear mittens/gloves.

• Straw test (or increase text size or zoom by 200% or more)

• Set very fast mouse pointer.

• Set very high browser zoom.

• Turn off audio (with multimedia).

About Accessibility – Disability & AT

19

• Increases potential customer base.

• Creates usability benefits for people with and without disabilities, including the increasing aging population.

• Reduces development and operational costs (server load, bandwidth, and maintenance).

• Improves cross-device browsing, including mobile phones, interactive television, and other delivery channels. (Robust)

• Reduces need for customer service.

About Accessibility – Business Case

20

• Avoids possible legal ramifications of not implementing web accessibility.

• Creates social acceptance; corporate social responsibility.

• Eliminates need to provide alternative webpage and media formats (braille, large print, CD, etc).

• Search Engine Optimization (SEO).

About Accessibility – Business Case

21

• W3C

• World Wide Web Consortium

• WAI

• Web Accessibility Initiative

• https://www.w3.org/WAI/

• WCAG

• Web Content Accessibility Guidelines 2.0

• https://www.w3.org/TR/WCAG20/

About Accessibility – Guidelines & Law

22

• WCAG 1.0 (1999)

• WCAG 2.0 (2008)

• Technology-agnostic.

• WebAIM’s WCAG 2.0 Suggestions

• WebAIM's WCAG 2.0 Checklist

• WCAG 2.1

• W3C Candidate Recommendation 30 January 2018

• Adds mostly mobile and cognitive guidelines

• https://www.w3.org/TR/WCAG21/

About Accessibility – Guidelines & Law

23

• U.S.

• Americans with Disabilities Act (ADA) 1990

• Rehabilitation Act Amendments of 1998, Section 504 & Section 508 (part of Rehabilitation Act of 1973)

• Enforceable in June 2001

• Updated Jan. 18, 2017

• Adopts WCAG 2.0 AA for new content

• Air Carrier Access Act (ACAA)

• Websites, kiosk, phone, etc.

• Doesn’t cover mobile

About Accessibility – Guidelines & Law

24

• U.S. — lawsuits and settlements

• Target, 2008

• In 2017, at least 814 federal lawsuits on inaccessible websites

• University, finance, retail, municipality

• Follow Lainey Feingold @LFLegal

• http://www.lflegal.com/2018/03/csun18-follow-up/

• More: http://bit.ly/a11ylawsuits

About Accessibility – Guidelines & Law

25

• UK

• The Disability Discrimination Act 1995 (DDA)

• Special Educational Needs and Disability Act 2001

• PAS 78 – guide by British Standards Institution (BSI) & Disability Rights Commission (DRC)

• Australia

• Disability Discrimination Act 1992

• Canada

• Canadian Human Rights Act of 1977

• World policies – http://www.w3.org/WAI/Policy/

About Accessibility – Guidelines & Law

26

• What are some business reasons for providing web accessibility?

Check on Learning

27

POUR:

(unfortunate) acronym for the 4 WCAG principles

• Perceivable

• Operable

• Understandable

• Robust

About Accessibility – POUR

28

• Perceivable

• Available to the senses (vision and hearing primarily) either through the browser or through assistive technologies (e.g. screen readers, screen enlargers, etc.)

About Accessibility – POUR

29

P

• Perceivable

• Provide text alternatives for images, etc.

• Provide captions and transcripts for video and audio.

• Present content in different ways.

• Design with proficient color contrast.

• Avoid movement and distractions on page.

About Accessibility – POUR

30

P

• Operable

• Users can interact with all controls and interactive elements using either the mouse, keyboard, or an assistive device.

• Important for mobile devices and IoT!

About Accessibility – POUR

31

O

• Operable

• All functionality is available from the keyboard.

• Users have control over timing and limits.

• Do not cause seizures (don’t flash content ~> 3x per sec).

• Provide multiple ways to help users navigate, find content, and determine where they are.

About Accessibility – POUR

32

O

• Understandable

• Content is clear and limits confusion and ambiguity.

About Accessibility – POUR

33

U

• Understandable

• Economical and plain use of language.

• Text supplemented with illustrations, videos, and other formats.

• Navigation, information structure are obvious and consistent.

• Make pages operate in predictable ways.

• Help users avoid and correct mistakes.

About Accessibility – POUR

34

U

• Robust

• A wide range of technologies (including old and new user agents and assistive technologies) can access the content.

About Accessibility – POUR

35

R

• Robust

• Functional across various technologies.

• Providing a name, role, and value for non-standard user interface components.

• Adhering to W3C standards ensures future compatibility.

• Validate your code - validator.w3c.org

• Use semantic markup.

• Use progressive enhancement (PE).

About Accessibility – POUR

36

R

Check on Learning

• What does POUR stand for?

37

Foundations

• 4 Layers

• Semantics & Order

• Other

38

Foundations – 4 Layers

1. HTML – be POSH!Plain Ol’ Semantic Html

2. CSS – style

3. JavaScript – to enhance behavior

4. ARIA – accessibility helper

39

Foundations – 4 Layers

40

Foundations – Semantics & Order

• Semantics

• Use HTML element that describes the content (not presentation)

• Good for:

• Accessibility

• Graceful degradation

• Future-proofing

• Easier to maintain (standard, consistency)

• SEO

• Professionalism

41

Foundations – Semantics & Order

Content Order = Source Order = Tab Order

42

Foundations – Other

• Use strong/em elements for importance/emphasis/delete; not CSS.

• If very important (such as sale price), must correct for screen reader users.

• Tweaking Text Level Styles by Adrian Roselli: http://bit.ly/a11ytext

• Never use an element for its design, for ex:

▫ X Blockquote for the indent.

▫ X Headings for the bold.

• Forms:

▫ Placeholder is not a label.

▫ If one selection required, use radio, not checkbox.

▫ Label groups of radio inputs and checkboxes.

43

Check on Learning

• What are the 4 layers of web accessibility code?

• Content Order = Source Order = ?

44

Techniques

• Layout/Structure

• Headings

• Images/Alt Text

• Forms

• Links

• Keyboard Access

• Tables

• Audio & Video

• About Flash

• About Validation

• Design & CSS

• JavaScript

• Single Page Apps (SPAs)

• ARIA

45

Techniques – Layout/Structure

• Visually consistent

• The main areas of the page—such as the banner, navigation, and sidebar—should be in the same place throughout the site.

• Consistent markup

• The areas should also be marked up consistently, such as using the same heading structure.

• Good usability and benefits those with cognitive impairments and those who use AT.

46

Techniques – Layout/Structure

Don’t disable pinch zoom.

No

<meta name="viewport" content="width=device-width, initial-scale=1,

maximum-scale=1, user-scalable=0">

Yes

<meta name="viewport" content="width=device-width, initial-scale=1,

user-scalable=1">

Meta viewport by PPK:http://www.quirksmode.org/mobile/metaviewport/

47

Techniques – Layout/Structure

Define page language with lang attribute.

Page level

<html lang=“en”>

Inline

Switch language to <a href=“foo” lang=“fr”>français</a>.

More:http://adrianroselli.com/2015/01/on-use-of-lang-attribute.html

48

Techniques – Layout/Structure

Skip-to links

• For keyboard user to jump over groups of repetitive links.

• “Skip to main” most popular .

• Also needed for things like search/filter bars.

• Mostly for sighted keyboard users.

• SkipTo plugin by PayPal Accessibility Team• http://paypal.github.io/skipto/

49

Techniques – Headings

• Use one H1 per page.

• Brief, succinct text.

• Properly nested (H1 > H2 > H3).

• Use a heading with <section> element.

• Can use heading within Legend.

• Use proper semantics!

• Wrong: <span style="font-size:2em"><b>My Page Title</b></span>

• Right: <h1>My Page Title</h1>

50

Techniques – Headings

51

Techniques – Images/Alt Text

• Provide alternative text for images that have with meaningful content.

• Fundamental but complex!

• Needed badly on infographics, graphical charts, and comics.

52

Alt text?

[Poll]

Techniques – Images/Alt Text

• If decorative, use alt=“” (or use CSS background).

• If same content exists in page text, use alt=“”.

• If image linked, alt text should describe purpose of link.

• Be accurate and succinct.

• Usually don’t need phrases like “image of…”

• Avoid text in images.

• Consider using CSS3 or SVG instead of a rasterized image.

53

Techniques – Images/Alt Text

54

Techniques – Images/Alt Text

• In HTML5, alt optional with figure/figcaption

• I consider this a poor recommendation.

• Captions and alt text are often two different meanings.

• Do this:

<figure>

<img src="shadows.jpg" alt="Human figures and graffiti tag painted on

deteriorating wall lit by streetlamp" />

<figcaption>Photo by Alfred Numen circa 1992</figcaption>

</figure>

55

Techniques – Images/Alt Text

For long text descriptions:

• Strongly suggest putting on page (or linking to page).

• Optionally can use longdesc, aria-describedby, aria-details (ARIA 1.1).

• None of these are perfect.

• Only aria-describedby is well supported but points on-page content anyway.

<img src=”dogs.jpg” alt=”two ugly dogs” aria-describedby=”dogsDesc” />

56

Techniques – Forms

• Labels

• Fieldset/legend

• Messages (errors, required information)

57

Techniques – Forms

• Labels

▫ All form elements must have a label.

▫ Best to align label above input (mobile, screen magnifier).

▫ Other methods such as title and placeholder are NOT robust.

▫ Use for and ID attributes to associated (not name).

<label for="firstname">First Name</label>

<input name="firstname" id="firstname" type="text" />

58

Techniques – Forms

• About “floating labels”

▫ Will pass WCAG 2.0 AA audit if

▫ Coded correctly

▫ Visual label doesn’t disappear

▫ Color contrast is sufficient

▫ Not recommended by me but a good compromise

59

Techniques – Forms

• Fieldset/legend

• Great for long forms and radio/checkbox groups.

• Screen readers will announce Legend text before each label text within Fieldset.

• Legend text should be brief & succinct.

<fieldset>

<legend>Your Gender</legend>

<label for="male">Male</label>

<input name="gender" id="male" value="male" type="radio" />

<label for="female">Female</label>

<input name="gender" id="female" value="female" type="radio" />

</fieldset>

60

Techniques – Forms

• Alternative method to Fieldset, especially for long Legend text:

<p id="question">What is the name of…</p>

<div role="radiogroup" aria-labelledby="question">

<input…><label…>

<input…><label…>

</div>

61

Techniques – Forms

• Messages

▫ Use aria-describedby for screen readers

<label for="address">Address</label>

<input name="address" id="address" type="text" aria-

describedby="hintAddr" />

<p id="hintAddr">Your primary residence.</p>

62

63

<form action="foo.php" method="post">

<fieldset>

<legend>Location</legend>

<p id="hintAddr">Where you are now.</p>

<label for="address">Address</label>

<input name="address" id="address" type="text" aria-

describedby="hintAddr" />

<label for="city">City</label>

<input name="city" id="city" type="text" aria-describedby="hint" />

</fieldset>

</form>

Techniques – Forms

64

Techniques – Links

• Link vs. Button

• Content (the link text itself)

• Awareness

• About title/tooltip

Reduce cognitive load!

• Proper role (design and code) provides predictable behavior for users

• Especially helpful for screen reader users

65

Techniques – Links

Link vs. Button

• Buttons do action (submit form, open dialog, show/hide content).

• Links go to URL (full page, page anchor, file).

• Don’t recreate a button.

• Customizing means recreating all native behavior (focus, role, keyboard) .

• Role=button used as last resort OR progressive enhancement.

66

Techniques – Links

Link vs. Button

• Also a design issue.

• Consistent design/functionality particularly helps voice-control UI.

• More: http://bit.ly/linkbutton

67

Techniques – Links

• Content (the link text itself)

• A link should always have meaning when taken out of context.

• A text link should be unique to that page (do not use the same link text for different resources).

• Avoid use of "click here", "more", etc.

• Do not write out and link a long URL

• bad readability

• annoying to screen reader users

68

Techniques – Links

• Awareness

• Is this a link? Keep the underline!

• Visually indicate when in focus (as well as on hover).

• Indicate type of link (if not regular hyperlink, e.g. PDF, MP4, etc).

<a href=“poster.pdf”>Download Poster (PDF)</a>

69

70

Techniques – Links

• Warning on title attribute (tooltip)

• In screen reader settings, title is often turn off.

• No keyboard support (silly browsers!)

• No support on touch devices.

• Assume the user may only sometimes read them.

• Use for supplementary content only.

• Use sparingly.

• DO NOT create redundant titles on links.

• NOTE: Title attribute is good for iframes and <abbr>

71

Techniques – Links

• Enhancing the title attribute (tooltip)

• Make keyboard accessible

• Make more readable/customizable

• Use aria-describedby and role="tooltip"

• Resources

• https://a11y.nicolas-hoffmann.net/simple-tooltip/

• http://ianmcburnie.github.io/mindpatterns/disclosure/tooltip/

• http://oaa-accessibility.org/examplep/tooltip1/

72

Techniques – Keyboard Access

• Many web users do not use a mouse.

• Assistive technologies frequently make use of keyboard input or even a virtual keyboard instead of a mouse or pointing device.

• Links and controls cannot require a mouse.

73

Techniques – Keyboard Access

• In CSS, use :focus together with :hovera:hover,

a:focus {

background-color: #ccc;

}

• Never use outline none (unless y’all want much more work):a:focus {

outline: none;

}

74

Techniques – Keyboard Access

• It's always best to stick with the standard A element.

• Wrong: <span onclick="window.location='foo.html';">

foobar</span>

• Right: <a href="foo.html">foobar</a>

75

Techniques – Keyboard Access

• For the tabindex attribute, avoid positive integer values (tabindex>0).

• tabindex="0”

• use with discretion

• makes elements besides links and form elements to receive keyboard focus.

• tabindex="-1"• use with discretion

• makes elements besides links and form elements to receive programmatic focus (by scripting, link, etc.)

76

Techniques – Keyboard Access

Interaction patterns:

• Enter activates links and buttons.

• Enter and spacebar activates buttons.

77

Techniques – Keyboard Access

Widget interaction patterns:

• Enter or Spacebar to open.

• Up/down arrow keys to select options.

• Escape to close.

• Tab closes and focuses next item on page.

Demo: http://bit.ly/a11ymenubutton

78

Techniques – Tables

• Provide caption (title of table).

• The summary attribute not recommended.

• Main purpose, define structure of table, no longer needed.

• Obsolete in HTML5.

• Difficult to maintain.

• Instead use aria-describedby with Paragraph.

• If you must table for layout, fix with ARIA:

• <table role=“presentation”>

79

Techniques – Tables, cont.

• Use TH for table header cells.

• May add scope attributes to TH to support older AT.

• Never nest data tables.

• Avoid complex data tables if possible.

• Use headers and id attributes if necessary.

80

Techniques – Tables, cont.

81

Tacos

Techniques – Tables, cont.

82

Mon Tue Wed Thu Fri

Breakfast

Lunch Tacos

Dinner

83

<p id="tableDesc">The following table displays the number of employees and

the foundation year of some imaginary companies.</p>

<table aria-describedby="tableDesc" tabindex="0">

<caption>Company Data</caption>

<tr>

<th scope="col" abbr="Company">Company Name</th>

<th scope="col" abbr="Employees">Number of Employees</th>

<th scope="col" abbr="Founded">Year Founded</th>

</tr>

<tr>

<th scope="row">ACME Inc</th>

<td>1000</td>

<td>1947</td>

</tr>

<tr>

<th scope="row">XYZ Corp</th>

<td>3000</td>

<td>1973</td>

</tr>

</table>

Techniques – Tables, cont.

• VideoAccessibility: Web Apps: Tables

84

Techniques – Audio & Video

• HTML5

• Multiple formats required due to differences in browser support.

• Ensure controls are accessible.

• Browser vendors slowing making progress.

• Track element for audio descriptions, captioning, subtitles, etc. (low support).

85

Techniques – Audio & Video

• HTML5 <audio> and <video>

• Check browser support.

• http://caniuse.com/

• http://html5please.com/

• Check codec support:

• http://mzl.la/Mn6tlp (MDN)

• http://bit.ly/Mn6wxN (HTML5Doctor)

86

Techniques – Audio & Video

HTML5 Code

<video id="video" width="500" height="300" preload="none" poster="cover.jpg"

autoplay="false" >

<source src="somevideo.webm" type="video/webm">

<source src="somevideo.mp4" type="video/mp4">

<p>Video not supported. You may <a href="foo.mpg">download the MPG

here</a>.</p>

</video>

87

Techniques – Audio & Video

• Accessible HTML5 Video Player by PayPal http://bit.ly/1oxpjTV

• Ind.ie: http://bit.ly/1GHi70U

• Plyr: https://plyr.io

• More: http://bit.ly/a11yvideo

88

Techniques – Audio & Video

• Transcriptions, captions

• Why:

• Deaf

• hard-of-hearing

• language is not user’s native

• learning-impaired

• broken speakers

• in library

• SEO

89

Techniques – Audio & Video

• Transcriptions, captions

• Tools:

• dotSUB.com

• Overstream.net

• Easy YouTube caption creator

• MAGpie

• Captionate (Flash)

90

Techniques – Audio & Video

• Transcriptions, captions

• Services:

• Casting Words: http://castingwords.com/

• Rev: https://www.rev.com/transcription

• Dragon Naturally Speaking

• Volunteers, interns

91

Techniques – Audio & Video

• Captioning tips:

• Should be accurate, consistent, clear, readable.

• Mixed case preferred, but use upper case for emphasis and shouting.

• Meaningful sound effects should be included.

• Denote when speaker has inflection/mood. [whispering]

• When a speaker cannot be identified, user gender to describe (e.g., “female 1,” “male narrator”).

• For video-only clips, provide a note saying "No sound is used in this clip".

92

Techniques – Audio & Video

• Audio description:

• AKA video description

• Also a WCAG AA requirement (for recorded video)

• Adds narration of what’s visually happening onscreen

• Learn more: http://www.acb.org/adp/ad.html

• Services: 3Play Media, Video Caption Corp.

• Frozen trailer example: https://youtu.be/O7j4_aP8dWA

93

Techniques – About Flash

• According to screen reader users, Flash content is one of most inaccessible items on the web.

• Adobe has worked hard to make it possible to create accessible Flash, but in Windows only!

• But in practice, frankly speaking, developers rarely do it.

94

Techniques – About Flash

• Avoid Flash.

• Make every attempt to develop Flash with accessibility.

• If it's not possible for whatever reason, be sure to provide alternate content.

• A great example of accessible Flash is this entertaining piece by Inclusive Technologies (direct Flash file link): Assistive Technology Boogie.

• It's keyboard accessible, provides captioning, and an option for audio description.

95

Techniques – About Validation

• Important for interoperability, but don’t go overboard.

• Tools

• W3C Markup Validation Service

• HTML Validator for Firefox

• Some design/developer applications such as Dreamweaver.

• User experience is ultimate test.

96

Techniques – Design & CSS

Readability

• Rendered text size of 16px+

• relative units preferred

• Medium weight font

• Ample line height (1.3-1.5)

• Medium line length (50-65 characters)

• Ample white space and margins

• Avoid centering blocks of text

• Avoid justified text

• Sufficient color contrast*

• Proximity

97

Techniques – Design & CSS

Sufficient color contrast (WCAG 1.4.3)

• Regular text:

• Regular text and images of regular text MUST have a contrast ratio of at least 4.5 to 1 with the background.

• Large text:

• Large text and images of large text (at or over 18 point or 14 point bold) MUST have a contrast ratio of at least 3 to 1 with the background.

98

Techniques – Design & CSS

Ample hit areas

WCAG 2.1 says “44x44 CSS pixels”

https://www.w3.org/TR/WCAG21/#target-size

• Unless:• Another equivalent

• Inline (block of text)

• Target is determined by the user agent (not author)

• Essential to the information being conveyed

• Use padding not margin around links

99

Techniques – Design & CSS

Hiding Content

Do not use display:none for content specific to screen reader users.

Use off-screen (good for skip-to).visually-hide {

position: absolute;

left: -9999em;

}

Use clipping (better for screen readers on touch-screen devices and RTL language support).visually-hide {

position: absolute;

clip: rect(1px, 1px, 1px, 1px);

}

100

Techniques – Design & CSS

.visually-hide {

position: absolute !important;

clip: rect(1px, 1px, 1px, 1px) !important;

-webkit-clip-path: inset(50%) !important;

clip-path: inset(50%) !important;

padding: 0 !important;

border: 0 !important;

height: 1px !important;

width: 1px !important;

white-space: nowrap !important;

overflow: hidden !important;

}

101

Techniques – Design & CSS

CSS-Generated Content

Don’t do:

<a href="#foo" class="icon-gear">

<span class="visually-hide">options</span>

</a>

Do:

<a href="#foo">

<span aria-hidden="true" class="icon-gear"></span>

<span class="visually-hide">options</span>

</a>

102

The CSS:.icon-gear:before {

content: "\29";

}

Techniques – Design & CSS

CSS-Generated Content

SVG, Icon Fonts, and Accessibility: A Case Study

• http://bit.ly/icon-a11y

• From “24 Accessibility” series

103

Techniques – Design & CSS

CSS-Generated Content

Screen reader support for SVG is inconsistent.

• SVG Test Page: http://bit.ly/svgsr

104

Techniques – Design & CSS

Recap:

• Make text readable

• Provide ample hit areas

• Hide content appropriately

• Be careful with SVG and CSS-generated content

As mentioned earlier:

• Use :focus together with :hover

• Avoid :focus { outline: none; }

• Don’t disable zoom!

105

Techniques – Design & CSS

More resources:

• Inclusive Design: 12 Ways to Design for Everyone: http://bit.ly/2K15Cpe

• Your Interactive Makes Me Sick: http://bit.ly/2K1e6g0

• A Primer to Web Accessibility for Designers: http://bit.ly/2K1s3dE

• Designing For Accessibility And Inclusion: http://bit.ly/2K1CaPY

• Inclusive Design Fundamentals (CSUN 2017): http://bit.ly/2K1CgqO

106

Techniques – JavaScript

• Use Progressive Enhancement when possible• May be a business decision

• Provide essential functionality/content first

• More of usability issue but can be accessibility issue in some cases

• Don’t use when not needed• Submit form, scroll page, autofocus, etc.

• Test with keyboard, then bridge screen reader gaps with ARIA

107

Techniques – JavaScript

• Always manage focus!

• Essential for accessibility as well as usability.

• Show/hide content e.g. modals, side panels

• Components such as autosuggest, menus, tabpanels

• Deleting content e.g. messages, etc.

• tabindex

• tabindex=0 makes element tabbable

• tabindex=-1 makes element tabbable only with JavaScript

• Don’t use otherwise.

108

Techniques – JavaScript

• Device Independence

• Avoid onMouseOver, onMouseOut, onDblClick.

• Better to use native components

• Save all teams a lot of work!

• Not keyboard accessible: <a onClick=foo()>Next Page</a>

• Adds code weight and complexity

• Doesn’t degrade gracefully

109

Techniques – SPAs

• SPA: Single Page Application

• Frameworks such as

• Angular

• React

• Ember

• Backbone

• Breaks conventions of web site behavior

110

Techniques – SPAs

• Implementing as SPA is not an excuse to neglect semantic markup

• and other good coding practices such as

• Page structure

• Focus management

• Properly hiding content

111

Techniques – SPAs

• AT must be notified when new “pages” are loaded.

• Not be silent but read something logical (such as updated H1).

• AT must be notified for other content changes.

• Alert messages, important content updates

• Remember focus management during dynamic content changes.

• Page title must update, if appropriate.

• Ensure functionality of browser Back/Next buttons.

• Properly hiding content from assistive technology that isn't visible on the current page.

112

Techniques – SPAs

• A few resources for accessible SPAs:

• Official React Accessibility page: https://reactjs.org/docs/accessibility.html

• Creating accessible React apps: http://simplyaccessible.com/article/react-a11y/

• Testing for accessibility in Angular 1 and 2: https://youtu.be/9y2MnXo45cs

• Building an Accessible Ember App: http://bit.ly/a11yEmber

• A React Design System: https://sforce.co/2K0VBs4

113

Techniques – ARIA

• Accessible Rich Internet Applications (WAI-ARIA) 1.0http://www.w3.org/TR/wai-aria/

• Roles

• Widget, Landmark, Document Structure

• States and Properties

• Widget, Live Region, Drag-and-Drop, Relationship

• ARIA 1.1

• W3C Recommendation 14 December 2017

114

Techniques – ARIA

• Attributes that define user interface elements to improve the accessibility and interoperability of web content and applications.

• Rule #1:

If you can use a native HTML element or attribute instead of an ARIA role, state or property, then do so.

115

Techniques – ARIA

• ARIA provides not functionality; still must build in with scripting.

• Adding an ARIA role overrides the native role semantics.

• Adding ARIA:

• in HTML (for landmarks, labeling and describing)

• with JavaScript (for widgets)

116

Techniques – ARIA

• Some quirks:

• Tab is not a main navigation tab (but tab panel)

• Menu is not a navigation/link menu (but dropdown with actions like desktop application)

• Banner and contentinfo should only be used once per page

• HTML5 required vs aria-required—use both

• longdesc vs. aria-describedby vs. aria-details

117

Techniques – ARIA

• Don’t use role="application" (very few exceptions)

• Puts AT user in forms mode.

• Some ARIA elements application role by default (tabs, dialog, menu, etc.)

• Most likely don’t need to use role="form"

118

Techniques – ARIA

• Use role="presentation" to repair parent-child relationships.

• Removes the semantics from the element.

119

<div role=“menu”>

<ul role=“presentation”>

<li role=“menuitem”>Foo</li>

<li role=“menuitem”>Bar</li>

</ul>

</div>

Techniques – ARIA

• For example, this:<h1 role="presentation">text</h1>

• becomes this:<>text</>

120

Techniques – ARIA

• Example: Menu Buttonhttp://bit.ly/a11ymenubtn

121

Techniques – ARIA Live Regions

• For AJAX implement Live Regions.

• aria-live (property)

• off, polite, assertive

• aria-busy (state)

• aria-atomic (property)

• aria-relevant (property)

122

Techniques – ARIA Live Regions

123

Techniques – ARIA States

• aria-checked (state)

• Indicates the current "checked" state of checkboxes, radio buttons, and other widgets.

• aria-expanded (state)

• Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.

• Show/hide controls, menus

124

Techniques – ARIA Properties

• aria-describedby (property)

• Associates descriptive text with an element (not name/label).

• aria-labelledby AND aria-label (property)

• Label/name form controls, landmarks, modal windows, etc.

• Use aria-labelledby with onscreen text

• aria-required (property)

• Like HTML5 required.

• aria-valuemax, aria-valuemin (properties)

• Defines the minimum and maximum values for a range widget.

125

Techniques – ARIA Properties

Highlights in ARIA 1.1

• aria-current (state)

• Indicates the element that represents the current item within a container or set of related elements.

• aria-modal (property)

• Indicates whether an element is modal when displayed.

• AT may limit navigation to the modal element's contents.

• aria-haspopup (property)

• Indicates the availability and type of interactive popup element.

• Value options extended to: menu, listbox, dialog, tree, grid.

126

Techniques – ARIA landmark roles

• role =• banner (page header - one per page)

• navigation (nav)

• main (main, div - one per page)

• complementary (aside)

• search (form, div)

• contentinfo (page footer - one per page)

• form, application [rare]

• Use all (except main) for backwards compatibility

127

Techniques – ARIA landmark roles

128

<header role=“banner”>

<nav role=“navigation”>

<footer role=“contentinfo”>

<div role=“main”><aside

role=“complementary”>

<form role=“search”>

Techniques – ARIA landmark roles

• VideoHow ARIA landmark roles help screen reader users

129

Check on Learning

• What are the 3 states of a live region?

• Name 4 landmark roles

130

Writing

• Use short sentences.

• Use short paragraphs.

• Favor the active voice over passive voice.

• Do not use jargon, slang or idiomatic phrases.

131

Writing, cont.

• Avoid directional language.

• “In the links to the left…”

• Don’t convey meaning with color alone.

• “Click the green button to…”

132

Writing, cont.

• Provide definitions of technical terms.

• Provide full terms for lesser known acronyms and abbreviations

• Write full text at least once on page.

• Use abbr element; acronym deprecated.

<p>I leased a new <abbr title=“Volkswagen”>VW</abbr>.</p>

133

Writing, cont.

• Page title (descriptive, concise, unique)

• Headings (descriptive, concise, unique)

• Labels for multiple navigation blocks

134

Writing, cont.

• Alternative text for images

• Decorative or use CSS? Linked? Already on page?

• Captions & transcripts

• Form Legends and Labels (brief and succinct)

• Links:

• Descriptive link text (meaningful on own)

• Notify user when linking to anything other than an HTML page

• Notify user when opening a new window

135

Check on Learning

• What is the element and attribute used for an acronym?

136

Testing

• Use multiple avenues to test

• Do what works for you and for your organization

• QA:

• Checklists

• Tool

• Manual techniques

• Screen readers

• High-contrast mode

137

Testing

But first…

Devs:

• Continuous integration (CI)

• @MarcySutton

• https://marcysutton.github.io/a11y-and-ci/#/

• https://www.youtube.com/watch?v=9x-MRZEEONE

138

Testing - Checklists

• Useful or not?

• Yes, a great starting point.

• Examples:

• WebAIM: https://webaim.org/standards/wcag/checklist

• The A11y Project: https://a11yproject.com/checklist

• Paul Adam: http://pauljadam.com/wcag20checklist.html

• More from Web Axe: http://www.webaxe.org/wcag-cheat-sheets/

• Internal/custom

139

Testing - Tools

• Color contrast tools

• See Web Axe list: http://www.webaxe.org/color-contrast-tools/

▫ Websites

▫ Browser add-ons

▫ Standalones

140

Testing - Tools

• Toolbars are useful for everyone.

• Examples:

▫ aXe (Deque Systems)

▫ WAVE (by WebAIM)

▫ WAT (IE, Opera by TPG)

▫ Web Developer Toolbar (Firefox, Chrome)

▫ Accessibility Developer Tools (Chrome)

▫ Now included by default (audit, inspector)

141

Testing - Tools

• Automated testing is great for:

• “Easy” catches and large projects

• Monitoring status/progress

• Alone catches only ~35-50% of issues.

• Examples:

▫ aXe & WorldSpace (Deque Systems)

▫ Tenon.io (w/Node.js)

▫ WAVE API (by WebAIM)

▫ SiteImprove

142

Testing - Manual Techniques

▫ Keyboard

▫ Functionality

▫ Focus order/management

▫ Visual focus indicator

▫ Similar text between page title and H1

• Text zoom (150 vs 200%)

• Transcripts, captions, audio description

• Adequate text size (14px+)

143

Testing - Manual Techniques

• Layout and navigation consistency

• Not using color alone to convey meaning

• Check document outline (heading structure)

• Check on different browsers and screen sizes

• Check on different devices and AT

• Reading level

144

Testing - Manual Techniques

Bonus!

• Text-only browser such as Lynx

• Turn off JavaScript

• Turn off CSS

145

Testing - Screen Readers

• NVDA (Windows, free) + Firefox

• JAWS (Windows) + IE

• VoiceOver (comes with OS X, iOS) + Safari

• Tutorials/cheat sheets:

• WebAIM: http://webaim.org/articles/nvda/ (also JAWS, VO)

• Deque: https://dequeuniversity.com/screenreaders/

• TPG: http://bit.ly/1UN8xnF

• Accessibility Testing with the NVDA screen reader: https://youtu.be/Vx1vSd5uYS8

146

Testing - Screen Readers

• TalkBack

• Ships with Android

• Use with Chrome

• Narrator

• Comes with Windows 10

• Window-Eyes

• Free to users of Microsoft Office

• Fangs

• Firefox add-on which simulates screen reader output with text output.

147

Testing - HCM

• High contrast mode

• Windows shortcut: ALT+LEFT SHIFT+PRTSCN

• Mac: System Preferences > Accessibility > Display > select “Invert Colors”

148

Check on Learning

• Name some accessibility toolbars and automated tools.

149

More Tips

• Plan accessibility from the very start.

• Get all teams involved

• Wireframes, content, QA, etc.

• Organization talking embedding accessibility culture: http://bit.ly/a11yCulture

• NVDA and VoiceOver screen readers are free.

• Learn last IMO

• Error handling is very important (esp. if legal or financial related).

• And preventing errors

• Sometimes there won’t be perfect solution to an accessibility problem.

• Sometimes the solution is subjective.

150

Resources

• List of Lists! http://bit.ly/a11yLists

• Organizations:• INDATA, Deque Systems, WebAIM, IBM, Microsoft, The Paciello Group,

Knowbility, Level Access, AbilityNet, AccessibilityOz, Shopify

• People: too many to name, check Twitter!• Hash tags such as #a11y

• Twitter lists

• Not a tweep? Try: Facebook.com/WebAxe

• YouTube channels• Dennis’ Accessibility channel

• DO-IT

• We Are Nomensa

151

Resources, cont.

• W3C Web Accessibility Tutorials:

• https://www.w3.org/WAI/tutorials/

• Email newsletters:

• http://www.webaxe.org/digital-accessibility-newsletters/

• Patterns:

• eBay MIND Patterns

• U.S. Web Design System

• Deque Code Library

• Inclusive Components blog

• Books:

• http://www.webaxe.org/web-accessibility-books/

152

Contact

• Websites

• EasyChirp.com

• WebAxe.org

• DennisLembree.com

• Twitter Accounts

• @EasyChirp

• @WebAxe

• @DennisL

153

Questions?

154