An Intro to Web Accessibility in Django by Annalee Flower Horne

Speaker 1: Come on, no.

Speaker 2: I have dyslexia and ADHD. So accessibility has been something that I have had to keep in mind basically my entire life. A few, a couple years ago, I was working on a Django app for a client who, the web administrator, is has low vision. She uses a screen magnifier. The first time I sat her in front of the Django admin interface, she couldn't see a thing because the light blue on white, this was Django 1. 8, was not working for her at all. So I had to learn a lot about how to break down barriers to accessibility and build a more accessible application. So I just wanted to share some of how we do it. So when we're talking about accessibility, I really like this definition that accessibility is an inclusive process of removing barriers because it makes it about the barriers instead of about the person. We can say my disability makes it difficult for me to navigate the web, but actually

Speaker 2: barriers to accessibility make it difficult for me to navigate the web. We eliminate those barriers and suddenly everyone can access the web and it's great. So we're gonna talk about some of the different disabilities that people have that can cause uh that can have them hitting up against barriers when they're trying to get trying to get online. The first one is blind and low vision users. This is the one that everybody thinks of. Think of you know you have to make your website screen reader friendly. Being accessible to blend and low vision users is actually, there's a lot more to it than being screen reader friendly. Although being screen reader friendly really helps, a well-formatted HTML really helps. When you're if you're using headers, H1s, H2s, H3s, screen readers will actually parse those to create a table of contents for the user so that they can dip down into the section of the page that's relevant. to them. So having those formatted correctly, having them

Speaker 2: using them consistently throughout the page so that you don't have different H1s all over the place, so that the screen reader knows how to parse it. Is a big help for that. High contrast is another big thing. A lot of blind and low vision users don't use screen readers. They use magnification programs or they zoom up the text. And having high contrast makes it much easier to see it, but they don't have to zoom so far in Descriptive link text is another big one here. If you're using a screen reader, one of the things that it does is it pulls all the links out of the page and shows them in a list to the user. So if the user is looking for more resources, they can just have a handy list of links. But if your list, if your list of links looks like click here, click here, click here, click here, first of all, don't do that because it's bad for SEO, but it's also really bad for screen readers. So you want to say, you know, you have a link to edit your profile.

Speaker 2: You want to say edit your profile here and have that whole thing be a link instead of just edit your profile here and having that be a link. so that a blind user or screen reader user can see it when they're pulling out that list of links. Last thing is, well actually two more things. Relevant image captions are a big one. You see two modes of failure here. One is people not including image captions at all. The other one is people captioning way too much, putting in way too much alt text. So this slide, it's got a picture of spectacles on a keyboard. If I was putting on alt text for this on a web page, that's all that I would say. You don't need to put in three paragraphs describing everything about this image. Because all a screen reader needs to screen reader user needs to know is what about it is relevant to the topic at hand. If I was using the same image to illustrate an article well in photography, I might instead say

Speaker 2: an example of a medium depth of field or something that's relevant to that topic. You don't have to describe the whole image because they can't see it anyway. But there's also things like bullet points, horizontal rules. Don't add alt text to those. A screen reader user is already going to know that they're reading an unordered list because the screen reader will parse that out of the HTML and tell them. They don't need to know what the bullet point looks like. If you've got a row of diamonds as a horizontal rule across your page and you put an alt text on all each of those and the screen reader is going to sit there going diamond diamond diamond diamond diamond until it gets to the end of the yeah that's that's that that's funny once right but if you actually have to navigate a page like that it's a real pain in the butt And the last thing is being responsive and zoom friendly. If you're doing a cutoff overflow thing in your CSS and then people zoom the text up to 300% so that they can read it, then suddenly there's going to be a whole lot of overflow.

