Baking Accessibility In

Apr 1, 2016

–

10:30 am

–

Alamo Drafthouse New Mission

Cordelia McGee-Tubb

Accessibility Engineer

Dropbox

A quick web search can bring up thousands of code samples for any type of component one could imagine building, but 90% of that code isn’t accessible, unintentionally leaving huge audiences of users behind. You have the power to change this! As the people creating style guides and component systems, you’re uniquely positioned to get accessibility right the first time and spread best practices to everyone who uses your code. In this talk, you’ll learn the key ingredients for baking accessibility into your design system, including mindful color palettes, semantic HTML, and a dash of ARIA. Let’s make the web better for everyone, one style guide at a time!

Transcript

Chris Coyier:

We have another speaker, as we do at a conference. Can you guess what the title of the next talk is? It's 30 feet wide above your head. It's Cordelia from Dropbox. So fascinating facts. Perhaps my favorite so far. Did a photo booth tour in San Francisco. She did 30 booths in day. That's impressive work. And she had it journalling eating a hot dog. And it has walked the perimeter of San Francisco and Manhattan. Cordelia is a web accessibility developer in Dropbox and teaches web accessibility to seniors. Cordelia. Looking for to your talk. Welcome her to the stage.

[Applause]

Cordelia McGee-Tubb:

