Accessibility wins for Django projects - Thibaud Colas

I'm

Speaker 1: Thibault, my pronouns are he, him. I'm a developer at Touchbox in UK. We're really happy to be here today. DjangoCon talks in the past have always been one of my go-to sources of Django learning, so it's really humbling to be here on the other side. So thank you for having me. And I also wanted to thank my partner who is looking after our child right now. I couldn't do this without her as well. So thank you, Deborah. Today I'm here to talk about accessibility and specifically accessibility wins for Django projects. So not just generally what accessibility is, but specifically for Django work, what do you have to worry about? And I'm here in particular to tell the story of how we've approached this for Wagtail. Not sure who has heard of Wagtail

Speaker 1: before, but I'm a core developer of the Wagtail CMS, so I'll also talk to you about this. Briefly, the slides are available online should you want to look at them at your own face and the links at the bottom here. Alright, let's get going. So first of all, this this Wagtail story. Wagtail is a CMS. Essentially you use it when the Django admin probably provide doesn't provide you enough to manage a site that is quite content heavy. for example the blog with lots of pages lots of fields on each page and maybe lots of different people wanting to edit those pages concurrently translating those pages and so on. So that's where kind of Wagtail comes in. It's based on Django, but uh the admin is much more geared towards those use cases.

Speaker 1: So of course we would we do want this admin UI to be accessible, uh to be usable by as many people as possible. And we also do want the sites built with Wagtail to be as accessible as possible. So I guess that's kind of What brings me here right now, we we learned along our journey, our Wackel journey, that accessibility matters and that unfortunately you can't just rely on uh best practices and semantic HTML. You also have to learn practically how do people make use of a website with assistive technology, what things you have to watch out for, and so on. So yeah, quite briefly, why do we care about making Wikileaks accessible in particular? It's because we want to provide an experience that's inclusive, that includes as many people as possible, regardless of their skill level background of

Speaker 1: or how they end up using the CMS. And in particular, people who do rely on assistive technology, well, we want them to be able to succeed in in the workplace at their jobs if they have to use Whitetail there. So we don't want someone to be left out just because they happen to use our CMS one way or another. And something else I want to mention early on as well is that these accessibility improvements that we tend to think of just for people who have low vision or who are deaf or Yeah, any any and all of these, they do lead to usability improvements for everyone. This is something called the curb cut effect. I'd highly recommend you have a look at this. And uh yeah, unfortunately there are there are other reasons that are not as positive. Um so currently uh we're working on it, but the admin interface still is quite difficult to use if you're using a screen reader.

Speaker 1: And uh well practically if you're one of our clients at Torchbox and you're choosing a CMS, well this might be problematic for you. It might make quite a bad option uh if you do have people who rely on assistive technology or if you do have um compliance targets that are quite strict. So those compliance targets actually exist all around the world in the US. That's called Section 508 for public sector websites. and ADA for literally all websites, depending on which lawyer you ask. And in the EU we also have similar laws. That are enforced. So yeah, this isn't something that's optional. This isn't something you do just to be nice. You you do have to do this. Oh, and yeah, it's not just white tail, by the way. So um whatever thing you're building, whether it's an internet

Speaker 1: uh some kind of dashboard, a Django admin based websites, uh you do need these to be accessible. And uh you can't just compromise on that just because the audience of the site is smaller. uh you wouldn't compromise on uh a website's security just because it's used by 10 people rather than 100. It still needs to be 12 factor and and so on Yeah, uh I want to also give you a brief uh legislation overview here in the EU. So um public sector websites complying with the directives I mentioned above. That's coming up uh a week from now, whether the site is new or existing for mobile apps, still have about a year to go. And um there was a new law coming coming um that's that got um

Speaker 1: drafted in uh December 2019 that now is going to make this mandatory for e-commerce, banking, and transport services as well not just public sector things. So yeah, this is coming. Um time time to do this. And uh yeah, it's also worth mentioning that Even though all of these things are different laws, they are all based on the same standard called WICAC 2. 1. I won't go that deep into the standards that much today, but I think this is worth knowing that uh the things I discussed today they aren't arbitrary things, subjective things. They are defined by very clear standards that lots of people work on at W3C. And uh yeah, these this is just you look at it online, all the information is there from first party sources

