Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Accessibility for teams Rob Dodson @rob_dodson

Slide 3

Slide 3 text

May 18th, 2017 Global Accessibility Awareness Day! #GAAD #io17

Slide 4

Slide 4 text

Accessibility For Teams! Rob Dodson @rob_dodson

Slide 5

Slide 5 text

Hey Rob,
 Our team is ramping up on accessibility. Do you have any material to help us get started?

Slide 6

Slide 6 text

Thanks! That's really helpful. But, what about our designers? Do you have your project managers do this course?

Slide 7

Slide 7 text

Accessibility is a team effort. Every person has a role to play.

Slide 8

Slide 8 text

Project Manager UX Designer Developer

Slide 9

Slide 9 text

Project Manager

Slide 10

Slide 10 text

Include accessibility work in every milestone.

Slide 11

Slide 11 text

Everyone should receive training. Identify critical user journeys. Incorporate a checklist. Evaluate product with user studies.

Slide 12

Slide 12 text

Everyone should receive training. ✓

Slide 13

Slide 13 text

Having one person "own" accessibility doesn't work that well.

Slide 14

Slide 14 text

This is a headline Followed by a subhead This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. Web Accessibility by Google bit.ly/web-a11y

Slide 15

Slide 15 text

Accessibility Fundamentals bit.ly/a11y-fundamentals

Slide 16

Slide 16 text

Material Guidelines: Accessibility bit.ly/a11y-material

Slide 17

Slide 17 text

Identify critical user journeys. ✓

Slide 18

Slide 18 text

"A user can add an item to their shopping cart." Primary user journey:

Slide 19

Slide 19 text

"A user can change their avatar in the settings menu." Secondary user journey:

Slide 20

Slide 20 text

Incorporate a checklist. ✓

Slide 21

Slide 21 text

This is a headline Followed by a subhead This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. WebAIM Checklist webaim.org/standards/wcag/checklist

Slide 22

Slide 22 text

This is a headline Followed by a subhead This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vox Accessibility Guidelines accessibility.voxmedia.com

Slide 23

Slide 23 text

Apply the checklist to your primary and secondary user journeys.

Slide 24

Slide 24 text

Checklist Item 1 Checklist Item 2 Checklist Item 3 Primary Use Case 1 Primary Use Case 2 Secondary Use Case 1 Secondary Use Case 2 x x x x

Slide 25

Slide 25 text

Incorporate checklist reviews into major milestones.

Slide 26

Slide 26 text

Evaluate product with user studies. ✓

Slide 27

Slide 27 text

It's possible to make something "accessible" but not very useable.

Slide 28

Slide 28 text

✓ ✓ ✓ ✓ Everyone should receive training. Identify critical user journeys. Incorporate a checklist. Evaluate product with user studies.

Slide 29

Slide 29 text

UX Designer

Slide 30

Slide 30 text

We tend to design using our own biases.

Slide 31

Slide 31 text

Remember, our bodies change.

Slide 32

Slide 32 text

And our context can change.

Slide 33

Slide 33 text

Content has good color contrast. Tab order is identified. Controls have accessible labels. Multiple ways to interact with UI.

Slide 34

Slide 34 text

Content has good color contrast. ✓

Slide 35

Slide 35 text

Text and icons should aim for a contrast ratios of 4.5:1 for smaller text and 3:1 for larger text (14 pt bold/18pt regular).

Slide 36

Slide 36 text

material.io/color

Slide 37

Slide 37 text

leaverou.github.io/contrast-ratio

Slide 38

Slide 38 text

Tab order is identified. ✓

Slide 39

Slide 39 text

Tab order - The order in which elements receive focus as the user presses the tab key.

Slide 40

Slide 40 text

Tab order should follow the order of the visual layout, from the top to the bottom of the screen. It should traverse from the most important to the least important item.

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

ChromeLens video

Slide 43

Slide 43 text

Controls have accessible labels. ✓

Slide 44

Slide 44 text

Accessible labels should be succinct, and don’t need to include the control type or state. Focus on action verbs. 1. Search 2. Voice Search 3. More options 1 2 3

Slide 45

Slide 45 text

✓ Multiple ways to interact with UI.

Slide 46

Slide 46 text

Consider how someone will interact with a control using a keyboard instead of a mouse. Plan your focus states.

Slide 47

Slide 47 text

Avoid conveying information with color alone.

Slide 48

Slide 48 text

✓ ✓ ✓ ✓ Content has good color contrast. Tab order is identified. Controls have accessible labels. Multiple ways to interact with UI.

Slide 49

Slide 49 text

Developer

Slide 50

Slide 50 text

Focus management, semantics, and ARIA combine to form a robust experience.

Slide 51

Slide 51 text

Tab order is logical. Focus is properly managed and visible. Interactive elements have keyboard support. ARIA roles & attributes applied as needed. Elements are properly labeled. Testing is automated.

Slide 52

Slide 52 text

Tab order is logical. ✓

Slide 53

Slide 53 text

Implicitly Focusable Native elements like input, button, and select get focusability for free! Click Me! Password Aisle Seat

Slide 54

Slide 54 text

Not all elements are focusable

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

bit.ly/a11ycasts

Slide 58

Slide 58 text

Focus is properly managed and visible. ✓

Slide 59

Slide 59 text

