Django’s accessibility track record

Speaker 1: Yes, so I'm Thibaut. Pronouns are he, him. I'm on Django's accessibility team and I'm a co-contributor for the Wagtail project. Just want to thank my my employer, Toshbox, for allowing me to be here, for supporting me. I want to thank my Wagtail colleagues for supporting this work over the years. And I want to thank my partner and my mother-in-law for allowing me to be here by looking after the kids while I'm with all of you. It wouldn't happen without them, that's for sure. The slides for the presentation are online, whitel. org slash dc2023. Yes, thank you. Highly recommend you look at the slides on your own devices as we go through this if you want to.

Speaker 1: And uh yeah, the slides the slides are online. Make use of them. I'd also love to take questions towards the end. Quick word from our sponsor, Torchbox by Employer. We're hiring, we work with lots of cool people. If you're looking for a job, give us a shot. And and Wactail, yeah, I guess I want to say like we we have a booth, we have stickers, we have a newsletter, it's an open source project like any other. Uh we just, you know, try our best to make it compelling. So Any feedback, very welcome. And yeah, we have stickers, right? And so yeah, why why I'm here? I'm here because accessibility is a really cool thing to work in in my opinion. And there really is lots more we could do in the Django universe. And I'd really like to see more people essentially take part in this.

Speaker 1: So this talk today is more of a I'd say a governance thing of what are the accessibility things we could do better in the Django space rather than uh here are specific issues that we can find on projects together. If that makes sense. And why I'm here, plainly speaking, it's also thanks to Musharaf. Musharraf uh reported an issue on a Wag Teleshoot tracker five years ago now Where he said, hey, I want to use Wagtail, quite like the docs, quite like the project. Oh, by the way, I'm blind and I discovered that my experience working with Wagtail would be rather unpleasant the way he puts it. And it was a wake-up

Speaker 1: call for me definitely that the software we build, the way we build it, affects people in their day-to-day job. And um yeah, I guess just when we get that kind of message from a specific person, to me it is eye-opening that we need to be better at this. So thank you, Musharaf, as well, most definitely. And um yeah, why I'm here, another reason is this big number, which I love to talk about. 96. 3 %. Some of you might be able to guess what it might be from my previous presentations. 96. 3 %, that's the amount of the top 1 million home pages in the world that have basic accessibility issues. actually is quite a quite a sad number despite it being such a big figure.

Speaker 1: And I guess in s in some ways like I have I have a really hard time grasping a number like this, making sense of why so many of our sites have those basic issues. And I guess nonetheless we have to try and find ways to yeah, not not that not that have to try and find ways to resolve those issues, which is why we're here essentially So to me it's a bit of a a North Star. I think Don used the term yesterday as well. It's this kind of very long-term goal you look towards of how can we make more sites accessible in our industry overall, not necessarily just Django. And um yeah, that number is is definitely going down over the years. Just like

Speaker 1: Can barely tell. It's not because of the projectors. It's just yeah. Um at at the current current pace, uh it would take about uh a hundred years. for us to reach half of the sites out there having no issues. So, you know, we just room for improvement. Yeah. So the good news the good news is in the Django world we're at ninety-five percent of the sites having issues, not ninety-six point three. Yay! It's not the exact same dataset. That's from a sample of 25,000 Django sites, not one million, and the source is me. So, you know, take it however you want. But yeah, I guess from those figures, we can

Speaker 1: we can I took it to hearts to dive as deep as I could from the big number to the small number to the actual issues, if that makes sense So yes, numbers. Developers love numbers. We all do, I believe. We're looking at a report from a tool called Lighthouse. Lighthouse, I'm sure some of you might have heard of it in the field of performance, perhaps as far as SEO for Google websites. Lighthouse has accessibility checks. That's one of the figures that it does by default. And we're looking here at a report on the Django admin that gives us a lovely 88. Not quite sure whether 88 is good or not, but I guess we can work with those figures that assess a specific page of a specific site we might work on and see what there is to be done. So we'll we'll

