An Intro to Web Accessibility in Django
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 1 | |
| Number of Parts | 52 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/32730 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Fitness functionVapor barrierMultiplication signMachine visionInterface (computing)Client (computing)Web 2.0Video gameMobile appCartesian coordinate systemTouchscreenComputer animation
00:49
Vapor barrierProcess (computing)Machine visionDifferent (Kate Ryan album)Web 2.0Revision controlAreaRight angleComputer animation
01:19
Depth of fieldContrast (vision)Online helpUniform resource locatorSheaf (mathematics)Content (media)Table (information)Key (cryptography)Electronic mailing listTouchscreenMultiplication signRhombusComputer programmingSoftware testingResultantMathematical analysisPoint (geometry)Web pageElement (mathematics)Standard deviationAreaArithmetic meanFamilyMetadataBlock (periodic table)Observational studyRule of inferenceString (computer science)Reading (process)Inheritance (object-oriented programming)Level (video gaming)Medical imagingWeightQuery languageComputer fileText editorProfil (magazine)Link (knot theory)Keyboard shortcutSlide ruleWebsiteFreewareWave packetQuicksortWeb 2.0Buffer overflowZoom lensDescriptive statisticsMachine visionBitRow (database)Goodness of fitStructural loadLatent heat
05:19
Range (statistics)FreewareDepth of fieldGraph coloringGreen's functionStandard deviationDifferent (Kate Ryan album)Machine visionComplete metric spaceWebsiteSlide rulePhysical systemEndliche ModelltheorieRight angleMereologyLine (geometry)Filter <Stochastik>Computer animation
06:07
Entropie <Informationstheorie>Functional (mathematics)Multiplication signTwitterSlide ruleContent (media)Game controllerDisk read-and-write headWeb 2.0VideoconferencingInformation1 (number)Focus (optics)Keyboard shortcutGroup actionElement (mathematics)Electronic mailing listCategory of beingTerm (mathematics)Web serviceCuboidNeuroinformatikPhysical systemCondition numberCartesian coordinate systemLatent heatArithmetic progressionWeb page2 (number)Exterior algebraVapor barrierDifferent (Kate Ryan album)MultiplicationBridging (networking)Source codePosition operatorDirection (geometry)MereologyReading (process)Right angleComputer programmingAreaSheaf (mathematics)Combinational logicOntologyHydraulic motorProcess (computing)Visualization (computer graphics)Pattern languageComputer animation
09:50
Wave packetRight angleWeb pageSoftware developerInstance (computer science)Graphical user interfaceUniform resource locatorInterface (computing)Extension (kinesiology)WebsitePoint (geometry)Error messageLevel (video gaming)1 (number)
10:43
TouchscreenVotingFormal grammarMultiplication signContrast (vision)Content (media)Error messageWeb 2.0CASE <Informatik>Graph coloringStandard deviationBitGoodness of fitWave packetComputer animation
11:37
TouchscreenCuboidEmailAreaGraph coloringError messageWeb pageBookmark (World Wide Web)Arrow of timeLink (knot theory)BitElectronic mailing listContrast (vision)Medical imagingQuicksortSet (mathematics)DivisorSpacetimeRight angleSound effectEndliche ModelltheorieGroup actionProjective plane
13:23
Element (mathematics)Web pageException handlingRight angle
13:44
OracleElement (mathematics)Dot product1 (number)Web pageOntologyProjective planeDialectMathematicsMobile appRepository (publishing)Multiplication signDifferent (Kate Ryan album)Plug-in (computing)Graphical user interfaceComputer animation
15:10
Arithmetic progressionPatch (Unix)Mathematical analysisWikiPlastikkarteMeeting/Interview
15:34
Term (mathematics)Software frameworkContent (media)Moment (mathematics)Sound effectGroup actionClient (computing)WordMedical imagingIndependence (probability theory)Line (geometry)Multiplication signPoint (geometry)Video gameWebsiteReal numberGoodness of fitRevision controlCuboidGraph coloringWeb pageBuffer overflowSet (mathematics)Electronic mailing listCartesian coordinate systemMaxima and minimaInstance (computer science)Figurate numberTouchscreenDifferent (Kate Ryan album)Reading (process)QuicksortStructural loadExtension (kinesiology)Error messageAddress spaceSoftware testingContrast (vision)ImplementationWeb serviceProduct (business)Pairwise comparisonLink (knot theory)Single-precision floating-point formatAffine spaceLatent heatComputer programmingNormal (geometry)AreaFormal languageTwitterComputer configurationPublic key certificateArithmetic meanSelf-organizationSource codeRight angleStudent's t-testUniqueness quantificationString (computer science)Asynchronous Transfer ModePattern languageTable (information)ParsingAbsolute valueWave packetIntegrated development environmentMathematicsFlow separationDebuggerExterior algebraGraphical user interfaceRange (statistics)Meeting/Interview
22:52
Computer animationXML
Transcript: English(auto-generated)
00:16
and ADHD. So accessibility has been something that I have had to keep in mind basically
00:22
my entire life. A couple years ago, I was working on a Django app for a client who the web administrator has low vision. She uses a screen magnifier. The first time I sat 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
00:44
a more accessible application. I just wanted to share some of how we do it. So 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, right? We can say my disability makes it difficult for me to navigate the web, but actually barriers
01:02
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 going to talk about some of the different disabilities that people have that can cause, that can have them hitting up against barriers when they're trying to get online. The first one is blind and low vision users. This is the one
01:21
that everybody thinks of. Think of, you know, you have to make your website screen reader friendly. Being accessible to blind 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, you know, headers, H1s, H2s, H3s, screen readers will
01:40
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, 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
02:03
high contrast makes it much easier to see it. 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,
02:22
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. 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
02:40
so that a blind user, a screen reader user can see it when they're pulling up that list of links. Last thing is, well actually two more things, relevant image captions are a big one. You see two loads 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
03:02
spectacles on a keyboard. If I was putting on alt text for this on a 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 while in photography, I might instead say an example of a medium depth of field or
03:23
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 even know what the bullet point looks like. You've got a row of diamonds
03:42
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, until it gets to the end of the page. Yeah, 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
04:00
your CSS and then people zoom the text up to 300% so that they can read it, and suddenly there's going to be a whole lot of overflow. There's going to be a lot of content that they can't see. So you want to make sure that your, 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 going to
04:24
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 turn it on by hitting command F5. Don't do that right now. We'll start talking. There's other free screen readers you can download. Those are really good for testing. But the caveat here, which is keep in mind that these are highly customizable
04:41
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. That's kind of like telling people, oh, you should just put on a blindfold to see how blind people navigate the real world. 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
05:01
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 particular form element captioned correctly or all texted correctly? They're good for that.
05:20
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 the long and short of it. There's free online tools. I've got one at the end of the talk on
05:42
my slides that will let you put your website through basically a filter that'll show you what it looks like to people with various kinds of colorblindness. Most 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
06:02
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, most people read faster than I
06:22
talk. So 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 after 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
06:40
get that 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
07:00
audio alone for that. Neurodiverse users. This is a 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 accommodations. The standard, the web content accessibility guidelines for epilepsy. They ask people to make sure that their web is, that their elements aren't blinking no more
07:22
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 scaling content. My brain
07:42
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. And I've been in multiple
08:01
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 trying to read something and there's a flashing ad over here or like
08:20
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 once 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 are just like, nope, that's it, you're logged out.
08:41
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 race the clock. 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
09:01
either the keyboard and mouse. Sometimes it's keyboard only. People with arthritis, people with certain conditions that, you know, paralyze their hands or 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
09:20
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. Tool tips and things that where somebody where you have an on hover action, you want to make sure that's
09:41
also an on focus action. So if somebody has keyboard focus on that item, they will see the tool tip. So those are big ones there. I'm going to talk about the admin interface. And when I went through this accessibility audit of the interface, this is actually the 1.9 interface, which is a lot more easier to make accessible than the 1.8 was.
10:01
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 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
10:21
you with accessibility audits. So the first thing, this is just the standard polls app in the 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
10:41
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 too light. The web content accessibility guidelines,
11:01
they want a 4.5 to 1 contrast. If you're using the AAA standards, it's 7 to 1 contrast. We're using the AA standards, which are a little bit more lenient. Fortunately, the wave tool here actually gives you your colors and allows you to play around in light and then dark in colors so that you can get something that's close to your
11:21
existing color but 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
11:40
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 because that image actually is being set with, I believe it's
12:03
being set with CSS. So somebody that is using a screen reader that can't see those little arrows doesn't know 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, checkbox, who is your favorite Captain Marvel, who is your
12:22
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
12:41
colors pretty fast. However, we've got some issues here. 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
13:01
it's a light blue on gray. Well, I had to up it to a dark blue and a darker gray. But 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 going to tell which thing, be able to tell which item in that list they're actually on. So I just also made that item bold, make it a little bit more
13:22
obvious. And that's what this looks like with all of those accessibility updates. Doesn't look bad, right? Looks pretty good. 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
13:41
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 going to have some extra time for questions, because apparently I talked with you fast. Over at last link, the Django Admin 508 GitHub repository. You can actually just install that as an app in your project,
14:02
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 the WebM Chrome plugin. Color Scheme Designer on Paluten is one of the ones where you can filter your page to see what it looks like to people with different kinds of colorblindness.
14:22
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, reading a bunch of docs isn't terribly fun, but these docs are pretty thorough, and they've got really good suggestions. So if you can check through those, you've got a question about, okay, I know this element is a problem. How do I
14:41
fix it? They will have some good guidelines for you. All right. Well, that's all I have, so if anybody has any questions. Yeah, we do have a, thank you so much, Alan. So we do have 10 minutes for
15:00
questions. We can get a few in. For recording purposes, please let me bring you the mic. So all right. Russ, and then we've got one back here. Thanks for that. The Django admin, obviously you've got it there as an external package that can overlay. Have you submitted that as a patch upstream to be looked at? I haven't yet. I'm still
15:20
working on it. The HTML isn't, all of the CSS is up, is fixed up there, but the HTML still needs some work. Okay, so this is a work in progress. You're working towards that though. Okay. Fantastic. Thanks. So it looks like a lot of this work is pretty much HTML
15:41
work. 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 make the situation better or worse? So mostly when you're looking at CSS, you're looking at color contrast is most of what you're gonna hit. Sometimes if you've got that overflow cutoff that happens in CSS, you
16:03
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. Hi. Thank you. Enjoyed your talk. I do work at a nonprofit, and I
16:21
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. The National Federation for the Blind, actually, obviously, has a really good, but they're a resource that I went to, and they do a lot of where they will
16:41
have 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 CSS, 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
17:00
you're setting up your HTML properly, then you can have the same page that's screen reader accessible and also human readable. 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. So ARIA is a screen
17:22
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 has some screen reader specific HTML tags that it supports. For instance,
17:40
alternative link text, because right now this is something that a lot of people want is alt text for links, because they want to be able to use links in paragraphs and then also have a separate alt text. It'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
18:01
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 and is using a different screen reader, the screen reader might not pick it up. For instance, the Mac standard one doesn't pick up ARIA tags. So my question is, given the kind of list
18:21
you have of accessibility issues that we're confronted with, and especially for pages or applications that haven't addressed those ever, what would be the best bang for your buck in terms of low-hanging fruit? Low-hanging fruit, clean up your HTML. Make sure that you're using
18:40
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,
19:02
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 a sentence that says what it is so that people can tell that it doesn't have meaningful content in it. Other things that are just there to visually set up the page, visually organize the page for sighted users, you don't need to caption those. We've got two final questions
19:22
queued up. We could take a third only so fast, but we'll get these two, and then we could take one more potentially afterwards. So you mentioned that it's good to test your pages with a screen reader, and you also mentioned that people who use those things regularly are going
19:41
to be much more fluent with them. Do you know of any organizations, or have you worked with anyone 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? I don't know of anybody who offers that as a service. I
20:01
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, because we read,
20:22
most of us, not me, but most people read faster than they talk, and so they get used to hearing it, and so they speed it up, and so if you just turn on your screen reader at a normal speed, most people, 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 going to take forever to read a page.
20:42
Thank you very much. I was wondering if you could talk about JavaScript single page applications, how accessibility changes on such an environment. So my experience with the JavaScript frameworks like that
21:00
is that they're an accessibility mess. They're not always an accessibility mess. One thing that the Wave 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 going to throw a lot of errors that don't exist or it's just not
21:20
going to be able to find the 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. All right. One final question. So my question is just from
21:42
an implementation standpoint, if you have 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 standard that's laid out or is that a pattern that you see used? That's something that
22:02
some people do is they will offer 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 persnickety designers, you end up sometimes with that compromise of at least offering a different version of the page that is higher contrast. I love designers.
22:24
I'm not knocking on designers, but sometimes y'all like your colors a little too much. If there are unanswered questions in the room, will you be available this week to chat with folks? Will you be at the sprints? I won't be at the sprints. I'm here until Thursday morning, but
22:41
absolutely. Stop me in the hall. Come sit with me at lunch. Awesome. Let's on my own on an empty table. We won't let you. Let's say thanks one more time.