Accessibility for the Django Community

Speaker 1: Okay, so this workshop is accessibility for the Django community. And yeah, there is going to be some rambling, some ranting. And a lot of slides, but some demo as well. The talk is or the workshop is mostly to convince Django developers that yes, you should also care about accessibility because a lot of the accessibility talks Do center around front-end development. And even when there is an accessibility talk in the Django conferences, it's around like Django admin, which is front-end facing. And it often comes up like many people who are purely backend developers have come up to me in the past and be like, yeah, all that's fine, but why do I care? Because I do backend.

Speaker 1: So we'll try to answer that. Before getting into that, let's get over with the boring person of who this fellow is standing here. I'm a self-proclaimed human rights center developer, which means I care more about accessibility, privacy, and security rather than how fancy AI is being used in the website, for example. I'm also a maintainer of open source software projects. I maintain the Ally project as well as the Onion Share. If you want to talk about those projects, please find me after the workshop. I am also part of the Vactel accessibility team and recently joined the Django accessibility team. I guess that adds a little bit credibility to this workshop.

Speaker 1: And I was the author of Security and Accessibility Chapter in Web Alban Act 2022. So these are all just facts for people who might be like, do you even know what you're talking about? Maybe a little bit. Um so getting back to the question, should a Django developer care about accessibility? Because again, we are doing backend stuff. Isn't accessibility all about front-end and design? Why do I, as a back-end developer, at all need to care about accessibility? Should a Django developer care about accessibility? The answer is actually pretty simple. Yes. I mean You I don't think it's just back-end developer. Everyone should care about accessibility and I guess my workshop can be finished here and everyone can leave But let's get a little bit more into depth and talk about why the yes, right?

Speaker 1: So what is Django? People coming to Django Con, I am guessing know what is Django. But still, this is an excerpt from Django Project. com website itself. It says Django is a high-level Python web framework that encourages rapid development and clean pragmatic design. It's probably one of the first paragraphs that you see when you go to the website. Interesting thing, if you look carefully, there is this two-word phrase called web framework. So at the end of the day, Django is still a web framework, which means Django is used to make websites as one of the primary things and as we know web is for everyone so in the screen you can see a picture from 2012 London Olympics

Speaker 1: Where Sir Team Berners Lee put up the writing call, This is for everyone. So, yes, web is for everyone. As web developers, we should probably not say, well, it works in my machine Um that doesn't work because web is supposed to work for everyone, not just your machine. So yes, the web is for everyone, but Now you might ask, well, what do you mean by everyone? And this is where I want to talk a little bit about the users and the assistive technologies that these users use. Because I really believe you should not do accessibility because some standard or some law in your country is requiring you to do that Those are for convincing your employer that hey, we should do the accessibility. But as a developer, you should do accessibility

Speaker 1: because you know these are the users. This is how my work is actually affecting And that is why we do accessibility. And we will talk about standards, but first let's concentrate on users because accessibility is about users. It's a human right So when we talk about users using the web, the first thing that comes to mind is the interfaces that they use to browse through the web. And The two most common ones are mouse users and touch users. A lot of people use mouse. A lot of people use touch if you're using your phone. I might say these two are almost Too carmal of an interface that people often just think that this is all the interfaces that is being used. And often people design and develop around just these interfaces.

Speaker 1: But that's not it There's more keyboard users. So keyboard users, if anyone has ever tried to browse through the web just using keyboard, you know it's Painful and really frustrating while it might be an option and a hobby for some of us. For some people it's a real necessity That they can only browse the web to keyboard use. There can be people with temporary or permanent motor disabilities. In the screen, there is a screenshot from a YouTube video from W3C where a person is using a stick and the stick is used to control the keyboard and that's how they browse to the web. So it's very important they are disabled and paralyzed so they can't really use any other interface

Speaker 1: Switch device users. So switch device users is kind of similar to keyboard users, but it's a little bit more constructive. So you uh So you can't do a you can't control a lot of keyboards. You are they have very limited dexterity. So there is very limited movement possible. So in the screen you can again see a screenshot from a video where someone is sitting on a chair and the chair has these two switches. So all they can do is just move their heads a little bit and that controls the two switches. And these two switches are usually uh one is the the traversing the page switch and another is the action switch. So basically if you want to map it to your keyboard,

