Designing & Creating Accessible Web Pages
Appel, Rachel
All too often, popular websites and apps fail to design for accessibility, unknowingly resulting in a huge loss of users who cannot use or access their site. It's all due to a lack of accessible design. That's around 20% of the world's internet users, or 1.4 billion people in total! In this session, you'll learn how to prepare content, design, and code using techniques that enable those with visual, auditory, motor, or cognitive impairments, so that the 1.4 billion accessible users can now use your apps effectively. You'll learn to access what your customer's accessibility needs are, as well as how to code with accessibility in mind. You'll learn about ARIA elements and design practices to keep in mind while crafting webpages and app layouts that adhere to Section 508 requirements (The USAs federal requirements for accessibility). Upon completing this session you will have learned to design sites and apps with better UXs that have the farthest reaching user base.
 afternoon. How are we doing? Are there people way up there? It's like lights and things. I am Rachel Appel. Welcome. This is Designing and Creating Accessible Web Pages. It applies to apps too. Basically any software with a UI, this stuff applies to that you can do. So for the next hour, we'll just take a look at things you can do. And they're actually surprisingly easy things you can do to make your site more accessible and actually make it way better than what a lot of websites have out there. Pretty much anything you need to know about me is at RachelAppel.com. So you can go there and it has links to like the decks to download and all that kind of good stuff. And there's my email as well. So you have that too. This talk is, they always ask if you want it to be an introduction or advanced or intermediate. And this is really none of the above. This is just things that you should be doing anyway in your web apps and native apps. Just practices that you should do. There's not really any visual studio code in here. You'll see some code on the slides. But that's about it. And a lot of this is just things to do, not necessarily a whole lot of writing code. There's a little bit of code to do, but a lot of it's other things, other techniques we can use to work with accessibility. So we'll take a look at all that in the next hour. So we'll look at content first, then accessible site layouts, accessible pages. You know it's coding. We'll see a bit of HTML, but nothing terribly deep. Or probably not much new in HTML itself. There are a few attributes we'll see with ARIA. But not anything like terribly like way, unless you've never done HTML before, it should not be way out of your ballpark. And a few tools at the end that we have to help us out. So here's the first reason why you want to have accessible software. So there's 7 billion people on this earth. Of course they're not all using the internet. But 1.4 billion of them can't, if they could access a website, can't necessarily access it in the same way that other people can. Or that the stereotypical user can. That's a significant number. It comes out to about 20%. In the U.S. alone is 268 million out of 314. Have some sort of accessible need. I see many people in this room that do as well. Just by looking at you. I could tell. I do too. I'll show you how in a minute. So there's a real business value to this. We tend to do things like think, hey, I'll develop for the masses. But this 20% is a small mass. That's a big number in business. Managers, like they see a number like 20% and a manager is all over that stuff. So that's kind of a big number. It's not like you're missing out on 1% of people. And even if you were, you might still want to pick up that 1%. Considering how easy it is to integrate and implement accessible techniques, I would go after it even for 1%. It is still a payoff to you to have that quality software. So that's one reason why it's so 20% of the world. A lot of people. There are many popular websites. Even in the US, we have a lot of Forbes, Business Insider, some of these popular viral type of sites. Or there's cats. Everybody loves cats. Cats are the internet. I think that's the whole reason why the internet exists. So we can see cat pictures. So people can't look at their cat pictures because the whole rest of the website is blocking them from even being able to do things like that. Or Forbes sometimes will pop up annoying ads and make it in such a way that they want to push an ad in front of your face. So when they do that, they literally stop you from actually being able to use the site. So that those people involved in organizing the site are kind of shooting themselves in the foot by doing that and to not making it accessible. And that's 20% that they're missing out on. So it's a lot of people. It's worth it. And the payoff is way out of proportion, way great for what you do. You really want to reach all of your customers. As many as possible. Probably can't get everyone when you're using something like a website. But we want to go for the broadest reach possible. So here in the USA, and what accessibility is all about is making sure that you're non-stereotypical, which would be considered someone not necessarily able bodied, possibly, but something like auditory, vision, dexterity, any kind of difficulty. And of course, aging populations. We have a big, at least in the US, a big baby boomer population. So it's a slightly older folks in the generation ahead of me. Not that old. So those folks are starting to, you know, the aging process. I myself, right, text gets smaller. Things are harder to see. My glasses get thicker all the time. So it's the same with everyone else. Things fall apart as you get a little bit older. An interesting stat, 35% of entrepreneurs, ironically the same people making some of these popular websites, are actually dyslexic. And if you are dyslexic, it can be difficult to navigate and consume content from a non-accessible website. It's 20 in the UK. A Forrester Research Group gave even more numbers. So I think we're getting the point here. Lots of people need various pieces of help with being able to consume and deal with and work with your website. So sometimes it impairs them so badly they can't even work with the software at all, which is the opposite of what we want. So I'm a little bit more of why. If we think about human traits, it runs across a spectrum. Some people have 20-20 vision and some people are blind. Those are those opposite spectrums. And then in between, we have folks like me with glasses, getting progressively worse. Other people have other issues, maybe from low hearing to no hearing, to very good. So it's always about the spectrum. And if we at least capture the edges, we should be able to capture the spectrum within it. And all of this, it affects how people interact with your site, with everything else. You get in a car, certain disabilities make it difficult to drive a car. Being blind kind of makes that impossible to drive a car. Google will solve that soon, I think. So we have for these four types. So this is our main categories of accessibility practices. Visual, that's pretty clear, our eyes. Auditory, so there's hearing issues. Text-based websites are not so bad with that, but we have YouTube and lots of video, more and more media and animations that people have to be able to deal with for hearing. And motor indexarity, I even noticed myself. I used to be a lot better at actually using a mouse. It's not like I haven't been using a mouse for, say, 30 years now. But just as I get older and I have carpal tunnel, so that thing that wrecks your hands, right, and my hand gets a little jerky and it gets a little harder to actually click on the right thing, I will probably click on the wrong thing at least once in the stock. I used to not do that. My arm is just getting worse. So that would be a motor accessibility problem or dexterity. There's also cognitive. So we have various autism, all kind of different things that can affect how people consume or interact with your software. And it's more than just websites, even though I'm mostly focusing on websites here, but we have apps and devices. Everyone has a phone. And I don't know how many times I see people doing this with their phone because they can't see it. And everyone's doing this because you can't hear anything. So the way we interact with things changes if we don't have that stereotypical able bodiness about us. So we want to make this better. We want to make it better for everybody. So if we want to make better websites and apps, we need to make better assistive technology. Well, that's what a lot of people think. But when you actually ask people that have accessible practices, they said, we don't want better technology. I'll show you the technology that they do have in a minute. We don't really want that. We want you to make better websites. Imagine that. Isn't that what every user actually says? We want better websites. Hey, we're developers. We want to make better websites. So it's a win-win at that point. So the vast majority, 81.3%, said, you keep making these technologies to help us. But if people just coded the websites a little better, we wouldn't necessarily need extra software to help us with software. So those kind of things. So that's the impact. A lot of people, some would like better technologies. Some have to have certain devices to help them with technologies. But most would prefer just a better website. As far as visual differences, well, first off, somewhere in here is a slide. So who is actually using assistive technology yourself right now? Because I see several of you who are. Not a hand. Anyone have glasses? There you go. You're using assistive technology. It's low technology, but it is an assistive technology. We have all these physical things that we do to ourselves. And if I didn't have them, stuff's blurry. Not blurry, not. So I need this, no matter how good the software is, unless they're really going to blow the font up that big, I need a little bit of assistive technology. But what I would prefer is people to up the fonts on most things, and then I can see it much better. So that's our first thing. And one of these accessible points are visual differences. So we have just poor sight, like me. Blindness. So you have to listen to everything. You can't see anything. So typing is not the worst problem there. We do have Braille input. However, it is listening to things on websites, text to speech for auditory disabilities. Then we have color blindness, color contrast, which are two different things, as well as those auditory things that I just mentioned. So if we have color blindness, how you perceive a web page, the shades and colors that you use may blend so closely together that many folks can't tell if you have a cancel and a submit button, and one is, say, green or blue or different shades, it may look almost the same or it may look like it should be red when it's not. So those kind of things, we have to at least take into consideration. And in contrast, I think even if you don't have a visual accessibility, if you color contrast, if you have really light text on really light background, you just can't see it. It's just too light. So that happens quite a bit. And you don't even need accessibility for that. That's just not good contrast. So we'll take a look at that color oracle in a minute. The next ones would be auditory differences. So you have low hearing. As you age to, get a little bit of low hearing, complete deafness, right? That happens as well. So then they can only interact visually if they can do that way. And then background noise. So I have this problem. If I'm at a party and people are talking, all that background noise makes it difficult to hear what's going on when I'm talking sometimes. So I think I'm falling apart with all these classes and hearing and all that. Other ones, there's a whole list here. All these things. You have an injury that can create, like carpal tunnel, that can create a problem. Any kind of spinal cord, any traumatic injuries, congenital injuries, or not really an injury, but you're born that way. Things like Lou Gehrig's, even arthritis. These can be very crippling. There are so many things. And these are not, you know, they're common, common enough that there's quite a few people out there with at least one or two of these different things that we need to consider when we create software. Cognitive differences. A couple other ones here. So dyslexia I mentioned before. ADHD that's a very popular cognitive impairment. People are able to live successfully with both of these. However, it does make it a little more difficult. Even though you may be successful, there's still some difficulties. And if I can take that roadblock away from someone so that they can smoothly progress and use my software, that's what I want to do. So I want to make it easier for that. So we have autism spectrum, injuries, visual stuff, learning seizures, all kind of things. Some of the things you'll see, I know people like to pass around optical illusions and cool things like that, which is fine. However, sometimes a website will sneak in something that just startles your eyes or something that flashes or flickers. And if you are someone who's prone to seizures, that can cause a seizure. Yeah, the Simpsons made a cartoon about it, but it still actually happens to people. There's also various learning disabilities. So if you're writing software, especially if you're writing educational software. So there's people with learning disabilities, and I've had clients where they did not have accessible software, even though they were creating software for schools. Oops, probably want to work on that. So we got in there and cleaned that up and made it more accessible, and even for learning disabilities as well. So with all of these different, we saw those four types. We have our auditory, visual, motor, cognitive. We have assistive technologies that we can work with to help ease the pain a little bit for these folks. So one I mentioned before, some you're already using. Some of it will actually be physical hardware. Here's another one. Things like the trackpad. It's actually supposed to be an assistive technology at one point, because the mouse is not very conducive for all people. Some other good ones, good old magnifying glasses, the same as glasses. It's still an assistive technology. But there's more, more exciting ones, if you will. Like the screen narrator. So I'll show you a screen narrator coming up. So that's pretty popular. We also have this Braille reader. It's just a sample of one. If you are impaired as much as, say, Stephen Hawking, he used to use a mouth stick, and now they actually have super high technology for him, and he just blinks. It's like a blink indicator. And that's all he needs to do. Head wands, sip and puff, all of these. There's the mouth stick. That's kind of like over in the U.S. we have this staples, and they have this red thing called the easy button, and you press it, and that's what that's a lot like. So we have just a nice, easy single switch access. Just tap it. Adaptive keyboards. Even non-accessible people will use some adaptive keyboards as well. It just makes it a little easier. There's also eye tracking glasses that help. And of course, voice recognition software is not just for what we would think of just, hey, dictation. Now it actually helps a lot of people to be able to be able to give input. They do not have good use of their limbs. You need an alternative way to input, so that wouldn't be a mouse, and it would not be the keyboard, so we need something else. So voice recognition, when we don't have those other items, but we do have our voices to deal with. And this is just a few of the assistive technologies that are out there. There are some others, but these are probably the most popular and the most important ones. And you can go and look on Google through the images. They're copyrighted, so I didn't want to put them in here. Just put these in there. But some of them about the head wand and the eye tracking glasses, you can see pictures of those if you look online. So it would be nice to see what you might be dealing with. It's good to know that if you're going to write software that this is going to aid with. So there's another keyboard, like an adaptive keyboard. Now if we have a visual issue, we may need a screen narrator. So with this, we have one that I like the best, I think is the good one, and it's free. Some of them cost some money. One of them is called NVDA. Web anywhere is good as well, and that is an online only. NVDA is something that you download. And of course there are some specific narrators. If you only have, like IE or Chrome, there's also Apple voiceover. So you have these different narrators available. So if we take a look at say a narrator, so I have NVDA, and if I crank it up, so it'll pop up. Oh, let me turn on my audio here. So it sounds like that. It's very robotic. The welcome screen comes on and I can tell it, like, I'll just go with the defaults, click OK. And then what we'll do is maybe bring up one of these websites and turn this back on. Now if you heard a bit of what that was saying, robot voice, it takes a bit to get used to that sometimes. It was going through and it said, hey, we're at WebAIM. And this is, by the way, since we're at WebAIM, if you go to webaim.org, this should be really the first place you go to if you're going to do anything accessibility. And these folks work with Mozilla and whatnot to help get this content out. This is one of their tools. And what it does is that screen reader will narrate what's on the screen. So when it does that, it goes through the logo. It may need to go through the menus and then tell you that there's an image here. And, you know, if you can imagine just closing your eyes and then listening to what would be happening on a web page and considering some of the stuff that is on web pages, a lot of stuff is going on, it's a difficult job for a screen reader. It has to go through and figure out is something visible or not because it doesn't want to read things that are not visible. It has to go through and see what's important. Sometimes it can't and it just reads everything. And things like links and menus sometimes actually get in the way of that. But if we want to listen to it, we can do that for another minute or two here. And let me go to another page. Let's do good old MSDN. Let's see what it says about MSDN. There we go, MSDN. Someone needs performance, something on that team. There we go. So, we'll just turn this on. Dialog Cider 8082. Are you going to do more? Yep. Learn to develop with Microsoft Developer Network MSDN Google Chrome Window. Learn to develop with Microsoft Developer Network MSDN Banner Landmark. Visited Link Enos. Visited Link Developer Network. Link Sign in Link MSDN Subscriptions. Link get to task dialogue Cider 82. So, if you listen closely to what it was saying, it also goes a bit fast. But it does have a bit of a British accent for a robot voice. Interesting. What it will do is it has to go through. It's the first time I have visited this page. It has to tell me that there are links here and what's down here and what's in the slider. And it doesn't always pick up things exactly because it has to interact with all this code and everything, but it does a pretty good job. It will go through the entire page too, if I let it. So, that's a lot of stuff. Even stuff down here if it needs to. And if we think about it, if I maybe refreshed this or just go to Microsoft.com and I learn how to type. And we'll crank it up and then just close your eyes and listen to it. Cider 82. 9.8 is pop. Classroom U.Tip and SILAR. Classroom Microsoft. Microsoft Office. Elh. Gemyside. Google Chrome. Oh, and it's in... Oh, being that this came up in Norwegian. Who? HTTPS. Sash. Sash. www.microsoft.com. Sash. NB. No. Sash. Default. Asks. I like how it can't pronounce ASPX. That's kind of fun. So, I think...... Being that this comes up in Norwegian, it doesn't know what to do on anything in Norwegian in there. So, that's another problem is we would need a localized version for Norway. But as you see, the crux with scanners or screen narrators is that it has to go through and goes through every time. And if you think about webpages, they usually have a banner and some links or breadcrumbs. And it has to do this like every single time, which is kind of annoying. I can see the first time a page comes up and go through and read the links because you need to know, but it keeps doing that. So, we'll take a look at a way to make it stop doing that and just skip over those links. But other than that, this is how people who are blind have to use the web. They need to use one of those screen narrators. And really, the only way to really, truly get a good page going with a screen narrator is just to load up your page and sit there, blindfolded, and listen to everything it's saying. It'll take a while to get through an entire page. We only have an hour here, but I think you can get the gist of it just from these little clips of NVDA going on. So, we do want to make sure that we're kind of screen reader accessible, and we'll see a little bit more of that in just a minute. With that, screen readers need to get through content. So, actually, the number one thing you could do to reach many, many more people and make it easier on them is making fonts bigger. There's almost not a single website anymore that actually has a decent font size. They're all tiny. And then I end up, I think most all of my browsers are at like 150%. This one's only 110, because I knocked it down for the other demo. I go into them, they're usually much, and I don't even need 110 because web aim makes large font. But I go to other websites, and I'm always zooming in, even with glasses and stuff. It's just too small, too tiny, too much little stuff. Other things too, and not just for visual folks, but the cognitive folks. We need things clear, right? Clear sections, clear headings. Clear sections and headings, and you can use your h tags in HTML for that to block them off. And you can also use the HTML semantic tags, like the footer, header, section, article, nav, those tags that came out with HTML5. You can use those. If you use those, screen readers will pick them up, and it will know exactly which section it's working in, and it will allow the user to more focus in on that section. When you have screen readers like NVDA, you can often hover over a part of the page, and it'll try to read that. But sometimes, if folks are just using divs or spans, it doesn't really know if that div is for an actual section of the page, or if it's advertisements or something else. So those semantic tags help us organize good code like that. A high contrast for colors, that's kind of important, too. So I'll show you a contrast thing in a second. Labeling. Here's another one. Even if you don't have accessible needs. There's sometimes you'll see a label, and then another field, and you don't know what the label's for, or they might call it a save button on one page, and a submit button on the next, which is inconsistent. I'm not a fan of inconsistent. I like consistent things. So clear and consistent labels and clear and consistent forms. I have an entire section on forms for us. But here, these labels make sure they are labeled, and you can actually use the HTML labels. And things like movies and animations. This is probably going to be one of the more... It's not difficult. It's just time consuming. Get an intern. Get one of them. And get closed captions. A lot of YouTube has closed captions, and usually, if it's something recorded, like a lecture like this, you can just take that recording and run it through a speech to text, and then capture it that way. So it makes it a little bit easier, and then have an intern go in and change it and make any modifications for the little boo-boos. I have a nice article, and actually I have one in MSDN Magazine, and one at my website about programming accessible websites and apps that go into details of things you can do. But this is really not difficult to just organize your pages nicely and make it easy and clear for people to read. So here's contrast that I said we'll have. This is crappy contrast. Who can't see it? I can barely see it, and I'm standing in front of it. You can't see it, but it's not the greatest, right? That's better. Now, the colors may be ugly, but you can see it. That's good contrast. Eh, eh, right. That's, it's better than the first one. Not as good as the second one. That's okay. That's right. So as you're starting to see, mostly if you get, if it's a light background, dark text. The dark background, light text. And things like certain colors like purple and gray don't contrast well, or certain blues and greens. You can usually see it just, it's just a little bit more difficult on the eyes to recognize what's going on. Of course, black and white is good contact, good contrast. Things like this, actually just staring at this for a few minutes, and then your eyes start to get a little, they hurt a little bit from looking at some text. So things like the, the bottom ones, of course, the red one is better. This is okay. There's a lot of people who will not be able to see this at all, because it is a gray text on white, and a lot of websites do, instead of black on white, a lighter gray on white. And that makes it difficult for many people. Many people have contrast issues where the first one, second one, or this third one, this, this pretty much this column except for the bottom one, and that little one on the end, they're just not the best. So just try to keep, and this is kind of easy. You can tell your project stakeholders contrast. Just make it a darker and lighter, so it's easier to see. And they usually say, oh yeah, good idea. And then off you go, and just simply doing that does a lot better. So here's another one with visual, visual problems. Right, so color blindness. Here's for my website, done four different times, not reprogrammed. All I did was I took the accessibility color wheel tool, and I put my URL in there, and it told me what my website would look like if I were color blind with one of these type of, there's three different types of being color blind. I can't really pronounce them that well. They're kind of big words. Deuterinopia, protonopia, and tightnopia, that one's a little easier. But as you see, now my page is just dark blue and white, and we're done. But some people see it as purplish, and the other see it as purplish, and my face is kind of green here. I'm not a fan of that. I don't look good with a green face. Here I'm looking a little pink, very pink, and this is green. So depending on exactly their level of color blindness, depends on how that page looks. So if I had a blue submit button, someone may see that as green, and depending on what shade of blue, it may even go off into what looks like another color for somebody. So the cool thing is you can go to this color wheel tool, and there we go, and you could go through here and put in some URLs and poke around and load up one day. Yeah, we'll come back when that loads up. So you can put it through, and you can see things like this. There's also a little tool called Color Oracle you can download. It also makes you download Java, JVM, which is kind of annoying, but it's a cool little thing. You could just have it do the same thing as well. It will tell you whatever you're looking at on screen doesn't have to be a web page. It could be a Windows app or something. It'll tell you about that. Also a great reference is there's this whole site on MSDN that does designing with color. And it's artist, very artist type of stuff. So it's more than just accessibility, which that's a good part of it. But just, you know, the theory, of course, they do that. Oh, wait a minute. At least they gave a link. There we go. But here it tells you things like if you use this color, this other color goes very well. Those kind of things. And those colors that go well tend to be better for accessible folks. So just kind of artsy stuff often helps with accessibility. Here's the color wheel, too. We can come in here and choose different foregrounds and backgrounds. So if I choose, there's, look at that. I see stuff like that all the time. You probably do, too. That yellow is so hard to read. That's right here. Then you end up highlighting it to see, changing it to a different color just to see what it is. We can invert that and it would be just as bad. So you could just come here and check with your color wheel. See, hey, that's not bad. And it'll even give you a little check mark to see what it's like. That's kind of crappy. Red text tends to fight with other colors a lot. Red and yellow, red and green. All that. So those things are good. Oh, and there's the little, you just go to colororacle.com. It shows up in your tray. But it is a, it's a tiny download, but it comes with Java, so that makes it a big download. You want to know why Facebook is the color it is? You probably guess. Because Mark Zuckerberg is colorblind. Right? He's red, green, I think. So that's why it's blue, because he could see that. That's the whole reason. We move from content to design, things that we want to do for design. Again, clear and consistent, not just sections, but navigation. This also, if you notice a theme here, most of these things that make it difficult or even impossible for an accessible user are at a minimum just annoying for a regular user, a non-accessible user. Things like navigation. When people change up the navigation, it's hard to follow. It doesn't matter if it's accessible or not. It's just bad navigation. The clear page layout as well. You could use HTML semantic tags to do that. There's maybe six of them. There's not a lot. They do the job. They do it well. Of course, again, clear content, distinct sections. The pop-ups. You'll probably, if you're doing a public website, have to fight with some marketing person over this, because they like pop-ups. But it does. There are so many people that simply cannot use these popular, fun, viral sites that they like because of stuff like that. It's so simple. A, pop-ups are, nobody likes them to start with. Screen readers as well. Screen reader will start reading the page, then a pop-up pops up. Some of the screen readers don't even know what to do because you have all this dynamic stuff going on. They just, they're done. They just die. Or they'd start trying to read the pop-up. Then you see the little link counting down up in the corner that is so tiny that you can barely click it, especially if you have a hard time with the mouse. Then it goes away after a while. Then the screen reader gets upset again and it doesn't know what to do. They're annoying. A lot of users, I will see people just dumping the website. Not even going to it. I even knew that myself just because it's annoying. If we're going to code accessible pages, it's part of our design and coding. At least over in the U.S., we have the practices here that apply anywhere. I think there's a European version of this, but I don't, somebody here could tell me I'm sure. What we call Section 508. There's a checklist at AIM that would help adhere to that. It's just this cool little checklist of basically what I'm telling you in this talk. These kind of things to do. You can go down and make sure that you have it checked and then run this cool little web AIM tool to see if that's happened. If I come over here, I actually have web AIM up somewhere. Here it is. If I go to webwave.webaim.org, I just come in here and I could pop in any URL. If I do microsoft.com, it's going to go through and it's scanning that page. It's going to tell us, I love doing this with Microsoft, then I could find little nitpicky things and complain about it because it's Microsoft. I used to work there. I know people who complained too. It's taking a while. There we go. Here's the first thing. We would get these three little bars here of styles, no styles, and contrast. You'll see a little summary of 55 errors that we have. Alerts, all these different things that you have. You can come here and you see it marks up the page and you can look at what's happening there. I could even, there we go. Took it a minute. Some of the yellow ones are okay. It's just that you might do something to make them better. Green is usually good. Red stuff though, not so good. I could come here and see what's going on. This is a huge page. Try to load in a smaller one. Chrome, did you lock up? Yes, it did. Thanks, Chrome. That was nice. I suppose there's nothing you can do. Yeah, I know. Thanks. Let's try that again. There's really nothing you could do with accessibility when Chrome just dies. It all just goes to hell. It'll come through. This is telling me something. If WebAIM has a hard time scanning it, it's probably not very accessible if it's having such a hard time. If we do, I'll do a wave again. I'll put my own site in here. If you don't want to just run things online, no problem. You can actually download this tool and then just run your pages through it locally. There's, I believe, a plug-in for Firefox in which you can do it there as well. There comes mine. Mine's not bad. There's one red error, a couple of alerts, mostly because I forgot a few headings. Things like alt attributes on an image is actually very important. Screen readers don't know what to tell people. They can't just see an image and tell people, hey, that's a cat. It can tell what's in the alt. If you put something clear and descriptive, this is a cat. The cat is purple, whatever color the cat is. Then the screen reader can read that tag. Once in a while, if you don't have an alt or something, that one I guess I forgot, there's no image there. That's why. Here's the good stuff, bad stuff in between. As you see, you hover over things and it'll be like, hey, there's some stuff. Look, there's a header. Here's this. It gives you all these cool little things. Over here on the side, you get it with styles. You don't have to see the styles and contrast. There's another way to check your contrast. I actually ran this through the contrast and I actually left it go on purpose. This is mostly contrasted. The only thing on my site that is not is this little tiny date and how many comments are in there, which if somebody goes into that site, they're going to see it in good contrast. I should probably make that darker anyway. That's my slacking, I guess, right there. We have our tools. Where's our? Somewhere in here. That's what I like to do. I like to go and run them through the wave tool, come out and check the contrast, check the styles, all that good stuff. It's really easy to do that. Again, you can download it if you don't. A little bit more for coding. This should be good for people like this. Mobile First. Everybody's kind of doing that anyway. Usually, if you practice mobile first development, you're doing things like considering a tiny screen in which you need to make things different in a formatted way so that people can consume that pretty good. If you design with mobile first, you're going to tend to have less junk in the page. The ads are not going to get in the way as much as a big page. It tends to be a little more trim and a little bit less bling, a little bit less eyesores, which makes it easier basically for everybody. What we want to do, though, as well, mobile or not, use ARIA. I'll show you on, I think, the next slide or so. These things called skip links, which are part of ARIA. Those help screen readers go through and read properly. Of course, we have to be keyboard and alternative input friendly. Keyboard is really not too bad for most people. However, if you're, we have just keyboarders here, like I hate the mouse kind of people, a lot of coders are like that. If you do almost 100% of your work just with the keyboard and you try to do a tab and tab through a web page, it's all over the place. It'd be tabbing up and down in no particular order very often. Then I will see people putting tab orders in that are not correct or out of order. You want to make sure it's keyboard friendly. All those other devices, like the Braille readers and things like that, make sure that that's friendly as well. In a slide coming up, I will show a few of those alternative ways to make things keyboard friendly. It's really simple, just doing a few things with these, what's called aria, adding them to your form. It's a tiny bit of code. Works great. If you're going to code, good thing the marquee and the blink tag are gone now. Those little things. First thing that came into HTML to go. So any strobing, flickering, flashing, those kind of things make it difficult. And crazy JavaScript makes it. It's fun to write crazy JavaScript. Not so fun to be on a page with crazy JavaScript popping up things. I've seen now they're taking to popping up an ad and then popping up an ad on top of an ad. How far are they going to take this? It's going to be ad after ad after ad. I hate ads on the web, pop up ads. I stopped watching TV because of ads and now they're all over the web. So one of these things to do to make it easy to navigate and then friendly forms are these things called skip links and they're part of aria. And if we look at this, this web aim organization has created what is called aria or it's accessible rich internet applications, aria. And it's just a set of small things you can do to make your applications rich on the internet. One of them is what's called the skip link. So as I mentioned before, when I go through with or any screen reader, it'll read the logo and then it has to read the links. And then I go to the same, maybe this next page and I click on that. And when I get to this page, it needs to do the same thing. It reads this, reads the links. If you're a sighted person, hey, that's no problem. You just don't look there. If you're not sighted and you have to have a screen narrator, then you have to painfully sit there listening to that over and over. It's kind of a pain. So what we could do is say, hey, screen reader, how about you skip over these? We'll tell you where to go to get to the good stuff first. And this is kind of a small navigation. You see a lot of sites with tons of links across the top. Oh, MSDN perhaps. Yeah, like, oh, look at, and then these things. That's not good for accessibility, Microsoft, by the way. That stuff. And then stuff down here. Oh, and not just that, but maybe even some of the stuff that gets, there we go. Some of this is possible. I do not want to sit through all that. That was painful. The irony of non-accessible accessibility page at Microsoft. Just saying. So these skip links. So this is one way to do this. And so if I come here, web aim does these perfect. Just go and see what they do and you do it. It's very easy. So to make the screen reader skip them, what I do is I just use an HTML, a named reference. So you do the little pound sign and name. And that will help us. So if I come in here, I'll look at the source for this. I had the source open. If I just look for anything called skip in here, it's easy. What they do is they create a little div. I zoomed a little far there. I like the big text. All right, so we create a little div. Skip to content. And this is what it is. It's this link before the rest of your links that just says, hey, screen readers, you go here and skip to that. Screen reader will look for this. And if it sees something that does that, it can go to there. Now there's a few more things in here. If I take a look, here's some of the other links as well. Oops, I have a skip. But that's basically all you have to do is in the somewhere in the top of your page, come in here and tell it where to skip to. Now this doesn't necessarily show up on the top here. All right, I zoomed a little far again. There we go. So these skip links, you could do it one of two ways. You can actually just have these as regular links and then say to the screen reader, take that and skip over those links. Or some people don't like to display the links and they have other navigation. You can just make it so that it's invisible. And you could do that by doing this, just setting a little bit of CSS. And that's actually what they do at WebAIM. So they have the regular links and then like a little hidden skip link. So the reader sees this hidden skip link. And it says, skip over all that stuff, go right to the content. And it doesn't visually display it for the people who are visual. So we just set it like way off to the left and just make it tiny. And then the reader will pick it up. But the user never has to see. It's a bit of a hack. It's a bit of a known hack. They'll fix that one day, I think, make it a little less reliant on CSS if you want them invisible. Another, now here's a good coding technique, again, the semantic tags. Now we have these ARIA tags that I just mentioned. And if I look here on WebAIM, there's a whole set of ARIA links. And you'll see things like, if I had a form, I could tell something, I want to make this an ARIA or application of rich internet. So I could make it that. And I could just take any HTML element and say, you're now going to be an ARIA element. It's nothing special other than the fact that ARIA elements work better with assistive technology than nothing, which is what we would have otherwise. So we have these ARIA tags. Sometimes, though, you'll see one where you can use a semantic tag, like with checkboxes and things like that. So we want to start with semantic tags before we get to the ARIA tags, but we kind of have to know about ARIA tags as well. So semantics, which is your HTML, your article, header, footer, nav, there's one or two others. A section is another one. And it's basically just your tag that says, this is an article on my blog or on my website. This is a section on my website, a section for ads, a section for this or that. So that's all that it is. It's just plain old tags. Once we run out of those, we should actually be doing this anyway. We should actually just be using HTML semantic tags that use the HTML standard now. So we should just be using them anyway, but they happen to partly be there because of accessibility. So with the ARIA, so that's the whole actual acronym, web accessibility initiative, accessible, rich internet applications. It's like somebody on the.NET team got to name this somehow, like giant name, the irony that you've, of getting through that with maybe an accessible problem. It is actually a W3C protocol. So there is an RFC for it. You can go to W3C and see the specs on ARIA. And all they are are attributes that go into HTML. So it addresses those missing semantics. Now this was around before semantic tags. So that's why there's some ARIA stuff that semantic tags ended up kind of taking over, if you will. So that's why that has that. But it addressed those missing semantics at one point. Perhaps at a later date, I'm hoping that they'll start to incorporate the rest of ARIA. I've heard that they're supposed to incorporate the rest of it in as just part of the HTML spec like they did with the semantic tags. That would be pretty cool if they did that. So with ARIA, they're all attributes. And they're basically attributes that tell us what this element does. And there's these three categories of them, properties, like what an element does. Is it a button? Is it an input? What is this? And remember, this is for a screen reader, not a person. States, which is the condition. So you might see ARIA checked to tell the screen reader that a checkbox is checked. Or you might see ARIA disabled to show that an element is disabled. Properties, like a required. You'll see kind of like your validation ARIA required. So these are just there to make assistive technology better. As far as those roles go for ARIA, we have, we'd sell it as a whole ARIA application. You could set banners. So if it sees ARIA banner, knows that it's maybe part of a navigation and logo. And that a screen reader is going to say, hey, I could just skip over that after the first time I read it. Forms, of course we want forms. That'll be an important one. Navigation's another one. We want to tell it ARIA nav to say when to navigate. And also searching as well. So we have these different roles. And the states. The ones in red are those ones where you can usually use a semantic tag instead. So if I wanted to label something, I could just use a label. Or described, I could just use a label. Same thing. Disabled. Just disable something. But there's other ones. If I need popups, I can say this particular div or span is going to have a popup. So I can say ARIA has popup equal true and we're good. Or just ARIA has popup. Don't even need the equal true. It's just a bit flag. These ARIA elements help us create accessible forms. So this way, so here's a problem. People fill out the form and then they click and things happen. And those things that happen is often JavaScript first before it goes over to the server. And JavaScript is a bit of the bane of the existence of an accessible user. JavaScript, first of all, readers don't know what it's going to do. And readers can't. They're not compilers. They don't go in there. They can't read the JavaScript and just figure out what it's going to do. It has to wait until the JavaScript is doing it. And then the reader tries to adjust. So when a popup happens, the reader had no idea. The narrator says, oh, something happened. Oh, there's more HTML here now. Let's read that. Or sometimes it just can't even do that. It doesn't know what to do. So if we want to work with this, we need to watch a little bit of JavaScript. So things like alerts and warnings. I think we're kind of over that phase where you'd click a button and you'd get a JavaScript popup telling you about validation. Now it's usually not so modal, not in your face. As much as possible, it's getting harder to do this. Trying to do things where anyone test by turning off scripting and then testing your site. That scares me a little to even try it on most sites. Scripting is just everywhere. Probably won't be able to get 100% on this. But try to see if you can run some of your sites with the least amount of scripting possible. The problem with not having scripting is then it's not the greatest experience most of the time. So we want to weigh that fact of not having the best experience with some nice, rich JavaScript versus the not so great experience of an accessible user. And we do have a majority-minority thing here. So we kind of have to weigh that and balance that. And of course, security and stuff like that. So if a validation happens, JavaScript will pop up something and the screen narrator just doesn't know what to do again because it's dynamic. And you can't necessarily even go anywhere. Once a pop-up message comes up, you have to do something with it. And if it's not a sighted user, they don't necessarily know to click and the screen reader is supposed to tell them, but it can't always because something dynamic happened and it didn't know what was going on. So for forms, along with trying to not kill people with JavaScript, trying to balance that, things that we want, make sure your tab order is good, which usually means not putting in tab orders. Another one that screen readers often choke on is if they JavaScript focus on the first field and screen readers, then some of them will just automatically start reading that field, which sometimes is okay, but sometimes not. Blinky stuff, buttons and links, they need to be big. So we have those multiple input devices and I will often see tiny, tiny links, tiny, tiny fonts, tiny, tiny buttons that is hard to click on or hard to tap on. A lot of accessible users don't use the mouse, possibly not even a keyboard. They're using the other devices and they need to tap or puff or something like that and tiny links and tiny buttons are their enemy. It's just impossible to work with them. So we could use ARIA again for all of that. So what we could do if we want to use ARIA to do that, we first want to use good old HTML and set up our field sets. So we could use that more semantic type of paradigm. Then we could have our fields and we want to put in legends for checkboxes and things that we want to group, radios, those kind of things. We could put them in a field set. If you're an MVC person, ASP.net MVC and you do a file new project, it actually puts some of this stuff in for you, the field set and all that good stuff. If you do Windows app development, like when JS, it actually puts in ARIA tags for you, which is kind of cool. So here's all the coding accessible forms, things we want to do. My label, right? So I don't need to use anything special, but make sure it's labeled. Use a label tag instead of just a span or something like that for what element. And then we have the input for that element. And then here if I have some validation, I might have a span to put it. And here's something else too. So you'll see this. But instead of saying the word required, you'll just see a little star, tiny little star. And it's hard for a lot of folks to see that. And a screen reader doesn't know what that is necessarily. Just a little star. It goes asterisk. And that's all it says, which tells us nothing. But it will see the word required. And it will say required. This is required. So that's the first thing we want to do is to make sure we have labels and inputs. And ARIA, every ARIA element is ARIA- whatever. From that slide a few slides ago, with that list of them, there's only a handful of them. But in this case, if this is required, so if I want to make this sample from the previous slide required, actually required, I come here and I tell it ARIA-required equal true. And then if there's a few, there are several screen readers out there. And if one of them hasn't quite caught up yet, or it doesn't work the best, that happens. At least the ARIA tag, it will definitely pick that up. Even if it kind of says required or doesn't pronounce it well, or does some other kind of boo boo. So we just do the ARIA-required. If I had, say, a check box and I wanted it to be checked by default, because we're sending a newsletter, that's why you do that. Then we would just say ARIA-checked, or ARIA-checked equal true. And we would make sure that that's checked and that the screen reader tells the user that it's checked. If they're blind, they don't necessarily magically know it's checked. So we just add ARIA attributes to what we want to tell the screen readers how to behave with that. I don't have the forms. Three minutes. So some of the tools, I showed the scanner and the 508 color contrast. This is a good one, this WCAG checklist. There's the same thing at web.com. Web content accessibility guidelines, that in a checklist are really good. So I come here pretty much any time I'm going to deploy anything. I come and we check the checklist. That was not what... Sometimes you copy and paste and it just doesn't seem to copy and paste. Or it's me. There you go. How about without that stuff? So here, this checklist. This is good. So it gives you all these different things. And you just go through. And it gives you all these recommendations. And you may not be able to do every single thing. But it's just a list of these things that I've been talking about. They use semantic markup. Make sure things are zoomed. Make sure things are meaningful and organized well. Use color correctly. So literally just a list. You print it out. Check it off. Write a little script or utility so that you can check this off at time that you're going to deploy. So I like checklists. That's how airplanes run. They go through checklists and checklists and checklists. I think they automate that now, though. Even so. Nice. I like that. You get to do all that. And then you could go to the scanner. Run things through your scanner. And if you just do these few things like using semantic tags, ARIA tags, watch your color contrast and consider color blindness. Add some of those ARIA elements into your forms. Make things big and clear. And those are not hard things. They're very simple things. It's not a lot of things either. But it helps quite a bit. It helps an order of magnitude for other folks that may have problems accessing your website. So I kind of like this. It's a big bang for the buck. You can now reach 20% more of your user base just by implementing these few things. And even if you don't get to them all, implementing some of them is better than implementing none of them. It will certainly make a difference to the users you implement it for, whether they're an accessible user or not. It benefits the non-accessible users as well. So that's like the real benefit of accessibility, is it actually helps everybody, not just those who are accessible. Oh, there's also 10 more free screen readers. There are lots of pay for ones. You can go find one that you like. A usability geek is a really good site. Anything with usability, making it easier to use. Also, there's a nice blog on NVDA in particular, since I kind of like that one as well. So usability, that's like lots of nice screen readers there you can test. And that's the thing I would suggest you do. Actually, like blindfold yourself, get the screen reader, and try to navigate a few web pages as if you were blind. It's a bit of a challenge, especially the first few times you do it, even after that. It's a very different thing. So if you can imagine, that's difficult for them as well, even though they may have been living blind for quite a while. So these things help everybody, regardless of who we're technically targeting, accessible users. So I like things that are good for everybody. It helps us all. And that's all I have. So thanks for coming. I think actually it was five minutes over, right? Yeah. Okay, well, thanks for coming. If you have questions, you can come up.
 afternoon. How are we doing? Are there people way up there? It's like lights and things.  I am Rachel Appel. Welcome. This is Designing and Creating Accessible Web Pages. It applies  to apps too. Basically any software with a UI, this stuff applies to that you can do.  So for the next hour, we'll just take a look at things you can do. And they're actually  surprisingly easy things you can do to make your site more accessible and actually make  it way better than what a lot of websites have out there. Pretty much anything you need  to know about me is at RachelAppel.com. So you can go there and it has links to like  the decks to download and all that kind of good stuff. And there's my email as well.  So you have that too. This talk is, they always ask if you want it to be an introduction or  advanced or intermediate. And this is really none of the above. This is just things that  you should be doing anyway in your web apps and native apps. Just practices that you should  do. There's not really any visual studio code in here. You'll see some code on the  slides. But that's about it. And a lot of this is just things to do, not necessarily  a whole lot of writing code. There's a little bit of code to do, but a lot of it's other  things, other techniques we can use to work with accessibility. So we'll take a look at  all that in the next hour. So we'll look at content first, then accessible site layouts,  accessible pages. You know it's coding. We'll see a bit of HTML, but nothing terribly deep.  Or probably not much new in HTML itself. There are a few attributes we'll see with ARIA.  But not anything like terribly like way, unless you've never done HTML before, it should not  be way out of your ballpark. And a few tools at the end that we have to help us out. So  here's the first reason why you want to have accessible software. So there's 7 billion  people on this earth. Of course they're not all using the internet. But 1.4 billion of  them can't, if they could access a website, can't necessarily access it in the same way  that other people can. Or that the stereotypical user can. That's a significant number. It  comes out to about 20%. In the U.S. alone is 268 million out of 314. Have some sort of  accessible need. I see many people in this room that do as well. Just by looking at you.  I could tell. I do too. I'll show you how in a minute. So there's a real business value  to this. We tend to do things like think, hey, I'll develop for the masses. But this  20% is a small mass. That's a big number in business. Managers, like they see a number  like 20% and a manager is all over that stuff. So that's kind of a big number. It's not like  you're missing out on 1% of people. And even if you were, you might still want to pick  up that 1%. Considering how easy it is to integrate and implement accessible techniques,  I would go after it even for 1%. It is still a payoff to you to have that quality software.  So that's one reason why it's so 20% of the world. A lot of people. There are many popular  websites. Even in the US, we have a lot of Forbes, Business Insider, some of these popular  viral type of sites. Or there's cats. Everybody loves cats. Cats are the internet. I think  that's the whole reason why the internet exists. So we can see cat pictures. So people can't  look at their cat pictures because the whole rest of the website is blocking them from  even being able to do things like that. Or Forbes sometimes will pop up annoying ads  and make it in such a way that they want to push an ad in front of your face. So when  they do that, they literally stop you from actually being able to use the site. So that  those people involved in organizing the site are kind of shooting themselves in the foot  by doing that and to not making it accessible. And that's 20% that they're missing out on.  So it's a lot of people. It's worth it. And the payoff is way out of proportion, way  great for what you do. You really want to reach all of your customers. As many as possible.  Probably can't get everyone when you're using something like a website. But we want to go  for the broadest reach possible. So here in the USA, and what accessibility is all about  is making sure that you're non-stereotypical, which would be considered someone not necessarily  able bodied, possibly, but something like auditory, vision, dexterity, any kind of difficulty.  And of course, aging populations. We have a big, at least in the US, a big baby boomer  population. So it's a slightly older folks in the generation ahead of me. Not that old.  So those folks are starting to, you know, the aging process. I myself, right, text gets  smaller. Things are harder to see. My glasses get thicker all the time. So it's the same  with everyone else. Things fall apart as you get a little bit older. An interesting  stat, 35% of entrepreneurs, ironically the same people making some of these popular websites,  are actually dyslexic. And if you are dyslexic, it can be difficult to navigate and consume  content from a non-accessible website. It's 20 in the UK. A Forrester Research Group gave  even more numbers. So I think we're getting the point here. Lots of people need various  pieces of help with being able to consume and deal with and work with your website. So sometimes  it impairs them so badly they can't even work with the software at all, which is the opposite  of what we want. So I'm a little bit more of why. If we think about human traits, it  runs across a spectrum. Some people have 20-20 vision and some people are blind. Those are  those opposite spectrums. And then in between, we have folks like me with glasses, getting  progressively worse. Other people have other issues, maybe from low hearing to no hearing,  to very good. So it's always about the spectrum. And if we at least capture the edges, we should  be able to capture the spectrum within it. And all of this, it affects how people interact  with your site, with everything else. You get in a car, certain disabilities make it  difficult to drive a car. Being blind kind of makes that impossible to drive a car. Google  will solve that soon, I think. So we have for these four types. So this is our main categories  of accessibility practices. Visual, that's pretty clear, our eyes. Auditory, so there's  hearing issues. Text-based websites are not so bad with that, but we have YouTube and  lots of video, more and more media and animations that people have to be able to deal with for  hearing. And motor indexarity, I even noticed myself. I used to be a lot better at actually  using a mouse. It's not like I haven't been using a mouse for, say, 30 years now. But  just as I get older and I have carpal tunnel, so that thing that wrecks your hands, right,  and my hand gets a little jerky and it gets a little harder to actually click on the right  thing, I will probably click on the wrong thing at least once in the stock. I used to  not do that. My arm is just getting worse. So that would be a motor accessibility problem  or dexterity. There's also cognitive. So we have various autism, all kind of different  things that can affect how people consume or interact with your software. And it's more  than just websites, even though I'm mostly focusing on websites here, but we have apps  and devices. Everyone has a phone. And I don't know how many times I see people doing this  with their phone because they can't see it. And everyone's doing this because you can't  hear anything. So the way we interact with things changes if we don't have that stereotypical  able bodiness about us. So we want to make this better. We want to make it better for  everybody. So if we want to make better websites and apps, we need to make better assistive  technology. Well, that's what a lot of people think. But when you actually ask people that  have accessible practices, they said, we don't want better technology. I'll show you the  technology that they do have in a minute. We don't really want that. We want you to make  better websites. Imagine that. Isn't that what every user actually says? We want better  websites. Hey, we're developers. We want to make better websites. So it's a win-win at  that point. So the vast majority, 81.3%, said, you keep making these technologies to help  us. But if people just coded the websites a little better, we wouldn't necessarily need  extra software to help us with software. So those kind of things. So that's the impact.  A lot of people, some would like better technologies. Some have to have certain devices to help  them with technologies. But most would prefer just a better website. As far as visual differences,  well, first off, somewhere in here is a slide. So who is actually using assistive technology  yourself right now? Because I see several of you who are. Not a hand. Anyone have glasses?  There you go. You're using assistive technology. It's low technology, but it is an assistive  technology. We have all these physical things that we do to ourselves. And if I didn't have  them, stuff's blurry. Not blurry, not. So I need this, no matter how good the software  is, unless they're really going to blow the font up that big, I need a little bit of assistive  technology. But what I would prefer is people to up the fonts on most things, and then I  can see it much better. So that's our first thing. And one of these accessible points  are visual differences. So we have just poor sight, like me. Blindness. So you have to  listen to everything. You can't see anything. So typing is not the worst problem there.  We do have Braille input. However, it is listening to things on websites, text to speech for  auditory disabilities. Then we have color blindness, color contrast, which are two different  things, as well as those auditory things that I just mentioned. So if we have color blindness,  how you perceive a web page, the shades and colors that you use may blend so closely together  that many folks can't tell if you have a cancel and a submit button, and one is, say, green  or blue or different shades, it may look almost the same or it may look like it should be  red when it's not. So those kind of things, we have to at least take into consideration.  And in contrast, I think even if you don't have a visual accessibility, if you color  contrast, if you have really light text on really light background, you just can't see  it. It's just too light. So that happens quite a bit. And you don't even need accessibility  for that. That's just not good contrast. So we'll take a look at that color oracle in  a minute. The next ones would be auditory differences. So you have low hearing. As you  age to, get a little bit of low hearing, complete deafness, right? That happens as well. So  then they can only interact visually if they can do that way. And then background noise.  So I have this problem. If I'm at a party and people are talking, all that background  noise makes it difficult to hear what's going on when I'm talking sometimes. So I think  I'm falling apart with all these classes and hearing and all that. Other ones, there's  a whole list here. All these things. You have an injury that can create, like carpal tunnel,  that can create a problem. Any kind of spinal cord, any traumatic injuries, congenital injuries,  or not really an injury, but you're born that way. Things like Lou Gehrig's, even arthritis.  These can be very crippling. There are so many things. And these are not, you know, they're  common, common enough that there's quite a few people out there with at least one or  two of these different things that we need to consider when we create software.  Cognitive differences. A couple other ones here. So dyslexia I mentioned before. ADHD  that's a very popular cognitive impairment. People are able to live successfully with  both of these. However, it does make it a little more difficult. Even though you may  be successful, there's still some difficulties. And if I can take that roadblock away from  someone so that they can smoothly progress and use my software, that's what I want to  do. So I want to make it easier for that. So we have autism spectrum, injuries, visual  stuff, learning seizures, all kind of things. Some of the things you'll see, I know people  like to pass around optical illusions and cool things like that, which is fine. However,  sometimes a website will sneak in something that just startles your eyes or something  that flashes or flickers. And if you are someone who's prone to seizures, that can cause a  seizure. Yeah, the Simpsons made a cartoon about it, but it still actually happens to  people. There's also various learning disabilities. So if you're writing software, especially  if you're writing educational software. So there's people with learning disabilities,  and I've had clients where they did not have accessible software, even though they were  creating software for schools. Oops, probably want to work on that. So we got in there and  cleaned that up and made it more accessible, and even for learning disabilities as well.  So with all of these different, we saw those four types. We have our auditory, visual,  motor, cognitive. We have assistive technologies that we can work with to help ease the pain  a little bit for these folks. So one I mentioned before, some you're already using. Some of  it will actually be physical hardware. Here's another one. Things like the trackpad. It's  actually supposed to be an assistive technology at one point, because the mouse is not very  conducive for all people. Some other good ones, good old magnifying glasses, the same  as glasses. It's still an assistive technology. But there's more, more exciting ones, if you  will. Like the screen narrator. So I'll show you a screen narrator coming up. So that's  pretty popular. We also have this Braille reader. It's just a sample of one. If you are  impaired as much as, say, Stephen Hawking, he used to use a mouth stick, and now they  actually have super high technology for him, and he just blinks. It's like a blink indicator.  And that's all he needs to do. Head wands, sip and puff, all of these. There's the mouth  stick. That's kind of like over in the U.S. we have this staples, and they have this red  thing called the easy button, and you press it, and that's what that's a lot like. So  we have just a nice, easy single switch access. Just tap it. Adaptive keyboards. Even non-accessible  people will use some adaptive keyboards as well. It just makes it a little easier. There's  also eye tracking glasses that help. And of course, voice recognition software is not  just for what we would think of just, hey, dictation. Now it actually helps a lot of  people to be able to be able to give input. They do not have good use of their limbs. You  need an alternative way to input, so that wouldn't be a mouse, and it would not be the keyboard,  so we need something else. So voice recognition, when we don't have those other items, but  we do have our voices to deal with. And this is just a few of the assistive technologies  that are out there. There are some others, but these are probably the most popular and  the most important ones. And you can go and look on Google through the images. They're  copyrighted, so I didn't want to put them in here. Just put these in there. But some  of them about the head wand and the eye tracking glasses, you can see pictures of those if  you look online. So it would be nice to see what you might be dealing with. It's good  to know that if you're going to write software that this is going to aid with. So there's  another keyboard, like an adaptive keyboard. Now if we have a visual issue, we may need  a screen narrator. So with this, we have one that I like the best, I think is the good  one, and it's free. Some of them cost some money. One of them is called NVDA. Web anywhere  is good as well, and that is an online only. NVDA is something that you download. And of  course there are some specific narrators. If you only have, like IE or Chrome, there's  also Apple voiceover. So you have these different narrators available. So if we take a look  at say a narrator, so I have NVDA, and if I crank it up, so it'll pop up. Oh, let me  turn on my audio here. So it sounds like that. It's very robotic. The welcome screen comes  on and I can tell it, like, I'll just go with the defaults, click OK. And then what we'll  do is maybe bring up one of these websites and turn this back on. Now if you heard a  bit of what that was saying, robot voice, it takes a bit to get used to that sometimes.  It was going through and it said, hey, we're at WebAIM. And this is, by the way, since we're  at WebAIM, if you go to webaim.org, this should be really the first place you go to if you're  going to do anything accessibility. And these folks work with Mozilla and whatnot to help  get this content out. This is one of their tools. And what it does is that screen reader  will narrate what's on the screen. So when it does that, it goes through the logo. It  may need to go through the menus and then tell you that there's an image here. And, you know,  if you can imagine just closing your eyes and then listening to what would be happening  on a web page and considering some of the stuff that is on web pages, a lot of stuff  is going on, it's a difficult job for a screen reader. It has to go through and figure out  is something visible or not because it doesn't want to read things that are not visible. It  has to go through and see what's important. Sometimes it can't and it just reads everything.  And things like links and menus sometimes actually get in the way of that. But if we  want to listen to it, we can do that for another minute or two here. And let me go to another  page. Let's do good old MSDN. Let's see what it says about MSDN. There we go, MSDN. Someone  needs performance, something on that team. There we go. So, we'll just turn this on.  Dialog Cider 8082. Are you going to do more? Yep. Learn to develop with Microsoft Developer  Network MSDN Google Chrome Window. Learn to develop with Microsoft Developer Network MSDN  Banner Landmark. Visited Link Enos. Visited Link Developer Network. Link Sign in Link MSDN  Subscriptions. Link get to task dialogue Cider 82. So, if you listen closely to what it  was saying, it also goes a bit fast. But it does have a bit of a British accent for a  robot voice. Interesting. What it will do is it has to go through. It's the first time  I have visited this page. It has to tell me that there are links here and what's down  here and what's in the slider. And it doesn't always pick up things exactly because it has  to interact with all this code and everything, but it does a pretty good job. It will go  through the entire page too, if I let it. So, that's a lot of stuff. Even stuff down here  if it needs to. And if we think about it, if I maybe refreshed this or just go to Microsoft.com  and I learn how to type. And we'll crank it up and then just close your eyes and listen  to it. Cider 82. 9.8 is pop. Classroom U.Tip and SILAR. Classroom Microsoft. Microsoft  Office. Elh. Gemyside. Google Chrome. Oh, and it's in... Oh, being that this came up  in Norwegian. Who? HTTPS. Sash. Sash. www.microsoft.com. Sash. NB. No. Sash. Default. Asks. I like how  it can't pronounce ASPX. That's kind of fun. So, I think... ...  Being that this comes up in Norwegian, it doesn't know what to do on anything in Norwegian in  there. So, that's another problem is we would need a localized version for Norway. But as  you see, the crux with scanners or screen narrators is that it has to go through and  goes through every time. And if you think about webpages, they usually have a banner  and some links or breadcrumbs. And it has to do this like every single time, which is  kind of annoying. I can see the first time a page comes up and go through and read the  links because you need to know, but it keeps doing that. So, we'll take a look at a way  to make it stop doing that and just skip over those links. But other than that, this is  how people who are blind have to use the web. They need to use one of those screen narrators.  And really, the only way to really, truly get a good page going with a screen narrator  is just to load up your page and sit there, blindfolded, and listen to everything it's  saying. It'll take a while to get through an entire page. We only have an hour here,  but I think you can get the gist of it just from these little clips of NVDA going on.  So, we do want to make sure that we're kind of screen reader accessible, and we'll see  a little bit more of that in just a minute. With that, screen readers need to get through  content. So, actually, the number one thing you could do to reach many, many more people  and make it easier on them is making fonts bigger. There's almost not a single website  anymore that actually has a decent font size. They're all tiny. And then I end up, I think  most all of my browsers are at like 150%. This one's only 110, because I knocked it down  for the other demo. I go into them, they're usually much, and I don't even need 110 because  web aim makes large font. But I go to other websites, and I'm always zooming in, even  with glasses and stuff. It's just too small, too tiny, too much little stuff. Other things  too, and not just for visual folks, but the cognitive folks. We need things clear, right?  Clear sections, clear headings. Clear sections and headings, and you can use your h tags  in HTML for that to block them off. And you can also use the HTML semantic tags, like  the footer, header, section, article, nav, those tags that came out with HTML5. You can  use those. If you use those, screen readers will pick them up, and it will know exactly  which section it's working in, and it will allow the user to more focus in on that section.  When you have screen readers like NVDA, you can often hover over a part of the page, and  it'll try to read that. But sometimes, if folks are just using divs or spans, it doesn't  really know if that div is for an actual section of the page, or if it's advertisements or  something else. So those semantic tags help us organize good code like that. A high contrast  for colors, that's kind of important, too. So I'll show you a contrast thing in a second.  Labeling. Here's another one. Even if you don't have accessible needs. There's sometimes  you'll see a label, and then another field, and you don't know what the label's for, or  they might call it a save button on one page, and a submit button on the next, which is  inconsistent. I'm not a fan of inconsistent. I like consistent things. So clear and consistent  labels and clear and consistent forms. I have an entire section on forms for us. But here,  these labels make sure they are labeled, and you can actually use the HTML labels. And  things like movies and animations. This is probably going to be one of the more... It's  not difficult. It's just time consuming. Get an intern. Get one of them. And get closed  captions. A lot of YouTube has closed captions, and usually, if it's something recorded, like  a lecture like this, you can just take that recording and run it through a speech to text,  and then capture it that way. So it makes it a little bit easier, and then have an intern  go in and change it and make any modifications for the little boo-boos. I have a nice article,  and actually I have one in MSDN Magazine, and one at my website about programming accessible  websites and apps that go into details of things you can do. But this is really not  difficult to just organize your pages nicely and make it easy and clear for people to read.  So here's contrast that I said we'll have. This is crappy contrast. Who can't see it?  I can barely see it, and I'm standing in front of it. You can't see it, but it's not the  greatest, right? That's better. Now, the colors may be ugly, but you can see it. That's good  contrast. Eh, eh, right. That's, it's better than the first one. Not as good as the second  one. That's okay. That's right. So as you're starting to see, mostly if you get, if it's  a light background, dark text. The dark background, light text. And things like certain colors  like purple and gray don't contrast well, or certain blues and greens. You can usually  see it just, it's just a little bit more difficult on the eyes to recognize what's going on.  Of course, black and white is good contact, good contrast. Things like this, actually  just staring at this for a few minutes, and then your eyes start to get a little, they  hurt a little bit from looking at some text. So things like the, the bottom ones, of course,  the red one is better. This is okay. There's a lot of people who will not be able to see  this at all, because it is a gray text on white, and a lot of websites do, instead of  black on white, a lighter gray on white. And that makes it difficult for many people. Many  people have contrast issues where the first one, second one, or this third one, this,  this pretty much this column except for the bottom one, and that little one on the end,  they're just not the best. So just try to keep, and this is kind of easy. You can tell  your project stakeholders contrast. Just make it a darker and lighter, so it's easier to  see. And they usually say, oh yeah, good idea. And then off you go, and just simply doing  that does a lot better. So here's another one with visual, visual problems. Right, so  color blindness. Here's for my website, done four different times, not reprogrammed. All  I did was I took the accessibility color wheel tool, and I put my URL in there, and it told  me what my website would look like if I were color blind with one of these type of, there's  three different types of being color blind. I can't really pronounce them that well. They're  kind of big words. Deuterinopia, protonopia, and tightnopia, that one's a little easier.  But as you see, now my page is just dark blue and white, and we're done. But some people  see it as purplish, and the other see it as purplish, and my face is kind of green here.  I'm not a fan of that. I don't look good with a green face. Here I'm looking a little pink,  very pink, and this is green. So depending on exactly their level of color blindness,  depends on how that page looks. So if I had a blue submit button, someone may see that  as green, and depending on what shade of blue, it may even go off into what looks like another  color for somebody. So the cool thing is you can go to this color wheel tool, and there  we go, and you could go through here and put in some URLs and poke around and load up one  day. Yeah, we'll come back when that loads up. So you can put it through, and you can  see things like this. There's also a little tool called Color Oracle you can download.  It also makes you download Java, JVM, which is kind of annoying, but it's a cool little  thing. You could just have it do the same thing as well. It will tell you whatever you're  looking at on screen doesn't have to be a web page. It could be a Windows app or something.  It'll tell you about that. Also a great reference is there's this whole site on MSDN that does  designing with color. And it's artist, very artist type of stuff. So it's more than just  accessibility, which that's a good part of it. But just, you know, the theory, of course,  they do that. Oh, wait a minute. At least they gave a link. There we go. But here it  tells you things like if you use this color, this other color goes very well. Those kind  of things. And those colors that go well tend to be better for accessible folks. So just  kind of artsy stuff often helps with accessibility. Here's the color wheel, too. We can come in  here and choose different foregrounds and backgrounds. So if I choose, there's, look  at that. I see stuff like that all the time. You probably do, too. That yellow is so hard  to read. That's right here. Then you end up highlighting it to see, changing it to a different  color just to see what it is. We can invert that and it would be just as bad. So you could  just come here and check with your color wheel. See, hey, that's not bad. And it'll even give  you a little check mark to see what it's like. That's kind of crappy. Red text tends to fight  with other colors a lot. Red and yellow, red and green. All that. So those things are good.  Oh, and there's the little, you just go to colororacle.com. It shows up in your tray.  But it is a, it's a tiny download, but it comes with Java, so that makes it a big download.  You want to know why Facebook is the color it is? You probably guess. Because Mark Zuckerberg  is colorblind. Right? He's red, green, I think. So that's why it's blue, because he could  see that. That's the whole reason. We move from content to design, things that we want  to do for design. Again, clear and consistent, not just sections, but navigation. This also,  if you notice a theme here, most of these things that make it difficult or even impossible  for an accessible user are at a minimum just annoying for a regular user, a non-accessible  user. Things like navigation. When people change up the navigation, it's hard to follow.  It doesn't matter if it's accessible or not. It's just bad navigation. The clear page layout  as well. You could use HTML semantic tags to do that. There's maybe six of them. There's  not a lot. They do the job. They do it well. Of course, again, clear content, distinct sections.  The pop-ups. You'll probably, if you're doing a public website, have to fight with some marketing  person over this, because they like pop-ups. But it does. There are so many people that  simply cannot use these popular, fun, viral sites that they like because of stuff like  that. It's so simple. A, pop-ups are, nobody likes them to start with. Screen readers as  well. Screen reader will start reading the page, then a pop-up pops up. Some of the screen  readers don't even know what to do because you have all this dynamic stuff going on.  They just, they're done. They just die. Or they'd start trying to read the pop-up. Then  you see the little link counting down up in the corner that is so tiny that you can barely  click it, especially if you have a hard time with the mouse. Then it goes away after a  while. Then the screen reader gets upset again and it doesn't know what to do. They're annoying.  A lot of users, I will see people just dumping the website. Not even going to it. I even  knew that myself just because it's annoying. If we're going to code accessible pages, it's  part of our design and coding. At least over in the U.S., we have the practices here that  apply anywhere. I think there's a European version of this, but I don't, somebody here  could tell me I'm sure. What we call Section 508. There's a checklist at AIM that would  help adhere to that. It's just this cool little checklist of basically what I'm telling you  in this talk. These kind of things to do. You can go down and make sure that you have  it checked and then run this cool little web AIM tool to see if that's happened. If I come  over here, I actually have web AIM up somewhere. Here it is. If I go to webwave.webaim.org,  I just come in here and I could pop in any URL. If I do microsoft.com, it's going to  go through and it's scanning that page. It's going to tell us, I love doing this with Microsoft,  then I could find little nitpicky things and complain about it because it's Microsoft.  I used to work there. I know people who complained too. It's taking a while. There we go. Here's  the first thing. We would get these three little bars here of styles, no styles, and  contrast. You'll see a little summary of 55 errors that we have. Alerts, all these different  things that you have. You can come here and you see it marks up the page and you can look  at what's happening there. I could even, there we go. Took it a minute. Some of the yellow  ones are okay. It's just that you might do something to make them better. Green is usually  good. Red stuff though, not so good. I could come here and see what's going on. This is  a huge page. Try to load in a smaller one. Chrome, did you lock up? Yes, it did. Thanks,  Chrome. That was nice. I suppose there's nothing you can do. Yeah, I know. Thanks. Let's try  that again. There's really nothing you could do with accessibility when Chrome just dies.  It all just goes to hell. It'll come through. This is telling me something. If WebAIM has  a hard time scanning it, it's probably not very accessible if it's having such a hard  time. If we do, I'll do a wave again. I'll put my own site in here. If you don't want  to just run things online, no problem. You can actually download this tool and then just  run your pages through it locally. There's, I believe, a plug-in for Firefox in which  you can do it there as well. There comes mine. Mine's not bad. There's one red error, a couple  of alerts, mostly because I forgot a few headings. Things like alt attributes on an image is  actually very important. Screen readers don't know what to tell people. They can't just  see an image and tell people, hey, that's a cat. It can tell what's in the alt. If you  put something clear and descriptive, this is a cat. The cat is purple, whatever color  the cat is. Then the screen reader can read that tag. Once in a while, if you don't have  an alt or something, that one I guess I forgot, there's no image there. That's why. Here's  the good stuff, bad stuff in between. As you see, you hover over things and it'll be like,  hey, there's some stuff. Look, there's a header. Here's this. It gives you all these cool little  things. Over here on the side, you get it with styles. You don't have to see the styles  and contrast. There's another way to check your contrast. I actually ran this through  the contrast and I actually left it go on purpose. This is mostly contrasted. The only  thing on my site that is not is this little tiny date and how many comments are in there,  which if somebody goes into that site, they're going to see it in good contrast. I should  probably make that darker anyway. That's my slacking, I guess, right there. We have our  tools. Where's our? Somewhere in here. That's what I like to do. I like to go and run them  through the wave tool, come out and check the contrast, check the styles, all that good  stuff. It's really easy to do that. Again, you can download it if you don't. A little  bit more for coding. This should be good for people like this. Mobile First. Everybody's  kind of doing that anyway. Usually, if you practice mobile first development, you're  doing things like considering a tiny screen in which you need to make things different  in a formatted way so that people can consume that pretty good. If you design with mobile  first, you're going to tend to have less junk in the page. The ads are not going to get  in the way as much as a big page. It tends to be a little more trim and a little bit  less bling, a little bit less eyesores, which makes it easier basically for everybody. What  we want to do, though, as well, mobile or not, use ARIA. I'll show you on, I think,  the next slide or so. These things called skip links, which are part of ARIA. Those help  screen readers go through and read properly. Of course, we have to be keyboard and alternative  input friendly. Keyboard is really not too bad for most people. However, if you're, we  have just keyboarders here, like I hate the mouse kind of people, a lot of coders are  like that. If you do almost 100% of your work just with the keyboard and you try to do a  tab and tab through a web page, it's all over the place. It'd be tabbing up and down  in no particular order very often. Then I will see people putting tab orders in that  are not correct or out of order. You want to make sure it's keyboard friendly. All those  other devices, like the Braille readers and things like that, make sure that that's friendly  as well. In a slide coming up, I will show a few of those alternative ways to make things  keyboard friendly. It's really simple, just doing a few things with these, what's called  aria, adding them to your form. It's a tiny bit of code. Works great. If you're going  to code, good thing the marquee and the blink tag are gone now. Those little things. First  thing that came into HTML to go. So any strobing, flickering, flashing, those kind of things  make it difficult. And crazy JavaScript makes it. It's fun to write crazy JavaScript. Not  so fun to be on a page with crazy JavaScript popping up things. I've seen now they're taking  to popping up an ad and then popping up an ad on top of an ad. How far are they going  to take this? It's going to be ad after ad after ad. I hate ads on the web, pop up ads.  I stopped watching TV because of ads and now they're all over the web. So one of these  things to do to make it easy to navigate and then friendly forms are these things called  skip links and they're part of aria. And if we look at this, this web aim organization  has created what is called aria or it's accessible rich internet applications, aria. And it's  just a set of small things you can do to make your applications rich on the internet. One  of them is what's called the skip link. So as I mentioned before, when I go through with  or any screen reader, it'll read the logo and then it has to read the links. And then  I go to the same, maybe this next page and I click on that. And when I get to this page,  it needs to do the same thing. It reads this, reads the links. If you're a sighted person,  hey, that's no problem. You just don't look there. If you're not sighted and you have  to have a screen narrator, then you have to painfully sit there listening to that over  and over. It's kind of a pain. So what we could do is say, hey, screen reader, how about  you skip over these? We'll tell you where to go to get to the good stuff first. And  this is kind of a small navigation. You see a lot of sites with tons of links across the  top. Oh, MSDN perhaps. Yeah, like, oh, look at, and then these things. That's not good  for accessibility, Microsoft, by the way. That stuff. And then stuff down here. Oh, and  not just that, but maybe even some of the stuff that gets, there we go. Some of this  is possible. I do not want to sit through all that. That was painful. The irony of non-accessible  accessibility page at Microsoft. Just saying. So these skip links. So this is one way to  do this. And so if I come here, web aim does these perfect. Just go and see what they do  and you do it. It's very easy. So to make the screen reader skip them, what I do is I  just use an HTML, a named reference. So you do the little pound sign and name. And that  will help us. So if I come in here, I'll look at the source for this. I had the source open.  If I just look for anything called skip in here, it's easy. What they do is they create  a little div. I zoomed a little far there. I like the big text. All right, so we create  a little div. Skip to content. And this is what it is. It's this link before the rest  of your links that just says, hey, screen readers, you go here and skip to that. Screen  reader will look for this. And if it sees something that does that, it can go to there.  Now there's a few more things in here. If I take a look, here's some of the other links  as well. Oops, I have a skip. But that's basically all you have to do is in the somewhere in  the top of your page, come in here and tell it where to skip to. Now this doesn't necessarily  show up on the top here. All right, I zoomed a little far again. There we go. So these  skip links, you could do it one of two ways. You can actually just have these as regular  links and then say to the screen reader, take that and skip over those links. Or some people  don't like to display the links and they have other navigation. You can just make it so  that it's invisible. And you could do that by doing this, just setting a little bit of  CSS. And that's actually what they do at WebAIM. So they have the regular links and  then like a little hidden skip link. So the reader sees this hidden skip link. And it says,  skip over all that stuff, go right to the content. And it doesn't visually display it  for the people who are visual. So we just set it like way off to the left and just make  it tiny. And then the reader will pick it up. But the user never has to see. It's a bit  of a hack. It's a bit of a known hack. They'll fix that one day, I think, make it a little  less reliant on CSS if you want them invisible. Another, now here's a good coding technique,  again, the semantic tags. Now we have these ARIA tags that I just mentioned. And if I  look here on WebAIM, there's a whole set of ARIA links. And you'll see things like, if  I had a form, I could tell something, I want to make this an ARIA or application of rich  internet. So I could make it that. And I could just take any HTML element and say, you're  now going to be an ARIA element. It's nothing special other than the fact that ARIA elements  work better with assistive technology than nothing, which is what we would have otherwise.  So we have these ARIA tags. Sometimes, though, you'll see one where you can use a semantic  tag, like with checkboxes and things like that. So we want to start with semantic tags  before we get to the ARIA tags, but we kind of have to know about ARIA tags as well. So  semantics, which is your HTML, your article, header, footer, nav, there's one or two others.  A section is another one. And it's basically just your tag that says, this is an article  on my blog or on my website. This is a section on my website, a section for ads, a section  for this or that. So that's all that it is. It's just plain old tags. Once we run out  of those, we should actually be doing this anyway. We should actually just be using HTML  semantic tags that use the HTML standard now. So we should just be using them anyway, but  they happen to partly be there because of accessibility. So with the ARIA, so that's  the whole actual acronym, web accessibility initiative, accessible, rich internet applications.  It's like somebody on the.NET team got to name this somehow, like giant name, the irony  that you've, of getting through that with maybe an accessible problem. It is actually  a W3C protocol. So there is an RFC for it. You can go to W3C and see the specs on ARIA.  And all they are are attributes that go into HTML. So it addresses those missing semantics.  Now this was around before semantic tags. So that's why there's some ARIA stuff that  semantic tags ended up kind of taking over, if you will. So that's why that has that.  But it addressed those missing semantics at one point. Perhaps at a later date, I'm hoping  that they'll start to incorporate the rest of ARIA. I've heard that they're supposed to  incorporate the rest of it in as just part of the HTML spec like they did with the semantic  tags. That would be pretty cool if they did that.  So with ARIA, they're all attributes. And they're basically attributes that tell us  what this element does. And there's these three categories of them, properties, like  what an element does. Is it a button? Is it an input? What is this? And remember, this  is for a screen reader, not a person. States, which is the condition. So you might see ARIA  checked to tell the screen reader that a checkbox is checked. Or you might see ARIA disabled  to show that an element is disabled. Properties, like a required. You'll see kind of like your  validation ARIA required. So these are just there to make assistive technology better.  As far as those roles go for ARIA, we have, we'd sell it as a whole ARIA application.  You could set banners. So if it sees ARIA banner, knows that it's maybe part of a navigation  and logo. And that a screen reader is going to say, hey, I could just skip over that after  the first time I read it. Forms, of course we want forms. That'll be an important one.  Navigation's another one. We want to tell it ARIA nav to say when to navigate. And also  searching as well. So we have these different roles. And the states. The ones in red are  those ones where you can usually use a semantic tag instead. So if I wanted to label something,  I could just use a label. Or described, I could just use a label. Same thing. Disabled.  Just disable something. But there's other ones. If I need popups, I can say this particular  div or span is going to have a popup. So I can say ARIA has popup equal true and we're  good. Or just ARIA has popup. Don't even need the equal true. It's just a bit flag.  These ARIA elements help us create accessible forms. So this way, so here's a problem. People  fill out the form and then they click and things happen. And those things that happen  is often JavaScript first before it goes over to the server. And JavaScript is a bit of  the bane of the existence of an accessible user. JavaScript, first of all, readers don't  know what it's going to do. And readers can't. They're not compilers. They don't go in there.  They can't read the JavaScript and just figure out what it's going to do. It has to wait  until the JavaScript is doing it. And then the reader tries to adjust. So when a popup  happens, the reader had no idea. The narrator says, oh, something happened. Oh, there's more  HTML here now. Let's read that. Or sometimes it just can't even do that. It doesn't know  what to do. So if we want to work with this, we need to watch a little bit of JavaScript.  So things like alerts and warnings. I think we're kind of over that phase where you'd  click a button and you'd get a JavaScript popup telling you about validation. Now it's usually  not so modal, not in your face. As much as possible, it's getting harder to do this.  Trying to do things where anyone test by turning off scripting and then testing your site.  That scares me a little to even try it on most sites. Scripting is just everywhere. Probably  won't be able to get 100% on this. But try to see if you can run some of your sites with  the least amount of scripting possible. The problem with not having scripting is then  it's not the greatest experience most of the time. So we want to weigh that fact of not  having the best experience with some nice, rich JavaScript versus the not so great experience  of an accessible user. And we do have a majority-minority thing here. So we kind of have to weigh that  and balance that. And of course, security and stuff like that. So if a validation happens,  JavaScript will pop up something and the screen narrator just doesn't know what to do again  because it's dynamic. And you can't necessarily even go anywhere. Once a pop-up message comes  up, you have to do something with it. And if it's not a sighted user, they don't necessarily  know to click and the screen reader is supposed to tell them, but it can't always because  something dynamic happened and it didn't know what was going on. So for forms, along with  trying to not kill people with JavaScript, trying to balance that, things that we want,  make sure your tab order is good, which usually means not putting in tab orders. Another one  that screen readers often choke on is if they JavaScript focus on the first field and screen  readers, then some of them will just automatically start reading that field, which sometimes is  okay, but sometimes not. Blinky stuff, buttons and links, they need to be big. So we have those  multiple input devices and I will often see tiny, tiny links, tiny, tiny fonts, tiny, tiny  buttons that is hard to click on or hard to tap on. A lot of accessible users don't use the mouse,  possibly not even a keyboard. They're using the other devices and they need to tap or puff or  something like that and tiny links and tiny buttons are their enemy. It's just impossible to  work with them. So we could use ARIA again for all of that. So what we could do if we want to use  ARIA to do that, we first want to use good old HTML and set up our field sets. So we could use  that more semantic type of paradigm. Then we could have our fields and we want to put in legends  for checkboxes and things that we want to group, radios, those kind of things. We could put them  in a field set. If you're an MVC person, ASP.net MVC and you do a file new project, it actually puts  some of this stuff in for you, the field set and all that good stuff. If you do Windows app  development, like when JS, it actually puts in ARIA tags for you, which is kind of cool. So here's  all the coding accessible forms, things we want to do. My label, right? So I don't need to use  anything special, but make sure it's labeled. Use a label tag instead of just a span or something  like that for what element. And then we have the input for that element. And then here if I have  some validation, I might have a span to put it. And here's something else too. So you'll see this.  But instead of saying the word required, you'll just see a little star, tiny little star. And it's  hard for a lot of folks to see that. And a screen reader doesn't know what that is necessarily.  Just a little star. It goes asterisk. And that's all it says, which tells us nothing. But it will  see the word required. And it will say required. This is required. So that's the first thing we  want to do is to make sure we have labels and inputs. And ARIA, every ARIA element is ARIA-  whatever. From that slide a few slides ago, with that list of them, there's only a handful of them.  But in this case, if this is required, so if I want to make this sample from the previous slide  required, actually required, I come here and I tell it ARIA-required equal true. And then if  there's a few, there are several screen readers out there. And if one of them hasn't quite caught up  yet, or it doesn't work the best, that happens. At least the ARIA tag, it will definitely pick  that up. Even if it kind of says required or doesn't pronounce it well, or does some other kind of  boo boo. So we just do the ARIA-required. If I had, say, a check box and I wanted it to be checked  by default, because we're sending a newsletter, that's why you do that. Then we would just say  ARIA-checked, or ARIA-checked equal true. And we would make sure that that's checked and that the  screen reader tells the user that it's checked. If they're blind, they don't necessarily magically  know it's checked. So we just add ARIA attributes to what we want to tell the screen readers how to  behave with that. I don't have the forms. Three minutes. So some of the tools, I showed the scanner  and the 508 color contrast. This is a good one, this WCAG checklist. There's the same thing at  web.com. Web content accessibility guidelines, that in a checklist are really good. So I come here  pretty much any time I'm going to deploy anything. I come and we check the checklist. That was not  what... Sometimes you copy and paste and it just doesn't seem to copy and paste. Or it's me. There  you go. How about without that stuff? So here, this checklist. This is good. So it gives you all  these different things. And you just go through. And it gives you all these recommendations. And  you may not be able to do every single thing. But it's just a list of these things that I've been  talking about. They use semantic markup. Make sure things are zoomed. Make sure things are  meaningful and organized well. Use color correctly. So literally just a list. You print it out. Check  it off. Write a little script or utility so that you can check this off at time that you're going  to deploy. So I like checklists. That's how airplanes run. They go through checklists and  checklists and checklists. I think they automate that now, though. Even so. Nice. I like that. You  get to do all that. And then you could go to the scanner. Run things through your scanner. And if  you just do these few things like using semantic tags, ARIA tags, watch your color contrast and  consider color blindness. Add some of those ARIA elements into your forms. Make things big and  clear. And those are not hard things. They're very simple things. It's not a lot of things either.  But it helps quite a bit. It helps an order of magnitude for other folks that may have problems  accessing your website. So I kind of like this. It's a big bang for the buck. You can now reach  20% more of your user base just by implementing these few things. And even if you don't get to  them all, implementing some of them is better than implementing none of them. It will certainly  make a difference to the users you implement it for, whether they're an accessible user or not. It  benefits the non-accessible users as well. So that's like the real benefit of accessibility,  is it actually helps everybody, not just those who are accessible. Oh, there's also 10 more free  screen readers. There are lots of pay for ones. You can go find one that you like. A usability  geek is a really good site. Anything with usability, making it easier to use. Also,  there's a nice blog on NVDA in particular, since I kind of like that one as well. So usability,  that's like lots of nice screen readers there you can test. And that's the thing I would  suggest you do. Actually, like blindfold yourself, get the screen reader, and try to navigate  a few web pages as if you were blind. It's a bit of a challenge, especially the first few times  you do it, even after that. It's a very different thing. So if you can imagine, that's difficult for  them as well, even though they may have been living blind for quite a while. So these things help  everybody, regardless of who we're technically targeting, accessible users. So I like things  that are good for everybody. It helps us all. And that's all I have. So thanks for coming. I think  actually it was five minutes over, right? Yeah. Okay, well, thanks for coming. If you have questions,  you can come up.
Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_0_2531.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_2532_3335.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_3336_5723.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_5724_10595.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_10596_14375.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_14376_14711.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_14712_16295.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_16296_16379.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_16380_28595.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_28596_29675.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_29676_32795.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_32796_32843.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_32844_32891.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_32892_34415.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_34416_34763.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_34764_34811.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_34812_34979.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_34980_35363.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_35364_35939.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_35940_36431.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_36432_36671.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_36672_38975.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_38976_39551.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_39552_44363.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_44364_44543.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_44544_44723.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_44724_45515.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_45516_49499.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_49500_49583.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_49584_49787.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_49788_51035.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_51036_51083.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_51084_51503.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_51504_53411.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_53412_57587.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_57588_57923.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_57924_58415.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_58416_59843.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_59844_60143.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_60144_60383.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_60384_60551.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_60552_60599.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_60600_61067.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_61068_62783.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_62784_63203.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_63204_63887.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_63888_63935.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_63936_68039.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_68040_68399.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_68400_68471.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_68472_70463.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_70464_70583.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_70584_70847.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_70848_70907.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_70908_70967.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_70968_71099.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_71100_71171.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_71172_71255.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_71256_71699.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_71700_71867.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_71868_71987.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_71988_72035.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_72036_72095.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_72096_72695.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_72696_72767.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_72768_72875.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_72876_72971.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_72972_73127.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_73128_73775.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_73776_74771.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_74772_75983.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_75984_76055.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_76056_76919.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_76920_79067.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_79068_80267.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_80268_86279.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_86280_88835.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_88836_88907.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_88908_89027.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_89028_90659.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_90660_90767.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_90768_92255.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_92256_92735.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_92736_92975.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_92976_93023.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_93024_93239.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_93240_93335.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_93336_93491.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_93492_93539.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_93540_93599.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_93600_94163.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_94164_96623.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_96624_97859.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_97860_98687.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_98688_98735.png Designing_and_Programming_Accessible_Website_and_App_UIs_-_Rachel_Appel_98736_101695.png
afternoon. How are we doing? Are there people way up there? It's like lights and things. I am Rachel Appel. Welcome. This is Designing and Creating Accessible Web Pages. It applies to apps too. Basically any software with a UI, this stuff applies to that you can do. So for the next hour, we'll just take a look at things you can do. And they're actually surprisingly easy things you can do to make your site more accessible and actually make it way better than what a lot of websites have out there. Pretty much anything you need to know about me is at RachelAppel.com. So you can go there and it has links to like the decks to download and all that kind of good stuff. And there's my email as well. So you have that too. This talk is, they always ask if you want it to be an introduction or advanced or intermediate. And this is really none of the above. This is just things that you should be doing anyway in your web apps and native apps. Just practices that you should do. There's not really any visual studio code in here. You'll see some code on the slides. But that's about it. And a lot of this is just things to do, not necessarily a whole lot of writing code. There's a little bit of code to do, but a lot of it's other things, other techniques we can use to work with accessibility. So we'll take a look at all that in the next hour. So we'll look at content first, then accessible site layouts, accessible pages. You know it's coding. We'll see a bit of HTML, but nothing terribly deep. Or probably not much new in HTML itself. There are a few attributes we'll see with ARIA. But not anything like terribly like way, unless you've never done HTML before, it should not be way out of your ballpark. And a few tools at the end that we have to help us out. So here's the first reason why you want to have accessible software. So there's 7 billion people on this earth. Of course they're not all using the internet. But 1.4 billion of them can't, if they could access a website, can't necessarily access it in the same way that other people can. Or that the stereotypical user can. That's a significant number. It comes out to about 20%. In the U.S. alone is 268 million out of 314. Have some sort of accessible need. I see many people in this room that do as well. Just by looking at you. I could tell. I do too. I'll show you how in a minute. So there's a real business value to this. We tend to do things like think, hey, I'll develop for the masses. But this 20% is a small mass. That's a big number in business. Managers, like they see a number like 20% and a manager is all over that stuff. So that's kind of a big number. It's not like you're missing out on 1% of people. And even if you were, you might still want to pick up that 1%. Considering how easy it is to integrate and implement accessible techniques, I would go after it even for 1%. It is still a payoff to you to have that quality software. So that's one reason why it's so 20% of the world. A lot of people. There are many popular websites. Even in the US, we have a lot of Forbes, Business Insider, some of these popular viral type of sites. Or there's cats. Everybody loves cats. Cats are the internet. I think that's the whole reason why the internet exists. So we can see cat pictures. So people can't look at their cat pictures because the whole rest of the website is blocking them from even being able to do things like that. Or Forbes sometimes will pop up annoying ads and make it in such a way that they want to push an ad in front of your face. So when they do that, they literally stop you from actually being able to use the site. So that those people involved in organizing the site are kind of shooting themselves in the foot by doing that and to not making it accessible. And that's 20% that they're missing out on. So it's a lot of people. It's worth it. And the payoff is way out of proportion, way great for what you do. You really want to reach all of your customers. As many as possible. Probably can't get everyone when you're using something like a website. But we want to go for the broadest reach possible. So here in the USA, and what accessibility is all about is making sure that you're non-stereotypical, which would be considered someone not necessarily able bodied, possibly, but something like auditory, vision, dexterity, any kind of difficulty. And of course, aging populations. We have a big, at least in the US, a big baby boomer population. So it's a slightly older folks in the generation ahead of me. Not that old. So those folks are starting to, you know, the aging process. I myself, right, text gets smaller. Things are harder to see. My glasses get thicker all the time. So it's the same with everyone else. Things fall apart as you get a little bit older. An interesting stat, 35% of entrepreneurs, ironically the same people making some of these popular websites, are actually dyslexic. And if you are dyslexic, it can be difficult to navigate and consume content from a non-accessible website. It's 20 in the UK. A Forrester Research Group gave even more numbers. So I think we're getting the point here. Lots of people need various pieces of help with being able to consume and deal with and work with your website. So sometimes it impairs them so badly they can't even work with the software at all, which is the opposite of what we want. So I'm a little bit more of why. If we think about human traits, it runs across a spectrum. Some people have 20-20 vision and some people are blind. Those are those opposite spectrums. And then in between, we have folks like me with glasses, getting progressively worse. Other people have other issues, maybe from low hearing to no hearing, to very good. So it's always about the spectrum. And if we at least capture the edges, we should be able to capture the spectrum within it. And all of this, it affects how people interact with your site, with everything else. You get in a car, certain disabilities make it difficult to drive a car. Being blind kind of makes that impossible to drive a car. Google will solve that soon, I think. So we have for these four types. So this is our main categories of accessibility practices. Visual, that's pretty clear, our eyes. Auditory, so there's hearing issues. Text-based websites are not so bad with that, but we have YouTube and lots of video, more and more media and animations that people have to be able to deal with for hearing. And motor indexarity, I even noticed myself. I used to be a lot better at actually using a mouse. It's not like I haven't been using a mouse for, say, 30 years now. But just as I get older and I have carpal tunnel, so that thing that wrecks your hands, right, and my hand gets a little jerky and it gets a little harder to actually click on the right thing, I will probably click on the wrong thing at least once in the stock. I used to not do that. My arm is just getting worse. So that would be a motor accessibility problem or dexterity. There's also cognitive. So we have various autism, all kind of different things that can affect how people consume or interact with your software. And it's more than just websites, even though I'm mostly focusing on websites here, but we have apps and devices. Everyone has a phone. And I don't know how many times I see people doing this with their phone because they can't see it. And everyone's doing this because you can't hear anything. So the way we interact with things changes if we don't have that stereotypical able bodiness about us. So we want to make this better. We want to make it better for everybody. So if we want to make better websites and apps, we need to make better assistive technology. Well, that's what a lot of people think. But when you actually ask people that have accessible practices, they said, we don't want better technology. I'll show you the technology that they do have in a minute. We don't really want that. We want you to make better websites. Imagine that. Isn't that what every user actually says? We want better websites. Hey, we're developers. We want to make better websites. So it's a win-win at that point. So the vast majority, 81.3%, said, you keep making these technologies to help us. But if people just coded the websites a little better, we wouldn't necessarily need extra software to help us with software. So those kind of things. So that's the impact. A lot of people, some would like better technologies. Some have to have certain devices to help them with technologies. But most would prefer just a better website. As far as visual differences, well, first off, somewhere in here is a slide. So who is actually using assistive technology yourself right now? Because I see several of you who are. Not a hand. Anyone have glasses? There you go. You're using assistive technology. It's low technology, but it is an assistive technology. We have all these physical things that we do to ourselves. And if I didn't have them, stuff's blurry. Not blurry, not. So I need this, no matter how good the software is, unless they're really going to blow the font up that big, I need a little bit of assistive technology. But what I would prefer is people to up the fonts on most things, and then I can see it much better. So that's our first thing. And one of these accessible points are visual differences. So we have just poor sight, like me. Blindness. So you have to listen to everything. You can't see anything. So typing is not the worst problem there. We do have Braille input. However, it is listening to things on websites, text to speech for auditory disabilities. Then we have color blindness, color contrast, which are two different things, as well as those auditory things that I just mentioned. So if we have color blindness, how you perceive a web page, the shades and colors that you use may blend so closely together that many folks can't tell if you have a cancel and a submit button, and one is, say, green or blue or different shades, it may look almost the same or it may look like it should be red when it's not. So those kind of things, we have to at least take into consideration. And in contrast, I think even if you don't have a visual accessibility, if you color contrast, if you have really light text on really light background, you just can't see it. It's just too light. So that happens quite a bit. And you don't even need accessibility for that. That's just not good contrast. So we'll take a look at that color oracle in a minute. The next ones would be auditory differences. So you have low hearing. As you age to, get a little bit of low hearing, complete deafness, right? That happens as well. So then they can only interact visually if they can do that way. And then background noise. So I have this problem. If I'm at a party and people are talking, all that background noise makes it difficult to hear what's going on when I'm talking sometimes. So I think I'm falling apart with all these classes and hearing and all that. Other ones, there's a whole list here. All these things. You have an injury that can create, like carpal tunnel, that can create a problem. Any kind of spinal cord, any traumatic injuries, congenital injuries, or not really an injury, but you're born that way. Things like Lou Gehrig's, even arthritis. These can be very crippling. There are so many things. And these are not, you know, they're common, common enough that there's quite a few people out there with at least one or two of these different things that we need to consider when we create software. Cognitive differences. A couple other ones here. So dyslexia I mentioned before. ADHD that's a very popular cognitive impairment. People are able to live successfully with both of these. However, it does make it a little more difficult. Even though you may be successful, there's still some difficulties. And if I can take that roadblock away from someone so that they can smoothly progress and use my software, that's what I want to do. So I want to make it easier for that. So we have autism spectrum, injuries, visual stuff, learning seizures, all kind of things. Some of the things you'll see, I know people like to pass around optical illusions and cool things like that, which is fine. However, sometimes a website will sneak in something that just startles your eyes or something that flashes or flickers. And if you are someone who's prone to seizures, that can cause a seizure. Yeah, the Simpsons made a cartoon about it, but it still actually happens to people. There's also various learning disabilities. So if you're writing software, especially if you're writing educational software. So there's people with learning disabilities, and I've had clients where they did not have accessible software, even though they were creating software for schools. Oops, probably want to work on that. So we got in there and cleaned that up and made it more accessible, and even for learning disabilities as well. So with all of these different, we saw those four types. We have our auditory, visual, motor, cognitive. We have assistive technologies that we can work with to help ease the pain a little bit for these folks. So one I mentioned before, some you're already using. Some of it will actually be physical hardware. Here's another one. Things like the trackpad. It's actually supposed to be an assistive technology at one point, because the mouse is not very conducive for all people. Some other good ones, good old magnifying glasses, the same as glasses. It's still an assistive technology. But there's more, more exciting ones, if you will. Like the screen narrator. So I'll show you a screen narrator coming up. So that's pretty popular. We also have this Braille reader. It's just a sample of one. If you are impaired as much as, say, Stephen Hawking, he used to use a mouth stick, and now they actually have super high technology for him, and he just blinks. It's like a blink indicator. And that's all he needs to do. Head wands, sip and puff, all of these. There's the mouth stick. That's kind of like over in the U.S. we have this staples, and they have this red thing called the easy button, and you press it, and that's what that's a lot like. So we have just a nice, easy single switch access. Just tap it. Adaptive keyboards. Even non-accessible people will use some adaptive keyboards as well. It just makes it a little easier. There's also eye tracking glasses that help. And of course, voice recognition software is not just for what we would think of just, hey, dictation. Now it actually helps a lot of people to be able to be able to give input. They do not have good use of their limbs. You need an alternative way to input, so that wouldn't be a mouse, and it would not be the keyboard, so we need something else. So voice recognition, when we don't have those other items, but we do have our voices to deal with. And this is just a few of the assistive technologies that are out there. There are some others, but these are probably the most popular and the most important ones. And you can go and look on Google through the images. They're copyrighted, so I didn't want to put them in here. Just put these in there. But some of them about the head wand and the eye tracking glasses, you can see pictures of those if you look online. So it would be nice to see what you might be dealing with. It's good to know that if you're going to write software that this is going to aid with. So there's another keyboard, like an adaptive keyboard. Now if we have a visual issue, we may need a screen narrator. So with this, we have one that I like the best, I think is the good one, and it's free. Some of them cost some money. One of them is called NVDA. Web anywhere is good as well, and that is an online only. NVDA is something that you download. And of course there are some specific narrators. If you only have, like IE or Chrome, there's also Apple voiceover. So you have these different narrators available. So if we take a look at say a narrator, so I have NVDA, and if I crank it up, so it'll pop up. Oh, let me turn on my audio here. So it sounds like that. It's very robotic. The welcome screen comes on and I can tell it, like, I'll just go with the defaults, click OK. And then what we'll do is maybe bring up one of these websites and turn this back on. Now if you heard a bit of what that was saying, robot voice, it takes a bit to get used to that sometimes. It was going through and it said, hey, we're at WebAIM. And this is, by the way, since we're at WebAIM, if you go to webaim.org, this should be really the first place you go to if you're going to do anything accessibility. And these folks work with Mozilla and whatnot to help get this content out. This is one of their tools. And what it does is that screen reader will narrate what's on the screen. So when it does that, it goes through the logo. It may need to go through the menus and then tell you that there's an image here. And, you know, if you can imagine just closing your eyes and then listening to what would be happening on a web page and considering some of the stuff that is on web pages, a lot of stuff is going on, it's a difficult job for a screen reader. It has to go through and figure out is something visible or not because it doesn't want to read things that are not visible. It has to go through and see what's important. Sometimes it can't and it just reads everything. And things like links and menus sometimes actually get in the way of that. But if we want to listen to it, we can do that for another minute or two here. And let me go to another page. Let's do good old MSDN. Let's see what it says about MSDN. There we go, MSDN. Someone needs performance, something on that team. There we go. So, we'll just turn this on. Dialog Cider 8082. Are you going to do more? Yep. Learn to develop with Microsoft Developer Network MSDN Google Chrome Window. Learn to develop with Microsoft Developer Network MSDN Banner Landmark. Visited Link Enos. Visited Link Developer Network. Link Sign in Link MSDN Subscriptions. Link get to task dialogue Cider 82. So, if you listen closely to what it was saying, it also goes a bit fast. But it does have a bit of a British accent for a robot voice. Interesting. What it will do is it has to go through. It's the first time I have visited this page. It has to tell me that there are links here and what's down here and what's in the slider. And it doesn't always pick up things exactly because it has to interact with all this code and everything, but it does a pretty good job. It will go through the entire page too, if I let it. So, that's a lot of stuff. Even stuff down here if it needs to. And if we think about it, if I maybe refreshed this or just go to Microsoft.com and I learn how to type. And we'll crank it up and then just close your eyes and listen to it. Cider 82. 9.8 is pop. Classroom U.Tip and SILAR. Classroom Microsoft. Microsoft Office. Elh. Gemyside. Google Chrome. Oh, and it's in... Oh, being that this came up in Norwegian. Who? HTTPS. Sash. Sash. www.microsoft.com. Sash. NB. No. Sash. Default. Asks. I like how it can't pronounce ASPX. That's kind of fun. So, I think...... Being that this comes up in Norwegian, it doesn't know what to do on anything in Norwegian in there. So, that's another problem is we would need a localized version for Norway. But as you see, the crux with scanners or screen narrators is that it has to go through and goes through every time. And if you think about webpages, they usually have a banner and some links or breadcrumbs. And it has to do this like every single time, which is kind of annoying. I can see the first time a page comes up and go through and read the links because you need to know, but it keeps doing that. So, we'll take a look at a way to make it stop doing that and just skip over those links. But other than that, this is how people who are blind have to use the web. They need to use one of those screen narrators. And really, the only way to really, truly get a good page going with a screen narrator is just to load up your page and sit there, blindfolded, and listen to everything it's saying. It'll take a while to get through an entire page. We only have an hour here, but I think you can get the gist of it just from these little clips of NVDA going on. So, we do want to make sure that we're kind of screen reader accessible, and we'll see a little bit more of that in just a minute. With that, screen readers need to get through content. So, actually, the number one thing you could do to reach many, many more people and make it easier on them is making fonts bigger. There's almost not a single website anymore that actually has a decent font size. They're all tiny. And then I end up, I think most all of my browsers are at like 150%. This one's only 110, because I knocked it down for the other demo. I go into them, they're usually much, and I don't even need 110 because web aim makes large font. But I go to other websites, and I'm always zooming in, even with glasses and stuff. It's just too small, too tiny, too much little stuff. Other things too, and not just for visual folks, but the cognitive folks. We need things clear, right? Clear sections, clear headings. Clear sections and headings, and you can use your h tags in HTML for that to block them off. And you can also use the HTML semantic tags, like the footer, header, section, article, nav, those tags that came out with HTML5. You can use those. If you use those, screen readers will pick them up, and it will know exactly which section it's working in, and it will allow the user to more focus in on that section. When you have screen readers like NVDA, you can often hover over a part of the page, and it'll try to read that. But sometimes, if folks are just using divs or spans, it doesn't really know if that div is for an actual section of the page, or if it's advertisements or something else. So those semantic tags help us organize good code like that. A high contrast for colors, that's kind of important, too. So I'll show you a contrast thing in a second. Labeling. Here's another one. Even if you don't have accessible needs. There's sometimes you'll see a label, and then another field, and you don't know what the label's for, or they might call it a save button on one page, and a submit button on the next, which is inconsistent. I'm not a fan of inconsistent. I like consistent things. So clear and consistent labels and clear and consistent forms. I have an entire section on forms for us. But here, these labels make sure they are labeled, and you can actually use the HTML labels. And things like movies and animations. This is probably going to be one of the more... It's not difficult. It's just time consuming. Get an intern. Get one of them. And get closed captions. A lot of YouTube has closed captions, and usually, if it's something recorded, like a lecture like this, you can just take that recording and run it through a speech to text, and then capture it that way. So it makes it a little bit easier, and then have an intern go in and change it and make any modifications for the little boo-boos. I have a nice article, and actually I have one in MSDN Magazine, and one at my website about programming accessible websites and apps that go into details of things you can do. But this is really not difficult to just organize your pages nicely and make it easy and clear for people to read. So here's contrast that I said we'll have. This is crappy contrast. Who can't see it? I can barely see it, and I'm standing in front of it. You can't see it, but it's not the greatest, right? That's better. Now, the colors may be ugly, but you can see it. That's good contrast. Eh, eh, right. That's, it's better than the first one. Not as good as the second one. That's okay. That's right. So as you're starting to see, mostly if you get, if it's a light background, dark text. The dark background, light text. And things like certain colors like purple and gray don't contrast well, or certain blues and greens. You can usually see it just, it's just a little bit more difficult on the eyes to recognize what's going on. Of course, black and white is good contact, good contrast. Things like this, actually just staring at this for a few minutes, and then your eyes start to get a little, they hurt a little bit from looking at some text. So things like the, the bottom ones, of course, the red one is better. This is okay. There's a lot of people who will not be able to see this at all, because it is a gray text on white, and a lot of websites do, instead of black on white, a lighter gray on white. And that makes it difficult for many people. Many people have contrast issues where the first one, second one, or this third one, this, this pretty much this column except for the bottom one, and that little one on the end, they're just not the best. So just try to keep, and this is kind of easy. You can tell your project stakeholders contrast. Just make it a darker and lighter, so it's easier to see. And they usually say, oh yeah, good idea. And then off you go, and just simply doing that does a lot better. So here's another one with visual, visual problems. Right, so color blindness. Here's for my website, done four different times, not reprogrammed. All I did was I took the accessibility color wheel tool, and I put my URL in there, and it told me what my website would look like if I were color blind with one of these type of, there's three different types of being color blind. I can't really pronounce them that well. They're kind of big words. Deuterinopia, protonopia, and tightnopia, that one's a little easier. But as you see, now my page is just dark blue and white, and we're done. But some people see it as purplish, and the other see it as purplish, and my face is kind of green here. I'm not a fan of that. I don't look good with a green face. Here I'm looking a little pink, very pink, and this is green. So depending on exactly their level of color blindness, depends on how that page looks. So if I had a blue submit button, someone may see that as green, and depending on what shade of blue, it may even go off into what looks like another color for somebody. So the cool thing is you can go to this color wheel tool, and there we go, and you could go through here and put in some URLs and poke around and load up one day. Yeah, we'll come back when that loads up. So you can put it through, and you can see things like this. There's also a little tool called Color Oracle you can download. It also makes you download Java, JVM, which is kind of annoying, but it's a cool little thing. You could just have it do the same thing as well. It will tell you whatever you're looking at on screen doesn't have to be a web page. It could be a Windows app or something. It'll tell you about that. Also a great reference is there's this whole site on MSDN that does designing with color. And it's artist, very artist type of stuff. So it's more than just accessibility, which that's a good part of it. But just, you know, the theory, of course, they do that. Oh, wait a minute. At least they gave a link. There we go. But here it tells you things like if you use this color, this other color goes very well. Those kind of things. And those colors that go well tend to be better for accessible folks. So just kind of artsy stuff often helps with accessibility. Here's the color wheel, too. We can come in here and choose different foregrounds and backgrounds. So if I choose, there's, look at that. I see stuff like that all the time. You probably do, too. That yellow is so hard to read. That's right here. Then you end up highlighting it to see, changing it to a different color just to see what it is. We can invert that and it would be just as bad. So you could just come here and check with your color wheel. See, hey, that's not bad. And it'll even give you a little check mark to see what it's like. That's kind of crappy. Red text tends to fight with other colors a lot. Red and yellow, red and green. All that. So those things are good. Oh, and there's the little, you just go to colororacle.com. It shows up in your tray. But it is a, it's a tiny download, but it comes with Java, so that makes it a big download. You want to know why Facebook is the color it is? You probably guess. Because Mark Zuckerberg is colorblind. Right? He's red, green, I think. So that's why it's blue, because he could see that. That's the whole reason. We move from content to design, things that we want to do for design. Again, clear and consistent, not just sections, but navigation. This also, if you notice a theme here, most of these things that make it difficult or even impossible for an accessible user are at a minimum just annoying for a regular user, a non-accessible user. Things like navigation. When people change up the navigation, it's hard to follow. It doesn't matter if it's accessible or not. It's just bad navigation. The clear page layout as well. You could use HTML semantic tags to do that. There's maybe six of them. There's not a lot. They do the job. They do it well. Of course, again, clear content, distinct sections. The pop-ups. You'll probably, if you're doing a public website, have to fight with some marketing person over this, because they like pop-ups. But it does. There are so many people that simply cannot use these popular, fun, viral sites that they like because of stuff like that. It's so simple. A, pop-ups are, nobody likes them to start with. Screen readers as well. Screen reader will start reading the page, then a pop-up pops up. Some of the screen readers don't even know what to do because you have all this dynamic stuff going on. They just, they're done. They just die. Or they'd start trying to read the pop-up. Then you see the little link counting down up in the corner that is so tiny that you can barely click it, especially if you have a hard time with the mouse. Then it goes away after a while. Then the screen reader gets upset again and it doesn't know what to do. They're annoying. A lot of users, I will see people just dumping the website. Not even going to it. I even knew that myself just because it's annoying. If we're going to code accessible pages, it's part of our design and coding. At least over in the U.S., we have the practices here that apply anywhere. I think there's a European version of this, but I don't, somebody here could tell me I'm sure. What we call Section 508. There's a checklist at AIM that would help adhere to that. It's just this cool little checklist of basically what I'm telling you in this talk. These kind of things to do. You can go down and make sure that you have it checked and then run this cool little web AIM tool to see if that's happened. If I come over here, I actually have web AIM up somewhere. Here it is. If I go to webwave.webaim.org, I just come in here and I could pop in any URL. If I do microsoft.com, it's going to go through and it's scanning that page. It's going to tell us, I love doing this with Microsoft, then I could find little nitpicky things and complain about it because it's Microsoft. I used to work there. I know people who complained too. It's taking a while. There we go. Here's the first thing. We would get these three little bars here of styles, no styles, and contrast. You'll see a little summary of 55 errors that we have. Alerts, all these different things that you have. You can come here and you see it marks up the page and you can look at what's happening there. I could even, there we go. Took it a minute. Some of the yellow ones are okay. It's just that you might do something to make them better. Green is usually good. Red stuff though, not so good. I could come here and see what's going on. This is a huge page. Try to load in a smaller one. Chrome, did you lock up? Yes, it did. Thanks, Chrome. That was nice. I suppose there's nothing you can do. Yeah, I know. Thanks. Let's try that again. There's really nothing you could do with accessibility when Chrome just dies. It all just goes to hell. It'll come through. This is telling me something. If WebAIM has a hard time scanning it, it's probably not very accessible if it's having such a hard time. If we do, I'll do a wave again. I'll put my own site in here. If you don't want to just run things online, no problem. You can actually download this tool and then just run your pages through it locally. There's, I believe, a plug-in for Firefox in which you can do it there as well. There comes mine. Mine's not bad. There's one red error, a couple of alerts, mostly because I forgot a few headings. Things like alt attributes on an image is actually very important. Screen readers don't know what to tell people. They can't just see an image and tell people, hey, that's a cat. It can tell what's in the alt. If you put something clear and descriptive, this is a cat. The cat is purple, whatever color the cat is. Then the screen reader can read that tag. Once in a while, if you don't have an alt or something, that one I guess I forgot, there's no image there. That's why. Here's the good stuff, bad stuff in between. As you see, you hover over things and it'll be like, hey, there's some stuff. Look, there's a header. Here's this. It gives you all these cool little things. Over here on the side, you get it with styles. You don't have to see the styles and contrast. There's another way to check your contrast. I actually ran this through the contrast and I actually left it go on purpose. This is mostly contrasted. The only thing on my site that is not is this little tiny date and how many comments are in there, which if somebody goes into that site, they're going to see it in good contrast. I should probably make that darker anyway. That's my slacking, I guess, right there. We have our tools. Where's our? Somewhere in here. That's what I like to do. I like to go and run them through the wave tool, come out and check the contrast, check the styles, all that good stuff. It's really easy to do that. Again, you can download it if you don't. A little bit more for coding. This should be good for people like this. Mobile First. Everybody's kind of doing that anyway. Usually, if you practice mobile first development, you're doing things like considering a tiny screen in which you need to make things different in a formatted way so that people can consume that pretty good. If you design with mobile first, you're going to tend to have less junk in the page. The ads are not going to get in the way as much as a big page. It tends to be a little more trim and a little bit less bling, a little bit less eyesores, which makes it easier basically for everybody. What we want to do, though, as well, mobile or not, use ARIA. I'll show you on, I think, the next slide or so. These things called skip links, which are part of ARIA. Those help screen readers go through and read properly. Of course, we have to be keyboard and alternative input friendly. Keyboard is really not too bad for most people. However, if you're, we have just keyboarders here, like I hate the mouse kind of people, a lot of coders are like that. If you do almost 100% of your work just with the keyboard and you try to do a tab and tab through a web page, it's all over the place. It'd be tabbing up and down in no particular order very often. Then I will see people putting tab orders in that are not correct or out of order. You want to make sure it's keyboard friendly. All those other devices, like the Braille readers and things like that, make sure that that's friendly as well. In a slide coming up, I will show a few of those alternative ways to make things keyboard friendly. It's really simple, just doing a few things with these, what's called aria, adding them to your form. It's a tiny bit of code. Works great. If you're going to code, good thing the marquee and the blink tag are gone now. Those little things. First thing that came into HTML to go. So any strobing, flickering, flashing, those kind of things make it difficult. And crazy JavaScript makes it. It's fun to write crazy JavaScript. Not so fun to be on a page with crazy JavaScript popping up things. I've seen now they're taking to popping up an ad and then popping up an ad on top of an ad. How far are they going to take this? It's going to be ad after ad after ad. I hate ads on the web, pop up ads. I stopped watching TV because of ads and now they're all over the web. So one of these things to do to make it easy to navigate and then friendly forms are these things called skip links and they're part of aria. And if we look at this, this web aim organization has created what is called aria or it's accessible rich internet applications, aria. And it's just a set of small things you can do to make your applications rich on the internet. One of them is what's called the skip link. So as I mentioned before, when I go through with or any screen reader, it'll read the logo and then it has to read the links. And then I go to the same, maybe this next page and I click on that. And when I get to this page, it needs to do the same thing. It reads this, reads the links. If you're a sighted person, hey, that's no problem. You just don't look there. If you're not sighted and you have to have a screen narrator, then you have to painfully sit there listening to that over and over. It's kind of a pain. So what we could do is say, hey, screen reader, how about you skip over these? We'll tell you where to go to get to the good stuff first. And this is kind of a small navigation. You see a lot of sites with tons of links across the top. Oh, MSDN perhaps. Yeah, like, oh, look at, and then these things. That's not good for accessibility, Microsoft, by the way. That stuff. And then stuff down here. Oh, and not just that, but maybe even some of the stuff that gets, there we go. Some of this is possible. I do not want to sit through all that. That was painful. The irony of non-accessible accessibility page at Microsoft. Just saying. So these skip links. So this is one way to do this. And so if I come here, web aim does these perfect. Just go and see what they do and you do it. It's very easy. So to make the screen reader skip them, what I do is I just use an HTML, a named reference. So you do the little pound sign and name. And that will help us. So if I come in here, I'll look at the source for this. I had the source open. If I just look for anything called skip in here, it's easy. What they do is they create a little div. I zoomed a little far there. I like the big text. All right, so we create a little div. Skip to content. And this is what it is. It's this link before the rest of your links that just says, hey, screen readers, you go here and skip to that. Screen reader will look for this. And if it sees something that does that, it can go to there. Now there's a few more things in here. If I take a look, here's some of the other links as well. Oops, I have a skip. But that's basically all you have to do is in the somewhere in the top of your page, come in here and tell it where to skip to. Now this doesn't necessarily show up on the top here. All right, I zoomed a little far again. There we go. So these skip links, you could do it one of two ways. You can actually just have these as regular links and then say to the screen reader, take that and skip over those links. Or some people don't like to display the links and they have other navigation. You can just make it so that it's invisible. And you could do that by doing this, just setting a little bit of CSS. And that's actually what they do at WebAIM. So they have the regular links and then like a little hidden skip link. So the reader sees this hidden skip link. And it says, skip over all that stuff, go right to the content. And it doesn't visually display it for the people who are visual. So we just set it like way off to the left and just make it tiny. And then the reader will pick it up. But the user never has to see. It's a bit of a hack. It's a bit of a known hack. They'll fix that one day, I think, make it a little less reliant on CSS if you want them invisible. Another, now here's a good coding technique, again, the semantic tags. Now we have these ARIA tags that I just mentioned. And if I look here on WebAIM, there's a whole set of ARIA links. And you'll see things like, if I had a form, I could tell something, I want to make this an ARIA or application of rich internet. So I could make it that. And I could just take any HTML element and say, you're now going to be an ARIA element. It's nothing special other than the fact that ARIA elements work better with assistive technology than nothing, which is what we would have otherwise. So we have these ARIA tags. Sometimes, though, you'll see one where you can use a semantic tag, like with checkboxes and things like that. So we want to start with semantic tags before we get to the ARIA tags, but we kind of have to know about ARIA tags as well. So semantics, which is your HTML, your article, header, footer, nav, there's one or two others. A section is another one. And it's basically just your tag that says, this is an article on my blog or on my website. This is a section on my website, a section for ads, a section for this or that. So that's all that it is. It's just plain old tags. Once we run out of those, we should actually be doing this anyway. We should actually just be using HTML semantic tags that use the HTML standard now. So we should just be using them anyway, but they happen to partly be there because of accessibility. So with the ARIA, so that's the whole actual acronym, web accessibility initiative, accessible, rich internet applications. It's like somebody on the.NET team got to name this somehow, like giant name, the irony that you've, of getting through that with maybe an accessible problem. It is actually a W3C protocol. So there is an RFC for it. You can go to W3C and see the specs on ARIA. And all they are are attributes that go into HTML. So it addresses those missing semantics. Now this was around before semantic tags. So that's why there's some ARIA stuff that semantic tags ended up kind of taking over, if you will. So that's why that has that. But it addressed those missing semantics at one point. Perhaps at a later date, I'm hoping that they'll start to incorporate the rest of ARIA. I've heard that they're supposed to incorporate the rest of it in as just part of the HTML spec like they did with the semantic tags. That would be pretty cool if they did that. So with ARIA, they're all attributes. And they're basically attributes that tell us what this element does. And there's these three categories of them, properties, like what an element does. Is it a button? Is it an input? What is this? And remember, this is for a screen reader, not a person. States, which is the condition. So you might see ARIA checked to tell the screen reader that a checkbox is checked. Or you might see ARIA disabled to show that an element is disabled. Properties, like a required. You'll see kind of like your validation ARIA required. So these are just there to make assistive technology better. As far as those roles go for ARIA, we have, we'd sell it as a whole ARIA application. You could set banners. So if it sees ARIA banner, knows that it's maybe part of a navigation and logo. And that a screen reader is going to say, hey, I could just skip over that after the first time I read it. Forms, of course we want forms. That'll be an important one. Navigation's another one. We want to tell it ARIA nav to say when to navigate. And also searching as well. So we have these different roles. And the states. The ones in red are those ones where you can usually use a semantic tag instead. So if I wanted to label something, I could just use a label. Or described, I could just use a label. Same thing. Disabled. Just disable something. But there's other ones. If I need popups, I can say this particular div or span is going to have a popup. So I can say ARIA has popup equal true and we're good. Or just ARIA has popup. Don't even need the equal true. It's just a bit flag. These ARIA elements help us create accessible forms. So this way, so here's a problem. People fill out the form and then they click and things happen. And those things that happen is often JavaScript first before it goes over to the server. And JavaScript is a bit of the bane of the existence of an accessible user. JavaScript, first of all, readers don't know what it's going to do. And readers can't. They're not compilers. They don't go in there. They can't read the JavaScript and just figure out what it's going to do. It has to wait until the JavaScript is doing it. And then the reader tries to adjust. So when a popup happens, the reader had no idea. The narrator says, oh, something happened. Oh, there's more HTML here now. Let's read that. Or sometimes it just can't even do that. It doesn't know what to do. So if we want to work with this, we need to watch a little bit of JavaScript. So things like alerts and warnings. I think we're kind of over that phase where you'd click a button and you'd get a JavaScript popup telling you about validation. Now it's usually not so modal, not in your face. As much as possible, it's getting harder to do this. Trying to do things where anyone test by turning off scripting and then testing your site. That scares me a little to even try it on most sites. Scripting is just everywhere. Probably won't be able to get 100% on this. But try to see if you can run some of your sites with the least amount of scripting possible. The problem with not having scripting is then it's not the greatest experience most of the time. So we want to weigh that fact of not having the best experience with some nice, rich JavaScript versus the not so great experience of an accessible user. And we do have a majority-minority thing here. So we kind of have to weigh that and balance that. And of course, security and stuff like that. So if a validation happens, JavaScript will pop up something and the screen narrator just doesn't know what to do again because it's dynamic. And you can't necessarily even go anywhere. Once a pop-up message comes up, you have to do something with it. And if it's not a sighted user, they don't necessarily know to click and the screen reader is supposed to tell them, but it can't always because something dynamic happened and it didn't know what was going on. So for forms, along with trying to not kill people with JavaScript, trying to balance that, things that we want, make sure your tab order is good, which usually means not putting in tab orders. Another one that screen readers often choke on is if they JavaScript focus on the first field and screen readers, then some of them will just automatically start reading that field, which sometimes is okay, but sometimes not. Blinky stuff, buttons and links, they need to be big. So we have those multiple input devices and I will often see tiny, tiny links, tiny, tiny fonts, tiny, tiny buttons that is hard to click on or hard to tap on. A lot of accessible users don't use the mouse, possibly not even a keyboard. They're using the other devices and they need to tap or puff or something like that and tiny links and tiny buttons are their enemy. It's just impossible to work with them. So we could use ARIA again for all of that. So what we could do if we want to use ARIA to do that, we first want to use good old HTML and set up our field sets. So we could use that more semantic type of paradigm. Then we could have our fields and we want to put in legends for checkboxes and things that we want to group, radios, those kind of things. We could put them in a field set. If you're an MVC person, ASP.net MVC and you do a file new project, it actually puts some of this stuff in for you, the field set and all that good stuff. If you do Windows app development, like when JS, it actually puts in ARIA tags for you, which is kind of cool. So here's all the coding accessible forms, things we want to do. My label, right? So I don't need to use anything special, but make sure it's labeled. Use a label tag instead of just a span or something like that for what element. And then we have the input for that element. And then here if I have some validation, I might have a span to put it. And here's something else too. So you'll see this. But instead of saying the word required, you'll just see a little star, tiny little star. And it's hard for a lot of folks to see that. And a screen reader doesn't know what that is necessarily. Just a little star. It goes asterisk. And that's all it says, which tells us nothing. But it will see the word required. And it will say required. This is required. So that's the first thing we want to do is to make sure we have labels and inputs. And ARIA, every ARIA element is ARIA- whatever. From that slide a few slides ago, with that list of them, there's only a handful of them. But in this case, if this is required, so if I want to make this sample from the previous slide required, actually required, I come here and I tell it ARIA-required equal true. And then if there's a few, there are several screen readers out there. And if one of them hasn't quite caught up yet, or it doesn't work the best, that happens. At least the ARIA tag, it will definitely pick that up. Even if it kind of says required or doesn't pronounce it well, or does some other kind of boo boo. So we just do the ARIA-required. If I had, say, a check box and I wanted it to be checked by default, because we're sending a newsletter, that's why you do that. Then we would just say ARIA-checked, or ARIA-checked equal true. And we would make sure that that's checked and that the screen reader tells the user that it's checked. If they're blind, they don't necessarily magically know it's checked. So we just add ARIA attributes to what we want to tell the screen readers how to behave with that. I don't have the forms. Three minutes. So some of the tools, I showed the scanner and the 508 color contrast. This is a good one, this WCAG checklist. There's the same thing at web.com. Web content accessibility guidelines, that in a checklist are really good. So I come here pretty much any time I'm going to deploy anything. I come and we check the checklist. That was not what... Sometimes you copy and paste and it just doesn't seem to copy and paste. Or it's me. There you go. How about without that stuff? So here, this checklist. This is good. So it gives you all these different things. And you just go through. And it gives you all these recommendations. And you may not be able to do every single thing. But it's just a list of these things that I've been talking about. They use semantic markup. Make sure things are zoomed. Make sure things are meaningful and organized well. Use color correctly. So literally just a list. You print it out. Check it off. Write a little script or utility so that you can check this off at time that you're going to deploy. So I like checklists. That's how airplanes run. They go through checklists and checklists and checklists. I think they automate that now, though. Even so. Nice. I like that. You get to do all that. And then you could go to the scanner. Run things through your scanner. And if you just do these few things like using semantic tags, ARIA tags, watch your color contrast and consider color blindness. Add some of those ARIA elements into your forms. Make things big and clear. And those are not hard things. They're very simple things. It's not a lot of things either. But it helps quite a bit. It helps an order of magnitude for other folks that may have problems accessing your website. So I kind of like this. It's a big bang for the buck. You can now reach 20% more of your user base just by implementing these few things. And even if you don't get to them all, implementing some of them is better than implementing none of them. It will certainly make a difference to the users you implement it for, whether they're an accessible user or not. It benefits the non-accessible users as well. So that's like the real benefit of accessibility, is it actually helps everybody, not just those who are accessible. Oh, there's also 10 more free screen readers. There are lots of pay for ones. You can go find one that you like. A usability geek is a really good site. Anything with usability, making it easier to use. Also, there's a nice blog on NVDA in particular, since I kind of like that one as well. So usability, that's like lots of nice screen readers there you can test. And that's the thing I would suggest you do. Actually, like blindfold yourself, get the screen reader, and try to navigate a few web pages as if you were blind. It's a bit of a challenge, especially the first few times you do it, even after that. It's a very different thing. So if you can imagine, that's difficult for them as well, even though they may have been living blind for quite a while. So these things help everybody, regardless of who we're technically targeting, accessible users. So I like things that are good for everybody. It helps us all. And that's all I have. So thanks for coming. I think actually it was five minutes over, right? Yeah. Okay, well, thanks for coming. If you have questions, you can come up.
we can use to work with accessibility. So we'll internet. But 1.4 billion of them can't, if they of accessible need. I see many people in this use the site. So that those people involved in want to reach all of your customers. As many as popular websites, are actually dyslexic. And if make better websites and apps, we need to make people that have accessible practices, they said, types. We have our auditory, visual, motor, Microsoft.com and I learn how to type. And we'll content, distinct sections. The pop-ups. You'll so many people that simply cannot use these users, I will see people just dumping the to code accessible pages, it's part of our design call Section 508. There's a checklist at AIM that would help adhere to that. It's just this cool can read that tag. Once in a while, if you don't display it for the people who are visual. So we have to know about ARIA tags as well. So bang for the buck. You can now reach 20% more of your user base just by implementing these few