Speaker 1: go from there. We can actually do that with Lighthouse. not just for a single page, but for all of the websites out there in the world. That's something that the HTTP Archive project does every month of every year. And they do this also by categorizing which technologies the sites are built with. So here we have a lovely chart that is really hard to make sense of. It's the Median scores on accessibility of the sites built with those technologies. So at a very high level we can see that it's kind of quite bunched up. Okay, that kind of makes sense in some ways. But technique definitely there are technologies that are consistently higher up on this chart than other ones, or rather

Speaker 1: sites built with those technologies. So yeah, uh let's let's zoom in a bit and uh look at the more precise details, the end of the line, so to speak. in uh 2033 here and now. At the very top of the list here we have we have Squarespace, an online site builder, proprietary, then we have the WordPress CMS right below, so still scoring quite great. And we have Wagtail and Rails that score 83. Finally this all line, that's the average websites are there, all technologies included at 82. And then below this average websites, we have Django and Django CMS. So that does mean there's quite a clear call for us to improve this.

Speaker 1: And I guess at least do as good as average. Um we do better as far as how many sites have no issues at all, but in terms of average lighthouse scores at least there is room for us to do even better I want to say by the way, all of those uh charts and uh bits of data sets, I have added a link at the bottom of the slides if you want to follow up on the numbers and um the queries I use to extract this data So yeah, just to hammer the point home here, comparing uh frameworks specifically, Django websites, uh the median score is 80. The uh all websites, all technologies, median is 82, and then there are a few tools like remix that score much higher than that. So It might not necessarily mean that

Speaker 1: there is not necessarily a causation here, but there's definitely some amount of correlation between technology and accessibility. A quick uh warning though about those figures, they're only based on automated checks, which only find depending on who you ask. either 57 % of issues or 40-20% of issues. So even those figures that aren't partially good, they only tell a partial story of how accessible the web actually is, which is important to be aware of. So yeah, let's let's dive even deeper. Another chart that's quite hard to read, but the main point I want to make here is that The data is there for us to make sense of and see which improvements we can make to Django and Django

Speaker 1: websites. So here we're looking at specific checks within Lighthouse. uh checks done by the AXE accessibility testing engine that my colleague Scott mentioned in his earlier talk. AX gives us very precise indications of what is there to improve on the sites. And Those bars here, they represent how many Django websites out there have those issues. So turns out one of the most common issues on Django projects is color contrast. Which uh you might think at first glance, oh, like that doesn't have that much to do with Django, right? But at the same time, I suppose it's uh definitely a choice on the part of Django for it not to have too many concerns about the front end And I suppose nonetheless something where if it is an issue on with

Speaker 1: our websites, we do have to see how we can acknowledge it and perhaps do better. And yeah, there's plenty more down the line that are much closer to how Django works under the hood. I really like charts. Surprise, surprise. I made one that specifically compares which checks does Django do better at than the average site and which checks it does worse at. The main thing I want you to get here, the the worst ones are on red at the top, but better ones are on green, is that there clearly is a pattern between the technology and the results of those checks which means there is an obvious call for us to improve on those specific uh

Speaker 1: specific results. And uh yeah, just to hammer this point home, I also pulled the charts from other projects I've assessed I work on Wagtail, the CMS, so I have pulled the chart together for Wagtail and same story. There's clearly things that we do better at as a as a project and things where really like I don't know what's up with area required parents, but there is room for improvement on that one specifically. And um yeah, Drupal, same story with Drupal. Drupal websites, site implementers have opinions about how the web is built, we see the results of those opinions on in what works and what doesn't My favorite tilbeat on here is my my colleague Scott Berlier mentioned how much heading order matters on the page.

Speaker 1: That is something where Wagtail scores terribly And Drupal scores excadently. So definitely room for us to learn from other projects there. And yeah, just one last time I can also compare sites that my employer builds compared to the average on the web. And there's clearly some insights there that there's this one specific thing we could do better at. So, yeah, technology has an impact, not just the specifics of the implementation, but the overall architecture, the way you build the project, the way you define what a project is, the process is important. The QA obviously is essential and yeah it all matters and there is room for us to think about all those things in my opinion as a Django community, not just the