Speaker 1: All right, yes. So I don't I don't want this to be all negative. I think I really want to point out that to me there is a bit of uh a cultural shift in progress and that hopefully a few years from now it will just be like uh having bathrooms that are large enough for wheelchairs. It will just be part of the landscape of how we build things on the web and we won't have to think about it too much. And things like Wagtail will just have this taken care of for you to some extent, things like Django as well. For now, for now though, we'll look at some common issues that you have to be aware of. Yeah, worth pointing out as well that this is live, so I'll make the most of it. And I also have the Slack chat open should you want to make comments along the way.

Speaker 1: I might or might not find the chance to look at them So yes, those common issues, they are very common. And again, I'll try and focus on the ones that are specific to Django and in particular that the ones that Django developers can have a part in fixing. All right, let's dive in. Alt text for images. I feel like this one feels quite basic potentially. Lots of people know what alt text is, how you're meant to provide describe describing text for images on your sites. So uh what the problem might be? Well let's let's look at this bit of UI here. Uh WhiteTail is trusted by people you know, list of logos underneath. I'm going to now use my screen reader superpowers to show you how someone with a screen reader would perceive this UI.

Speaker 1: So I'll switch to what they experience. One, two, three, and ah. Well, that's a bit problematic. All of the all of the content is gone. Wax is by people you know, which is no one. So what the problem is quite simply is that all of these are images and none of them actually have alt text defined. They just have alt equals empty string, which means that well, there is no alternative if you can't see the visuals of the images Which uh yeah is quite bad. So why is that? Essentially this is a this is a models problem, not a template problem When you use an image like this on a page on your site, well, you need a field for the image file and you also need a field for the alt

Speaker 1: text. So in this case The images clearly aren't decorative. They are the whole content that's being displayed in the section. So they do need this one field in the CMS. So that's why, uh or in Django, sorry. So that's why it's important for Django developers to be aware of things like this. These aren't things you can fix just in the templates, although of course you do have to use the fields in the templates as well. So yeah, solution for this is quite straightforward. If an image on your site isn't decorative, there should be an alt text field alongside it. And you should make it possible for users to leave it leave this blank if the image is described otherwise. or have this mandatory if there is nothing else on the page describing the image. Yeah, and again, why does it matter for Django developers to be aware of this?

Speaker 1: So I'm sure you've seen this type of charts uh many times in the past if you've been to conferences. This is a chart showing the cost of fixing or changing code depending on where the change is detected, whether you find a bug close to launch or as part of gathering a requirements for your site. So essentially the closer to requirements, the cheaper. The closer to launch, the more expensive to fix those things Well, the fundamental problem here is that someone like me auditing a site, uh, usually tend to come uh look at the site only towards launch, which is a bad thing in its own right, but it still does work like that most of the times Whereas if you're working on your models in Django, well, this is much closer to the actual design and architecture of the site. So it's worth being aware of things like this as soon as possible.

Speaker 1: So you don't just carry the issue all the way towards launch and then you have migrations to do, you have to figure out where to add the field, how to do that, and you have to ask people working on your site to go and add the content afterwards. It's much easier for all of this to just be something you're aware of up front. And yeah, so this isn't just images, so videos are another example of this. So here we have a blog post that has two video embeds on it. Again, three other superpowers. Oh, nothing is on there. And well that simply is because those two embeds from YouTube, they don't have a title attribute. Again, something that you have to be aware of quite soon in order to have this field there in the CMS if possible, or just make sure your embeds

Speaker 1: integration is aware that it has to pull this data from YouTube. I also want to point out here I use the example of YouTube, but you might also be tempted to say, well, I don't want to rely on a third-party service. I just want my videos to be managed. directly in uh in Django. And um, well, that's all fine, but then you have to be aware that you also have to provide captions for the videos, potentially transcripts as well. And uh I can't count how many times I've seen people go down that route of having videos managed directly on their side. And I have to tell them quite late in their process that they actually need those fields as well. You can imagine how you probably would rather know about this upfront so you could make an informed decision of whether to roll this out yourself or use a third-party dependency for this, like YouTube.

