Django Accessibility for Everyone

Hello? Can everybody hear me? Great. Okay. So I'm Lauren and I'm a junior developer at Torchbox and I'd like to talk to you about accessibility today So this talk is especially for people who are new to accessibility or might feel daunted by it, but I hope that everyone will be able to learn something from my talk today. The links to the slides are at torchbox. com forward slash Edinburgh-accessibility if you'd like to follow along. And I'll leave that on the first few slides as well. Well first of all, a plug. Come and say hi. Some of us from Torchbox have a stand in the hall, so please come and say hi and I'll be hanging around there

If you've got any questions, it'd be great to meet you all. Okay, so my hopes for this talk. I really hope that this talk will spark an interest in you to learn more about accessibility I'd like to show you some simple ways that you can improve people's experiences online. And I'd like to signpost you to resources and people who can help you learn more. But first of all, why does this all matter? In 2020, a survey was conducted by Scope, which is a disability equality charity based in England and Wales. And they asked their users about their experiences online. One of the questions they asked was, how does it make you feel when you cannot complete a task online?

And I'd just like you all to reflect for a minute now on how that might make you feel. The word cloud that I'm showing now is some of their responses. So this includes words like angry, stupid, annoyed, and overwhelmingly their users feel frustrated. One response was simply that they feel isolated, excluded, alone, frustrated, and unimportant to society. One survey respondent also wrote that it makes me feel like the internet doesn't belong to me and it's not a welcoming place. It strips others of their independence and leaves them feeling excluded. I'm sure that we would all agree that this is not what we want our users to be feeling.

One way that some people choose to understand disability is through the social model. Now I want to caveat this with not everybody likes this model, not everybody chooses to view disability through this lens, but it is one way that we can think about disability. The social model describes how disability disables people by barriers in society and the the way society is organized, but not by their impairment or difference. These barriers can come in all shapes and forms, from an in-person barrier like a building without a ramp, to people's prejudices, to inaccessible websites. And in our role as web developers, it's our responsibility to make sure that our websites are accessible.

But first of all, we need to know a little bit about how people access the web And as you might imagine, it's kind of complicated. People access the web in lots of different ways. And some people use assistive technology So this can include things like screen readers, refreshable braille displays, specialized keyboards, but this is by no means an exhaustive list. And assistive technology is a fantastic tool that we can use to break down these barriers. But we need to learn to work with it to make our websites accessible. Okay, so I'm mentioning the word accessible a lot. But what does it mean to be accessible? Well

The Web Content Accessibility Guidelines, which is a bit of a mouthful, and so people like to abbreviate it to WUCAG or various other pronunciations of it. outlines four guiding principles that we can use to make our websites accessible. And these are that our websites should be perceivable, operable, understandable and robust. And when we're creating websites, we should try to bear all of these in mind. Okay, yeah. So you might be thinking accessibility is old news. All right, let's have a look at what the web is like today So this is the HTTP archive. So some of you may have heard of it, and for those of you that haven't, basically it's kind of cool and you should have a look.

It trawls through the internet, it compiles metrics of the top websites online. And one of those metrics is accessibility And it uses Lighthouse, which is Google's open source accessibility auditing tool, to do these testing, do these tests. And when I was thinking about planning this talk, it was kind of hard to know how to narrow down what I should focus on. But the HTTP archive helped me focus on what the top accessibility issues were on the web today. So if we look at the top million websites, it shows us that there are a few areas that are consistently underperforming. And these are color contrast. button names, link names, labels, and alternative

alternative text on images. This graph shows the same sort of thing. This shows the same five categories that I've just mentioned with an extra one which is the missing document language. And the story in Django is much the same. My colleague Thibaut, who is sitting at the front, who has also helped with the organization of today, who should definitely speak to Analyze the difference between the accessibility scores of Django-specific websites and all sites. And not only do we see the same sort of trend with those categories that I've just mentioned before We also see that Django specific websites actually underperform relative to other websites on certain of these

accessibility tests. And those are shown in the top And these are things like we tend to overuse ARIA labels. We tend to forget to set a document language, and we tend to forget to give alternative Texts for images. So when I'm giving this talk, I'm gonna try and highlight these things especially And I'll return again to this graph which shows the top six accessibility issues across the web because together These top six issues account for 96. 1% of all the errors we detect. On those top million websites. So 96. 1, that's crazy. So these six things that I'm going to talk about today, we can fix most

