Accessibility wins for Wagtail projects – Thibaud Colas

Speaker 1: All right. Well, hi, uh I'm Thibaut. My pronouns are he, him. Uh I work at Touchbox as a front-end developer. As a front-end developer, and I'm also part of the Wagtail core team. I'm really pumped to be here. For people who were at Wagtail Space last year, I was also talking about accessibility there, but only focusing on the Wagtail admin accessibility, which which is quite important, but is only only one side of this. Today I'll be talking about accessibility of Wagtail websites and websites in general, not just Wagtail but definitely with the white tail lens, which is going to be hopefully really cool. So yeah, just a quick word of context on this, why this matters, why do we care about this

Speaker 1: Really it comes down to the simple fact that we build websites for people and we want people to be able to access the sites we build, the sites we invest lots of time in. no matter their abilities, uh, no matter their backgrounds, no matter their current situation. Um the other day I was trying to use my password manager with my keyboard because I I couldn't reach my my mouse, it wasn't working and I couldn't access my passwords without uh my keyboard, with my keyboard only. So that's kind of the thing we're talking about here. And and also worth knowing at this stage is that when you talk accessibility, people do tend to think screen readers, people who are blind But accessibility improvements generally do lead to usability improvements for all. This is something called the curb cut effect, which you should look up if you're interested in this.

Speaker 1: And yeah, on a more negative note , just to clarify that accessibility is not something that's optional anymore, and it really never was. There is really clear body of law now internationally. So in the US there is section 508, which is very well known for federal websites. There is ADA for uh literally all businesses in in the in the US and public spaces. Uh the ruling is still out with the Supreme Court on whether our websites are also meant to be ADA compliant or not. I would definitely say yes. uh there's lots of lawsuits happen happening around here um latest ones with gimlet media who you might be uh listening to the podcasts of And Patreon also had some legal trouble recently.

Speaker 1: Not trouble, but you know, uh cause for concerns. And in the EU and UK as well, there's the same body of laws that apply to uh public sector and all companies And yeah, just under the hood, this is all based on the same very well-established standard, which is WCAC 2. 1AA. I won't talk about the standards too much today, but this is definitely the one to look up if you're interested in this. Yeah, and also this isn't just about Wattel sites, of course. This is about literally all websites, no matter their audience, no matter where whether they are public or internal only. And no matter what they are built with, this isn't just white tail. Yeah, and this this can all sound quite negative, so I just want to address that it doesn't have to be

Speaker 1: And I I really think there is a cultural shift in in the works here around inclusivity and accessibility. And hopefully a few years from now, this will just be part of the landscape. not something we have to even think of that much. It will just be part of what the web is and how we build websites. And hopefully Waxel can be a part of this to some extent. For now though, back to the real world of 2020. It turns out that if you work at Tornbox as a front-end developer, you get to uh receive also accessibility audits or do lots of audits of other websites And you do notice quite a few patterns. So we'll look at some of those patterns today. And yeah, again, I don't want this to be all negative. Quite a big chance for this to be a bit of a

Speaker 1: try not to cringe exercise or try not to laugh. So I'll do my best to stay positive and always propose solutions and only uh show websites that I've contributed to myself. Um and yeah uh if you worked on those sites uh Well I yeah I have to and we've also worked on sites that were subpar and we we can all do better. It's all good as long as we all I'm in for doing better Um so yeah, diving right in. Alt text for images. Um you might have seen this logo farm before. It it looks really cool. And I will now use my screen reader superpowers to turn this into the version that screen reader users see. And you can take a guess as to what happens

Speaker 1: Alright, we can see the alt text. So some of them have fairly decent white alt text, Mozilla, logo. This would be better as just Mozilla, but why not? Samaritans logo. jpg Well yeah I guess Samaritans will be plenty enough. MQ logo on six cross for background. png so obviously this this is showing all text that is seems to be shared from the file names of of those images. So not ideal. I think in this case uh we we're lucky enough because the files did tend to be named appropriately. So the start of the alt text of each image still is meaningful But there is no reason for all of this trying to be there. It would really be just the text that's on each of those logos and and nothing else

Speaker 1: So this is actually a very very very common issue in Wagtail because Wagtail by default when you upload an image its title field comes straight from the image's file name And also by default, when you uh embed an image on the page, it's as text comes from the title field, which uh yeah, is the recipe for for success or disaster and yeah, makes me cringe really hard every time I see this. But it's the default, which is what makes it so bad. So the obvious solution here is to have an alt text field for each of those images. And I have for each of those slides quite a few links to in-progress issues or a few pull requests. This is definitely something we're looking at fixing directly in Wagtail, but in the meantime.