Speaker 1: Um yeah, so again, yeah, the sooner the better. If this is me uh doing an audit and pointing pointing this out after launch, this is going to be uh a very long fix for you to roll all that content, whereas if you're aware of it up front, you can assess at the national level do you have the capacity to produce those transcripts or not? And if so, how? One more What I'd like to point out is um heading levels. So H1, two, three, four, five in HTML. Screen reader users rely on this to follow a logical sequence for them to navigate the page without to having to go through it all top to bottom So briefly, what you need to be aware of is 1H1 per page, don't skip any levels, only use headings for the structure of the page, not just because the designs have larger text here and there.

Speaker 1: It's it's very easy for me to be critical of Wagtail having worked on it so much. For once this is something we do quite well, well, where if you define a rich text field in your models, you can restrict which heading levels are available in that given field which actually reflect restricts the controls that are in the U-text editor in the CMS admin, which means that your CMS users then can only use the heading levels that make sense semantically in this given field So yeah, worth looking out for things like this when you shop for Riflex editor. Yeah, so just to hammer the points home, this is an example of uh this thing gone gone wrong. So this is uh Django project. com website and this is a bookmarklet called h123. So here I have the result of that bookmarklet.

Speaker 1: I can see the document outline on the page. I can see there is one, two, three, four h1s Here it skips an H2 for some reason. Don't know why, but latest news is underneath support Django. So yeah, this is this is not what you want. This is the type of thing that you need to be watching out for One last one for the road. So forms. Yeah, I kept this one short. So Django has convenience as table and as UL methods to render. all of the forms at once as tables or lists. Please avoid them as much as possible. Yeah, tables layout, that's the thing we did like 10 to 20 years ago. It doesn't have anything to do on modern websites anymore.

Speaker 1: And tables are very hard for screen users to navigate. This is somewhat okay, but tables in particular is really problematic. So avoid this and yeah, also worth pointing out that even the vanilla markup from Django without these helpers are really doesn't doesn't give you much. So basic things like showing which of the fields are required, that's not something that Django provides as a default. Like sure the field has a required attribute in HTML. but it doesn't have any visual indication of which is required, which is optional. So be be wary of those defaults like this that only give you uh the uh yeah broken half of uh usable forms All right, lots of negative stuff. But we got it out of the way and now we can look at more positive things that will help you get there.

Speaker 1: So next section is called Developer Wins. I want to point out early, again, I'll focus on things that are specific to Django as much as possible. I wrote a blog post recently about audits generally, not just for Django. from the perspective of developers in particular. So do check it out if you want to learn more about what I'm describing here. So developer wins, again, we want to focus on things that help developers making more accessible Django projects. And again, the idea is to not just have things that you run towards launch here. The idea is to shift, to shift left, as they say, towards the requirements and coding. stage. So if you if you compare this to uh security or performance, you wouldn't only start to worry about your site's security or performance after launch.

Speaker 1: You'd presumably worry about having a sound foundation, whether that's a framework or something else. um having best practices like trial factor again and then having um potentially static analysis of your code to check for those concerns. Potentially runtime analysis or monitoring as well and tests. So again, like spreading the uh how concerned am I about those things throughout the whole project, not just there. Accessibility is the exact same. So yeah, first thing first that I won't cover, but I wanted to give you a few links on the training. Obviously the best way for people to be aware of those things as early as possible. is for them to know about the issues and the only way for that to happen is education, learning resources, and so on.

Speaker 1: Those two links, if you have the time, do check them out. Otherwise I'll move on to again Django specific things. But before I get there, I wanted to show you my three favorite tools. Axe. It's a free and open source accessibility testing engine, has all the rules you could wish for for WICAG and detection 508 compliance. Accessibility Insights is a browser extension that bundles Axe and much more. And Pali essentially is Axe on the command line. Try these out, they will help you tremendously. And yeah, I also wanted to mention static analysis. So people might not be aware of this unless they spend lots of time in the client-side front-end framework landscape. But these days, things like React and Vue, they have quite well-established ESLint