Speaker 1: the first switch is basically a tab key And the second would be an enter or a space button, depending on which element it is. So a very famous person who uses or used to use switch devices, Stephen Hawking. So, yes, there are real people who are using this. Screen reader users, this is actually one of the more or less commonly known interfaces when it comes to accessibility. So people with limited or no V. use screen readers almost all browsers and operating systems have some form of screen readers these days so um Yeah, it it really helps. So in the screen you can see a person who is blind, who is traversing to the page

Speaker 1: using their keyboard and while using their keyboard they're using screen recorder so whatever they hear in the screen recorder actually appears in this little tarker screen so in this particular screenshot it says link UCSF Medical Center Right. And a very important thing to remember about screen reader users is which many people don't think about is screen reader users are not always people who have no vision Sometimes they can have limited vision. So it's really confusing for screen reader users when they can see that there is something. But they can't hear it at all. So it's really confusing of an interface when you're like, okay, I'm calm through something. I can see it on the screen, but the feedback clearly doesn't match.

Speaker 1: So yes, that's also something that you need to be really careful about. Probably yeah. And a very common common interface that almost everyone can use all browser support is Zoom users or people with low vision prefer using Zoom. You would think this is one of those interfaces which is like, yeah, who doesn't build for Zoom users? Just try Some of the standards require you to have zoom till 200%, and I can guarantee you a lot of websites break when you zoom at 200 %. So you should really be careful when you're making your website that Zoom is something that your website doesn't break with

Speaker 1: because there are actual people who are using Zoom And then there are many more. There is mouth stake, four eyes, sip and puff device, which is also kind of search device uh Burelli input brand display reduce motion for people who might get triggered by some kind of motion. So there are diff many different interfaces. And We need to make our websites available for everyone because again, web is for everyone. Now, for people who are more convinced with standards, yes, there are standards which talk about how they are more like guidelines on how to make your website more accessible. The most popularly and commonly known accessibility standard is web

Speaker 1: content accessibility guidelines. There are plenty of talks. There have been talks about it in DjangoCon itself before. It just it is a little bit of a lengthy document and sometimes the document itself can be little inaccessible, a little ironical, it's difficult to understand sometimes But yeah, there are websites like Ally Project which tries to kind of condense the information and convey the information in simpler terms. But yeah, that is one of the standards that commonly meets And web content accessibility guidelines is one of those standards which people are like, okay, everything mentioned there is probably something a front-end or designer needs to jump in and that's why it's a front

Speaker 1: end and designer's responsibility. But there is this another standard called authoring tool accessibility guidelines. It's also a very important standard And it's an important standard to talk in Django Con because let's face it, a lot of Django applications are around CMS or some form of authoring tool. So even if you are building a plugin for a CMS that is actually leading to a CMS or some authoring tool. So authoring tool accessibility guidelines is again a lengthy guidelines, but it can be divided into two parts. The first part is make the authoring tool accessible by themselves. So if it has an admin panel in the CMS, that panel itself should be accessible because in your editorial team There can be someone who is using an SSF technology.

Speaker 1: Not everyone as editors use mouse and touch. But there is another very important part which is provide tools that enable authors to create accessible web content. So Django often comes into play when you don't want to make static websites, right? You want to create content and you want to provide an authoring tool where someone can go ahead and create content. So it's very important that you always provide things so that the authors can create the content which at the end is accessible. And that content needs to follow WCAG. But the tool needs to have ATAC or author into the accessibility guidelines, which allows the editors to create the accessible content. Make sense

Speaker 1: Okay, but you might still be like everything sounds good, but isn't it still a front-end designer's responsibility to think about accessibility? And So there is this website called WebM, and they release a WebM million report every year. And this is the 2024 report, and as you can see The six most common, these are the six most common WCAG failures across website. The first is low contrast text. Yes, that is probably a design decision. There is missing alternative text, missing form labels, empty links, empty buttons, and missing document language If you see missing alternative text, it's still more than like 50% websites fail it when we probably all know about alt

Speaker 1: text by now in images So, in this graph, if you think when you are making a Django CMS using an authoring tool, There are probably four items that directly link into a back-end developer's job. Possibly missing alternative text. If in your backend there is no field to add an alternative text, if you as a back-end developer has never provided a field It's probably not possible for the front-end developer to code in any way and add an alt text. Similarly, it goes for missing form labels. A lot of Django content has this form builder tools And if your form builder tool really doesn't care about adding labels or even associating the labels