Hey, to answer your question, the perimeter of San Francisco is 28 miles and the Manhattan is 34 miles you can do it in a day. I am doing a San Francisco perimeter talk later this year. I'm here to talk about baking accessibility into your design systems. A little more about me, I'm an accessibility specialist at Dropbox by day, and I'm doing a master's at night and I'm excited about that. I have this illustration of me, which is May 4th Cordelia's tall. You can take a picture of that. What is accessibility? It's basically creating experiences that everyone can use regardless of their abilities. So if we are speaking about web for instance, if someone is blind, or color blindness or hearing loss or has a dexterity issue that effects how they use a website they be still able to use and enjoy all those points that anyone else can use? If they are done correctly, you have a flexible system that considers accessibility from the beginning. This includes them in the design process in the development process. And it's flexible enough for people to figure out whether or not they want to use an option. Let's talk about what happens when accessibility isn't baked in by default. And I will use metaphor, because we all love those, and talk about making muffins for your niece's birthday party. And on your way there, your mom said, these were supposed to be blueberry muffins. And you forgot that, and you start to forces blueberries into the muffins and they are gross. They are not really the same as blueberry muffins; they are not melted and delicious. It's not a good experience. By definition yes, it's a blueberry muffin, and yes, you may have an accessible system, but it not a good system. Why am I talked on to you about blueberry muffins? I believe you are the Julia Child of systems. You are the people what are creating the cookbooks that everyone else reads. You are creating the systems that everyone else uses whether in your internal application or owed on the web. We have talked about bootstrap in the last few days, which is this awesome cookbook, it's like an Martha Stewart cookbook, everyone reads them. I wanted to talk about this today, because everybody is copying Steph's code, if you are a developing and you are learning thought write code by copying and pasting other code. And I learned by Googling things, for example, I did Google search for hamburger menu code. Many of us don't like hamburgers code, you can do a Google search for hamburger menu code and get 6,000 results and probably 80 percent of them aren't accessible. And a bunch of people willing and copy the code recipes and they work well with a mouse or touch screen, but they don't work well for somebody who is navigating with a keyboard reader. So I say, people are going to go to the web to copy your recipes. And we want to make sure to give people the best recipes you can. This is about the users at the end of the day, we want to make the best recipes that work for the largest amount of people. I want to talk about universal design. We are talking less about accessibility but about the universal design. It's less about a box you want to check, but thinking about users with disabilities or ages or having needs different from your own, thinking about the users from the very very beginning of the process and making that information in when you are designing. I went to a huge accessibility conference last week. And here is a tweet I was saying, the big theme of the conference was the importance of universal design. You can change code to be more accessible but it won't fix bad U X. A lot of people agreed with that. That accessibility is more than just writing good code, it's about building really comprehensive systems. We are going to go over the ingredients of accessible. Which is making common code. And sugar and spice and everything nice which are all the traits I don't have. Your systems are unique. And they believe we will talk about the accessible. Let's talk about the foundational ingredients. A lot of this is about H T M L. Use semantic H T M L. If you are familiar with that, it's using H T M L the way it was intended. If you have a heading on your page, or large text that starts off a section, use an H T M L heading instead of spam to make it look large. Use a table rather than than a theme that makes it look acceptable. It's essential for users of assistive technology. It's anything that allows people that exists as a layer between your website and the people who use it. For example, screen readers, if you are blind or have low vision, you might use a screen reader to connect with the web, so they, again, depend on things being lined up correctly. Speaking of buttons, I suggest to use those in the your code libraries. Here, you have style guides that people can cut and paste. Here all the code examples we are using are accessible by default. Here on the screen I have any sample style guide, and I have a primary button and secondary button and the code is button class, equals button primary. It looks like it button. I have seen lots of style guide that use an anchor needs. So I have anchor slash code. It still works the same with a mouse but it's not reachable with a keyboard. Because the element without on H ref aren't accessible. When you create C S S classes, like button primary. It gives people license to use that element on anything they want. This looks like it button but it a D I V with class primary. This looks like a button and acts like a button to a mouse user but a keyboard user or a screen reader users wouldn't have access to that. If are creating button class, maybe in your C S S style sheets, make sure the button class is only applied to actually H T M L buttons, so people can't stick it on any old D I V and make something that is not accessible. The second tip on accessible web development is input fields. A big trend right now that I'm hoping is going way is to stick input field inside input fields. So the code for this is input type is text and place holders is favorite animals. There are a few different accessibility issues with this sample. First it's low contrast. If I'm low vision, I might not see that. If I start typing in there, the label completely goes away. That's a huge issue if you are typing in there and you get distracted, and go back, and man, I don't know why I typed the lemur here, be sure to include a visible label. So here I have a visible field that shows "favorite animal," and then in the text box is "leaping lemurs." Here I have a label in the H T M L followed by the input field. There is still no association between the input field and the code. There is nothing saying that this label is associated with the input field. Be sure when you are including form input field in your style guide, and I have seen a lot of these, to include a fourth attribute in your label. Here, I'm saying this the label for the animal field and I'm saying, place holder, of animal. It has a benefit for mouse users because my focus will go into the input field. I won't go back into the alternative text. Iconography is important to style guide. Any time you have an icon you should include a text for it. Here I have a greenhouse icon, and I have a few different code snip pets for it. It could be an image for home. Or if I'm on a plant website, I might want to have A L T equals greenhouse, make sure to include a text alternative for people who can't see that image. You want to convey to users that it's not an important text here I have the same icon next to the text home. And I can say, ALT equals empty string. If I were using S F Gs, I might use R equals hidden equals true. Saying, ignore the image because there is other text on the screen. If you have decorative images, use them as your own discretion. Here I have an illustration of me, and here I replaced that illustration with decorative circles. It adds extra info about the type of person I am. I would use an ALT of Cordelia, smiling, because that is what is happening on that illustration. I would not put a ALT in circles. So if you put a decorative image, you should put an ALT or that it's not important information. In some cases you may have to use ARIA. Which stands for Accessible Rich Internet Applications. You can add to an element to aid hit role state or property to assistive technology. Here are examples. Here I have 18 F, web design standards for the U.S. Government. On the screen, they have accordions elements. Are the first second and 13 amendments, et cetera. If we could not see the screen, how would we know that information? There isn't an easy way to do that with H T M L. So you would include ARIA elements. You can use ARIA to associate the headers with the content. The style guide does is and they include documentation to show how to do that correctly. You can use ARIA, for any components like modals. I threw a lot of information at you, and I only scratched the surface. These are the accessibility standards that most web sites are trying to meet. Hayden is a cool guy. He created these practical ARIA examples that are snippets that create a tab set with minimal code. And then web accessibility Slack community and people in that community are super super open to newcomers. We sit around is chat about accessibility best practices and I recommend you join us. That's the core H T M L component. So let's talk more about design. The sugar and spice and everything nice the branding of your product and how you can work accessible into that. Here, I have an illustration of honey and agave. And I encourage you to make keyboard interactions as rich as mouse interactions. A lot of people don't navigate with a mouse. It doesn't matter what tool they are using. You want it to be a fun experience for everybody. Make think about keyboard users, don't leave them behind when you are developing fun stuff on a hover. When you hover on the light post, you get these come up. And when you hover over each of them, they jump a little. This is a night fun interaction that Facebook introduced to their product. And they went a step further and made sure that they were keyboard accessible. I thought that was really really great because they are trying to provide a fun experience regardless of how people are experiencing their website. The one problem I would say with this with keyboard is the focused halos you may have seen. Don't forget about them. A lot of times people don't like the focus halo on buttons or anything that is focusable. I have this little heart button and there is a focus around it. A lot of teems people don't like it and get rid of it. Which is super bad for people using keyboards. So they rely on focus indicators. It's fine to get rid of the blue outline, but you want to come up with something else. You could create your own focus halo here. This is a good way to develop your own brand. Here I put a purple border around my button. And a tool tip. People often times don't know hover over these. And here I had a round border around it. There are a lot of ways to incorporate your particular esthetics and your branding into accessible features like focus halos. Actually I think all these are ugly. Here is the same button with the word "love" next to it. And here are some random examples of things you could do instead of the halo. You could change it to be red or underline to be bold, and this is pretty ugly, you could add a scroll behind the button on focus. The point is you are thinking about keyboard interactions and infusing your brand into that. In the same way you might be thinking about mouse interactions. Now color, I think that is one of the hardest things to get behind when thinking about accessibility design. People are scared that if they are using accessible color palates, it will be just black and white schemes and ugly. There are two rules for color accessibility. First you should maintain a reasonable contrast ratio between background and text colors. And second don't use color alone to convey meaning. First, let talk about reasonable ratios. So the guidelines I talked about earlier have specific ratios for text color against background color. So it's 4.5 to 1 for regular Tex and 3 to 1 for larger text. So I recommend you use an on line tool so test your colors for that. There are a lot of tools available, I like wave. You can test your entire web sites accessibility. And you can test a lot of stuff. Again people are worried that making things high contrast will make them ugly. I would say that's totally untrue. This is a color safe which generates color for you. I said I want a white text on a color background. It's a lot more vibrant on my screen here. Here you can see some really bright purples. You can definitely find colors within your company's brand name that will work P. Here is a color that is not fully accessible. Here is a page for scooter. And here is the gray scale color palate. There are ten shades gray here. So you have ten gray colors in the gray scale palate. And the top five is a check showing they are compliant. If you were looking at the style guide and saying, what does that mean? He added some documentation at the top saying, if these say W top oh compliant, you can use these colors for text against a white background. It's not that you can't use the other colors, you just shouldn't. The there are a lots of ways to use color besides text. Week see the larger color palate for scooter. I would say about a 3rd of the colors can be used for text. The rest of them can be definitely be used for a lot of other things. I would say use vibrant colors as much as you can and use light colors, just make sure you are using dark colors for text and using the other brights colors elsewhere. Here I have a cake I drew, it says Clarity in big bold purple letters on top of it, you may or may not depending on where you are sitting to be able to see that there are green bits are icing and blue bits. But those or not the important information, the important information are in dark text. Here is the lightening design system page. You can see they are using a lot of bright colors. They are using a blue that passes for your background color for their text and they are using color in other innovative ways. The decorative images would probably have alternative text set to an empty string because they are like floating objects. If you scroll down the page you can see different tiles talking about the lightening design systems under lining, like the, the tenants of the S. And if you look at trust worthiness, which is yellow which is traditionally a hard path to write text. They are not putting yellow text on white, they are using a yellow outline in some places, and yellow for their iconography and keeping your text a dark blue. So there are a lot of ways to use bright colors that aren't conveying meaning performer use more than just for meaning. The first name field is not filled out. This is a problem for people with low vision or who are color blind who may not notice the red. A way to check this is to put your computer in gray scale mode. And you can see that miff first name in a first name border and last name border, so now I don't know that the first name is required. So include additional information this is an example from scooter again. You can see the first name field now has an icon, and it has text saying it's required. It's still putting that stuff in red, so it still using color to convey meaning but relying to convey meaning. I can still tell that this information it required. I have the required text, I use gray scale mode a lot. We talked about how to make your code accessible. We have only scratched the surface, but throws are big areas to think about it. And next, sharing your recipes, you should share that if you have done all that work. Clap if you have heard of have P I N T A R E S T fails. So people go into that sight and try the tutorial, and they don't work out. Here they had these super cute chick, cake pop, and someone tried them, and it's totally mutilated. And it's against an ugly wooden table, and the caption says nailed it. This happens a lot when you see these image tutorials on line, where they don't spell out all of the steps. And people try them and fail. I bet this ugly cake pop really tasted good. What often happens with design systems, is the opposite. They will copy your C S S and your animations say, but they won't copy the under lying thinking that went into that C S S or why are you using that animation in that particular place? Or that style? And they won't copy your H T M L mark up necessarily, so people might have a button class and acts like a button, but it's secretly a D I V behind the scenes and isn't accessible. So include accessibility notes in your documentation. So it's important to tell people that it's accessible and why. I used to work at Salesforce and I was on the accessibility team there. And I worked were designs to make sure their components were accessible. And one of the things I did was to write accessibility documentation for each component. So here we have the avenue tar documentation, and the first thing is about accessibility. Bootstrap again, everyone this. They have some very long documentation. And they talk about using ARIA attributes. I think it's important to talk about ARIA that B because people knew to coding night see the ARIA prefix and they will not use it. So this is very important to use for people who need assistive technology. I highly recommend using the documentation the way boot strike that ask other style guides are do you go. This encourages people to pay constant attention to access. A. . If they see accessibility notes on every page of your documentation they will know that they should bake it in and not take it on the end. It spreads best practices. They may not use your components they will go off and build it on your own, but they will know how to do it because you have talked about it. This is the common model of having your right hand side navigation for your style guide, normally the accessibility line item is at the bottom of the that navigation which is scary for me, because again it reenforces that accessibility is something to think about at the end of the process which is not it is case and people might not know to go there. So I like general accessibility documentation. I think it creates a hollow tick thinking about the design. If you are going to have general documentation you should inclusive it with the component documentation. The lightening design system doesn't include java script, but component is a general paragraph about general interactivity and bullet pointed list of the mark up followed by a list of the excepted keyboard action of interactions. To recap our cooking class, there are four things to think about, first bake accessibility in from the beginning. Second use key ingredients of semantic this T M L, ARIA when you need it. The first rule of ARIA is not to use it. And keyboard interactivity. Think about color, don't see accessibility as a barrier to making things fun. Spread your recipes generously. That's what I got for you.