Speaker 1: uh linting plugins specific to accessibility issues. So yeah, worth being aware of these. So now back onto things that are Django specific. There is a package called Django HTML validator. I'm not too sure how people feel about HTML validation these days But it definitely covers quite a lot of basic things, about 15% of issues according to numbers I could find. So this one package uses the official uh VNU validator and essentially bundles that in Django so that HTML validation happens whenever you render uh pages. So either because you're loading the page in your browser or as part of your unit tests. And yeah, you'd be surprised how many HTML validation issues you can find on

Speaker 1: a major website built with a major CMS on top of a major framework. in 2020. So uh yeah, these actually cause real issues for people who rely on the semantics of the page. And um yeah, just worth knowing about. And yeah, something else I'm quite excited about is this uh linter I've been building over coronavirus. So this is curly lint. It's an experimental linter for Django templates and Jincha templates. The idea being again to bring this type of static analysis that gives you feedback as much as as soon as possible uh to bring that to the Django world. So curly int is again very experimental, but still available as a as a PyPI package.

Speaker 1: It's a command line tool, you can install it, run it on your templates, and it finds issues. It has rules that are quite basic but still useful nonetheless, like checking that your page is to have a lengt attribute so that the screen reader would actually read the page in the correct language. Yeah, other basic rules that like avoiding autofocus on form fields. Other basic rules like avoiding Django's as table and as UL. It's essentially as good as it gets to have me on your team without paying me. I can just complain via curly lint. Please don't do this. And um yeah, I'm not sure how you perceive this from your side, but from my side I wanted to point out that you actually do find issues with this. So yesterday, just for fun, I tried to run it on my personal websites.

Speaker 1: And well, I found I was missing a language attribute on one of my templates. And I found that uh one of my very old talks didn't have any alt text on the images. Um so yes, the issues are real. Um and I also ran it on the Django codebase and found an issue with Django as well. So Um yeah, there is a template in Django that also doesn't have the length attributes on the HTML template, which means that the page will be read out with the wrong language. Yeah, and I also found a parser bug with color lint because yes, it's uh try it out but don't necessarily rely it's rely on it in production. Um Yeah, so that was static analysis, which I think is uh amazing.

Speaker 1: You should try and have as much of it as possible regardless of what you're looking at in your project QA-wise. Now I want to show something that's on the opposite side of the spectrum. So this project called Django Pattern Library that is from Touchbox, my employer. This is what we use to manage UI component libraries for Django projects. So the basic idea is to have a way to work and test your UI components. in isolation from where they are used in your project. And the reason this is relevant here is that, well, this is kind of unit tests for UI stuff. So the whole idea is that well you have this this data then uh in in uh in this function library and you can try all of the variations of your components based on what data requirements they have.

Speaker 1: And of course you can run accessibility tests quite easily on those components, regardless of where they happen to be displayed in your site. So yeah, if you are interested in partner libraries, definitely recommend checking it out. But yeah, this is quite a fundamental change of approach. One other thing I want to mention is to learn how to use a screen reader. So I'll give you a quick demo of that. I will switch over to Safari and open voiceover on there.

Speaker 2: VoiceOver on Safari.

Speaker 1: There are only three keyboard shortcuts you need to make use of a screen reader like VoiceOver and most other screen readers. The first one is how to open it. That's command f5 on a map, on a Mac. The second one is

Speaker 2: voiceover.

Speaker 1: How to close it. That's also command F5. And then voiceover has this thing called the rotor, which I'll open with Ctrl-Alt

Speaker 2: U.

Speaker 1: That allows you to navigate through your pages.

Speaker 2: Heading level one Django administration.

Speaker 1: So here I can see all the headings on the page. I can use the error. I can look at all the tables on the page. Not quite sure why they are tables here, but

Speaker 2: links menu.