Speaker 2: There's going to be a lot of content that they can't see So you want to make sure that your the so the web content accessibility guidelines, which are produced by W3, they're sort of the gold standard for how to make accessible web pages. And their standard is that your text should be zoomable to 200% without losing any content. We're gonna talk a little bit more about screen readers later, but I just want to point out if you're on a Mac, you actually have a screen reader already installed, you can uh turn it on by hitting Command F5. Don't do that right now, it will start talking. There's other other free screen readers you can download. Those are really good for testing, but there's a caveat here which is keep in mind that these are highly customizable programs that people get a lot of practice using. So sometimes people will tell you, oh, you should just turn on a screen reader to see how blind people navigate the web. It's kind of like telling people, oh, you should just put on a blindfold to see how blind people

Speaker 2: navigate the real world, right? There people have practice and they have training in how to use these things So just because it's hard if you turn it on and you don't get discouraged because that doesn't mean that your website is awful for everybody. It means you don't know how to use a screen reader yet. But they're really, really good for testing individual elements. So it's a good thing to have one installed so that you can see if you're looking for a specific thing like you know how do I have this do I have this this particular form element captioned correctly or all texted correctly? They're good for that. Colorblind users. There's a lot of different kinds of colorblindness. Basically, the standard here is don't use color alone to distinguish elements. If you've got a form where you're putting red text to indicate what are the required fields, put a star next to it too, so that people that see red as gray still know what those required fields are. Basically that's

Speaker 2: that's the long and short of it. There's free online tools. I've got one at the end of the talk on my slides that will that will let you uh puts your website through basically a filter that'll show you what it looks like to people with various kinds of colorblindness. Most kind people with colorblindness though are in this range here. They're not usually over On that last one, which is complete lack of color vision. Most people can see some color, but you want to watch out that you're not using colors that are just going to read as the same to them, like blue and green. Deaf and hard of hearing users, this one's pretty straightforward. Caption your audio content. If you can, accompany it with a transcript as well. And the reason I say this If you're trying to get specific information out of a talk, having most people read faster than I talk.

Speaker 2: So if you were if you were trying to watch this video later and get specific information out of here, you might just want an audio transcript that you can control F to the particular thing you want. instead of having to watch the whole video just to get the captions. And accompanying nonverbal sounds with visual cues. Everybody's had the experience where they try to click on a button and they get that dun sound which tells them that the button's not clickable. If you are hard of hearing or deaf or you don't have your headphones that day, you're not going to hear that noise. And so you might sit there just keeping clicking on it, wondering why it's slow or why it's broken, because you don't realize that you forgot to check the box that says I accept the terms of service So, you know, have something pop up or you know little red text that says you need to accept these terms before you can continue. Don't rely on audio alone for that. Neurodiverse users. This is the category I fall into. These are people with various neurological issues. You've got low literacy is not a neurological issue, obviously, but it's on the list because it needs the same kinds of accommodation.

Speaker 2: The standard, the web content accessibility guidelines for epilepsy, they ask people to make sure that their web is that their elements are blinking no more than three times a second. Because if you're blinking really fast, you can trigger a seizure, which is obviously bad news bears. Dyslexia and executive function disorders. As somebody with ADD and somebody with dyslexia, it's really helpful to me if there's a lot of headings and subheadings breaking up content. Control F is my best friend. I have a hard time skimming content. My brain just doesn't work that way. So I need to find the specific thing that I'm looking for. Breaking up content that way also helps people with ADHD because when we get distracted, we'll be able to find our place again really fast. Letting users pause or stop anything that's animated or blinking, carousels, if you've got slideshows. It takes me a long time to read those things.

Speaker 2: I've been in multiple situations where I'm trying to look at something on a slideshow and then it moves to the next slide and I have no way to stop it, so I have to wait until it comes around again. That is super annoying. So let people pause things, let people hide things. My other favorite thing is when I'm when I'm trying to act when I'm trying to read something and there's a flashing ad over here or like scrolling tweets over here I get distracted every five seconds and I have to find my place again and it takes me forever. You can have my ad blocker when you stop moving things on my page. And then saving progress when sessions expire. People that take a longer time filling out forms, we get these little pop-ups. A lot of times now they'll say, do you need more time? But there's still a few that'll just like, nope, that's it, you're logged out. Make sure that you save our progress so that when we log back in, we don't have to redo it all over again and erase the clock.