Chris:

I like how to end with a proper muffin.

Yeah, this is a really exciting blueberry muffin.

Cordelia:

Hand drawn by me. I'm not really good at making real blueberry muffins but I can draw them.

Chris:

It's time for the chat. Your talk flipped everything on its head. Hi. There is so much good stuff there. One point you made early was that maybe accessibility could be not just making it work, but make it work enjoyable to you. Not like, first sighted users it's got do cool an making, we made it work with accessibility. It's not fun. It's a degraded crappier version.

Cordelia:

I was thinking of the flak notifications. What if those read out to a screen user whether they got to the page? It's including people in the on the fun. The main thing is when you are creating a fun and enjoyable experience, everybody should be able to take part in that. A lot of sites have accessibility modes which is a huge no, no, because.

Chris:

Turn on accessibility mode.

Cordelia:

People this that will be a better experience, but it's super because the people who turn on that mode might not get all the same feature. Like that mode will get really neglected quickly.

Chris:

It's like a recipe for a second class citizen.

Cordelia:

Exactly. Think of ways to inject fun. Like the Facebook example of the pictures popping up for everyone.

Chris:

What I thought was what if it were a way of tricking someone like had he me to have more fun with it. Where I feel like, now I have tot to do the accessible stuff. So instead saying, now I can think about the experience and kick it up a notch.