Speaker 1: back-end code, so to speak. Yeah, let's dive even deeper with a demo. And we are gonna look at accessibility issues on Django websites together. Which is gonna hurt a bit, but it's for the better. We all have a lot to learn from this, I'm sure I guess just for saying like I have quite a bit of time. So just for saying like I'm not like trying to call out any one person, like definitely the sentiment is here. Those issues, once we found them, they're really simple to address. So it's mainly a matter of finding them together and being aware of those issues. So we don't make them in the future. And so we address them in a site that already exists.

Speaker 1: And yeah, again, like Django Project. com, you might have seen the talk from Paolo earlier this week who mentioned that they're working on a rebuild of the site and they definitely are taking the things that I'm gonna point out today into account. While we look at this page, can I ask from the room, like can you spot any issues perhaps? Any any takers? Yeah, over there Oh thank you, Ney. It's one of my favorite things to do is not like how many issues, but rather how quickly when you arrive on the page, can you spot one? Can you spot five? Can you spot ten? It's the best indication of how good the site is.

Speaker 2: Yes? Oh, you can hear me excellent. Okay, so first guess, uh bottom row, please take a few minutes to complete the It is white on green, but I'm having a hard time reading it from here without squinting a little bit. So I would say those letters are too narrow.

Speaker 1: Yeah, yeah, definitely. Thank you. That's excellent. Um so yeah, the readability of the text is a problem because of I suppose how thick or thin the font is as well as the color. This is called a color contrast issue. That's the most common way you put it. And there's plenty of them, it turns out. And yeah, we we mentioned this specific block at the very bottom, but this page is so to speak covered with those issues. I'll switch back to my full browser window and we can use our lovely little extensions that allows us to run many checks on the page. It's gonna point out specific elements in red. That's the ones where it found issues. This extension is called Accessibility Insights. I cannot recommend it enough

Speaker 1: because it contains both automated checks that are the best in industry in my opinion from Axe as well as manual checks. So Though this thing about color contrast you can find automatically, you could also decide to say turn off the color on the page and find issues that way. It might make it much more obvious which things aren't readable enough if you turn off the colors. Um I'll scroll down a bit more and can anyone else find another issue perhaps? Yeah.

Speaker 3: Link formatting, it needs an underline under the

Speaker 1: not sure who here has checked their GitHub today. You might have had a notification that underlines have been turned on by default. This is amazing. Links do need underlines so you can tell where the links are. Not sure if you can like realize on here where the links are exactly. It is really hard to tell if you're on a poor monitor or just if you have low vision, like as I do. And um yeah, just adding an underline, that's all there is to be done here. Really simple. And um yeah, just makes sense. Uh we'll try and spot another issue perhaps. Can you tell me or zoom out a bit. Can you tell me on this page, which of those elements is the main heading, the heading level one of this page

Speaker 1: Any guesses. Well let's see what let's see what our our checker thinks, right? Because we do have checks for that. It might just be a manual check, but maybe it can like point out to us which which element is which heading All right. All right. All right. So yeah, um I mean why not, I suppose? Yeah, so I guess I don't even know how to say it to be honest. Yeah. Unless you're really clever about it, it probably should only be one, not not three. And I suppose like the the earlier on in the page, the better.

Speaker 1: I think if I had guessed, I would have probably guessed this main element here at the top would be the heading level one. Definitely not that to the side. Definitely not like way further down like this. Anyway, just you know, once you know about those issues and the tools to find them, they're really easy to spot. Yeah, um again like this is completely free and you have the automated checks and the manual ones. We look for one more issue about keyboard support. I'll go straight towards demonstrating this issue because it's really visual and I really like it. We'll turn on my extensions tab stops feature Which allows us to visualize how someone tabbing through the page with a keyboard would go through the elements one by one. So

Speaker 1: generally you want top to bottom and left to right in English So far so good. Makes quite a bit of sense. And it counts for us how many tab stops it takes to reach a particular item. Obviously if the item is important on the page, the sooner the better. And what I realized with this is that if I want to reach something that's visually quite far up, like the download button, it's kind of the monodomic call to actions of this page, isn't it? Takes 25 tap stops to get there. So yeah, I guess definitely if this is one of the main call to actions, it probably does make sense for it to be reachable sooner. And again, like nothing specific to Django here, but being aware of those issues as a community will help us