Speaker 2: So these are some of the different kinds of barriers people can experience when they're accessing the web. I'm going to talk about, oh, I forgot one. Alternative controls. People that access the web without using either the keyboard and mouse. Sometimes it's keyboard only. People with arthritis. People with certain conditions that paralyze their hands, they'll have or they'll they'll have limited movement in their fingers. They might have a switch system that plugs into their computer and the computer reads that as a keyboard. So you want to make sure that your applications are accessible to people that are using a keyboard only. Big thing here is just watch your cursor focus. Make sure that you're not trapping focus. If something pops up in a modal then they should be able to use a keyboard to close that modal. And when they do, it should return focus to whatever they were on before the modal popped up so that it doesn't direct them back to the top of the page again.

Speaker 2: Tooltips and things that where somebody where you have an on-hover action, you want to make sure that's also an on-focus action. So if somebody has keyboard focus on that item, they will see the tooltip. So those are the big ones there. We're going to talk about the admin interface and when I went through this accessibility audit of the uh interface. This is actually a 1. 9 interface, which is a lot more easier to make accessible than a 1. 8 was. We're going to talk about, you can see up in The very top right corner there, left, yeah, right corner from your side, that W, that is the wave. webaim. org Chrome um extension. And what that does is I like the Chrome extension. You can also go to the website itself and plug in your URL. But if you use the Chrome extension, you can use it on local instances so you can do your development there. And what it does is it helps you with accessibility audits.

Speaker 2: So the first thing this is just the the standard polls app and the you know Django tutorial. This is showing us what our HTML looks like. And it tells us we have two H1s on this page. Just not ideal. We want to be using these consistently. A page should only have one H1, it should go down from there. But other than that, we're actually doing pretty good here. There's no big red errors except. Yeah, that's what I was just talking about. About screen readers want you to be using these consistently. We do have contrast errors here. That blue on the white is is too too light. The web content accessibility guidelines, they want a 4. 5 to 1 contract. If you're using the triple A standards, it's seven to one contrast. We're using the AA standards, which are a little bit more lenient.

Speaker 2: Fortunately, the um The wave tool here actually gives you your colors and allows you to play around and lighten and darken colors so that you can get something that's close to your existing color, but is actually has a good enough contrast. So in this case, we've got a 2. 4 to 1 contrast, it's no good. We can up it to 5. 4 to 1, make the color a little darker , and that gets rid of all of our errors. And now you can see it. This is with the darker colors. It doesn't look that bad, right? So this is a detail page. And here we are getting actual HTML errors. We don't have a header on the column that has all the checkboxes in it, and the checkboxes themselves are unlabeled. So when a screen reader is going to look at these, it's also pegging that we have an empty link on the sort by column

Speaker 2: because that that image actually is a It 's being set with, I believe it's being set with CSS. So somebody that is using a screen reader that can't see those little arrows doesn't know what that uh what that link does. When a screen reader looks at these checkboxes, that's all it says. Unchecked checkbox. We want to change that. So it says unchecked checkbox, who is your favorite Captain Marvel? who is your favorite Miss Marvel, so that they have, when they're accessing the checkbox itself, they don't need to move from that to figure out what it is they're clicking on. We've also got some contrast errors here. A lot of them actually. So these are actually pretty easy to fix because the admin doesn't use that many colors, so you can find and replace the colors pretty fast. However We've got some issues here.

Speaker 2: When we make that breadcrumb light enough that it doesn't have a contrast error anymore, suddenly it looks exactly like the rest of the breadcrumbs. So what I did is I added an underline there so people can tell they're on questions now and they're not on homework polls, but they can click. back to those. Down here in the filter list, you'll see it's it's a light blue on gray. Well I had to up it to a dark blue on a darker and a darker gray. But once you when you do that, when you then desaturate it, somebody that's colorblind might not be able to see that dark blue. So it might just look like gray and gray and they're not gonna tell which thing be able to tell which item in that list they're actually on. So I just m also made that item bold. make it a little bit more obvious. And that's what this looks like with all of those accessibility updates. Doesn't look bad, right? Looks pretty good.