Speaker 1: do make sure that all of your images have an alt text field. This is good practice generally. And um yeah alt text for images uh strikes back. Another logo farm on website you might have seen before. I'll I'll use my screen reader superpowers again, but uh give you a couple seconds so you can guess what happens here All right, Wagtail is trusted by people you know like Google and NASA. And if you're a screen reader user Well wact tail is trusted by no one. Because as it turns out, none of those images have alt text. which um you know sometimes images are decorative so it's good for them not to have any but in this case well the images are the main content of this section

Speaker 1: So here as well, it should just be set to the text that each of those logos contains, which should really be an easy fix. And yeah, I'm sure that someone will ask me for a pull request at the end of this talk, which is more than fair And yeah, quick notes about this as well. Although text also happens to be what's displayed if the images fail to load on your website for whatever reason. So even for SEO or uh just uh as a fallback it's always good for this to be there just in case and um yeah so in this case the alt text has to be mandatory because otherwise there is no content and uh yeah display it And I'll text for image again. So let's look at another example on a website you might have seen before too. So here there are two images, this profile picture here.

Speaker 1: Lovely, and then this kind of uh uh decorative image at the top of the blog post. Um so let's let's see what uh what three other users will be able to see from this So you can see the alt text from the profile picture is my name, Tibor Colas. So that actually feels quite good, except for the fact that Tbor Colas is also written right next to this. So if you're reading this with a screen reader, it will say an ongoing effort. T-bocodas, table codes. So there really is no reason for this to be said twice. So I guess it's for you to decide do you want to have alt text that provides a bit more flavor, maybe, and describes the profile picture in a bit of a quirky way, or just not have it at all if it matches content that's right next to the image. And yeah, the pressure in Google Photos, that's the alt

Speaker 1: text I set for that image. And well, it's not the best copy to start with, but also this image has nothing to do with the actual content of the post. It would just be better for me as an editor if I could just say, well, for this one, I don't want any alt text at all. So again, quite an easy fix. Make sure that each image has an alt text field next to it in the CMS. Make sure the field is optional and appropriate so that people can elect not to have alt text if the content doesn't require it or if the content around it already describes the image. And yeah, again, this is definitely something we're looking at addressing in WhiteL core and yeah, definitely something that I'll be asked to fix in those websites in the meantime. Also want to mention something very quickly at this stage, which is that none of those things whatsoever are front-end

Speaker 1: development. So there is this conception that accessibility is kind of a front-end concern, whoever makes the template But all of these really are about the content model you have for those pages, making sure that there is the art text field where needed in the models and that is either optional or monitory depending on what is being displayed. Um next one, embed titles. I think you can see where this is going at this stage, so I'll just uh switch to it very briefly. This is what you see as a commander user with what gets announced, which is essentially just an empty frame. So by by default Our embeds in Wagtail always have a title attribute that gets pulled out from the embed provider and added to the iframe so that screen reader users can know what the frame is before they interact with it.

Speaker 1: And for some reason, sometimes it just doesn't come through. I think this is something that's actually fixed in uh in code write CMS, just not in Wacta itself. And yeah, it does need to be fixed. So here, well, we either need to look into why the embeds don't have a title in those cases, or make sure that when you implement this, that your editors have a title field directly on there And there's an open issue for that as well. Heading levels, so this is a live demo of a tool called Totally, which is packaged as a Wagtail extension called Wagtail Accessibility. So you can see on the right here I have the heading outline of the page. And it's very important for three users that this heading outline makes sense so they can navigate the page easily. So you can see here I turn this on

Speaker 1: and I can see for the whole page what the outline is like and I have one H1, H2, H3, that's great. two three three three blah blah blah and then right at the end of this I have another H1 for some reason and then more H1s. So this really isn't isn't good. There should only be one H1 on the page. And this kind of tool is useful because um Even though ideally it would be great for developers to catch this because this is all based on the templates, it's still valuable for editors working with uh with CMS to have access to this. So they can also hold the tech team accountable and say, hey, I'm spending lots of time optimizing my outline in the CMS. So why isn't that working there as well? And for their work too, when they select a heading level for their content in a blog post, they can see the results of it right there,