Speaker 1: make more accessible websites. Yeah, so Django Project. com, many issues, lots of room for improvements, but we are working on it and getting there. We can look at Django's forms template. Django loves to tell, or at least Django people love to tell me as a front-end developer that Django doesn't have opinions about HTML and front-end and so on. But for forms, I suppose it does. And yeah, uh not necessarily the best it could be. Um so Django 's forms rendering until quite a few versions ago. The default one was to render forms as a table. Tables should be used for tabular

Speaker 1: data, not for forms layouts I guess you know it does look visually slightly easier to scan than if it wasn't a table, but it creates lots of issues for screen reader users that will have to navigate this. Rather simple sequence of fields as if it was tabular data. The screen readers do optimize the navigation experience depending on what the content is and navigation for forms probably shouldn't be mixed up with navigation for tabular data But I guess the good news on this one specifically is that the issues we can look at together have all been addressed already on the Django project. So I mentioned earlier that I'm part of the accessibility team. One of the first things we focused on as a team was improving the accessibility of Django's public HTML outputs rather than things like the Django admin, which we will get to.

Speaker 1: Don't you worry. So yeah, specifically here we're looking at a radio choice field with radio balance. And the issue earlier on was that we can see here as well. was that um when you have a group of related radios like this they need to be in a field set so we can understand that they're grouped together which is missing here and they also are missing a label which in the case of a field set group will be a legend element And talking about legends, the person who fixed this, David Smith, is my personal Django hero. He's pretty much fixed all of the most gnarly bugs I could throw at him on pharmaceubility in Django. So yeah, thank you, David. Um yeah, there are other issues on here that we've worked on, but I think I might just

Speaker 1: Let's move over to um Django's admin. We need to talk about the Django admin. Like I I have a really hard time grasping how, if I look at Django's survey results, it's one of developers' favorite features in the framework. But it it looks like something that's from ten years ago and maybe there's like a visual like choice there, but for accessibility as well unfortunately it is just not working very well. So I guess we'll look move over to a specific demo page and perhaps we can figure out how long it takes us to find one issue

Speaker 1: or maybe ten issues. Oh oh my gosh I don't know where to start. There's just yeah, there's just too many of them at some point. She's just like, okay, well. So we take it gradually. We definitely made quite a few improvements. This is Django 5. 0, by the way, the latest and greatest, not even released yet. Made plenty of improvements, but there's lots of room, I suppose, to to lots of uh space for further further work to be done. Some of these are really simple to fix. I'd say like perhaps what's more interesting to discuss rather than the fixes is the fact that there might be a bit of a lack of ownership in the Django space on who works on the admin. who has the skills, perhaps making Django more compelling as a contribution

Speaker 1: project for UI, UX, front-end development people might might help fix this. But yeah, at the moment I guess there's just lots of um lots of things that are wrong with this. Um I think I think one way to put it would be that um if you gave this to a colleague and they just politely say nothing, that'll probably be the best you could expect. But you could also give this to a colleague and receive a lawsuit in return. Because It does prevent their job people from doing their job if they can't access the admin tools for your website. So yeah, just something worth you know pondering about a bit. Uh thankfully the Django product isn't liable for quality of the Django admin. Alright, I'll try and be you know a bit more cheerful.

Speaker 1: Let's go back to the slides because this can you know get we get to you after a while. Yeah we found lots of issues. Definitely found them pretty fast but it's alright. We're working on them. And we'll talk about that next Yeah, tap stops, tap stops are great, just a great way to yeah, Musharraf. I guess this is what it comes down to for me. Like, you know, I want to make it work for those people who need it first and foremost. Alright, back to the slides. What to do and where to go from there. Yeah, here are all the things we could do and I really like this slide in particular because this is uh

Speaker 1: like for like copy of the one I posted at DjangoCon Europe 2020, three years ago. And one of the reasons I was very keen to be here is to report back on the progress we've made since then. The Accessibility team was formed right around the time that I put this slide together. And now we actually have quite a bit of progress in all of those areas. Again, like we have about 10 years of accessibility technical debts. to catch up on. So though progress has been made, there is room for even more. I'm gonna go through this list just as I switch over to the next years, what my hopes are Next year I'm hoping that we have made even more progress on making the Django admin compliant with XPT standards as well as Django Project.