Cordelia:

Like creating keyboarding experiences for infants. I have in the past, had people ask, why did a we have to make this keyboard accessibility. And people then say, I like using the keyboard, it's faster, like special keyboard shortcuts, that make at a better for everyone. So everyone benefits.

Chris:

Cool. There is a good C S S trick there. That I was attracted to. It's so easy to make. It's a class and it a button, so I'm going to make the class button or S L D S button, and that gives us the power to make literal anything a button. And it's a tricky way to keep people from doing that, to force people to not do that. It's button dot button.

Cordelia:

I know it a little contentious. People don't like doing that.

Chris:

I know people don't like, because it decrease specificity by a mike robe. Speaking of that, what does it take to ship something at Dropbox.

Cordelia:

I would like it to. I'm actually fairly new at Dropbox I'm working on building out tooling now. I have a set of manual guidelines I want people to go through. You can write a lot of accessibility tests on that. But it's also the human experience. You don't want to check boxes, where every single button is a button. You want to make sure the experience is good. I tell people go threw the feature the you are working on. Do you get stuck?

Chris:

It's a literal focus.

Cordelia:

If you are tabbing behind every modal.

Chris:

How many tabs have a modal?

Cordelia:

Every one. If you Google, there is a good code sample on line, it's an incredible accessible modal. It's really rad and awesome. It's a rock star N I N J A modal. I highly recommend looked up this resource.