When you change the content of the page it's important to direct the user's attention by moving focus.

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

close Menu

Slide 62

Slide 62 text

focus(); close Menu

Slide 63

Slide 63 text

focus(); close Menu

Slide 64

Slide 64 text

Sometimes we want to trap or prevent focus from entering an area.

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

inert is a new HTML attribute that removes an element and its descendants from the tab order and the accessibility tree.

Slide 67

Slide 67 text

… …

Slide 68

Slide 68 text

… …

Slide 69

Slide 69 text

Try the polyfill at github.com/wicg/inert

Slide 70

Slide 70 text

Focus is properly managed and visible. ✓

Slide 71

Slide 71 text

Focus rings can seem unpredictable, leading a lot of developers to remove them with outline: none. This is an anti-pattern!

Slide 72

Slide 72 text

:focus-ring is a new CSS selector that helps differentiate mouse and keyboard focus.

Slide 73

Slide 73 text

/* override UA stylesheet if necessary */ .fancy-button:focus { outline: none; } /* establish desired focus ring appearance */ .fancy-button:focus-ring { outline: 2px solid blue; }

Slide 74

Slide 74 text

Apply focus states based on modalities or user preference.

Slide 75

Slide 75 text

Try the polyfill at github.com/wicg/focus-ring

Slide 76

Slide 76 text

Interactive elements have keyboard support. ✓

Slide 77

Slide 77 text

This is a headline Followed by a subhead This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. This is body copy and it goes a little like this and Lorem ipsum dolor sit amet, consectetur adipiscing elit. ARIA Authoring Practices. This is your cheat sheet for component accessibility! w3.org/TR/wai-aria-practices-1.1

Slide 78

Slide 78 text

ARIA Authoring Practices. This is your cheat sheet for component accessibility! w3.org/TR/wai-aria-practices-1.1

Slide 79

Slide 79 text

Roving tabindex Programmatically move focus in response to key events and update the tabindex to reflect the currently focused item.
Item 1
Item 2
Item 3
Item 1 Item 2 Item 3

Slide 80

Slide 80 text

Item 1
Item 2
Item 3
Item 1 Item 2 Item 3 focus(); Roving tabindex Programmatically move focus in response to key events and update the tabindex to reflect the currently focused item.

Slide 81

Slide 81 text

bit.ly/a11ycasts

Slide 82

Slide 82 text

ARIA roles & attributes applied as needed. ✓

Slide 83

Slide 83 text

The Authoring Practices Guide will also tell you which ARIA attributes to use and when to use them!

Slide 84

Slide 84 text

ARIA Design Patterns w3.org/TR/wai-aria-practices-1.1

Slide 85

Slide 85 text

Elements are properly labeled. ✓

Slide 86

Slide 86 text

Labels help users understand the purpose of a control.

Slide 87

Slide 87 text

Control must be a child of or targeted by an IDRef using the label's for="" attribute. Only works with native form elements. “First name, edit text” First Name:

Slide 88

Slide 88 text

aria-label A string to be used as the accessible label. Overrides any other native labelling mechanism. “Main Menu, button”

Slide 89

Slide 89 text

aria-labelledby A reference to an element (or elements) which will act as an accessible label. Overrides any other labelling mechanism including aria-label. “Men’s Outerwear, Shop Now, button”

Men's Outerwear

Shop Now

Slide 90

Slide 90 text

Testing is automated. ✓

Slide 91

Slide 91 text

Automated testing with aXe CLI github.com/dequelabs/axe-cli

Slide 92

Slide 92 text

Lighthouse developers.google.com/web/tools/lighthouse

Slide 93

Slide 93 text

Lighthouse developers.google.com/web/tools/lighthouse

Slide 94

Slide 94 text

Lighthouse developers.google.com/web/tools/lighthouse

Slide 95

Slide 95 text

The (experimental) accessibility panel in Chrome DevTools will help you check your work!

Slide 96

Slide 96 text

Use the new Accessibility DevTools experiment to inspect your elements.

Slide 97

Slide 97 text

Use the new Accessibility DevTools experiment to inspect your elements.

Slide 98

Slide 98 text

Use the new Accessibility DevTools experiment to inspect your elements.

Slide 99

Slide 99 text

Tab order is logical. Focus is properly managed and visible. Interactive elements have keyboard support. ARIA roles & attributes applied as needed. Elements are properly labeled. Testing is automated. ✓ ✓ ✓ ✓ ✓ ✓

Slide 100

Slide 100 text

Accessibility is a team effort. Every person has a role to play.

Slide 101

Slide 101 text

Project Manager Provide team training Identify use cases Incorporate checklist into process UX/Designer Understand diverse user needs Design inclusively Developer Manage focus Add keyboard support Include proper semantics

Slide 102

Slide 102 text

Web Accessibility by Google bit.ly/web-a11y

Slide 103

Slide 103 text

A fortnightly YouTube series on Web Accessibility bit.ly/a11ycasts

Slide 104

Slide 104 text

Check out our docs bit.ly/a11y-fundamentals

Slide 105

Slide 105 text

Material Guidelines: Accessibility bit.ly/a11y-material

Slide 106

Slide 106 text

thank you! Rob Dodson @rob_dodson Images by Nick Bluth, Julien Devaux, Oksana Latysheva, Alena, Dan Lowenstein for the Noun Project