Speaker 1: with which input field it's going Then that will probably fail front-end developer and designer can't do anything. Similarly goes with empty links and missing document language. And I'm going to show those in demo Also, you know, through into accessibility guidelines, as we were talking, the second part is probably completely a back-end developer 's job. So this is where I do the brave thing and jump into code examples and pray to the demo gods that nothing breaks. If you want to follow along, you can. It's a GitHub repository. So yes, these are probably the codes. You can clone this GitHub repository, which is

Speaker 1: uh at github. com slash subtaclas django dash accessibility dash demos. So if you want, you can go there, clone this repository, and then we can follow along. and actually show you in the code what I mean about what I was talking about. Okay If you want to see this, that probably the git clone line is the first thing that you need to copy paste. And apart from that, everything we can follow along.

Speaker 1: Django dash accessibility. Did I spell it right? And dash demos dot git. Yeah. So once you do that, you'll probably have uh is this large enough? Probably not. This too large. So you should have a folder like this. You can see it into the folder. There are a few other steps, which is Creating a virtual environment, going into the virtual environment and installing requirements. txt. The requirements. txt really just has Django and Pillow because

Speaker 1: I'm going to show image examples and Django image field users pillow and Django because this is DjangoCon So once you have done that, it's again python tree manage. py migrate to migrate all the database changes, create a super user, and then we can run the server. So yes, all the general normal thing that you would do with the Django project.

Speaker 1: To save some time I have done most of those things and I'm just going to run the server and I didn't do so So let's see. So it's uh Pretty basic, not so good designed list of images which doesn't show any image because we haven't added any. So we'll go to admin My password is for anyone who attended Pivot Stop can guess the passwords. Yeah. I kind of considered doing it through Vactel, but then I was like, why not do Django at me?

Speaker 1: And yeah, if you did the migration and did a super user, did run server, went to admin, logged in, you should see something like this. Right? So it's just groups and users is something Django already provides and articles, images and social icons are the things that I have added. That's where I want to talk about the different things. So let's get started with adding some images Okay. And so here is a model. I will show you the model in a bit, but here I have a title, I have this image field where I can add an image and some attributions. So so so so so let 's see. Um

Speaker 1: browse I do have some images Since I downloaded that image, I know some of the attributions, but uh let's uh we leave it. Attributions is more like um if you want to attribute who took payments and things like that, right? Save, add another let's say two, let's add another image. And let's yes, um, I'm not sure.

Speaker 1: So let's say I have added three images, and now if I go to the website It should look a little bit better, not great. Um but I guess it works. Um yeah So yes, there are three images and we have added the images right now. This is how the model looks. I'll show you quickly. Um So yeah, the very first part is the image model. So it has a title, it has an image with image field, says where it uploads, and it has an attribution field which is not compulsory and then there is a underscore underscore str

Speaker 1: to say how it will be represented. Um so yes that's the image field everything looks okay and it's a pretty like common image field that people might have so that they can upload image and then use the image somewhere else, right? What's the issue with this? I mean they have clearly shown the image and everything looks good in this website. So what's the issue with this? Well, just like you can do inspect element, which a lot of browser hackers love to use, what we accessibility hackers love to use is probably inspect accessibility properties And if you go to inspect accessibility properties, yes, there are many automated tools that you can use that will say Yes, what I'm going to say right now.

Speaker 1: But I just want to say that all the browsers already have an accessibility properties that you can go and check if you already know what to check. So, yes, there is an image, and you can see that image has empty text label, which means that it doesn't have an alt text, right? So content with images must be labeled is something that is written there. Just to show an automated tool, Axe DevTools is there. If I run it on this page, it's going to say the same thing that three issues have been found and all our images must have alternate text Now, if you as a back-end developer give this and you are like front end is going to take care of making it accessible and

Speaker 1: The front-end developer doesn't really care about the accessibility so much and they're like, okay, it says it's failing What I'm going to do is I'll go here gallery. html. What they said is add an alt text. So what I will go ahead and do is I'll do image. And if I reload this, works. If I just rerun a scan, no issues found. Automated test passed. We have made our website accessible. The issue is if you now go back to the accessibility dev tool and you see this is what the