Speaker 1: com. Django Project. com in some ways is a really simple sites in some other ways I guess does need all of us to agree on what the site is and how it works. But one thing we definitely agreed on is the fact that it does need to be accessible, which is which is perfect for me. Yeah, Django features accessible by default. We're honestly almost there. There are only a few things here and there I could report on, but overall we've made a lot of progress on this specifically, which to me feels like the right area to have focused on. Docs about accessibility as well. I'm hoping we'll get there really soon. We have pull requests open to have docs for contributors as well as to upgrade documentation for site implementers using Django. And yeah, reviews of packages, I really feel like there's a place for this

Speaker 1: in the XPD team, like providing guidelines or doing the reviews ourselves A specific bit of um accessibility know-how I want to leave you with as well is this uh shift-left methodology. So it's this idea that rather than doing a big accessibility audit towards the point where your project is shipped, you do this iteratively over time. That's really what I think the Django community should strive towards of is when you decide how to build things, you take the activities into account at the beginning in the design phase. And yeah, so for Django, what this could look like, shift left is clearer standards for people who contribute to the project. creating new features with accessibility in mind.

Speaker 1: Automated QA, we work on that quite a bit. Manual QA, having just clear guidelines on how you're meant to test your UI changes. And again, the audits still present but only as the last result. There's also a very relevant standard that I want you to be aware of called ATAG 2. 0. Again, my colleague Scott earlier talked about Wactail websites and the fact that there were two aspects to Wactel accessibility. The admin and the sites you do with it. It's the same with Django. We have to worry about how accessible the admin is and how it allows us to produce accessible websites. Which is what this standard is about. And yeah, ultimately people like Musharraf, having them involved in this equation and having them being the driving forces between our behind our initiatives, to me is what matters.

Speaker 1: And I was really reaction to my last talk on the topic. And uh yeah, I think it's very important to give those people the space to give us direct feedback. Thank you all. You're lovely. Uh as an example of this, one of the most recent things I've worked on in Django is um switching the date picker to be more accessible and we've been able to find someone in our community who uses uh voice control software it's really hard to find those people there aren't many of them so just having access to those people and then having the goodwill to work with us is really invaluable So yeah, just

Speaker 1: finishing, there'll be plenty of time for questions. I don't want you to use it. Finishing on what we're already up to, DjangoCon again, just you know, we have to value those things, accessibility of the physical space. The fact that there's multiple events around the world makes it much easier for people to attend, obviously. Guidelines for speakers, captioners, we couldn't have captioners. without real humans to be completely honest it's just not the same so we have to appreciate this. Django project. com actually testing I've done quite a bit of that and it's definitely taken into account in the upcoming project Thank you, thank you, Paulo. And um the Django docs, plenty happening there as well, which are all things you could be involved with, either as an event organizer, as a Django Project. com contributor, or as a Django

Speaker 1: contributor. And yeah, I wanted to end with all the things I could see happening in our space to make I suppose to make improvements big and small. So uh on Dawn earlier this week and Rachel mentioned juggle Django. space. And it feels to me like the perfect program for us to take on bigger challenges like accessibility and make uh much larger improvements, concerted improvements. And Django takes parts in a summer of code as well from Google. It could take part in many of those programs with accessibility being one of the focus areas. Could also be parts of sprints, could be something where we commission an audit, could be say an awareness thing around having a Django Girls or official Django tutorial extension focused on those aspects

Speaker 1: There's loads of room for improvements. Um we've talked lots lately about changing the the default starter template in Django And I guess accessibility improvements in the starter template could definitely help steer our community towards better practices. Oh yeah, and a plug for the web sustainability guidelines. We're talking lots about WICAG and ATAG, but there are also guidelines from the sustainability side of the equation. that are concerned both about accessibility as in usability of the web, but also things like social equity, privacy, and so on. It's all part of one bigger story. And yeah, so things things big and small. The last slide was the big ones, and then the small ones, there's lots of small ways to help us improve this.

Speaker 1: We have a channel on the Discord that's really active, people share resources on there. We have an activity team that's present both online and at the sprint And um yeah, plenty of ways I suppose to make Django more compelling for for UI people, um whether it's by changing Django tooling, perhaps adding linting for CSS, perhaps linting templates Perhaps it's by having sprints with designers around from your colleagues from your companies, lots of ways for us to work with those people. And on that note, yeah, thank you all. I hope you liked it and QA very welcome. I'll be at the sprints working on this as well