Chris:

You talked about focus halos a bunch. And I thought some tweets, guilty of removing them. I thought, you can do anything you want there. There are a lot of factors of the I imagine people have a lot of opinion on that. Is there any push back there? Most people say to leave alone. I like the blue. Or they say, they took the opportunity to do some cool delight there.

Cordelia:

I think consistency is really important there. If you are defining your own, keeping that style consistent across your entire website. At Dropbox we have a slight variation of the blue halo, we have a Dropbox blew halo. I haven't gotten any push back on removing it and replacing, it it's just make sure there is something there regardless of what it is.

Chris:

It reminds me of things like form styles default, or links should be blue because they were.

Cordelia:

I believe the style thing for select. Let me do a rant here, because of custom select drop down. A lot of people will replace it with list items but they don't include the keyboard function although but not use ARIA on it, so if I were a screen user, trying to navigate, it would not read out the way the native one does.

Chris:

There are a hundred things that it gives you for fee, like if it opens up if it's toward the bottom or you can type W and it goes to the W thing.

Cordelia:

It's regard to reproduce that with drops.

Chris:

Regarding tooling we talked about that because you wished you could do more. It's hard to tie in with things that we use. A lot of time people pushes or commits on master, or a suite type of thing.

Cordelia:

A lot of times people walked in house, but there are a lot of open sources for that. You can Google a lot of those. So ten is great for accessibility.

Chris:

From your talk, accessibility is treated is a tack on thing, but in documentation for a style guide, here is how you use, and also it's accessible maybe if you use this thing. Again that's a second class citizening which is undesirable.

Cordelia:

A lot of people are scared of accessibility at first because they think it's a lot of extra work, but every single time I have work with someone on making something more accessible, they are like at the end, oh wow, that's cool. Now it works better for me. Of.

Chris:

It's better than we thought it was going to be.

I remember reading a post years ago about the accessibility alphabet. It's people with a broken arm.

Cordelia:

Or people outside on a sunny day looking at your phone.

Chris:

It's not just for blind people only. Do you have an example of one of those, in a way that you solve for it? Like an unusual accessibility issue?

Cordelia:

Hum.

Chris:

The sun one was a good example.

Cordelia:

I personally have migraines with aura. It's a frightening thing. And sometimes I use a screen reader. If I didn't, I will sometimes increase text. That's something that is really really common. This also speaks to, getting accessibility features surfaced as top level features. My grandmother sends me text in all caps because it's easier for her to see. She doesn't know she can press command plus plus to increase her font size, so she does what work for her.

Chris:

I mention you know how to use screen readers. That's a moment of frustration for me. I know I have to test. And it's so hard, I don't know what to do. What was the learning curve for you? Are you wicked proficient.

Cordelia:

No, I'm not I'm constantly learning new techniques for how to do it. My blind colleagues, have taught me so much. I was in a conversation yesterday with my friend about screen readers, specifically, and they have to learn the technology arrest fast and it's hard. So there is work to do there. For ramping people up. They are good with voice over apps there are is good documentation around it.

Chris:

Thank you so much.

Video

Sketch Notes

Transcript