Speaker 1: They also don't complain, but you can check the name and the name says uploads slash call me Fred something something something. So if someone is using a screen reader, this is basically what they hear. They hear image and then comma, then there will be like upload slash call me fit. And I don't know if that Currently conveys the mess is about the first image. Um so yeah Now, if you leave it to the front-end development, uh this might happen, or they will come back to you and say what I am going to say. Which is we can't do this. We need something. And what we need is um

Speaker 1: so I have created some branches to show the examples, but we need to have a field for the alt text. And if I can remember, uh okay. So if you all just change to this branch, checkout ad -alt dash text. It's there in the slides as well. You can follow along. Um so yeah, if you go to that and then you run migrate That kind of adds some things. What does it add? Okay, so let's go back to the models and see what we did.

Speaker 1: So, what we have right now done is basically add a description field in the image. Okay So now that we have the description field in the image, if I go back and remember to run the server So yeah, um if I go to any of the photos, it's kind of going to say like okay there is a description field so um we can just check and this is a picture of a building with Building with uh back

Speaker 1: to the future booster. Let's say that works for now. And I save. And another thing that I've changed in gallery. html is now I am using this image. description because In the back end, we now have a description field which we can now use in the alt. And that gives the editors firstly to write something instead of a front-end developer who might not have a lot of copy expertise. And they want to just write building and be done. So it gives the editors firstly a lot of control how they want to describe the image that they are uploading. As well as now if I

Speaker 1: Go to the first one and I check. Um you can see that okay, did I not reload? That should not happen Yeah, so um you can see in the image name it's written building with a back to the future poster, which probably describes this a little bit better than upload slash call to Fred or something. So great, and so we are done with alt text and that should solve everything. No, um there is a slight bit of complication here which is Alt text doesn't really work like all the images should have the same alt text everywhere. There is a concept called contextual alt text. So an alt text should always

Speaker 1: Be presented in context. So a same image can have a different alt text for a different context. A same image might have an alt text somewhere and be decorative completely on a different page So it's very important to realize that it's not just that you add the image, add an alt text in that particular model and be done with it. You also need to probably have somewhere else. So that's where we have this article model as well. So I can add an article here. Back to the future article. body I'm going to use this website called um DeLorean lipsum anyways don't like

Speaker 1: Laurean Ipsum anymore And I'm going to say the photo was the first one that's on. So if I save this, um And I have an URL which I want to see is article slash one. If I my memory serves well. So you have now kind of like a post with an image And then there is an article somewhere below, right? And you can use the same image description here as well, and that would have that would solve it to some extent because there would be some meaning to it but in this particular context when I write this post maybe this is not exactly what I want

Speaker 1: because It's the image description that I added to the model is what the thing that would actually, if Django Admin did have an image picker kind of thing, here I have just written a foreign key Not put any different widget. So it just appears as a drop-down. But if it was an image picker, ideally that's where I show the image description. Why? Because the editor knows what they are selecting at that point. So if an editor is a screen reader user editor, they know that this particular image has a building with a back to the future poster But maybe in this particular context for the article, they really don't need to mention it's a building with a back to the future poster. They just need to mention the back to the future poster.

Speaker 1: So in that case, we are going to check out the other branch and Contextual alt text is a really difficult topic when it comes to CMS. In Wactil, we are having an entire Google Summer of Code Programming done to add contextual alt text to Wagtil. So it's not like something I can solve in a 50 minutes talk, but I have kind of done a very simple example here. And again we need to do manage. So yeah, so what we have changed here now is instead of image, this is the article class. And what we had before was just photo body and title. Now we have a photo underscore description.

Speaker 1: This photo underscore description is for the image in context to the article. So that's what adds the context and also is underscore decorative is also in context to the article. Why I have added is underscore decorative in the article model. and not in the image model is because the image model should always have an image description because the editors who are using the tool needs to know the alt text otherwise they can't understand if the editor itself is using a screen reader they don't know what image they're picking even if it's for a decorative purpose but the image can be decorative uh in context to the article Right. So that's a little bit of a caveat.

Speaker 1: Run server Let's go back to this article and now we have a photo description and here we can say back to the future movie poster. Because maybe in this article context you don't need to know there's a building or not. Right. And then if I do that, so if you see um in local jose thousand, it still should say Building with a back to the future poster, but here it should say. If I did the demo correctly, back to the future movie poster Right. So in this context it's a different alt text, and in the other context it has the alt text that is the general one, which is describing the image. Okay