Speaker 4: All right. Thank you, Thibaut, for that excellent talk. I have uh two things both from Sarah Abduramana. First of all, uh she posted a heart hands emoji in the Slack. I wanted to pass it on to you.

Speaker 1: Oh.

Speaker 4: And second, a question from her. When with your Lighthouse audit that your data set was from April 1st, when did you run those tests?

Speaker 1: Can you repeat that?

Speaker 4: When did you run the Lighthouse? When did you run the Lighthouse audit test that you did on from the data set from April?

Speaker 1: Oh, okay. Um I ran it so the the the April I run this um every couple of months. or so so the April one is based on the HTTP archive data sets. Underlying data is there every month up to date, but my personal testing takes quite quite costs quite a bit of money. So I only run it now and then. It's all public, so I can definitely share both the spreadsheets where the data exports are as well as the queries that pull the data from all the Django sites out there. For the Django admin itself, right now I only do this on a very ad hoc basis, like the full audits of the admin, but I have actually started using um platform that allows us to run this essentially on demand. So you might have seen me earlier demo the Django admin. It's actually a completely static export of the admin

Speaker 1: that anyone can go to and use for the specific purpose of testing accessibility issues in Django. So yeah, this we can run on a on a daily basis if we wanted to.

Speaker 4: Great, great question. Other questions?

Speaker 1: Sorry, there's lots of echoes, so I have trouble hearing you from here, but

Speaker 5: so you listed out quite a few things that need to be solved. in terms of accessibility in the Django space, how do you prioritize what to do? You you mentioned that this part seemed the most important. I'm wondering why why that's the most important and what do you see as the next most important

Speaker 1: Yeah that's a great question. So I guess to me, uh I mentioned the idea of the North Star earlier, this one big number that's accessibility issues in websites out there. So to me it's like trying to think, okay, of all the things we could do, which ones will have the biggest impact on the industry as a whole? So perhaps it's speaking at events and raising awareness. Perhaps it's also in the case of Django fixing things that are there for websites between Django, which are much more numerous and I guess see much more traction, much more usage from people than the Django admin. So the Django admin takes a backseat just because I I assume it has fewer users than the sites between Django. And similarly the Django docs. making sure that accessibility is quite clear like what to do in the docs is also because I assume people using the docs

Speaker 1: will produce much more accessible websites than if we only worked on the admin itself. Does that make sense? I'll ask my question later to I'll have to do that. Oh come on, we have we have so much time. I ended like 15 minutes early. Just so we have plenty of time.

Speaker 3: Thank you very much, Thibaut. You said something really interesting. Um said, well, maybe this isn't this isn't the interesting problem. The interesting problem is how we're exposing these issues to potential Django contributors and maybe we could do that differently. You suggested it might be an issue of ownership.

Speaker 1: Yeah?

Speaker 3: Do you I wonder if you would you say a little bit more about that, about how easy you think it might be to change that?

Speaker 1: Oh, that's a tough question than you did.

Speaker 3: There was an easy one somewhere else.

Speaker 1: Great point, great point. I'm not on the stage for yes. Um I guess to me it comes down to uh quite quite a few things. Um I think in the past, X VDC might have had a a bad rep as like across all the things you could do as a developer. It's just like, oh, that's kind of one of the easy ones. So maybe let's not do that. So I guess it has definitely helped quite a bit to make it leave a space for it in our communities and make it sound like it's something that's really important because because it is. And um I I suppose in the Django space specifically I do get the feeling that Though there are lots of full stack people, they tend to lean quite heavily towards the backend, Django being a Python project, that's pretty understandable. That does mean that we need to try even harder to find people who are keen to work on UI things,

Speaker 1: accessibility. There's plenty of accessibility things to do on the back end, but definitely in the case of Django, there's lots of catch-up to do on the front end. So I guess find these initiatives where we can engage with perhaps a slightly different audience of contributors, perhaps with newcomers. Who come from the field without the background of Django expertise and might already have lots of skills on the on the front end where we need it the most. Um, I guess the last thing I could add is I mentioned uh making Django more compelling for this audience. So Things like Django templates, they are really simple on purpose. I guess it can be quite a turn off for people who feel quite proficient with things like React, that Django on purpose makes Django templates so simple. So perhaps things to consider there is things like