of the common problems. All right. The good news is that actually these six are kind of easy to fix, right? That's good. Um and there isn't really any bad news. So we're gonna get on with it All right, I'm gonna ask you now, what do you see? Is anyone can anyone make out anything from this image? Okay, this might make it a little bit easier, but it might not for everyone. So this is an Ishihara test plate which tests for colour deficiency. And it's estimated that about one in twelve men and about one in two hundred women have some degree of colour deficiency. So when we're designing our websites, we need to bear something in mind.

First of all, we shouldn't just use colour to communicate. Imagine you're on a website and you read, select the green button for yes and the red button for no. And then you see this. Okay, so this these identical looking beige buttons are actually how somebody with red-green colour blindness might perceive them. And so It's not very helpful, you're not gonna know which to click. And so we need to just add labels and it becomes a lot clearer for us Secondly, colour contrast matters. So when we're talking about colour contrast, we're talking about the difference between the colour of the background and the foreground. And if we're dealing with text in the foreground, we need to bear in mind the size of that text and also the font

And so bigger text and thicker fonts, we can get away with slightly lower contrast. And this is one tool that I can recommend you check out. But I will list more at the end of the presentation. And so when you're developing and you're choosing a color palette, do have a look at these tools and see how your palette matches up to these guidelines. Okay Cool, we've just fixed 83% of those websites. Alright. Okay, but let's take a step back. So before I said existive technology can remove barriers if we give it what it needs. And some of you are thinking, well, what does it need? Well, semantic HTML can give it what it needs, and many of you will have come across it. But for those of you that haven't, this is what it is.

So semantics is means relating to meaning, and so semantic HTML elements have their meanings built in. Why is this useful? Well, you get some functionality for free. That's less work for you and me. And that's good news It's also good for SEO. So search engines tend to give more importance to keywords when they're written in headings and links rather than just general divs. And we can also improve uh have a better mobile experience. So Mozilla argues that semantic HTML code is often lighter in file size than non-semantic code, and it's easier to make responsive. So what's not to like? Well, there are a lot of them.

There are about a hundred of these elements, and it can be pretty overwhelming, especially if you're not familiar with them. So You should probably have a little look at the Mozilla docs and check them out, familiarise yourself with them because you'll probably find one that does what you want it to do or thereabouts. And example elements include things that you might have come across already, like headers and summaries and buttons, or lesser-known ones, for example, search. In fact, put your hands up if you've heard of search. Okay, so that's maybe like 5% of you guys. But yeah, have a little look in the Mozilla docs and familiarize yourself with it. I want to focus now just briefly on one in particular, which is headings.

So headings are notoriously poorly used. Okay? And there are a few simple rules that can simplify how we write headings. In general, we just want to write them in order. We start with the H1 tag, we go to the H2, we go to the H3. Doesn't matter how big you want the font to be, we can change that elsewhere. We shouldn't skip any levels and we should just use one H1 heading per page. This is also really good for the digestibility of your content. So I'm dyslexic and so it's super helpful for me to see content laid out in a way which is in sections. It will also help people that use assistive technology because they will be able to pass through the different sections more easily.

And so this will help your website in a whole load of ways if we can learn to use these right. Okay, a small break. We're gonna make a button and we're gonna try and bear in mind everything we've learned about semantic HTML. So we think we're off to a good start because we know about the button tag. And then we make this. So this is a really badly designed button and not just because it looks like it's come straight from the 90s. Basically, this button is bad because both sighted users and people that are screen reader users who cannot see the screen won't know what this button is for.

And the reason for that is that there is no button text and there are no labels. So that's all we need to do. We need to add those in. So this means going from This shown above to simply adding this save word between our button tags. And that is it. That's all we need to do. And this is actually the most elegant, simple fix, and it's preferable in this case. Another thing that we can do is add an area label or an area labelled by. And just to flag, if you do add the area labelled by, just make sure that you actually refer to another div And don't just forget about that, or it's going to be kind of floating around and it's not going to know what it's referring to.