Speaker 1: So, so so so so so I do. It can also be a decorative one. This image might not be, but that's why you need to provide probably a checkbox. Here I have provided a checkbox. If I mark the checkbox as decorative , this is going to do This and here if you see the image thing is not there right it was there before it's not there now. Why? Because when you have uh if we do an inspect element here it has an alt empty string so this is how you declare most of the time an image as uh decorative or a presentation purpose you can add your

Speaker 1: liquor to presentation in image you don't need to use that don't use a When you don't need to use it. So yes, you can just say empty string in the art, and that will convey the message that it's a decorative image. Which is why it's not shown here because it will hide that information from the screen reader because it's decorative and the screen reader user doesn't need to know about it In this case it's probably better not being a decorative image. Okay. And that kind of solves the contextual alt issue But so yeah, uh contextual art is actually a WCAG success criterion 1.

Speaker 1: 1. 1. It's actually one of the first success criterions and There is still more than 50% websites which fail on it. So probably no one is reading even the first paragraph. Accessible name for links, that's another thing that we saw in that graph as one of the top six issues. Um, so WCHG success criterion 2. 4. 4 , little below in the list, but A link should have a name and this kind of sounds like how are so many websites failing this? Because of course a link has a name. If you are writing a content, there must be a string where you are clicking and it has a name. Well I have an example for you So if you

Speaker 1: now change to this branch called social dash link dash name i I think this is one of the most common places where links start to go not having name. Hopefully everything works. Okay. So yes, now we did have a social icon Tindi. Actually, yeah. Probably wait. I am going to do it slightly differently. Probably should show you the bad thing first. Right

Speaker 1: Okay, let's try the bad thing first. Get check out to the previous one If everything still works, it should have social icons, right? So I'm just going to add some social icons and that also needs to be an image. So I kind of need to first add an image Which I don't know where I did at open. Okay. Oh, so let's say Facebook Uh yeah, local maybe something. And I do have question.

Speaker 1: Okay, yeah. Sure. Uh uh, you need to check? Um Can you recommend any literature or tutorials regarding the contextual alteration? Okay, yeah, I am going to mention some links at the end But let's go with this and it now we know has a description. So I'm going to just write Facebook logo and then do a save. that should actually kind of show this Facebook logo also in this grid. CSS grid works. So that's it. And then I just add, let's say, some

Speaker 1: probably just facebook. com and I add a link. Sounds like a popular way of adding a social link to your website. You have the image, you have the link, what else can you need? Firstly, I need to remember the URL So I'm kind of just showing the same post, but this one has a logo, pretty big one for some reason. Um So if you do and inspect accessibility properties, this is where the issue comes, and this is the link that the interactive elements must be labeled. If you go to let's say A checker like this. It says

Speaker 1: firstly image must have an alternate text because this Facebook logo doesn't, but also link must have the discernible text So this works fine. There is a logo. If you click on it, you go to the website. But if you are using a screen reader user, uh if a screen reader user is using this icon, they have no idea where this link goes. They just hear link and done. So that's why the social media icons whenever or any icon that you have in your website It needs to have some form of label. So the image needs to have a label and that kind of will give a label to the link, at least in this example So now again the solution that you might be thinking is well

Speaker 1: can't we just again go and see You know, just write alt equals to icon dot icon dot I think it was what was it Some photo description or something. Um description, yeah And that should work. And if you rerun the scan, it will say it has no issues. And if you Check again, it's going to be like Facebook logo and for the screen reader user at this point they are hearing link

Speaker 1: Facebook logo Now the thing is you might be like okay that kind of gives an idea but if you go and have an accessibility audit they are going to fail you at this point because a link 's name should say where the link is going to. So Facebook logo is not the text that the link should have. Again an example of contextual alt text actually because in this context Facebook logo is the wrong alt text to have. In this context, you will either have just Facebook or you will write Facebook page of whatever your website is. So Let's go ahead and fix that and that's when I need to change that

Speaker 1: And I need to migrate. Yeah, so now basically if I go to the models, the social icon itself has a link text So I can go back now and I can see again need to run the server I can see that in this context, the link test should just say Facebook. So now when I do this, save, go to the demo And if you see it just says link text is Facebook. So now a screen reader user is going to hear link Facebook. Now you can actually improve the accessibility more in this case.