Speaker 2: So yeah, I talk really fast. So this is just the detail page. Again, it's got a whole bunch of unlabeled form elements that we'd want to fix, but that doesn't look very pretty when I fix it, because it doesn't look like anything when I fix it So here's some accessibility resources. I'm gonna have some extra time for questions because apparently I talked way too fast. The um over there that last link, the Django Admin 508. GitHub repository. You can actually just install that as an app of as an app in your project and it will override your Django admin styles for you to give you the darker blue that you just saw here. And then here's some the webinar Chrome plugin. Color scheme designer on Palatin is one of the ones where you can filter your

Speaker 2: page to see what it looks like to people with different kinds of of colorblindness. W3. org has all of these accessibility guidelines up online and they're actually pretty easy to search through. So it's something where you can go and look at those. I mean it's you know reading a bunch of docs isn't isn't terribly fun, but these docs are are pretty thorough. And they've got really good suggestions. So if you can check through those, if you've got a question about, okay, I know this element is a problem, how do I fix it? They will have some good guidelines for you. All right, well that's all I have. So if anybody has any questions.

Speaker 3: Yeah, we do have a thank you so much, Alan. So we do have uh ten minutes for questions. We can get a few in. Um for recording purposes, please let me bring you the mic. So all right. Russ, and then we've got one back here. Um

Speaker 4: thanks for that. Uh the at Django Rabbian obviously you've got it there as an external package that can overlay. Have you submitted that as a patch up stream to be booked out?

Speaker 2: I haven't yet. I'm still working on it. All of the CSS is up, is fixed up there, but the HTML still needs some work.

Speaker 4: Okay, so this is a work in progress. You're working towards that though. Okay. All right, fantastic. Thanks.

Speaker 5: Um so uh so it looks like a lot of this work is pretty much HTML work. Um does CSS have a fair amount of effect on it? And if so, how do the CSS frameworks and stuff like that play in? Do they do they make the situation better or worse?

Speaker 2: So mostly when you're looking at CSS, you're looking at color contrast is most of what you're going to hit. Sometimes if you've got that overflow cutoff that happens in CSS, you want to avoid that or at least make it so that your text can zoom up to at least 200% without triggering it. But mostly it's just setting colors that have a high enough contrast, and you can do that in pretty much any front-end framework.

Speaker 3: Hi, uh thank you. Enjoyed your talk. I do work at a nonprofit and I was curious if you are if you would name any nonprofits that you feel like have especially good websites in terms of you know the full range of the public being able to access them.

Speaker 2: The National Federation for the Blind, actually, obviously, has a really good um but they're a resource that I went to and they do a lot of where they will have the the version of the page that is that is meant for people to look at and then they have the version of the page that is meant to be read to somebody, which just strips out all of the uh CSS and it but it's not just like the page without the CSS. It's formatted differently so that the screen reader can read it and get everything. You usually don't have to go that far. Usually if you're using if you're setting up your HTML properly then you can have the same page that's screen reader accessible. accessible and also human readable.

Speaker 6: One thing that I didn't hear you call out explicitly in your talk, but I imagine you have some experience with is ARIA. And I'm wondering sort of what your experience has been with that and any difficulties you might have come across when using it.

Speaker 2: Sure. So ARIA is a screen reader program. I actually use the one that comes built in on the Mac, so I haven't been using ARIA at all recently. ARIA is sort of the big most common screen reader program and it it has some screen reader-specific HTML tags that it supports. For instance, alternative link text, because right now this is something that a lot of people want is alt-text for like links because they want to be able to use links and paragraphs and then also have a separate alt text that'll tell people what it actually links to. Right now screen readers try to mimic what the page actually looks like. So they don't pick up alt text on links. They're going to pick up the actual text of the link That's annoying. Aria has an option where you can actually add an ARIA tag to that that will read something different. The danger there is that those aren't universally supported tags. So you can stick in ARIA tags for ARIA to read, but somebody that is on a Mac