This though should be a last resort. The first solution I showed by just adding the save word between those button tags, that really is the preference. ARIA labels and the like can produce several different sort of unwanted side effects, which I'll talk a little bit about in a minute. But as a little heads up, it can be kind of difficult for people that use speech input to select these. um elements. Um and also as Django devs we actually tend to overuse them. So please, I almost took out the ARIA label bit of this presentation because I think we like using them a little too much. So the lesson from this is often simple is better.

Alright, that was nearly a third of all websites that we just fixed again And now on to links. So this is what not to do. This is a visualization of what it might look like. um when links are pulled out of a page by assistive technology. So you've got a web page which has got loads of links on it. It's got a click here, read more, here, here, here it's going to be overwhelming and people are not going to know what these links are for when they're pulled out of the page. So the the lesson is click here really is your enemy. Please don't use it. Use better link. uh label than that. We can label links with area labels

as is shown here. But again, a little word of warning. The ARIA label will be read out by the screen reader, but not the linked text. So in this case we have an ARIA label which is my area label. And then between the A tags we have some link text. A screen reader will not read out some link text. It will just read out my area label. And so we want to be really mindful of that. Another thing to bear in mind is that your ARIA label should really start with the visible link text. And this is because Again, with the speech input users, I've got a couple of scenarios here which will hopefully

illustrate illustrate what I mean. So with the scenario one , a speech input user could simply activate the first button by simply saying click OK If they wanted to do the same with the second button in scenario two, they would have they could not say click OK. Even though the visual text in that tag is the word okay. They would have to say click confirmation selection because of that area label. And so we want to be really mindful of making sure that any area labels we have. start with the visible text as well. So for those users that can see the screen, they will be able to sort of intuitively select what it is they're trying to select.

Okay, we can also use an area described by, and that works in very much the same way as an area labeled by. We just need to remember to include that ID which refers back to our area described by. And this has fixed about 50% of the websites from that initial slide, which is a big win. Okay, so now we're on to labeling. This is a bad example of how you would want to label a form. So it in this in this example it's not clear which input box belongs to which label. And so all we need to do to fix that is include a for

attribute here So I want to just make it really clear. This isn't going to change the positioning of your label relative to your input box. All this is doing is linking the two. And so this is this visualization is more of a metaphor than a uh what's gonna happen on screen. And that's again nearly half of those audits that we've just we can fix with that simple word for And then the last one is the image alternative text. So when you're writing alt text for images, you want a short, snappy, descriptive alternative text. And the important thing which I didn't realize coming to into this was that actually the same image in different context

might need different alt text. Okay, so what do I mean? Imagine that you're writing you you're writing alt text for this image here in the context of DjangoCon. So your alt text might look a little bit like this. The skyline of Edinburgh, our host city for DjangoCon. Alright, same image now. But now we're a photography website. It's a cityscape at dust taken with a wide aperture and a low ISO. Great. It's the same image, but it's in a different context And one last one, you're an Edinburgh tourist information booklet and you're advertising Edinburgh's Millennium Clock Tower at dusk. Okay, so do think about the context of the image. Don't just describe everything in it.

Think about what's relevant to your specific context. And I hear some of you screaming, my image is just decorative. That's okay. You can leave it empty. So imagine you're a blog and they're pointing you towards our top ten books for summer. And just below it sits an image of some books. And they're just general books. Nothing special about these books. We can just leave that alt text empty. And that's totally fine. But this is not the same as not setting alt text. If we don't set the alt text, then a screen reader or other s other assistive technology It's gonna read out whatever the file name for that image is, which is gonna be something like screenshot29052345.

png, and it's gonna be really annoying for users. So Set it, leave it empty, but don't forget about it, okay? And that's it. That's that's nearly 60% of those websites There's just one more that some of you might have remembered from before, and that's that missing document language. And you'll be really happy to know that that's a really short fix as well. You just need to add in the language, and that's it And that error was on nearly 20% of those home pages from before. And now, putting all that together, that's only 6. 1% of websites fixed. Hopefully that was roughly bearable. Um am I running over time? Okay. I'm just gonna s