Speaker 1: I can look at all the links on the page and right away spot issues just based on this and this is exactly how people who use screen readers uh use them so this is worth knowing about just because in the end of the day that's how they actually experience your sites Yeah, I'll leave it there, but yeah, this is really

Speaker 2: voiceover off.

Speaker 1: And again, I just showed voiceover because it was fast for me on the Mac, but there are other options. I can also show you voiceover on iOS if you can look at my camera for a moment. I'll also have it next to the microphone. I just need to triple tap the home button

Speaker 2: Voice over

Speaker 1: to start it.

Speaker 2: Safari, address, lemon, reload.

Speaker 1: And then to navigate, it's just swipe right. Navig le

Speaker 3: monde.

Speaker 2: HDFAIL before.

Speaker 1: All right. We'll leave it there. And yeah, it's it's that simple to get this uh going and use them for testing. So worth knowing about. I want to end on community wins and again call for that cultural shift I mentioned earlier on. To me, Django, it's quite clearly Django developers have a role to play in this because again this matters for all projects and the standards are well defined and there are lots of tools you can use for those types of checks. So yeah, do take some more some time to be aware of those standards. Even though you might only spend most of your time in the back end, you do need to be aware of those constraints on images, heading levels, and so on when you when you model your websites. And the tools that you can use to actually run tests before someone like me steps in and does an audit,

Speaker 1: these are already available. There's lots of free and open source options as well. And I think that Django as a framework as well has a clear role to play in this. There is this study by Web IM called the Web IM Million, which tracks how accessible the web's one million most popular websites are. And uh the numbers are horrendous, honestly. There's no other way to put it. Um so yeah, I I feel like frameworks like Django have to step in and provide better defaults whether that's the actual framework or whether that's just documentation of how to implement those things. And yeah, this is actually happening for Django. So quite recently, Tom Carrick So I had a discussion on the Django developers mailing list and out of the discussion came this process

Speaker 1: depth from Django, for Django, sorry, to have a dedicated accessibility team. I really think this is worth considering and worth your time and feedback. So things that could this could involve, well, obviously making the Django admin WCAG compliant. making the Django docs and websites retag compliant, having Django features that you use to build your sites be compliant by default as well. better documentation and and so on. There really is uh lots of room for improvements if I'm honest. So yeah, worth being involved in those conversations. and yeah, providing your feedback on these. And again, um coming back to my Wagtail story, well I guess this is where we were at with Wagtail about a year ago. We initially we

Speaker 1: discussions about RCMS, the admin, the websites, the docs. And the conclusion of this of this discussion, while we're still very much in progress on actually fixing the issues, But at least it feels like as a community, we do have quite clear consciousness that those things matter and we want them addressed as much as possible as soon as possible. So yeah, that's where I'll I'll leave you. Um and thank you. Uh I hope this was good and there'll be time for questions, hopefully Yeah, there I forgot there was a recording for this as well. Alright, recording is on. Um yeah Please fire away all the questions you want in the chat or uh

Speaker 1: on vocal if you prefer or on Slack. I'll be around for quite a bit more time after this as well. First question was uh where you can find the depth that I just mentioned. So I'll probably try and share my screen and show it to you at the same time as um Answer the question. This is essentially on a repository that Django has just for depths. Alright, you should see my screen now. So Django slash depths. And it's number 69. This is where they have all of the in-progress ones. And this is still just a pull request for now. So I think the feedback process is as simple as reviewing a pull request, essentially.

Speaker 3: Okay, thank you.

Speaker 1: Sweet Does anyone have questions?

Speaker 4: I know your talk focused on screen readers, but is there any other kinds of accessibility that we should be aware of? Oh

Speaker 1: boy. Yes. Oh that that's a very tough one because there are so many things I could mention, but I guess I I'll try and uh keep it brief while other people think of other questions. So I'll quickly share my screen again and show you a few things just as a kind of demoing what those things might be that you have to consider. I'll show you the extension I talked about during the presentation. So this has automated checks that essentially cover uh any and all types of issues. If I run this on the Django website, all of the ones that are there are uh most of them actually at least are related to contrast issues. So this idea that um The text needs to be readable enough regardless of how good the vision of people are.