Speaker 1: You can even add like a separate that's again in the front-end side. So that's on the front-end developer, probably not what back-end developer needs to care, but as a front-end developer. you can have the text be represented differently and make the image as a decorative thing so that the image is not something that the screen reader need user needs to hear about. But yes, that's front-end developer's responsibility. But if the back-end developer didn't give a place for a social icon model to add a link text, the front-end developer can't do much So that's talking about accessible name for links. Now another thing that is there and very commonly missed is the lang attribute. The lang attribute is one of the attributes which you can use in almost all the HTML elements,

Speaker 1: but usually you use it on the very first HTML element. You will see HTML lang equals to in quotation en uh if you actually go and see in this example as well It is their lang equals to within quotation EM, which basically says that it's the entire content in this website is written in English. Right. Um and that's fine. One of the issues that often comes with this where you get a false positive that yeah my website is great is when you copy this base. html, you are trying to make a Spanish website. And you have copy-pasted the entire base. html and it says yes, lan equals to en and everything below is Spanish.

Speaker 1: So that's probably not correct. And then the other context where it really gets confusing is when you have a website which has mixed content. So I can have an article website, but there are articles both in English but also in Spanish. So let's kind of do that. Um the issue with this is I don't know Spanish. So I what can I do? Can anyone see some Spanish lines? Right? Hola? Yeah. Okay. That works, I guess. That was Spanish, I knew. Um, and then you just put something. and let's say

Speaker 1: the photo description I don't remember what this photo was but let's say on double scenery and save Right. So if you do go now to probably two, then you should have something like this. Spanish and holder and saying that. The issue with this right now is if you do an inspect element, if you see there is in HTML it says lang equals to en So it appears as that the entire website has English content, which it doesn't at this point. So what we need to do is Let's see language.

Speaker 1: Yep. Um Right and then run this over, not forgetting this thing. Yeah, so basically what that does is in the models in the article you have another field which says language, right? Because It might be the rest of the website has content which is in English, but the language should be present in the particular article itself. And if you go and see now, the article tag here has a lang which says lang equals to language, which conveys that information that The entire document is in English, but the article part is in Spanish. Which means I should have written a Spanish title, but that's on

Speaker 1: me. Bad editor. Um so now if you go reload this page you can see that the HTML still is saying en but here it's still in en because I had it default but if I now change that and I say no this is a Spanish Content and if I load it, it will say that the HTML content is still EN, but that particular article is in Spanish, and that conveys that information. So if someone Let's say is using some form of translation tool, they can now actually translate that and know that okay, this website is this particular part of the website is in Spanish because If someone is let's say using Spanish to English translation

Speaker 1: and always the lang is in English, then it might not translate at all. So the lang attribute, very important, and that is the though the statistics was more about missing document language, but this is one of the places where Back-end developers also need to provide a lang attribute when you are writing an article to convey the message. If writing the article in Spanish changes the entire document into Spanish, then you can probably even change the HTML's lang attribute. into ES. And there are actually a lot of other accessibility features which I can't talk because time 's not there almost gone. Authoring tool accessibility is everything in the authoring tool should be accessible.

Speaker 1: Accessible authentication is something that WCAG 2. 2 has added, which says that you can't have just one form of authentication which might be issues for example captures if you give an capture you have to provide an alternative because capture might not have a be compatible with screen recorder. So accessible authentication, authentication doesn't work without the back-end part. So you need to provide those features. Form labels, another thing, if you are building a tool which allows you to create a form, then you need to know how to create labels for that form as well. Same with the form errors. If you are there are a lot of Django tools which provide Django forms and Django forms might have errors and the errors might not be associated with that input field. So in that screen readers can then figure out where the error comes from, which field they need to change.

Speaker 1: But lot about code done and I want to finish my talk a little bit with saying Django isn't just a code it's a community right that's why we are having DjangoCon conference That's why we have a lot of other Django events. That's why we do a lot of talks, a lot of tutorials. Every project that is doing something with Django is part of the community. And when there is a community, inclusivity is very, very important. And since you need to make the community inclusive, you need to care about accessibility in the Django community as well. Just writing good code and having accessibility doesn't mean a lot. So there are two different kinds of accessibility when it comes to community part, digital, which is what we talked about a lot, but also physical, like

