Web Accessibility for Designers: A guide to meeting accessibility guidelines for UI/UX designers | Cassandra Cappello | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Web Accessibility for Designers: A guide to meeting accessibility guidelines for UI/UX designers

teacher avatar Cassandra Cappello, Product Designer and Educator

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

13 Lessons (50m)
    • 1. 01 Introduction

      1:40
    • 2. 02 Why Accessibility

      3:01
    • 3. 03 WCAG

      6:48
    • 4. 04 Color Blindness

      8:18
    • 5. 05 Text Accessibility

      7:19
    • 6. 06 Forms

      3:34
    • 7. 07 Target Areas

      1:27
    • 8. 08 Language

      3:20
    • 9. 09 Vision Impairment

      2:48
    • 10. 10 Audio and Video

      1:29
    • 11. 11 Keyboard Accessibility

      4:28
    • 12. 12 Tools

      4:59
    • 13. 13 Conclusion

      1:03
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

141

Students

--

Projects

About This Class

Web accessibility is often something that gets pushed to the side. It’s easy to assume that all users can see, user a keyboard, use a mouse or touch screen, and overall interact with your website or product content the same way you do. But this simply isn’t true. Assuming everyone can use things in the exact same ways leads to an experience that works well for some people, but creates major issues or barriers for others.

Accessibility is starting to gain more traction in the design and tech industries, especially since more and more countries are creating laws surrounding accessibility. If you’re a web designer or a UI/UX designer of any level who doesn’t feel confident in their accessibility knowledge, this is the course that’ll level you up with practical skills.

What you’ll learn in this course:

  • How to design for those with vision impairment of different degrees

  • How to design for those with color vision impairment

  • How to design for those who are hearing impaired

  • Keyboard accessibility for all users

  • Creating target areas that work for all users

  • What accessibility tools are available to you

  • How to convince your team, organization, or client to adhere to accessibility standards

Meet Your Teacher

Teacher Profile Image

Cassandra Cappello

Product Designer and Educator