Speaker 1: introducing newer tooling or perhaps things that make Django more compelling towards front-end use cases. without it being opinionated too much about which specific frameworks. Yeah, and finally the the the art outreach programs, in my opinion, are a great way to get fresh talent who will have time to pick up the specific specific things like pick up the expertise for the specific things that the project needs.

Speaker 6: Merci beaucoup Thibault. Um my question is uh with regard to testing and sort of automating and um acceptance testing and CI, for example, and tooling around that. I I don't know if you have any Any uh thoughts you'd like to share with us?

Speaker 1: Yeah, definitely. Um so I mentioned quite a bit the the axe checker from from DEQ And I mention it quite a bit because it is open source and it is specifically tailored towards scenarios where you don't want false positives, where you want any and every one of the checks that it raises. to be a real issue. So my rec my one recommendation for CI would be to find an integration of Axe with the specific CI, um sorry, the specific uh test uh frameworks you might have available in your specific tech stack. So tools like playwright definitely have an AX integration. Puppeteer as well has one. Now we're looking at the Selenium one on screen. The Selenium integration is the one that Django is hoping to use for its own test suite in the near future.

Speaker 1: So yeah, find which integration of Axe is available and run it on your website. The one thing that's tricky about this, to be completely honest, is having the test suite for your site runs in CI. So if you do already, you've solved that. If you don't, you have to figure out which test data to have running your website in CI, which can be tricky at times.

Speaker 5: Next questions? Yep.

Speaker 7: So thanks for your talk. You are sharing um percentage of uh the admin uh uh it's very low from the point of view of accessibility. So my question is do you think it's possible to increase uh this percentage of accessibility or it's better to maybe think to right from scratch for example something like HTMX or similar

Speaker 1: That's a great question. So um the way I think about this is um lots of us involved with Django, we do this on quite an ad hoc basis, just like now and then over time, small tidbits of work. It probably will be close to impossible for us to do a rewrite from scratch in that way. It just means it's gonna block any or an old improvements to the current version in the meantime. So I think I would love to see a rewrite from scratch. But if we went for that, it would definitely have to come from someone who is quite well placed in the Django community and can schedule that as a program of work over multiple years So I believe that the Dango Software Foundation currently is very close to running

Speaker 1: board elections. It will have to be someone who perhaps goes to the board with this specific idea of I think we should do this and let's organize this over multiple years. If I like had to give advice on how to do this, it would be Let's have Django participate in a Google Summer of Code and ArtReachy and all those other programs with this kind of plan in mind And let's make sure that well ahead of this, we have plenty enough mentors to support this so that as a bigger group we coordinate on making that happen. So yeah, it's possible, but it requires lots of coordination, momentum, and I guess in the meantime, we can still work on making short-term improvements here and there.

Speaker 1: We have time for one more question.

Speaker 8: Thanks. Great talk. Another question about tools. There are certain tools out there that promise miracles like fix your accessibility issues with one line of JavaScript. Can you talk about stuff under that umbrella? I think it might be a bit of a rant, but I I we're ready.

Speaker 1: Yes. Oh AI. Yes. Um Oh how do I do a fair take on this? I guess the best way I can put it, first of all, it might not be the most eloquent for for this specific thing. So Overlay fact sheets, that's the best thing to Google if you're keen on being aware of those tools and what they promise and what they might or might not deliver. This is a Manifesto of sorts, and I'm one of the signatories, just uh uh heads up. Um There's this Class of tools essentially that promise quite big improvements without having to change the website's code, without having to change your team's practices. And I suppose in some ways they do fix some issues, but the wider problem

Speaker 1: is that uh they might not necessarily and you have no control over exactly what they fix. So those tools exist in the AI space. It's really common for people to promise that AI can detect issues and fix them automatically. I I I believe there's like definitely reason to explore this and try those out. But at the moment I definitely would recommend uh focusing on the fundamentals of uh accessibility requirements, talking to your users and building things from the get-go, the accessibility. Think let's think deeper.