Speaker 2: and is using a different screen reader For instance, the Mac standard one doesn't pick up ARIA tags.

Speaker 7: So my question is given the kind of uh list you have of of accessibility issues that we're confronted with and especially for um pages or or applications that haven't addressed those ever, what would be you know the best bang for your buck of in terms of low-hanging fruit?

Speaker 2: Low-hanging fruit, clean up your HTML. Make sure that you're using well-formatted HTML that the screen reader is going to have an easy time parsing. I think color contrast is low-hanging fruit, but that's going to depend on how picky your designers are. Other low-hanging fruit is getting good captions on your images. Just the images that have specific content. You basically, if it has text in it, you want to caption it. If it has meaningful content, you want to caption it. If it's something that's illustrating something but doesn't have a lot of meaningful content, you just need like a sentence that says what it is so that people can tell that it doesn't have meaningful content. Other things that are just there to visually set up the page, visually organize the page for cited users, you don't need to caption those.

Speaker 3: So we've got two final questions queued up. We could take a third. Ollie's so fast, but we'll get these two and then we could take one more potentially afterwards.

Speaker 8: So you mentioned that um it's it's good to test your pages with a screen reader, and you also mentioned that it's it's uh people who use those things regularly are going to be much more uh fluent with them. So do you know of any organizations or have you worked with anyone? um that uses a screen reader regularly or uses these assistive technologies regularly to actually test your pages sort of before you would go to production.

Speaker 2: I don't know of anybody who offers that as a service. You know, I know individual friends that I can ask, but that's a good question. I will try to dig that up and put it on the Django Twitter tag if I find it A lot of what blind readers do when they're using screen readers is just speed them way up. Um because we read, most of us, not me, but most people read faster than they talk. And so they will just, they they get used to hearing it and so they speed it up. And so if you if you just turn on your screen reader at a normal speed, most people, who's who speeds up their podcasts? Yeah. Yeah, it's the same thing. If you turn on a screen reader at a normal speed, it's gonna take forever to read a page.

Speaker 5: Thank you very much.

Speaker 6: Um

Speaker 5: I was wondering if you could talk about JavaScript single page applications, how accessibility changes in on such uh

Speaker 6: such such an environment.

Speaker 2: Um so my experience with the the Django Frame or Django framework or the JavaScript frameworks like that is that they're an accessibility mess. They're not always an accessibility mess. One thing that the WAVE uh Doohickey that I just forgot the word for, does is it tests the page after it's been rendered. Whereas if you plug it into a checker that doesn't render the JavaScript first, it's gonna throw a lot of errors that don't exist, or it's just not gonna be able to find any content So yeah, the Chrome extension, I think there's a Firefox extension too, are both really handy for that because it'll actually let the page load before it starts reading them. Most screen readers are smart enough now to also do the same thing.

Speaker 3: All right, one final question.

Speaker 4: So my question is just from an implementation standpoint, if you have uh clients or colleagues that have designed a page and it looks very good but you want to actually start moving towards accessibility. Is there like the mode you described a few moments ago, like a high contrast mode or an accessibility mode? Is that a a standard that's laid out or is that a pattern that you see used

Speaker 2: That's something that some people do is they will offer you know a higher contrast mode or a larger text mode. It tends to be better to just make your page accessible out of the box. But if you have really, really persmissive personicity designers you end up sometimes with that compromise of at least offering a different uh different version of the page that is higher contrast.

Speaker 1: It's easy to start and then kind of

Speaker 2: Yeah. I love designers. I'm not knocking on designers. Sometimes y'all like your colors a little too much.

Speaker 3: Honelia if there are unanswered questions in the room, um will you be available this week? To chat with folks, will you be at the sprint?

Speaker 2: I won't be at the sprints. I'm here until Thursday morning, but absolutely stop me in the hall. Come sit with me at lunch

Speaker 3: Awesome, let's

Speaker 2: on my honored and empty table.

Speaker 3: We won't let you. Let's say thanks one more time.