Speaker 1: The location that we choose for DjangoCon is that accessible, the can wheelchair users actually go through it? Live captioners, we have seen that the talks have live captions or that people who can't hear they can still see the content. A lot of conferences even have sign language interpreters. There can be brave signs like for example, you need to go to the washroom. If it's only text, maybe Um some blind person can't see, so maybe some real signs can actually help there. So there can be different solutions to different issues. Social media, this is something that has been like Everyone in DjangoCon is posting something, and sadly, everyone in DjangoCon is not posting with an alt text. Some people are, and I'm really happy for them, but

Speaker 1: Some people are not. So most of the social media platforms still have like you can add alt text in some ways. User experience might not be great in everywhere But yes, adding an alt text is very important. If we keep on talking about development around alt text, but then we add social media pictures of DjangoCon which doesn't have any alt text and people who are using the social media really doesn't know what that picture was about. That again kind of defies the purpose. And for social media alt text, and this kind of goes with the contextual altics as well, is the alt text depends on context as well. And if there is a text in the image, that text should be there in part of the alt text. Don't start your alt

Speaker 1: text by saying image off, photo off. Doesn't need to be that. Already the screen reader is saying that it is an image If images are link, all text should be the link text. We saw it already. If image is a chart, often it works better that you describe the data in a concise manner rather than saying Bar chart one, twenty five, something like that. May depend on the use case. Also speakers, good color contrast and large phones, because yes. Reduce amount of text. Many people might find it a little difficult if there is a lot of information coming. Always describe visuals in a slide. So if you have a picture in the slide, it's better to describe it, what the picture is about Avoid acronyms as much as you can.

Speaker 1: There is actually a link by W3C on how to make accessible presentations. I think it was actually included in the DjangoCon CFP. So great work there Accessibility for contributors. So if your project is looking for contributors, then your project should have some guidelines for the contributors itself, such as Making the events contribute, like making the events accessible, also using accessible platforms for communication, the documentation should be accessible. Some can even say that the editor and the editor config that you're providing is part of the authoring tool because it's make allowing coders to author a project. So that might also need to follow data. Have an accessibility statement that is probably something the Jenga project also needs to do.

Speaker 1: And platform for assistive tech users to submit issues So it's very important that people who find issues in accessibilities, they can provide those issues and those issues actually get worked on rather being issue level accessibility and going into void. So, yes, accessibility is a human right. It's not a tech debt. Don't treat it like a tech debt. And that's all from me. Thank you. Question. One of the questions was can we recommend any literature or tutorial regarding the contextual alt text? Um I think if I'm not wrong Web has a contextual or

Speaker 1: text um document. Is it this one? Yeah, so webem has this link called webm. org slash technique slash alt text. I can probably paste it in the Chat as well. So that kind of stays in the second section of the website, which is context is everything and kind of explains what context means, why it can be different in different scenarios, what does decorative mean? And it kind of also has this squeeze kind of example where they are like, what do you think is the best alt text in this context? Yeah, that is a good article to start with. The second article I would say after that is just read WCHE.

Speaker 1: It's a little difficult, but if you actually read it in depth, you will understand why context matters. Is there any other question? I didn't see anything else in chat. Do you have? Yeah.

Speaker 2: Yes. Um so You said that if an image is a link, the uh the the alt text should be where the link is pointing, right? Yeah. But what if the image isn't just decorative and also a link?

Speaker 1: Right, so

Speaker 2: possible to like describe the image and describe the link separately?

Speaker 1: Yeah, you can. In that case, really I would say is Probably it's a better idea to have it as a separate text somewhere below. Right? But that's my recommendation. Uh the design system can be different. But if you feel like the image is important enough to have its own contextual alt and then the link below should go somewhere else Probably having a separate link text is better than putting it as part of the image because that means that image was not supposed to be a link. It's supposed to be n visual content that isn't conveying some information You have a question? Yeah.

Speaker 2: Yeah, I'd love to know your take on um the opportunities for automated tools to help flag or resolve those issues. So you mentioned contextual textures and even like things like languages. Do you think that there is room for better Django tools or activity tools generally to type those things or resolve them?

