About the talk
Accessible web applications reach wider audiences, ensure businesses are in compliance with the law, and, most importantly, remove barriers for the one in seven worldwide living with a permanent disability. But limited time, lack of knowledge, and even good intentions get in the way of building them.
Come hear my personal journey toward accessibility awareness. You will learn what accessibility on the web means, how to improve the accessibility of your applications today, and how to encourage an environment where accessibility is seen as a requirement, not simply a feature.
I’m a front-end developer and designer based in Fort Worth, TX with a passion for web technologies, inclusivity, and Texas BBQ. Currently cooking up code for Yum! Brands.View the profile
Thank you so much for tuning in to watch this talk and thank you two rails, for having me. This is actually the very first conference I've ever spoken at. So I am thrilled to be able to share with the rails Community. Something that's very close to my heart and a little bit about myself. My name is Ryan. I am a second career developer from Fort Worth, Texas and some of the things that I like about Texas would be summed up in this one image here. I absolutely love the food here. If you're ever in Texas, I highly
recommend the barbecue. It's pretty hard to find bad barbecue, honestly, but yeah, we have some great Mexican food as well. So definitely check that out. This is also the state where I'm at. My wife. This is a picture of us in high school and I have a very intense look on my face here. Let me put up a Recent picture. There we go. Clearly we have matured. So I mentioned that I am a second career developer. My first career was as a designer. I was a designer for 15 years and those 15
years can be summed up in one image. So that was basically how that went. But luckily I eventually made the jump to development and now I helped make the space that comes from The Container Store and More specifically, I work on our e-commerce website. One of my passions is front-end development. And I absolutely love it. I love it because it's one of the first layers that users encounter on the web and a big part of front end development is ensuring that the UI that you build is accessible. That it can be used by
everyone. So, you know, in order to learn more about That our team invited a special needs teacher to share how her students use accessible technology on the web. And I've been building websites for quite some time. Longer than I've been at The Container Store. So I thought that I knew how to build accessible you. I but after her presentation, I realized how informed uninformed I really was. And that basically led to this talk. Before I go any further, I want to get this out of
the way. This isn't a rails talk but it's rails adjacent. This talk is about an idea. It's an idea that sir Tim berners-lee had when he invented the web 30 years ago, and it was an idea to create a community that openly and freely shared knowledge that anyone could access. The problem is a lot of the content on the web. Now is inaccessible, and it's getting worse. Webcam a nonprofit organization, specializing in web accessibility conducts yearly surveys of the top. 1 million homepages in last year's survey. They found over almost 61 million errors, accessibility
errors. And that's up 1.2% from the previous year. It's important to note also that this survey utilized automated accessibility testing, which doesn't really catch all of the errors. So the picture is probably much worse. I want to talk about how we as developers can help solve this crisis. First, let's talk about what I mean, whenever I say, accessibility simply put accessibility is about removing obstacles. To ensure. Everyone has equal opportunity to participate. In that word evil is very important.
And when you're talkin about, accessibility on the web, that means building websites applications tools and Technologies in a way that allows everyone to participate and contribute equally. So, if you build anything for the web, this should matter to you. It should matter because first of all, it's the law. In the US, the Americans with Disabilities Act prohibits discrimination on the basis of disability. And even though the Act was passed before the wide adoption of the internet websites, have been declared subject to the. Ada is places of
public accommodations and other countries have passed similar laws. This past year. We've seen people rely more and more on the internet to get things done. And as a result, we're seeing your eyes and Ada related digital lawsuits as well. There are 3550 new Ada lawsuits in 2020. And that's up 23% from the previous year. So, you can definitely see a trend here. Accessibility also matters because it can be good for your business, the CDC estimates, 61 million Americans. That's one in four. Us adults have a disability that
impacts their major life activities. The Nielsen company calls this group, one of the most present and perhaps most overlooked segments of the US consumer. And it's a segment with over 490 billion dollars in disposable income. You can see how important it is to cater to this community and we can actually becoming a unique marketing opportunity. Another reason accessibility matters is that it makes things better for everyone. You can see this in real life, curb Cuts were originally introduced at Berkeley to allow wheelchair users to cross the street without any additional help. But
they also benefit parents with strollers Travelers with luggage and children on skateboards and scooters accessibility on the web. Similarly, benefits. All users, the more accessible you make your your website or your application, the easier it is for everyone to use. Especially when you consider what people are experiencing when using your app or site, there are temporary. Disabilities like broken Limbs and distracted drivers, and people in noisy restaurants that may have a hard time hearing. And even old age brings with it a decline in ability. Finally
accessibility matters because it's an essential, right? We have an ethical responsibility to ensure. All content is made available to as many people as possible. This was the original intent of the web. So now, you know that accessibility matters, but maybe you're like I was in that teachers presentation. I was completely unaware of common issues and I didn't even know where to start. So I ended up at the web content, accessibility guidelines, or will keg for short. It was created with the goal of standardizing web
content accessibility. And actually, it's about to be expanded to include accessibility for All Digital content whenever it is, whenever it changes over to version 3.0, the current version 2.1 has three levels of compliance. There's one a, which is the bottom tier and that's your basic accessibility. Right? Level 28 has been considered the legal requirements. That is the middle tier tier. And then three is the gold standard is the top-tier. What can also uses four
guiding principles to Define accessible content and they are perceivable operable, understandable and robust? A convenient way to remember these principles is the acronym poor. Let's take a look at for content in action. The first principle perceivable. It means that content should be able to be recognized by any of the available senses. And that means that anything that's on the screen. Not only has to be seen, But heard and even felt it necessary and we'll talk about that more in a minute. The first example, will look at has to do with color improper contrast
is one of the most, if not the most common accessibility error, and it's probably the easiest to fix. In this example, which is in Chrome. We have two different blocks of text one. That's smaller and one that's large. Let's go ahead and inspect this in Chrome Dev tools. You can see that we get a color swatch here that we can click. And then you see that the contrast ratio is 2.59. That means is 2.59 times darker than its background, but it needs to be 4.5 *. So one way we can fix this is, if you see these lines here, this is to
a compliance and this is three a compliance. We're going to drag the color indicator. Just below the to a line. Now, we're going to now you can see that it's fixed. So, we'll go ahead and close that to save the color. Number to inspect the large text. Go ahead and bring that up and you can see in the pallet that it again has 2.59 contrast ratio will. Since this is larger text. We just need a 3.0 contrast. We can go ahead and click the suggested color swatch and then close that palette.
And now we've fixed the color contrast issue. This is actually something that you would want to bring up with a designer. And honestly, this is something that is a designer should already be designed for, but you should always if you're developing, always check to make sure that the colors have the proper contrast. Like I said earlier, content should be able to be heard and even felt. Well, one of the main things that accessible technology does is it transforms one type of content into another screen readers, transform text in the audio content, Braille
displays transform text in the content. You can actually touch and we even have software that that can automatically transform. Audio content into captions, are these Technologies still need help? For the next few examples. I'm using voice over the screen M that comes with Mac OS as well as the Safari web browser. Voiceover on Safari. So we just turned on voiceover and it tells us some information first. It tells us what application are on so screen heaters
aren't just a web technology there, an accessible technology for your entire operating system. So they need to be able to tell you what application you're on. The next thing that it tells us is that what is the name of the window? Which is alt text example, and then it tells us what has keyboard Focus, which is the web content inside of alt text example, let's go ahead and jump into the content and see what everything else sounds like. I'll text, I'll text. I'll text
you. So, the first thing it does is it focuses on to a main element? The main element is a semantic HTML element that defines the main content of a web page. And this basically, halloscream M, can identify what the main content of a page is. The next thing that we hit is the alt text heading and then we jump to a figure which is where we are right now. Of figure is another semantic HTML element that defines a Content that represents something. And inside, we have a caption with all text that caption is wrapped in another
semantic HTML element called caption and that just defines the relationship between that caption and the surrounding figure. So we'll talk more about semantic HTML elements in a minute, but for now, let's see. What images sound like in a screen reader. The top of the Chrysler Building at the Cloudy Sky image. So when we focus on to the image, it told us that we were on an image, but it first told us it gave us a description of the image. So how does the screen you don't know what this image is? We've actually added all text
to this image. All text is a short description that it describes what the images. There are a lot of rules around what makes good, all text, and I highly recommend you checking them out. It's fairly easy to search and find a lot of great content online. A, but the important thing here is that you add an ALT attribute to your images. Always when you don't have an ALT attribute on your image, it can sound very confusing. Image. So it reads off the image source, which in this case is just a bunch of different letters from together and it doesn't really make sense at all. So
always include an ALT attribute on your images. If your image is purely decorative and you don't want it to be announced to a screen reader, then include a blank, alt attribute. And in fact, you might want to think about adding those images as background images, that way they're not read by the screen, mirror at all. Finally, let's take a look at Icon buttons. Screen readers can announce button labels if they have text inside, but what if they just have icons? In this example, we have a button with only a hamburger menu icon visible. Let's hear
with this button. Sounds like voiceover on navigation, menu. So this is a button to open up a menu. And right now, you can see that there is actually a label associated with it navigation, menu. So, how does the screen reader know what that label is? Well, we're adding it with a a visibly hidden label. So this span here has the class Sr. Only which is a class that visibly hide texts, but still exposes it to the screen reader. Another thing that we're also doing here is hiding the SVG from the screen reader to make sure that that it doesn't. And now it's anything inside of
the scg because you can have things inside of oven SVG. They can actually be read by a screen reader. Another thing that we have to do is add focusable equals false, because of a bug in Firefox that actually focuses svg's and any any content that's focusable should be interactive. And as for the most part spg's are not going to be interactive. Without a label buttons again, provide no useful information to screen reader users. In this example. I remove the label and here's what it sounds like.
Collapsed button. So no label at all. If I'm just using a screen reader. I don't know what this button does. Here's a look at that Sr only class. That hides the of the texts visibly. It's using a combination of clip, pass and position absolute to visibly hide the the text and also to remove the text from the document flow, so it doesn't take up any physical space. Now that we have receivable content me and make sure that our content is operable. That means people should be able to interact with content in a
variety of ways. Contents and support different inputs, like mouse keyboard, touch and voice, as well as different context, like a desktop screen with magnification software or mobile devices. Full keyboard support is critical to supporting the widest variety of devices. So let's look at that first. The next week samples. I'm going to be using the Ruby on Rails repository on GitHub because GitHub really does a good job of providing good keyboard interaction. So we're going to start navigating using a keyboard on this page and you can
see the first thing that pops up is a skip to content link or skip link. Let me tab through again. So you can see all of the different things that you can interact with in this toolbar. Now, I'm going to go back to the skip to content link and activate it. Now. I'm going to start driving again and you can see I've skipped completely the the entire toolbar. So, this is a great pattern, especially if you have a lot of content in your header, even, even if you don't, I would say that this is a great pattern to use for any
website or application, unless you're just unless you just have a super simple site. You may have noticed also that is like tabs for the page. You could see where I was on the page. Thanks to the focus style. So the focus element of style. Delao me to know where I am and all the times on this page. I completely remove the focus Style. And I'm tapping and you can't see where I am. So this so that yellow Straits, the fact that it's very important to keep Focus Styles. A lot of times designers will want to remove Focus Styles because they
may not look nice. But it's, it's okay to restyle Focus Styles as long as they are still accessible, at least as accessible as the default. Soca Styles, if not more accessible. Making web content accessible is really about getting people options and screen, reader users have multiple ways that they can navigate quickly through content. And this demo on back on Safari with voice over. Lee's menu. So what I just pulled up is called the rotor. The rotor is sort of like a command center. It's a collection of different menus. This
is the links menu, but we have other menus as well that group certain types of content together and allow a stream M user to jump through content on the page very quickly. Let's arrow down through all these links. Is it created 470? So I'm going to stop right there. There actually a ton of links on this page. So navigating using links is not going to really say. He a lot of time whenever you have a lot of links on my page, but I did want to show. This one thing here. You can see where the focus is on the page. Currently.
It's on a label 2.5 k and the link text itself is different. It says, 2470 users are watching this repository. And the reason why that link text is different is because it has to capture the context of where the link is. The link itself doesn't have a lot of room there. So they're saving room by abbreviating a 2470. And it's right by watched. So you can tell about visibly by the context that 2,500 people are watching this repository. Well, you have to represent that context in the link
texted cell. So they're doing that here. Similarly, to how we put a label on the icon button. One of the most popular ways screen reader, users navigate a page is by heading headings are important to breaking up content for clarity. And they're one of the most effective ways to help people navigate complex Pages. Let's pull up the heading menu and in the rotor and navigate to the first heading in the read me. So now I'm on the first level, the first level heading up the reading page, but I really want to get started with Ruby on Rails. So
let me see if there's a heading of getting started. Heading out to heading out to. So voiceover provides a very convenient shortcut key to jump through or navigate the page using headings and I was easily able to jump through all of that content there. It's fine to getting started section. And now I can just read starting from here on down, very convenient. Another concern for keyboard operability is cussing, you. I this mean you follows the disclosure pattern. There is a button and a
hidden panel, the button toggles, the panel expanded and Laps. So, I can actually tab to the button kit return and open and close it and space and open and close it. I can also tab through the menu content and hit asked to close the menu. This keyboard interactions are standardized in the accessible Rich internet applications spec. Or why are you? You might remember that Aria, hidden attribute, I pointed out earlier. Well, Aria is a collection of Aria specific, attributes and rules, and relationships that helped
content, that's perceivable inoperable. We need to make sure that it's understandable. Declaring the page language is one way of making content understandable. The Lang attribute scene right here is actually set to English on the HTML element and this app is inherited. So every single child element will receive English as its language. And if you are including language, that is a different language, like a Spanish or French word. Then you want us around that content and set a different language attributes on that block. The
important thing here is that this helps screen readers understand what language they're parsing. So it helps them pronounce the word. Another way you can help make your content understandable is by providing clear errors. On this form example. I'm going to go ahead and hit submit without filling out any data and immediately I get these errors so I can see the first year is that my email is required. Let me fill this out. And as I fill it out, I see that the content is now invalid. So let me put a valid email in there. And
likewise, let me put a password in the password field. Let me hit submit and success. Screen readers, need help associating labels and messages with Foreman puts buttons are labeled with the button elements children, but inputs are a little bit different. Let's listen to what input sound like in a screen reader. Email, requiring a text or email is required. So it did a few things when we focused this email input. First. It announced what the label of the input is your email and then it told us that it was required and also importantly told us that it was invalid,
but didn't pause briefly. And it told us what the error was, that was associated with the input. And the way that we're doing that is first of all, we have a label element, which is another semantic HTML element and it has this for attribute that we sent to the idea of the reference input. Next we have on the input and Aria described buyer. There's another Aria attribute. Are you described by? And then we're setting it to the ID of the error message container.
So when you focus this in put the screen reader will read out the information for the input first and then pause briefly. And then it will read any content that is a child of anything in the description of the input. So right right here. You see that it is completely blank. This is before we fill out an error, but once an air is filled out when you focus this input, it will read out that description. Finally, in order for content to remain accessible. It must be robust. Robust content should be accessible to a wide variety of Technologies and
contacts and remain accessible into the future. And the best way to do this is by using a an HTML. Validator. You need to make sure that you write valid HTML these online HTML. Validator is are everywhere. This is the w3c HTML. Validator. All you do is you paste the URL of your website here and then submit it and hopefully you get this nice little green message that there are no errors. But if you do find errors, you can easily figure out where those errors are
on the page. And this is, this is a great way to prevent some really bad bugs, really bad, accessibility bugs, especially Another way to make sure that your content is Rob us is to make sure that your mark up has the proper rules and relationships Define. You know, I talked earlier about Aria, how it defines the roles in relationships. Well, the best way that you can do this, is that use semantic markup. I, I keep talking about some Mark. But it is very important. They're actually over 100 HTML elements and many of them have predefined rolls associated with
lot of HTML elements, like button. For instance, button has it handles keyboard interactions without having to do anything. So it's it definitely pays to use semantic, markup. Soon example of this, we've gone back to our little menu disclosure this first one here and you know, I can open it and close it, but I also have a duplicate one that I created looks exactly the same, but you can see the difference whenever we inspect. Dee's menu elements. So, the first one here
shopping website and I add an item to my card. And there's a card icon that automatically updates to the new card amount. You need to let screen readers know, that that's changed. In this example. We're using our form again. And what we're doing is we're alerting that there are errors present on the form. Voiceover on Safari. So there are errors appears in the screen, but it also it's its Dynamic and yet the screen M, picks up that text and the reason it's
doing that is because we're using another semantic HTML element the output element. The output element is a form element. That is dynamic. Basically, anything that happens inside of an output element, it gets reported to a screen reader and that's part of this area, specification called live regions and live regions. There's a lot of complexity to live regions, but basically had its hard, they watch certain regions of the page, and when those regions change, they let screen readers or accessible technology know, and
then that technology can then announce those changes. So we've been talking a lot about what can I add to a and all these different types of specifications and I think it's important to let you know that this is just the minimum requirement just because we meet a certain specification doesn't necessarily mean that our content is accessible. We're definitely on our way to being completely completely accessible, but we need something to confirm that. So the best way you can make
sure that your content is accessible is through testing manually testing with real accessible technology users. There are some great case studies out there that talk about how to do this. And there's one article in particular that second article on the stringing that they used. A company called Fable tech labs and all. This company does is they will test your content with real accessible technology users. So, this is definitely something you want to look into as your building accessible u. I So this
point you're he may be thinking. Wow, we covered a lot and you're telling me that we're just scratching the surface. This just sounds like too much. Let's talk about some ways that, and keep you from feeling overwhelmed. One of the best ways to do. This is through automation automated testing, is fantastic. It can help catch bugs that can help keep bugs out of your code, but it can also help keep your. You, I accessible automated testing into your CI, CD pipeline can give you important real-time metrics.
One of the things that the strategy that you want to use is to make sure that you're not adding new violations with every commit and also you want to make sure are you want to see if you're reducing violations with every commit There's some great tools to help you test for accessibility there plugins for Cypress, Cypress isn't into end testing solution, highly recommended. We use it at The Container Store. There's a score, which is a product from from GQ. This is the company on the screen right now,
A score is a framework. That a lot of tools are based on. There are plugins built with axcor Lighthouse, which is Crumbs, are Google Chrome's. Validator is actually built with White House, built with a score, for accessibility Audits and also like house has a great see eye solution Lighthouse. See ISO Check that out as well. You can scale accessibility with component-based design sharing a library. Of, you. I allows you to focus on one element at a time and any changes to
a single component can easily propagate throughout your entire website or application. What you're seeing here is actually from Brad Frost Atomic design and atomic design is a component methodology, that breaks Pages down into a hierarchy of composition. So you break your UIA down into simpler and simpler components into until you can no longer break them down. And this is a really interesting way of approaching component design. A component solution might look like web components. What components are basically a combination
of different Native web apis, that allow developers to encapsulate functionality and markup into a custom element. This is really interesting. I'm looking into web components right now, but I'm also discovering that there are some rough edges still and mainly around accessibility itself. Off the rails. Specifically flywheel have written a great article about how they use partial to create composable components. They make use of the cells Jim from Trailblazer. A cells are view models that encapsulate all presentation in rendering logic. So it easily
encapsulate all of the markup and behavior of a component and that should make it easier to bake your accessibility into these components. Some things you can do to help as you develop our manually test. So install a browser accessibility extension and run it regularly. I am a huge fan of a score Deadpool's which is the Chrome plugin for an ax out of the box. You can detect 57% of accessibility errors, and there's even a pro version that can detect up to 84%. I with guided test. Always test your interfaces with a
keyboard. Can you easily navigate? Can you operate the UI without a mouse? This is probably one of the best indicators right off the bat of how accessible an application or website is. I would really encourage you to learn a screen reader stream readers, especially the people that have never used them before. They can be very awkward, but don't get discouraged. I highly recommend using them. They they really do help. You. See your you, I in a completely different manner for Windows. You can download an in and install
nvda, which is a free open-source screen reader and form. A cup already talked about voice over its built-in. It comes with Mac OS. So definitely go in and download them. Open one up and check it out. Finally, start thinking about shifting accessibility to the left in the process as much as possible. Yes. You need to be thinking about it in design. You need to think about accessibility in development. But you also need to think about accessibility when you're writing feature requirements. And even
whenever you're hiring the earlier, you organization thinks about accessibility the easier if it comes. You may struggle at first, but accessibility is just like performance or security or every other complex subject that developers face the more you pursue it. The more you learn the better, you will get. Yes, it can be a lot of effort at first, but believe me but effort is worth it. I mentioned at the beginning of this talk that it's really about an idea and on the 30th anniversary of the World Wide Web sir. Tim berners-lee wrote a letter looking back at the webs Legacy
and forwards the web's future. He reiterated this idea as a core truth that the web is for everyone and collectively. We hold the power to change. It. It won't be easy. But if we can dream a little and work a lot, we can get the web we want. Thank you so much for watching this talk. You can reach out to me on Twitter. I'm out at the real Boon. I write on my personal blog and you can also follow me on deaf Community. If you have any questions, please don't hesitate to reach out. I hope you enjoy the rest of rails,. Thank you very much.
Buy this talk
Buy this video
Our other topics
With ConferenceCast.tv, you get access to our library of the world's best conference talks.