Teacher

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. 01 Introduction: Hi, everyone. My name is Cassandra, and welcome to Web accessibility for designers. I'm going to give you a brief explanation of what to expect in this course. This course is mostly going to be from a Web user interface or user experience. Designers perspective. We're going to cover the Web content accessibility guidelines, also known as the W C A G and the different options you have when it comes to making your website or sell for a product accessible. So, as you can see in the overview, I'm also going to go over some accessibility for the following areas. Color, blindness, different degrees of vision impairment, auditory impairment and other physical impairments like arthritis or even having a broken arm. It doesn't necessarily have to be a permanent impairment. I'm going to tell you specific things to look out for while designing, as well as giving you direct tips on what to do and what not to do in order to make sure that your product is accessible for everyone to use. I'll also be going over some areas that are specific to Web developers, not in terms of how to physically do these things, because after all, I'm a product designer and I'm not claiming to be a developer. I'll mainly be going over these things so that you, as a designer, can communicate with your developer or engineering team. And no, some of the integral things they need to do in order to bring your website or sell for product up to speed accessibility wise. So I hope you enjoy this course and good luck. 2. 02 Why Accessibility: why make it accessible? First of all, what is accessibility? Having an accessible site or software product means that the content is available and its functionality can be operated by literally anyone. It's easy to assume that all users can see use a keyboard, use a mouse or a touch screen, and overall interact with your website or product content the same way that you do. But that simply isn't true. Assuming everyone can use things in the exact same way leads to an experience that works well for some people but creates major issues or barriers. For others, accessibility refers to the experience of users who might be outside of the range of the typical user who might access or interact with things differently than you'd expect. Like I said before these issues people may experience could be permanent or temporary. As I said earlier, carpal tunnel or broken arm could cause issues when trying to use a keyboard or a mouse. Some people may think there aren't that many people who suffer from disability and that they're on edge case. We'll discuss this a little more later, but there are millions of people who suffer from disabilities in this world. Some of them are invisible, but it doesn't mean that they aren't there. And yes, even if there are fewer people with disabilities rather than not, the percentage of people is still significant. Why would you not want to increase your customer race as much as possible by making it available to everyone? As designers, we have the power and the responsibility to ensure that everyone has access to what we create. There's also a strong business case for accessibility. Countless studies have shown that accessible websites have better search results. Are Morrell Seo friendly, reach a bigger audience, encourage good coding practices and have better usability. Overall, there are also legal arguments for it in certain countries. Meeting a certain level Accessibility is the law. Some of these countries are Canada, which is where I'm from, as well as Germany, France, Norway and some parts of the of the United States. There are more countries that have adopted some kind of legal, accessible guidelines, but I'm obviously not familiar with, with all the laws outside of the place that I live. So I also want to make a point that there are different degrees of accessibility that will get into in our next lecture, and it truly isn't as hard as it may seem to implement. So if you're feeling overwhelmed or concerned about incorporating this into your projects or bringing this to your corporation, it's not as hard as you think, and I think you'll be successful in doing so. 3. 03 WCAG: the Web content Accessibility guidelines, which I'll refer to as the W C A. G from here on, has three levels of accessibility a double A and Triple A A being the lowest and easiest level of accessibility to meet in Triple A being the highest and most difficult level of accessibility. To me, the W C A. G is referred to as the gold standard inaccessibility. I obviously don't know where in the world that you are, so I urge you to look into your country's accessibility laws if there are any. Some countries have accessibility laws in certain fields, like transportation or banking, but that may not apply to your job. Some countries have their own set of accessibility laws that maybe aren't directly from the W. C. A. G. In most Western countries, there is some reference to the W C A G within their accessibility laws, or they have embraced the W C A G fully. For example, in Canada, newly created a refreshed websites as of 2014 had to meet a level a standard for reference . I'm recording this in 2020 and currently our laws are moving towards meeting double a standards. So by January 1st 2021 Web based products must meet double A standards, and this has been in the works for years. Companies that are not updating products or creating new products have had years to work toward the school meeting. Triple A standards is not legally required in Canada at this time. I don't think it's legally required in any areas of the world that I can think of. But if I'm wrong and that's the case in your country at this point in time, then be sure to look into it and comply with those standards. Also, keep in mind some countries may have different accessibility laws for government bodies versus private businesses. I can't really advise anyone confidently outside of Canada, so take time to do a Google search. I'm sure that your government website will outline the details. If there are any now, let's go over some general statistics surrounding accessibility. Like I said, I'm going to focus on North America since that's what I'm most familiar with. And if you don't live in Canada or the United States, I urge you to look up disability statistics in your own country so almost 14% of the Canadian population aged 15 or older, which is 3.8 million individuals, reported having a disability that limited their daily activities. Close to 56.7 million Americans, which is 18.7% of the US population, experiences some type of disability. Out of this number, it was found that 38.3 million have serious disability problems, which is 12.6% of the entire U. S population. This information from both countries comes from the most recent census that I could find that contain this information, which is from 2012. As you can see, there are millions of people in just these two countries alone that have some kind of disability. What that disability is could really very ah, but the point is I'm trying to make is that 14 to 18% is not as much of an edge case as you may think. That's close toe 1/5 of the population. Keep in mind the census does not include Children, so Children could also be experienced some kind of disability and adding to those numbers if there are a lot of facts and statistics at you. So what can you do with this information? As a designer, it be great if the company that you work for already saw accessibility as important. If they don't or legally don't have to, you can look into the laws. If there are any or share disability statistics for your country with your team or your boss, you can also share some business reasons for including accessibility in the design and development process. Like I said earlier, increased customer reach is a big one. I found that sharing this information over time can bring some people onboard into making their products more inclusive. If convincing your team or company is not a factor for you, we can get right into talking about the physical options available to you. So Option one. You can design your product or website to be completely accessible as is. What I mean by that is that there is one version of your site or product, for example, and it just is accessible and meets all the guidelines it needs to for all users all the time. Option two. You can use something called inaccessibility toggle so you would have a non accessible version of your website or product, and then somewhere there would be a toggle in order to put in order for the user to put it into accessibility mode, I personally prefer to do Option one. If I can make it accessible and just do it once, why wouldn't I? It would do reduces complications in away some good reasons to employ an accessibility. Tolerable instead is that maybe you want to update your site or software to be accessible without completely redoing it, because it already exists, so you can have an accessibility type toggle on your site, header or in the settings of your application. This could be for a few reasons. One common one that comes to mind is that the company's brand color is an ex inaccessible color for those who are colorblind. So instead of changing the brand entirely, they will create accessibility toggle, in which the brand color becomes much darker. A good example of this is the IOS interface eso. If you have an iPhone, you can go into your settings and turn on your accessibility toggle. From there, you'll see the shade of blue that IOS uses for text suddenly is a darker shade of blue. At the end of the day, both of these options were good. They both followed the W C A. G, and they both could meet legal standards, which you choose is really up to you and your situation. 4. 04 Color Blindness: colorblindness or, more accurately, color vision deficiency is a Nen heritage condition that affects males more frequently than females. An estimated 8% of males and about 1% of females have color vision problems. If you're not color blind, it's kind of hard to fully understand what people with different types of colorblindness see on some design software is. There's plug ins that will show you what your design looks like to those who are colorblind . One I like to use on sketch is called Stark, and I've linked it as a reference alongside the structure on the screen. I'm going to show you a rainbow color palette I created for the sake of this example, and I'm going to go through the eight different types of color blindness to show you what this palette looks like to people who have these kinds of color vision deficiencies. The most common types of hereditary color blindness are due to the loss or limited function of the red cone known as proton or green cone. Known as Du Tran photo pigments. This kind of colorblindness is commonly referred to as red green colorblindness, so there are four different types of red green colorblindness. So, as you can see here, this is what our rainbow palette looks like when you have protein obeah and dono pia. And here you see another kind of red green colorblindness, which is prote anomaly. And do you after anomaly. The next less common type of color blindness is blue yellow color blindness. You can see in this example that it looks very different from the previous ideas of red green colorblindness. So this is try tote anomaly, and the second type is try to Zenobia, the final and least common type of color. Blindness is complete color blindness. It's rare that people are completely colorblind, so you can see here we have our crop AC Roma tonally and AC Roma top CIA. Uh, and this is what people would see if they see very limited color overall and no color at all. So now I'm going to give you some tips for designing for colorblindness. The first tip is to avoid the following color combinations, which are especially hard on color blind people. So they are green and red, blue and brown, blue and purple, green and blue like re in yellow, blue and gray green and gray and green and black. I don't actually expect anyone to memorize these combinations, but they're just combinations to try to avoid where possible. And you can always refer back to this or this information can be found on other websites. I'm sure when you're choosing colors, the second tip is to make it monochrome, so this isn't a must. But using various shades of a single color instead of multiple colors is, of course, a surefire way to avoid color blindness issues. That's because if you're using one color, you'll be creating different shades of that color, so each one will have different degrees of darkness and lightness. People who are colorblind are surely able to see the different degrees between light and dark. So if you choose to different colors, you might not notice that they have the same level of saturation or whatever. Other similar to that might be so to a color blind person. Those colors may end up looking indistinguishable. Tip number three is to use high contrast color. Blind people can still perceive contrast as well as difference in hue, saturation and brightness. Use this to your advantage. Many color blind people report being able to better distinguish between bright colors rather than dim ones, which tend to blur into one another. So I'm just showing you an example of a website that used a lot of bright colors. Four is bigger lines. Some mildly color blind people are able to see a color, but only if there's sufficient mass to it. If a line of color is too thin, it won't show up as the right color. Keep in mind, you don't necessarily have to do this for components that don't need to be focused on. Like if you have a divider. That is really not a huge focus for the user. You don't need to add more mass to it so that it can be more easily visible for color. Blind people. Um on example of this is this website that I'm showing you like they have text along these lines, and maybe they wanted to bring attention to that by thickening up those lines. Another example would maybe be in a form field. Let's say you didn't fill out the form field, and now it has its outline or underlying turns red, for example, you might want to add some weight to that so that people who are mildly colorblind concede that that outline has gone from black to red. Number five is very important. Don't assume colors will signal emotions in and of themselves. If you're using red to signal bad or warning, consider adding another symbolic element to get the point across to colorblind viewers. An example of this could be on alert. Icon. Another great real world example of this is trail. Oh, so that's what you're seeing on screen right now. They allow users to color code their tasks and labels, but they also have an accessibility mode or all the colors have patterns. If you're colorblind, you at least be able to differentiate tasks via the pattern. If you can't buy the color now getting into color contrast eso color contrast between text and its background color is going to be the thing you'll be checking the most. As a designer, there are a lot of color contrast checkers out there all links summers, reference material, the sketch plug in I previously talked about. Stark also has a built in color contrast checker, So to meet double A standards, your body copies contrast ratio needs to be 4.5 to 1, so these numbers are on a scale from 1 to 21. The first number, 4.5 in this example, references the luminous of light colors. Love. The second number one, in this example references the luminous of dark colors. So 4.5 no one should address multiple visual impairments like color deficiencies and age related loss of contrast. Sensitivity. Large text is considered 18 point or larger for accessibility purposes. So for large text, the contrast ratio is a little lower. It's 3 to 1 because the text is bigger. People who have vision deficiencies are more easily able to see the text. So ah, higher contrast ratio just isn't needed. When you put your text and background colors into a color contrast checker, it will let you know if it passes a double or triple A standards and whether passes any of those levels with body copy or large text. 5. 05 Text Accessibility: Another thing you have full control over as a designer is text accessibility. Since you are the person who will choose the textiles, eso in general letter forms and symbols should contrast well with their background. The typeface shouldn't be too condensed or to extended, not too thin or thick or not have thick and thin variations within the structures of the letter forms. So a few typefaces that meet these requirements Oh, are Helvetica Ariel Future gill sans for Dana, Avenir Franklin Gothic and for Tigger, and you can see examples of them on the screen right now. Clearly, these are essentially very readable Sand Saref, so anything in that family will work just fine. It doesn't mean that these air the Onley fonts that you have to choose from, there are hundreds that you have to choose from, but something that seems similar to one of these examples eyes probably a safe bet. There are also guidelines in the W. C E g for line height, also called letting. If you're a graphic designer, um, so the W. C A. G states that line spacing should be at least 1.5 times the font size. You're working with and space between paragraphs should be at least two times the font size . So as you can see here, we have three different examples with different line spacings, which is literally the space between each line of text. So based on what the W. C. A G literally says, I would argue that the statements are misleading because saying that the space is at least two times the size means that it could be infinitely bigger, and then you're spacing would still be accessible or legible. This is obviously untrue. Too much spacing is Justus Bad is too little spacing. As you can see in this example, the 1st 1 has to little spacing. Second option was with one mill has too much spacing. It's still difficult to read about in different way, and then the third option on the right has just enough spacing. Uh, so you really want to keep your line height around 1.5 times the size of the body copies font size and the paragraphs pacing around two times the size, Ah, of the font size. If you're following proper typography rules, then you'll also adhere to accessibility rules in eight Lee, because you're still allowing people to read text as optimally as possible. So what that translates to is if your body copy is 16 pixels, your line height is 20 pixels. That's still within the realm of acceptable for people to read, which is close to what the W. C. E G calls for. Similarly, the guidelines for letter spacing is that it should be at least 0.12 times the font size and word spacing should be at least 0.16 times the font size. Once again saying at least is misleading year, it is really more like approximately these sizes. Um, so as you can see, we have three different examples once again on the far left. It's too tight in the middle, the letters or too spaced out and on the right. The letters have a good amount of spacing between them that it's easy to read, and it should be accessible, so letters and words being too spaced out would get terribly difficult to read. As you can see, I'm showing you what all these look like. One of these options is clearly easier to read. Also keeping month these concepts and examples I'm using are related to Latin character sets since I speak an orc in English. If you're typesetting in a different writing system. Thes con, these concepts may need to be slightly adjusted. Some other basic rules from the W C G to make your text accessible are number 12 Never justify your text. Justification creates gaps between the words, which makes it difficult to read. So would be best to not set your text to justified a ragged edge, which is what you see. Ah, in the 1st 3 examples is best, since it's actually allowing for consistent word and consistent letter spacing within each line. So, as you can see justified text on the right, if your graphic designer you you may understand the term about to use, there are a bunch of gaps those gaps in graphic designer called Rivers. So the justification is creating a lot of rivers, which does break up the user's ability to read. That's something that is really difficult for anyone. It doesn't have anything to do with, um, a specific kind of I cite problem. In this case, there is no like specific disability that I can think of where this is now hard it it obviously, is more difficult if you have, like low eyesight. But it's just innate lee difficult for everyone to re justify text that has not been properly typeset. As you can see, the other three options are much easier to read, so there are also some rules surrounding images of text, which I feel like our rarely used nowadays. But if you are using images of text that is decorative and contains no other visual significance than there is no color contrast requirement, this contrast requirement also doesn't apply to logos, which is the only calm, common example of an image of text that I can think of. So if you're branding color doesn't meet the contrast requirements. It's fine to leave logo as is, but maybe you could use a different color for other elements on your site or product to replace the non accessible brand color, except for captions and images of text, users also need to be able to resize text within their browser without assistive technology , up to 200% without loss of content or functionality. So in short, that means that users should be able to zoom into a Web page or what up up to 200% to meet this guideline. And this is for people who have low vision, which could be for multiple reasons. So this is something that a developer would be in charge of no designer. But it's still important to understand what needs to be done outside of your direct control to make sure that sites are accessible for everyone. 6. 06 Forms: there's so much that goes into creating accessible forms. One major thing is that you always need to help people understand what they should do and write in a form field. Which is why it's best if labels don't go away. Even when a person is filling out the field, Having a label that's within the input area means that people lose or context once they start typing. If they filled out the field incorrectly or accidentally filled out that wrong field, they probably wouldn't be able to tell, since the label has been replaced by whatever they've typed. Some options you have when designing forms are toe have a permanent label above the field, as you can see here in this example, in the one that is correct, not the one that is incorrect. And the second option is a material US style form field, which means that the label is also the placeholder text until you begin typing and then it animates to become a label on top. So this is another way of getting around the concept of always having a label present on a similar note, just like you should be providing labels. You should also provide instructions. When content requires a user input, this could be taken in two ways. One way is that you should provide instruction, usually under the field, regarding what the user is supposed to fill out. Maybe the form label is too vague, and you want some accompanying helper text to help the user understand the second way you could take. This is providing air messaging, which would appear under the field as well, usually eso. When an error occurs, you want to help the user find where the problem is. For example, if you should be highlighting the field with the error for them to see if this is a form field on a mobile device, then you should also have the browser APP Scroll to wear the field with. The error is, since it may be out of you for the user, you'll want to make sure that you provide a specific, understandable explanation regarding what the error is and also suggest corrections if you can. So, for example, if someone fills in a price field with letters, your text should specifically say that this field was incorrectly filled out and that it Onley except numbers with two decimal points, for example, that will help the user be able to fill it out correctly the next time cause maybe, for whatever reason, they did not realize that they cannot put letters in a price field relating back to the use of color. You also want to make sure that visual representation of the error isn't going to be too subtle for people who have some kind of vision impairment. For example, the form field just turning red could be too subtle, especially depending on the color of the field. When it's not in its error state, so you could add an icon you could add aRer text underneath. You could change the color of the label or any combination of these things in order to make sure that it's clear that this is an error state and that there's not just a simple color change. But there's some kind of obvious addition or change in this state 7. 07 Target Areas: a part of user experience that doesn't solely have to do with accessibility is the target area of buttons or any other clickable element. Some people could just have larger hands and others. Some people will have some kind of motor impairment, so this is really something that's useful for everyone. If your users have motor impairments, it may be difficult for them to select items on the page with precision. It's the job of designers to ensure that the target areas are not too narrow or hard to access. The W C. A. G has a minimum acceptable criteria, which is 44 pixels by 44 pixels. So that is a target area, minimum square size 44 or 44. Of course, your target area could be larger. Your button could have a target height of 44 pixels, and the width of the button could be 100 50 pixels, so that target with could become 150 pixels to match. This is just a highlight. That 44 pixel should be your minimum standard, so this should be suitable for everyone. But you can increase your minimum standard if you choose to. For example, Google products often use a target area of 48 pixels. Instead, whatever you choose, make sure that it meets this minimum standard and that you use it consistently and that the size of the target area you've chosen physically fits your design. 8. 08 Language: There are several general regulations in place in relation to language used in a website or digital product. From a development perspective, the human language of the Web page needs to be programmatically determined. This also applies for multi language sites. This is the screen Readers and Braille devices can automatically identify the language being used on the site, which will go into more later from a design perspective. Sometimes we as designers need to write small amounts of copy for websites or software. This is usually things like buttons, headings, labels, etcetera. So you're going to be looking at some good examples of this in the next couple of slides, where I'm showing examples that have clear text and and copy. So there are a few basic rules that come along with this. Firstly, all headings and labels need to be described need to describe the topic or purpose of the page field or whatever else they're describing. A Z conceding the example. This is pretty straightforward. You just need to put in the time to make sure that your copy makes sense to most, if not all, people, and is relevant to the topic at hand. This example is a pretty good one. Each of the sections and the tabs are all quite clearly named, uh, nothing too surprising there, which is exactly what you want. Once again, in this example, the buttons directly relate. Teoh. What kind of information you're going to get on the next page, the text and does. It does match the intention of the button and what the user is going to get into next. So continuing on. Secondly, the purpose of any link which could be link text in a paragraph or a button, for example, can be determined from the text alone or from the link text together with its programmatically determined link context. I know it's wordy, but that's essentially what I was saying before, where it's like the buttons make sense in relation to what is going to happen next. If I go to shop all, I'm going to go to a page of items that I can buy. If I go to the button that says the multi vitamin A multi vitamin 18 plus, I'm going to be taken to a page that talks about a multivitamin for people who are 18 plus , uh, yes, like I was saying, unrelated to the example. So in a nutshell, this means that the ideal your link text should describe what the link is doing. For example, not related to the one on screen. If I have a car design with a button under it that says Go, that's ridiculously vague, I don't know what I'm going to, but if it says view more recipes, clearly that is descriptive. And as user, I would understand there is Link leading me to a page full of recipes, right? There are some situations where ambiguous text is acceptable. For example, if you're creating game and you have links to three doors in which the user isn't supposed to know what's behind the doors, because that's the point of the game. Giving the doors ambiguous names would make sense, since the purpose is to create suspense for the user 9. 09 Vision Impairment: 57% of adults reported some form of vision loss, the majority of which are corrected by lenses. Complete blindness was reported by 0.9% of adults. The World Health Organization estimates that there are 246 million people worldwide who have low vision and 39 million people who are blind, which indicates that 86% of people with visual impairments have low vision. I'm telling you these statistics, because in a business environment, I often hear that blindness is comparatively unimportant because it's so rare and not worth supporting in the product. I beg to differ, since the whole point of making your product accessible is that it should work for literally everyone, which includes those with severe vision loss. The most well known thing that people with low vision often make use of is screen readers in order to hear the Web. In a way, there are different types of screen or years, no, all working exactly the same way. But in general they work similarly enough. Of course, any text on the site or APP will be read by the screen reader, setting up more detailed information from a development perspective is what really makes or breaks experience for those of vision impairment. One major issue is that screen readers need to be able to read imagery. They do this using all text, which is short for alternative text. So here's an example of what all text looks like. An HTML on the screen right now. Their descriptions in the code in the code attributed to the image so that screen reader can inform the user what the images related to you can also describe the image in the body . Copy instead, as long as the users aware of the context of the imagery, you want to be sure to describe what's happening in the image and relate how it pertains to the text. So, in short, don't use generic language like picture for your old text. You want it to be more descriptive than that. If the image is purely decorative or like I said, if there is a description in the body text to accompany it, you don't need toe at all text. But adding an empty old attribute will usually make the screen reader skip it. If you don't write any all text, some screen readers will read the file name to the user, which is the worst experience you can provide. So that image could be named as a string of numbers, for all we know, as this is a small detail. But it needs great attention because it does actually affect millions of people around the world who are using screen readers. 10. 10 Audio and Video: There are several regulations when it comes to audio and video for the hearing impaired. Let's go over these regulations separately. So the 1st 1 for pre recorded audio some kind of alternative needs to be provided that presents equivalent information when dealing with pre recorded audio Onley content. So this means that captions air provided for all of this audio content, you can provide close captions or permanent captions for the hearing impaired. Caption should also be provided for live or pre recorded audio content. If for whatever reason, you prefer not to or choose not to provide written captions, then sign language Interpretation needs to be provided for all pre recorded audio content. Sign language interpretation is also included in the guidelines for Triple A on the W. C A. G. So if you're trying to meet a triple A level guideline than you need to include sign language, it's not on option of captions versus sign language. When it comes to pre recorded video only content, some kind of alternative or audio track needs to be provided that gives the viewer equivalent information. If the video has a company audio, obviously an audio description needs to be provided for that pre recorded video as well 11. 11 Keyboard Accessibility: keyboard accessibility means that as creators of digital products, we ensure that all interactive elements are accessible via keyboard. For those who have a motor disability in which they can't easily use a mouse or maybe can't use one, it'll this could be due to an array of reasons, like a permanent motor disability. This could be due to arthritis or temporary issues like carpal tunnel or a broken wrist, etcetera. If you're not at all familiar with what it means to be considered accessible by keyboard, it essentially means that the user can navigate the site completely by using the keyboard. Mainly, the top button is used to move through different interactive elements. The space bar on the enter key can also be used to add or save elements if you're creating something new or editing something in this product. The escape and delete or backspace buttons are also commonly used in order to delete ed, emit order or delete elements. Arrow keys to navigate are also very commonly used. Keyboard accessibility is one of the most important aspect of Web accessibility since it affects so many users. Not only does it help users who have a permanent motor impairment. It also helps users with temporary disabilities, and blind users often use the keyboard for navigation as well. I obviously haven't covered every type of user that this effects, but the group of people is quite fast. I'm going to go over different interactive elements that are commonly built wrong for keyboard accessibility. It's not enough to just make sure that your site or Web app is keyboard accessible by making sure the user can simply tab through everything. There needs to be a consistent experience in how each key is used, and there needs to be a certain logic to the navigational order, which is a huge thing that people often overlook. I'm going to go through several examples of this showing you calm analysis elements where this could be overlooked. So the first example on the screen right now is models. Because motels are technically an off screen element, it could be a huge accessibility disaster if it's not executed correctly. When a user has a motile open and is navigating within that motile, it's necessary for the focus to remain within the motile and not move through any of the elements behind the motile. As you can see in the example would be extremely time consuming to tap through all the elements behind the motile to get back into it. If the models open, the usability to focus should be essentially stuck inside that motile. Another common one is hover states. Since hover states and focus have different functionality, many products have actions hidden under hover states. A good example is Facebook's hover states for reactions you shouldn't skip past the Hovers Day. If you want to make sure that your site or product is accessible, as you can see in the example on the left, the user is blocked from opening the tab without a mouse on the example on the right, you can see that applying a focus to that tab opens up the hover and allows the user to focus over each item within the hover component. The last example. I'm going to talk about His car design cards are very commonly used in products these days , and there's a lot more structure and guidance over how cards should be designed. But sometimes there's difficulty creating accessible, accessibility friendly cards due to their varying complexities and interactions. Gmail is a good example of accessible car design. As you can see, they sign a focus ST for cards. When they're now the aid to all hover actions are accomplished when the card is on focus and Onley actionable items can be focused, not every element within the card. Hopefully, these three examples have helped you understand the complexity of keyboard accessibility. These were the most common components with added complexity that's often overlooked by design and development teams. But it's extremely important to pay attention to these details if you want to create a good experience for all users, especially since sometimes people just like to tab through items for no disability related reason, so this is extremely useful to almost everyone. 12. 12 Tools: There are several types of accessibility tools out there for different platforms. We're going to go over these tools for the Web for IOS devices and Android devices. So let's get into Web accessibility talk holes, which we talked about a lot earlier in the course, which are basically the tools available in order to make an accessible version of your Web site or Web app. Like I said earlier, of course, you can't just make your product or site accessible from the get go. But if you can't or don't want Teoh, either building inaccessibility, toggle or buying a service that provides built inaccessibility toggles is your next best option. So now we're going to get into all the available tools for IOS devices. A developer should be ensuring that your application works with the relevant tools that come with the U. S. So some tools may or may not be relevant to your app. For example, if you have no video or audio component, then you don't need any close captioning. The first tool we're going to talk about is IOS voiceover, which allows users to use gesture based controls in order to hear a description of everything happening on the screen, they can adjust the speaking rate, pitch and language. IOS has over 30 languages available for voice over. This is essentially the IOS version of a screen reader. So if you want Europe to be fully accessible, your development team should be ensuring that all the text works with voiceover on a similar note. There is also the voiceover Braille Keyboard. It's pretty self explanatory. It's a Braille IOS keyboard with audio typing feedback. There's also guided access, which restricts input for certain users so that they can stay on task. This is usually used for users with autism or other sensory or tension related challenges. The last tool for IOS is captioning and descriptions, which is also pretty straightforward. It allows you to configure captioning and audio descriptions during video playback as a whole. IOS has an accessibility toggle to go into accessibility mode as well, for your application and just for your device in general. Okay, so now we're finally going to discuss all the tools available on android devices. The first is to use a screener here, so the screen reader that comes with Android devices is called the Talk back screen Reader which allows you to interact with your device using touch and spoken feedback. Talk Back will also describe things to the user, and the other option available for users is also called Select to speak, which I'm not showing you on the screen right now. This is still talk back, but it is very similar. So basically allows for your spoken feedback toe only occur at certain times, which you can set one in the same vein. They also have voice access, which allows users to control their devices with commands so it's hands free if that is an issue for your users. Switch access also lets users switch you switches or their keyboard to control the device instead of the touch screen. This could be because users have some sort of mobility issue in which it's difficult for them to accurately use the touch screen. And just like IOS, Android devices also have a Braille keyboard, which is called Braille back, which allows users to use Braille display in combination with talkback, which are still seeing on screen if they so please. So all of those ones that I just talked about are interconnected. Android also allows users to change their font size in their contrast and color options so you can adjust that toe work with their needs, whatever those may be. There are also several audio and captioning tools. Of course, you can turn on captions, which includes live captions if needed. Users can also use live transcribed to capture speech and view it as text their sound amplifiers for those who are hard of hearing and hearing aid support to users with hearing aids that compare with android devices in order to hear the more clearly. Clearly, this was a lot of information on, and there's many tools available that you can make sure applications work with. These tools are there to make everyone's life easier. So I recommend you look into it if you're completely unfamiliar with, um and this should be something that your organization or that your development team should also be aware of, and they should be working to connect these already existing tools to the application that you guys are trying to create 13. 13 Conclusion: Hopefully, this course has helped you understand accessibility as a designer. Some of this went into the realm of development, but it's important to know what the scope of accessibility can be, at least a high level. Just to recap the course, we discuss the W, C, A G and different statistics around accessibility. We covered accessibility for color vision, impairment for vision impairment to varying degrees, hearing impairments, mobility impairments and general concepts that could be difficult for many people, not necessarily because of a permanent disability. In the previous lecture, we run over all the common tools available to help ensure that your app is accessible. I hope that you've seen how important thinking about all these elements can be. There are millions of people who are unable to use the majority of products easily if it'll It's our responsibility as creators to ensure that these processes are made easier for everyone. I want to thank you for taking my course. I hope that you've learned a lot