Speaker 1: So it's not just whether you're completely blind and using a screen or not, but just how good your vision is. And of course, as you grow older Well, your vision declines quite a lot. So this is pretty much for everyone who wears glasses uh to just happen to be older than the average. Um Yeah, another example that I like to mention is um keyboard accessibility. So again, uh if you're using a screen reader, you likely use it with a keyboard, but even if you're not using one Well, you might be navigating the web with a keyboard and you might expect that to work. So this extension also has a check for you to see the order in which your page is navigable with a keyboard The idea being that, well, this should make sense and you should be able to follow along the page and interact with all of the parts of the page with the keyboard alone.

Speaker 1: So that's a common example as well. And I guess the last practical one I would mention is that if you're using a website on a small screen Well, there are lots of other concerns here. So for example, on the on the small UI, you might be tempted to make uh very small buttons. You don't want that to happen because if someone has to use your UI with a big thumb, they want to be able to press any and all buttons without accidentally doing something else. So yeah, just kind of uh uh the practicality of uh working on small screens, having the right input input targets, sizes. Um yeah, I think that's that's uh that's a good few ones, but uh it doesn't stop there. The list is quite long. Uh if you want to learn more about this, there is a thing called the do's

Speaker 1: and don'ts posters But have been made by on the GDS in the UK. Can I find them? So these do's and don'ts posters, they kind of cover all of the things you have to worry about. So again, screen readers, just one of them. I might share this link after the after the questions.

Speaker 4: Thank you. That's wonderful information.

Speaker 1: Yeah, my pleasure. Gaitano, you ask, what's the name of the tool I'm using right now to see the links? That would likely be uh accessibility insights which is the browser extension I was showing in my in my talk. So this is Well I'll be honest, there are many extensions like this out there. Why I like this one in particular is that uh it contains all of the different tests you could wish for in a single package. So both the automated ones with Axe, but also the kind of semi-automated ones. And even more interestingly, it also has fully manual tests, like I go through the page, the whole page myself as a tester and I take notes of what I've gone through done gone through. So yeah, it does pretty much everything and

Speaker 1: more. I hope my talk made some sense. I would be keen to hear what people think of curly lint as well in particular because I've been working on this for a while and Yeah, not quite sure what to make of it. But yeah, any questions fire away.

Speaker 3: You said about the the pictures that you can't see the alt text at the start I didn't understand why you ha can't uh see the alter because at least as far as I can tell, most of the times you use the template to do this, you know, not uh just uh takes the the picture from the from the model.

Speaker 1: Um So I think I understand what you're saying and essentially that only applies if someone took the time to Um well it has to be defined in the models, but it also has to be entered in the admin, you know, like if there's the field, someone needs to uh fill that field. And that's why those types of fields when the images aren't just decorative, they do need to be mandatory and someone needs to be there uh adding the alt text. Does that make sense?

Speaker 3: How are you supposed to uh show the image if you it because as far as I remember I you don't it's not a Django templating system that builds the the HTML tag for image. Or am I wrong here?

Speaker 1: Uh so you would you no you would use the Django templating system to create I guess you would you would use HTML to create the image tag and in Django templates you just uh map the images SRC and Alt attributes to the correct field. But you'd need to be aware that the ALT one needs to be there as well and not just SRC, if that makes sense?

Speaker 3: Ah, okay. I understand. You mean that uh you will need to put something in the alt because Uh uh in uh other uh situations it would be something uh generic, at least if not an empty s you know if not empty strings.

Speaker 1: Yeah, so if you if you don't put if you don't put anything in the alt, um if if you still have the alt equals attribute in your template Then screen readers won't read the image at all. They'll just pretend that nothing is there. But if you don't have the attributes at all, then it will actually read the URL to the image file, which As you can imagine is quite bad. Um so the alt attributes always need to be there in the templates Then the question that you have to answer in the CMS in the CMS sorry in the in your models is whether the alt attributes need to be defined or whether it's okay for it to not be there So essentially it might be better if I showed you an example actually.