Speaker 1: right away, as part of the preview. So yeah, for for um developers, Wattel makes it very easy to configure which heading levels are available in the CMS, which helps reduce those issues. So do make sure of make sure to use those resext features. Same for Streamfield if you have a custom heading block in Streamfield. And yeah, keep your templates in check as well. Another quick example of this, so what I meant by by all of this, so here there is some validation of this heading field. Why is there validation you might ask? Well this is because the field is empty at the moment and I tried to save the page with an empty heading heading field. And uh if this worked It would actually make it so stranger users have an empty

Speaker 1: heading in the in the uphindler documents, which as you can imagine isn't helpful at all. So that's the type of feature that is definitely back-end work But great to have the people in charge of this kind of modeling work aware of those constraints and making those decisions. And yeah, definitely worth checking whether your site has this in place or not. And um for rich text, the solution isn't as neat currently, but you can always uh hide empty heading elements with CSS should you need to. And hopefully there'll be better APIs in Wagtail to do this more easily in the future. Yeah, I have a few other issues listed on here, but I won't go into the details too much. There'll be some documentation coming up for all of these in the White Hell docs.

Speaker 1: All right. So yeah, we got all the negative stuff out of the way. I have all of my pull requests to change to send out. Now let's look at some actual good things we can make happen with Wagtail. but will make your sites more accessible. So first let's look at a few things that will make this better for content editors and what will make the content better. So this this extension I just showed you totally this is this is built in this is available as a third-party package for XPT Um yeah, it would be lovely if accessibility for Wagtail was just something you could install, but I at least you can install that, so do do it. Then something that's very simple but worth keeping in mind is just that you can use help text throughout your page editing UI in your fields just to provide ref

Speaker 1: relevant information for content authors so that they know kind of what is the expectation for accessibility. So a great example of this comes from the NHS in the UK. They they have a very uh very great uh design system that they use on on a lot of their projects and they have a white tail version of this where they have some of their components as as stream field blocks in this case and here for their uh do block You can see for the heading level, they have some very helpful, simple simple but still helpful uh head text and also uh a notion of which values are allowed. So this is it can be just as simple as that and still very useful. And yeah, if you're into design systems and uh components and how to make this work with Whitel, uh definitely check their work. They are at the forefront of this, I believe.

Speaker 1: And uh yeah on the same note but slightly bigger, uh since Wiktep 2. 7 I believe we also have a help panel, which is essentially again just more help text in uh pages in UI. the help panel uh is completely free form html so this is this one here is just a uh wireframe of what it could look like if you if you spent some time to make this work and how you could actually embed your organization's content guidelines directly into the page with this uh very very simple feature. So again it's just a wireframe just so you can see what you could use it with. Another one of these that's available already is Wacket Reading Level from VIX Digital in the UK. This is a very simple plugin that displays the reading edge for content in rich text fields So just based on the sentence length of the feeds

Speaker 1: and the word length, uh quite quite simple when you think of it, but it's really good to have this kind of feedback right as you enter content in the CMS. to make sure that it uh is up to your organization's standards. So worth knowing about and trying out. And on this topic, I would be very keen to make more of those types of rich text experiments happen So another example of this is this kind of spell check that is aware of your organization's uh content guidelines again, and maybe your organization has a list of words that you should try to avoid. And this kind of helps you highlight those words and make sure that people are aware of this. And of course it won't replace spell check from Grammarly or Word, but this can be made Wagtail aware and aware of your

Speaker 1: organization specific situation. And another one of these I really like is this sentence length highlighter, which literally just displays uh a color for each sentence based on this length. And you can see right away with this which sentences might be too long and might need to be broken down further for readability. So yeah, we'd love to make that happen. It's not a package yet. Now back on to developers. There's lots of things that are good for developers as well. Quick word on this. I actually wrote a blog post about accessibility testing tools for developers quite recently. So I'd encourage you to look at this post if you're interested in this. And right now only focus on the things that are the most white tail specific

Speaker 1: and yeah the things I didn't cover in this blog post. So first one is this package called Django HTML validator, which makes uh HTML validation uh available as a kind of Django-friendly way. I'm not too sure where people stand on HTML validation these days, but to me it really is kind of a nice, easy thing to do. And uh it practically it catches about 15% of accessibility issues. You might think this is quite low, but at the same time this is kind of a technology that we we have available for pretty much any kind of web development tech stack So might as well make use of it. And uh yeah, this validator is using the official W3C uh new validator, which also comes with a command line tool. And you can see the output of the command line tool that I use for my audits

