REACT AND ACCESSIBILITY

Zoltan Hawryluk, zoltan.dulac@gmail.com

WHY?

 Credit: Wikipedia user E Pluribus Anthony - https://en.wikipedia.org/wiki/File:Map_Canada_political-geo.png

POPULATION of Canada: 37 million!

POPULATION of u.s. citizens with disabilities: 39 million!

(that's 2 million more than the

population of Canada!)

Excuses for not doing accessibility:

• "It's too expensive"
• "The client doesn't care"
• "I don't want to do it!"
• "You can't make me!"

cost of an inaccessible website

• Target Corporation settled the class action lawsuit filed by NFB in August 2008 and agreed to pay class damages of $6 million.¹
• The National Federation of the Blind was awarded reasonable attorney's fees and costs of $3,738,864.96.¹
• “[T]he settlement amount is significantly more than what it would have cost Target to implement a high level of accessibility in the first place.”²

¹ https://www.w3.org/WAI/bcase/target-case-study

² http://webaim.org/blog/target-lawsuit-settled/

What do react developers and accessibility developers have in common?

they want to do right!

• They're always right ... just ask them!
• They want to do things the right way according to best practices.
• They want to do the right thing.
• They like to do the right things in code reviews.
• They like patterns and predictability.
• They want to be great mentors!
  
  
   
• They want to create stable and understandable systems....

.... webpack non-withstanding.  \(^o^)/

great!  How do I get up to speed on WCAG?

DON't start by reading the w3c documentation

https://commons.wikimedia.org/wiki/File:Chronic_fatigue_syndrome.JPG

insert Voiceover demo here

Problem #1 (EASY)

making things work correctly with a screen reader

Insert example here.

• Use valid HTML!
• Test with a screen reader
• Test with a mobile screen reader
• Links are things that open up a new page
• Buttons are things that perform an action on a page
• Don't mix up links and buttons!
• Avoid using <div>s for things that have valid HTML elements.
• If you must use <div>s to replace HTML elements, understand how to use ARIA roles.

Problem #2 (EASY)

how to allow screen reader users to skim a page quickly

Insert example here

• Use headings like a table of contents!
• Know what landmarks are and their ARIA roles.
• Understand how aria-labels work with landmarks.
• Mark up tables like tables.
• Use "skip links" to enable keyboard users to skip a large amount of interactive elements that are commonly glossed over by visual users.

Problem #3 (EASY):

How to give interactive elements context

for screen reader users.

insert example here.

• Use aria-labels sparingly to replace "visual text" with screen-reader only text.
• Use aria-describedby more to augment "visual text" with other "visual text" on the screen that gives context.

Problem #4 (easy):

How to give elements unique Ids.

Side note: the three most controversial dev topics:

• Tabs vs Spaces?
• What is the best editor to use?
• Is "GIF" pronounces "giff" or "jiff"?
• Is it spelled "ID" (with all caps) or "Id" (with an initial cap?)

insert example here.

• While you should not use Ids in CSS, you should still use them for accessibility!
• Ids  are used a lot in ARIA
• They show relationships between elements (labels and form elements, tabs and tab panels, dropdown labels and dropdown content)
• If you are putting several instances of a React component on the page, use guids to make unique Ids.

Problem #5 (medium):

How to make accessible modal dialogues.

insert example here

• Use either HTML5 <dialog> or aria-role="dialog" to create modal dialogs.
• Your dialog should contain a <div role="document">
• The close button should be first interactive element in the modal and should gain focus when the dialog is opened
• When using a tab key to navigate around the modal (or swiping around on a mobile device), focus should never go to an element outside of the modal.
• When the dialog is closed, focus should go to the button that opened it.
• Test your work on desktop and mobile.

Problem #6 (medium):

How to make accessible expandos/drawers/disclosures/popups

(or whatever the hell the fancy pants cool-kid designers are calling them nowadays)

insert example here

• use aria-haspopup on disclaimer buttons
• use aria-expanded="false" on the disclaimer button when it is closed, and aria-expanded="true" when it is opened
• use a routine like accessibility.refocusCurrentElement() when you are changing a disclaimers state.

SHAMELESS PLUG

accessibility.js - a library of common accessibility routines.

Problem #7 (easy - medium):

How to make accessible tables.

insert example here

• Use captions in your tables
• Use real TABLE tags, or their ARIA role equivalents.
• Use the scope attribute correctly.
• Know how screen reader users navigate through tables
• Keep your tables as simple as possible

Problem #8 (hard EASY!):

How to fix resized/zoomed text.

insert example here

• Design your components to be able to take any amount of content (and any size of content!)
• Use rems/ems ... avoid px (even if someone tells you it's okay to ... they're lying!)
• Use text-zoom-event to style text differently at different text-zoom levels.
• Keep track of color contrast!

Problem #9 (medium):

focus management in react

insert example here

• focus() is a function -- be careful when using props to apply focus (especially when you have several components that do it!)
• HTML5 autofocus should be avoided.
• focus should be applied after componentDidChange using requestAnimationFrame().

Problem #10 (medium - hard):

pitfalls of mobile screen readers

insert example here

• focus and blur events don't work how you expect with mobile screenreaders (i.e. they don't really work at all)
• "accessibility focus" is not the same as "keyboard focus"
• aria-hidden can be used to mitigate these pitfalls.

Problem #11 (easy - hard):

how to create an accessibility-positive culture in your team

insert example here