Speaker 1: Right, yeah, so like you know we have in Rapil and we have like Sally. Um so yes, there are some accessibility tools which allows editors to know that they are messing up some editorial things But for example, what you're saying is if the alt text is different and we need to like if it's just an image and name written and it still passes, do we need to change that? And I have seen some people create issues in automated testing tools saying that you should probably have some way of detecting this is just a file name and say flag it that this is a bad alt text So yes, definitely it would be helpful to have those tools. I think doing a tool around contextual alt is a little bit more difficult

Speaker 1: where How do the automated tool know that it is out of context? Does it always flag if it's the same alt text everywhere? Maybe, but can there not be two articles which have the same alt text in that context? maybe as well. So yeah, I think building that is a little bit tricky, but yeah, I think at least the tool should flag. This is just a file name Or if it doesn't follow a good practice, like an alt text starts with image off, that can be something of a wording that maybe this is not a good alt text. Yeah. Do you have another question?

Speaker 2: Yeah, do you did you publish these slides anywhere?

Speaker 1: Yes, the slides are there in slides. com slash I think

Speaker 2: Thank you.

Speaker 1: Thank you. I think there's no other question.

Speaker 3: I have one question.

Speaker 1: Sure. Do we have time though? I mean there is nothing else after this. Keep on asking questions. Yeah.

Speaker 3: So we're fighting this ongoing battle to get people to add up text and all these things to these images to communicate their intent. And last week we saw Mozilla announce that they're going to have a LLM inside their browser that will fill in the alt text. are against him what might be there.

Speaker 1: Right.

Speaker 3: Now this feels like it goes against the stu some of the stuff you're saying because the understanding of context couldn't possibly be there.

Speaker 1: Yes and this is some discussion we have in the actal team as well in the contextual arch text. We have also been thinking about whether AI is a good idea to add. But I have had, I don't know if everyone in the team agrees with me, but I have had this stronghold where I feel like an image description is something that an AI can do a good job of describing. And maybe that is better than having no alt text. But I don't always think that the context is something that should be left to the AI to completely decide. If they are deciding, at least there should be some way for the editors to override Right. But at the same time, it's also again like Mozilla and all these kind of tools that what they are doing

Speaker 1: is kind of doing some of like graceful degradation right like it's like okay there is no alt take so something is better than nothing And yeah, something might be better than nothing, but at the same time, wouldn't it be better that the editors provide it? Because the editors are writing the article Definitely understand the context better, definitely understand why they had put that image in, which Mozilla might not know. So I would still say that do pursue and ask your editors to add their own text. Yeah. Yeah.

Speaker 4: So I have a question maybe in how can like we make improvements in the Django community for this? I like this workshop Awesome. I wish this was filled with people, but so for example, I've seen quite a few inaccessible slides, like even during this conference. Like I've seen code that I couldn't read and like I'm not pictures. I mean I have glasses but with my glasses from like a couple seats back. So like how can we I guess as a community try to really empower speakers to care about this and also like provide Maybe I normally provide guidelines and I like the speaker I'm a speaker. There's guidelines on it and they like, oh please check your colour contrast. But do you have any ideas on how we could maybe get people to at the very least have like visually accessible slides

Speaker 4: with code that's readable and contrast that makes sense and fun size that's

Speaker 1: yeah I mean that's I have seen conferences which do like a speaker mentor program. I'm not sure if DjangoCon Europe also had it, but speaker mentor program is something where people can actually help with those. Yes, I I was actually kind of impressed seeing that DjangoCon CFP did have all the things that you should have. considered with accessibility, but yeah it's difficult for people to make someone read a document I understand. So that's where probably a speaker mentor kind of program helps. Especially if it's like um first-time speakers, not to say first-time speakers are like first-time speakers are actually sometimes better than people who have

Speaker 1: than people who have been speaking and be like, hey, I know my stuff But yeah, uh sometimes some conferences I've seen has like a compulsory speaker mentored thing or just like a sorry, just like a discussion with it's not really mentoring to say your slides are completely wrong, but just going having a rehearsal of sorts basically and going through and saying like someone in the Django Con team or the conference team saying, okay, this place you should have less text, this place you can have a better contrast. And I think that sometimes does help. Yeah. Like for the social media thing, I think there should be if there is a social media team who is handling all the DjangoCon social media, they should be trained what are the accessible practices that a social media team should follow.

Speaker 1: I think that's it. Thank you. Thank you.