Speaker 1: uh but at the bottom there. I'll skip through this quickly, but you can kind of see that this is this is very basic stuff, but still worth checking for Yeah, so on that note, another thing I really like to suggest for projects where this is relevant is to set up static analysis on your code that checks for common accessibility issues. So this is quite well established in the in the React and View world and kind of the modern front-end stacks, so relevant for headless sites first and foremost. They have these ESLin plugins that contains literally tens of different rules just focused on making your your templates, your markup accessible. And Style Int has a has a plugin that does the same type of work for styles. Um thinking of for example uh preventing you from disabling uh

Speaker 1: focus uh sorry the the outline for when you focus elements on the page. Which is very easy to do and forget about and is very problematic for people who rely on it for keyboard navigation. But yeah, this is this is not too close to Django templates. So One of my secret uh lockdown projects has been to work on this for Django templates and and uh Ginger. So the curly lint is an experimental linter for those templates I've been working on for the last Yeah, three or so months. I I would definitely recommend giving it a try. So it's peep installable and this is aware of your Django templates and the HTML within them. This passes the templates and this has rules for accessibility So currently I have made about seven or eight of those rules

Speaker 1: and essentially yeah it passes through your templates with a parser that's made for for those kinds of syntaxes. and then checks the the uh abstract syntax tree of your templates for command patterns that are not recommended, like the Django forms rendering one. So yeah, if you want to leave on the building edge, go give it a try and write on your templates and report back to me where it fails. And uh last one I would like to finish on is uh to learn how to use a screen leader. This might might seem like a very basic one, but I feel like there aren't enough developers around who actually know how to use these. And is is much, much easier than a lot of people would think, especially on the Mac with voiceover. So here I I have the list of the

Speaker 1: three shortcuts that you need with voiceover to make the most of it. So those three shortcuts, open and close voiceover. Control if you want to make it stop uh saying things and then control U to open the rotor, which is essentially the navigation menu of voiceover. from which you can check headings, tables, images, links, landmarks, iframes as well. all exactly like a stranger user would see them. So I I guess as as as good as it gets, it's really that easy. You can just navigate this menu with your keyboard arrow keys. It's very easy. And yeah, all it takes is those three keyboard shortcuts. So open Safari Try those shortcuts right away and yeah, see on your website how much information you can get from them.

Speaker 1: All of the things I had shown earlier about the alt text for images and iframes, that's something you can see for any website in like two seconds with those shortcuts. Yeah, so onwards. Community wins. So I'd like to uh end on an even more positive note if this is possible. and call for a bit of a cultural shift if they if there isn't one in the works already. I really think we are in a good place as developers to kind of be part of the solution here. So what do I mean by this? You here watching this talk, you can be the person on your team who advocates for those issues to be fixed. I know a lot of us do some activism on the side And a lot of us care about uh inclusivity and accessibility.

Speaker 1: Uh it matters for literally all of the websites we build, no matter who they are for. And there are there are very well-defined standards here. It's not something that's completely uh arbitrary and also really available tools that you can just uh start using right away. So you can be the person who knows how to use those tools and who knows about screen screenaders software and teaches people how to do it. There is this very good article I would recommend from Alistair Part about this very topic of activism, accessibility, and inclusivity. Which really resonated well with me. And for Wagtail, well, Wagtail can definitely be a CMS as part of the solution. So there is this very uh well-established project from Web IM. It's called the WebIME million. They keep track of the accessibility of the w

Speaker 1: of the of the world's uh most popular one million websites home pages. And the numbers are frankly terrible. Uh I believe that it's about 98% currently of websites that have issues on their homepage. And that's just the issues on the homepage, just the ones that automated tools can pick in a matter of pick up in a matter in a matter of second. So there is definitely room for us to do to do better here and uh I guess for Wagteil in particular there is room for Wagtail to do better here and It would be great to see some correlation between people using Wagtail and their website being more accessible because of it. So quite briefly what this means is What is essentially having better defaults? So all of the things I showed about before, having this fixed, having better starter templates for people so that when they start a Wacta