Speaker 1: How can I show you an example? Screen share. Application window. All right, should be back on my screen share. So this is uh this is a website we've built with Wagtail, but again that applies regardless of which flavor or Django you use. So these images right there that I was showing in my talk, well, this is the whole content of this section So here the images clearly aren't just decorative. Uh you do want to know what each of these are. So if you can't see the images well for in this case here you want this to say Google, NASA, MIT, Mozilla, and so on. You just wanna have the uh textual equivalence to all those logos. Um whereas if I go further down the page, so for example, here I have this list of websites built with Wagtail.

Speaker 1: So the images are are still interesting, I assume, but if you didn't have the images on there you if you couldn't see them you could still see the text underneath it would still say which uh website this is so in this case the images are mostly decorative There isn't that much value in you describing uh what exactly the Icemanic Opera website looks like. All you care about as a as a user trying to go through this page. is the fact that those websites are built with Wagtail. You don't really care what they look like precisely. If that makes sense.

Speaker 3: Yeah.

Speaker 1: Um I'll have a quick look on Slack, see whether there are any questions there. I was trying to commit to reading Slack as I went through, but of course this was That I thought. Um uh

Speaker 5: Thibault, I I've got a question. Oh

Speaker 1: yeah.

Speaker 5: Uh Kun here from the Netherlands.

Speaker 1: Yes.

Speaker 5: Hi. Uh can you elaborate a bit on uh accessibility tools in test? Like do you use curly lint in a test suite or what what how do you integrate Accessibility checks in tests.

Speaker 1: Get a couple of links up before I can answer this, just so it's a bit more visual. All right, and the link I need in particular is somewhere on there. So there is a great uh well very interesting audit again from the GDS in the UK. Uh they went through How many accessibility issues each of the common accessibility checking tools find? And um when you see a number like this, 40% of issues were found. I'm not sure what what you would say, but personally I feel like that's quite low. Like I would I would expect a tool that you have to pay for to find as many things as possible

Speaker 1: So what what this means is that no matter which combination of tools you are going to use, I should still be someone who manually audits the websites. whether that's as part of code review per feature or whether whether that's towards launch, you can do it however you want to some extent, but there needs to be some manual auditing. But of course manual auditing takes a lot of time. It's the same as doing penetration testing for security. You can't do this just all the time So that's why you need to have automated tools to help you with the testing, with the QA. And well, the problem with those tools is that even though they found quite a big chunk of issues Generally, you can only run those tools on the rendered page. Like literally once the site is built and you see it in the browser, that's where you can run the tools that find the most things.

Speaker 1: But ideally you wouldn't want to have to wait that long, like have to wait for the page to be displayed in a browser for you to run those tests If you did this in CI, well you need to have a continuous integration capability that displays your whole site in CI, which can be quite problematic. So that's why it's important to approach this in some kind of layered way where you have different checks that happen. from you typing the code to the site being live, that hopefully means that uh when the site goes live you can focus on only the things you could find this way. Um so I guess that that's what my my blog post uh that I mentioned is about to some extent. Um essentially you you want to spend

Speaker 1: um all of your time with the tools of find the things as close as possible to the actual code. So that's where curly lint is useful. Curly lint works. on the Django templates, not just HTML, which means that you can run it as part of actually typing your code. Whereas things like Axe or the HTML validation Well these don't support Django templates, you only can run them as part of uh your unit test potentially or integration tests. So yeah, what I would suggest practically these days is you could try using CodedInt as part of a pre-commit hook, for example, and then you could use Django HTML validator as part of your unit test. And then in in CI where you have more time for the test to run, you could use something fancier like Pally

Speaker 1: that uh includes Axe and a headless browser. That was a that was a very long answer, so I hope it kind of makes sense.

Speaker 5: Yeah, it does. Thank you.

Speaker 1: I think we probably run out of time for questions, but we'll probably someone probably let us know. But if anyone has any other questions, again I'll be around on Slack. Yeah, any any passing questions All right. I'll be around. See you all the time.