r really run through very quickly. uh the RIB section. So I was lucky enough in my first few months at Torchbox to work with R<unk>IB which is the Royal National Institute of Blind People And it's a UK charity which offers information and support and advice to almost two million people in the UK living with sight loss. And we rebuilt their website in Wagtail. And for those of you that aren't familiar with Wagtail, Wagtail is an open source Django-based content management system. And you should definitely come and speak to the Torchbox gang over in the hall to find out more about that. And from the beginning of that project,

R<unk>IB came to us with a really clear strategy and knowledge of their users. And it they made it very clear that their users were um uh obviously a top priority and they uh really needed accessibility to be pit placed front and center of anything that we did And so many of their users have various eye conditions. This can result in light sensitivity, reduced depth of field, reduced uh field of vision, blurring, involuntary eye movements, and so when we were designing their website, we really had to bear all of this in mind. And so this user research that we did was really key. We started early on and we split users into two groups for research.

We had low vision users and screen reader users. And we started testing in browser from the very start, sorry, from the very start before the site was even fully styled. We had some people giving feedback on flat designs, but really that focus was on the in-browser testing with the assistive technology. We spent hands-on time with our users. The team could therefore understand the sorts of problems that their users were encountering. From this, we learnt that users have different levels of experience with assistive technology. Not everyone takes the expected route when navigating a website.

um and that people's experiences um and symptoms could change on a daily basis and so This led to us improving our navigation, our site structure, and various sorts of labelling that we were doing on the website. It was also an iterative process and we kept going back from the user research, design and development team back to users. And one thing that emerged from this quite quickly and quite early on was that the option of dark mode was something that users really, really wanted. And so here is a screenshot of the RNIB website as it stands, in light mode, and the same page in dark mode.

And this is super useful for their users with various eye conditions, but including including those which who have light sensitivity. And we're actually still monitoring the use of dark mode on the website today to establish whether it actually might be sensible to set it as the default. Currently the default is light mode, but if enough users want it, then that will become, our dark mode will become the new default. One thing I just want to highlight though is that though this works for the users uh for R and I B, it it's not a one-size-fix -fits-all um thing. Dark mode can actually be more difficult for certain people to see.

So I also have an astigmatism And so actually dark mode is kind of difficult for me to see. And so it's really important that when you're designing websites and you're trying to make things accessible, you really do consider your users, not just somebody else's users. We also made Wagtail more accessible. And Albina is a front-end developer at Torchbox. And she worked on Wagtahill's accessibility checker and working in tandem with feedback from RIB gradually um created this checker. And basically what it does is you go onto the Wagtail admin and it will flag any um any of the common uh accessibility audits that are failing on your page as it stands and so you can correct them as you're going through.

One of the last things I'll mention is that accessibility, though it has been the focus of today's talk, is not the same as usability. Automated testing will only get you as far as compliance. But we're not just wanting a compliant website, we're wanting a beautiful user-friendly website. So we're aiming for some sort of sweet spot. Okay, to illustrate what I mean What is what what comes to mind when I say the words need for speed? Any ideas? Okay. Probably something like this. Okay, but actually what I meant was this need for speed.

Okay, so Imagine instead we're on a fundraising website and you're a screen reader user and your uh technology has just read out Need for Speed So you're imagining some sort of racing car thing. Um and actually it's a baking competition. So when we're giving things names Let's be clear about them. Let's let's say that it's a baking fundraiser, need for speed, and yes, it will be a race, but it's a different kind of race. So make things able to stand on their own And so going forward, what can you do? Well, I'd encourage you all to consider publishing an accessibility statement on your website. Be really receptive to users' feedback.

And the end I've got some resources and some people you should check out. Please do check them out and continue learning. I know it's been a lot, but the the the the rough rule of thumb is that if you're ever in doubt, just do the opposite of this. I don't know how many of you have come across User in Your Face, but basically it's a terrible, terrible user experience which is designed to show people just how bad it can get And so please do go onto their website, have a little play around, try and boom beat my record. This was my first attempt, so that's my caveat Um it really is a horrible five minutes um or so. Um and just do whatever they don't do or whatever they do do but Do it opposite.

Yeah, so thank you so much for listening. Please come and ask me questions at the Torture Box booth. I'd like to thank you, Thibaut all of the RIB team, Helen, Nick and Devon, and all of the Torchbox team and of course all the organizers. And yeah, thank you all for listening.