Speaker 1: site, they kind of have a few things taken care of for them. and having better documentation as well, just seeing like, all right, as a WhatsApp integrator, here are all the things you should be aware of to make sure that your website is as good as possible. So yeah, there is there is room for all those things to happen. And um yeah on the whitehead side we now officially have a dedicated team focusing on this uh that we started about a couple of weeks ago. There's three of us currently I definitely welcome more people being involved with this regardless of their skill level or interests. We are on Slack and yeah, we'll be working on making all of those things happen. So welcome everyone's input on this. And on that note, yeah, thank you. Thank you for going through this with me. And

Speaker 1: sorry for the people who have worked on those websites. And yeah, let's look at uh fixing some of those things together during the sprints. And I have some time for questions.

Speaker 2: Great. Thibaut, I actually do have a question right away about images specifically. So you had mentioned that Wagtail is talking about adding alt text um to the image, like um outright. Um I do wonder how um how that would impact the internationalization or multilingual efforts, because my understanding is that Alt text should probably be translated as well. So would that be uploading duplicate images then if you have alt text? Or

Speaker 1: that is a very good question and something I didn't cover in this talk. I will always recommend as much as possible for the alt text for images to be a field that's sitting alongside the image where it's used on the page rather than being defined at the image level Because the call the call of whether the image is decorative or not, or of what content should be used to de rep to replace it when people can't see the image, that should be made as part of creating the page rather than as part of uploading the image So in that case, if you have the Alt text field directly in the in the model for the page, translation is just taken care of as well. Checking on Slack, not sure if there's anything that comes if anyone has a question right away

Speaker 1: live.

Speaker 3: There's a question from from Vince, but maybe Vince you can ask it. I

Speaker 1: can't hear you, Vince.

Speaker 2: Vince, you're muted. Or something I don't know.

Speaker 1: Yeah, I'm I'm I'm looking at your question, so I I can I can pick it up now actually. Um So automatically naming media titles so the images based on the file name when uploading them. So yes, that's uh That's is really bad and that's what some of those RFCs and issues fix. So I believe one of these is about uh improving how the uh title extraction from the image file name happens so that just so that it's a better title no matter how it's used. And then some of those RFCs are about changing the behavior of where the as text for the for the image template tag comes from. So it comes ideally from something that's not the title, whether that's a that's um

Speaker 1: field on the image model or something directly on the page. I believe we're also going to be changing a recommendation for all websites to now start with a custom image model So it's easier for people to add this to their website should they need to. I hope this helps. Anyone else for questions?

Speaker 4: There is this question from Tim White and he asks, um how does a React affect accessibility in the Wecto UI?

Speaker 1: So um specifically for the Waxel admin, I would say it it doesn't too much and or it might be a benefit. So the The problem with React UI is that they tend to be quite dynamic, which means that if you maybe do routing client-side with React, well stranger users might not realize that the page has changed and maybe the UI completely is different and they don't know where they are anymore. But for what we use Wattel in in uh sorry for what we use React in Wattel currently it really should make our lives easier just because of the the better tooling that React has. And um uh React has this cooler third-party package called React Axe That allows us to, we have it in WattLed actually. That allows us to check the accessibility of our React components every single time they re-render

Speaker 1: in the admin. So as a developer working on those components, you can check that each change React has made to the page is accessible. So yeah, fundamentally it's equally as good, but in terms of developer experience, the tooling is much better. So I actually think it's a potential improvement. But yeah, there's definitely some different config considerations to be had if you have something that's a single page React app compared to uh uh widgets here and there.

Speaker 4: And I have got a question myself. If people would like to contribute to making Wacto more accessible and especially during Wacto Space US Uh what would you recommend to work on?

Speaker 1: You couldn't have asked it better, so I'll switch tabs I have been uh looking for uh a pretext to merge this pull request. Not to merge it, but just to open it. So this pull request is the documentation guidelines I had maybe been mentioning about how to make uh websites accessible out of the box and what to look at in Wagtail. So right now I would love to get some feedback on some of these, just to have them documented better, and then ideally to have them fixed. So yeah, definitely this. And I will click Create pull requests now. Thank you, Quinn. Uh any other questions? Alright, so I guess one more note before I

Speaker 1: I head off is um about uh React. Uh I was talking about the Web I million. There's actually one tech stack that uh has the lowest number of issues overall, and that's Catsby. So Gatsby is React based and just because of their overall focus on accessibility, they have managed to, I think on average, their Gatsby websites in the Web I'm one million have 50% less issues than than the average websites. So yeah, worth keeping in mind. And yeah, on that note, thank you, and I'll follow upon Slack