Making Wagtail Accessible

Speaker 1: Hi everyone, I'm Thiba. My pronouns are he, him. I generally thought it was a mistake that I had given you more time than others and I was just about to explore it shamelessly, but it's on purpose, so thank you very much. Um I'm really glad to be here. This is the first time I'm in the US and also the first time I get talked about accessibility, which is a topic I care a lot about, so I'm super pumped. I work at Touchbox as a developer and I'm also part of a core team. It's been about two years now. I've worked on DraftAil, the new editor since Wiketail 2. 0, and a few other things here and there. Today I'll talk about what Tom has referred to this morning, some work we've been doing recently with the government in the UK to make Wagtail accessible, and it's still a work in progress. But it's a big theme for us I think going forward. So I'll talk about what we've done over the last three months and um

Speaker 1: maybe a bit further ahead Um the slides are available. I've spent lots of time making lots of links in here to very good resources, so do check them out. So , bit of an announcement to start with. Since Wagtail 2. 6, which is due in a couple of weeks, we now have official compliance targets for stability. We are targeting WICAG 2. 1 level AA, which is an international standard for accessibility that is basically used in a lot of countries' national laws to define how accessible sites should be, either public or private sector. But it's the the most popular standard basically. And yeah, we've worked on trying to get WhiteL

Speaker 1: towards that standard. We are not there yet, but thanks to the work commissioned by the government in the UK, specifically the CMS team at the Department for International Trade, we've made quite a lot of progress and we've fixed issues with found That's more issues than we fixed, but still. And we also have quite a defined process. So I'll talk a bit about what that process is. And if you want to learn more about all of this, the release notes for Wacy 2. 6, which is due 1st of August. will contain much more information. So first off, why do we care about making Wagtail accessible? I think it's something that's quite important to address. Kind of a narrow reason would be just because it's not accessible at the moment, which means it's difficult to use for people who actually rely on assistive technologies to use the CMS, which is bad.

Speaker 1: We don't like things that are bad Um so there is this guy who opened an issue about a year and a half ago and he's blind and uses NVDA, a screen reader, to use the CMS. And he basically told us, hi, I love Wagtail as a developer, but as a user, it kind of sucks, sorry. And I think it's quite important we address that. One of the other reasons that's uh quite important to bear in mind, but is a bit negative, is that uh if you're comparing between CMSs, you don't want to pick the one that's not accessible because again there are laws. in countries now that mandate sites have to be accessible, not just public-facing sites, but also internal tools. And you don't want to get sued. So in the US there is section 508 which specifies what an accessible site is and which sites should be accessible

Speaker 1: And in the UK, there is the much less catchy public sector bodies, websites and mobile applications number two accessibility regulations 2018. Which is derived from Wikaic 2. 1 as well and comes from some EU directive. Don't know what else to say about that. Um so those reasons are really helpful to have in mind, but I find them a bit negative. So I've also tried to find some positive reasons to make websites accessible Um and just to care about accessibility in general, not just for Wagtail. The first one is that I I think we we all want all users of Wagtail to have a great experience, no matter their skill level, and also of course no matter their abilities

Speaker 1: It's kind of an obvious thing to say, but still worth stating. And in the workplace in particular, we don't want people to feel left out because they can't use the CMS can't do their job because they are relying on some assistive technology that Wattel doesn't support. So assistive technology if you don't know what it means It means technologies that people use to access websites when they have special needs like a screen reader, Zoom software, voice recognition, and so on. So to summarize, we want Wagtail to provide an inclusive experience. So what I mean by inclusive, if you think of our general concerns for making websites, performance, mobile device support Why we care about this is that we want people to access our sites and to make the most of them regardless of how performance of a device they are

Speaker 1: they have, what type of device they use, whether it's a phone or desktop. And for Wagtail as an example, the reason why we uh have Wagtail support multilingual interfaces in the admin, the reason why the admin is available in French, Spanish and so on, is that we want people to be able to use it without having to know English, which It's kind of an obvious thing to state, but it's the same story here. We don't want people to have to have special abilities to be able to use the CMS. We want it to be inclusive So yeah, just more positive things to look forward to. And one I didn't mention, which I think is quite important, and I disagree with Tom on that point compared to what he said this morning. is that even if you're not using accessibility technologies, most likely the changes we are going to make for accessibility are going to improve the

Speaker 1: usability of the CMS for you as well. So I think it's something we found out over the last three months which even if you don't benefit directly from the changes for screen readers, for example, you'd still find the CMS easier to use. And again, um this is not just about wagtail. So I'm talking about wagtail because this is what our client uh DIT used internally. But if you're building any kind of intranet dashboard a custom Django admin that's meant for internal usage in your organization, you still you still shouldn't compromise on accessibility even if there is a very small audience. it still is important that they can all make as much of the experience as possible.

Speaker 1: So let's have a look at what we did over the last three months for this client. We isn't just me, there was quite a big team of people working on this. So lots of people from Torchbox, lots of front-end developers, one user experience expert Lots of people from the Wagtail community that were very kind with their time to review pull requests or to make pull requests and people in Slack as well who gave us lots of feedback along the way. So uh when you start an accessibility uh compliance project, the first step is to have a good target. So what standard of quality do you want to aim for? And here the answer is WECAG 2. 1AA level. So WCAG has three levels, AAA and AAA

Speaker 1: , from um least accessible to most accessible and we chose AAA because AA sorry because That's what the law requires and also going all the way to AAA would mean quite drastic changes to the admin to make it compliant. didn't feel realistic at the time. And again, the idea with this standard is that it's international and it underpins many national laws. So if we do aim for that, Ragtail should be compliant enough for lots of countries, not just the UK. And I find it helpful with this kind of project not to just have a standard target, but also have targets for actual technologies, devices or here screen readers and so on

Speaker 1: that people will be using to to use the site so people developers know what to test on. So we made some targets for screen readers, NVDA on Windows um voiceover on macOS and also beyond screen reader so Windows Magnifier and Mac OS Zoom. If you know a bit about accessibility you might uh have heard of these as people of technologies that people use as well. It's actually more common for people to rely on this kind of zooming software if they have a special need than on screen readers. So there are more people using these two magnifying software than the screen readers above them. And same for speech recognition, it's also quite common of a tool that people use to access websites and also some mobile screen readers because there definitely are lots of people using screen readers on their phone.

Speaker 1: So this specific peak of assistive technologies They come from a wonderful survey by the GDS in the UK. It's kind of the equivalent over there of 18F here. So they look at digital services across all central governments. So they did this wonderful survey, and I only know one of such surveys, you should definitely check it out, where they basically looked at the most common assistant technologies that people use to access gov. uk, so the main government website in the UK. And yeah, I won't have time to show it, but you should definitely click on that link and check it out. So these come from the survey and um They are also there's a bit less here than what the survey contains just because we also want to have realistic targets. So the idea here is to set targets that people will actually be able

Speaker 1: to test on when they contribute to Wagtail. So we want to be realistic and pick things that they can actually install and know how to use without having expert knowledge. So that was for the targets. Then to try and help us make Wattel compliant, we picked a lot of tooling that can help checking accessibility. I don't think I want to spend too much time on this, but basically we chose AX as our accessibility accessibility testing tool. AXE is a rules engine, so it has rules that allow you to check for compliance against specific standards. And the reason why we chose it is because of this other great GDS resource, which you should also definitely check out, which is a comparison of accessibility testing software

Speaker 1: that compares for each of them how many issues they find in a site. And AX scores really well. It's not the best of them all, but it also happens to be free and very well integrated into other software And it also has a very low ratio of false positives, which means that if Axe does report something, it most likely is an issue with your site and not just something that might be an issue. So then building upon Axe, we have a browser extension accessibility insights so that everyone can install in in Chrome, Firefox, and Microsoft Edge, I think. React Axe is an integration of Axe in our developer tools and Pali is a way to run Axe and other tests from the command line. And I highly recommend all of them

Speaker 1: One more note about tooling. Oh, that's my computer. I'm going to do some live demo later on that's why the sound is on. So we we also made a big accessibility test suite with uh more than a hundred scenarios in it and I also had um beforehand a visual regression test suite, so comparing screenshots of the white ed UI before after our changes to make sure there were no regressions. And these were enormous investments. So yeah, good to know about. You should check out my repository if you're interested in them. I could make tons of talks just about that Um so we have the targets, we have the tooling. Next step is to actually go and do an audit.

Speaker 1: And um in order to have an audit of a site, you need to know what to test on the site. So the first step was to do a massive spreadsheet that contained all of the parts of Wagtail we cared about. So that's the left-hand column over there. And then for each of those parts Because there were many. We tried to figure out which ones mattered the most based on whether they were used in this particular CMS or not, by whom they were used. If a part of the UI is used by the ra by a writer, it's more important because there are more writers than admins of the sites, for example. And also how often They would use the UI. So if a part of UI of the UI is used by a writer every day, then it's definitely something we should focus on. And then for each of those views, we also try to think of the specific states they could be in.

Speaker 1: So for example, if you look at the login and password reset views. It's not just the form being accessible, but also the error messages you get when you enter an email that's not valid, that should be accessible. And if your UI has some loading or success states, it should also be equally as accessible as the rest of the page. So that took a lot of time and we ended up with 340 different scenarios to test And we ended up testing 190 of them. It's quite a big discrepancy between the two. So that's in part because some of the UI wasn't relevant. in other parts because it was hard to test automatically. And we found 336 issues. So it was Enough already for us to have plenty to do over the last three months.

Speaker 1: So it's also why I didn't try to bridge that gap too much. So 336, it can sound like a lot. It probably is a lot. There's a few reasons why the number is so big. First, there's lots of issues. Second, there's lots of duplicate issues. So for example, if you have a UI component that's reused between multiple pages. and it has an issue, issue will be reported multiple times, and it's not always easy to de-duplicate that. And there are also some false positives, still a couple. And on top of those 336, we also had some manual issue issues that had already been reported to Wagtail and we tried to address at the same time. Yeah, that that was a lot of issues. So let's look at all of the issues. Um I I personally find it a bit depressing to look at big lists of issues like that, especially when it's not code I've written myself.

Speaker 1: Don't feel very comfortable saying like this sucks and that sucks. But it still has some educational value, so we'll still try and do some of that, but let's try and make it in a more fun way. This is the image Google Photos, Google Photos, the photo storage software has this feature where you can type a keyword and you will try and search pictures that match the keyword. This is what it gave me for the keyword depression So not sure if it's a feature or a bug, but thank you. It does help. Um yeah, so Let's not look at the all of the issues, but let's do some live auditing of Whitetail together. And just to make it a bit more fun, I have some prizes. Stickers.

Speaker 1: I have butterfly stickers. I have very exclusive stickers from Michaelspace Minsk in Belarus. I have some Django Girl stickers that I'll be giving away if you give the correct answers. And I have set up a live instance of the YTL demo site with the password and username here. If you can find an issue on the site that I haven't found yet You will get a very special sticker from a Node. js meetup I organized in Finland that was the world's northernmost Node. js meetup. No one has it All right. That's your

Speaker 2: password use for everything.

Speaker 1: So let's first look at focus indicators and see what issues we can spot. So I ask you three questions. We first look at a good example of what a focus indicator should be. Then I ask you three questions. Uh whacked head space and I'll put it in the slide. I'm glad to see that you are actually. So forgot indicators, I start with a good example, then looking at work there will try to identify If we can spot where the keyboard focus is, if we can spot parts of the UI where there is no focus indicator at all, and how many types of focus indicators we can find.

Speaker 1: So let's look at the good example first. This is the great. gov website in the UK. If I press tab, I will skip to main consent link that appears. It's quite clear where the forest is on that pink. If I press tap again, you can see the forest moving here, there, then So pretty straightforward, it's just an outline and it shows you where the focus is. That's a great example of what a focused indicator should be. Now let's look at Wagtail. So we're looking at Wagtail version 2. 5. 1, which is what was the latest version when we started our work. We fixed that since then. But this is before we fixed it. So let's press tab and let's see if you can follow where the focus is. Oh, can you see something?

Speaker 1: Might be a bit hard to follow, right? Okay, where is it now? Oh there's way too many of these. I don't have that many stickers. So let's say fast this first. You can come clean your stickers afterwards. Okay. Let's try another one. Where is it now? Pages. You just use it according to your alpha. Damn, that's smart. Yeah, so that's actually things you cannot see on the page, which is A bad thing. You're meant to always be able to see what the focus is. So we found an issue, which is that the menu swallows the focus. Um then we are at the top here, so that's another type of focus.

Speaker 1: Then we are on the I think we are on blue around there. Yeah, so yet another uh hoping you keep count of how many stars we have here because Still quite a few already. Um I think we're on the tabs now. Oh, that's one we can easily see on the fields. Where is it now? Who says your choice? Yes. I think it might be on change image, but yes, it's either the two and they are not pages, so that's why there is no URL at the bottom. And now it's on edit this image.

Speaker 3: Yeah, and testing against the projector.

Speaker 1: Yeah, so yeah, not that great. How many different focus styles? Two, four? Okay, four or five. I'll I'll give it to you I think. I see it didn't count, but uh that that sounds about right. Um Yeah, so that's the type of thing you do while you audit Wagtail and that's why it's a bit depressing because you would think it's a basic thing to do but it hadn't been done yet and now it is Okay, up next, tab stops. So something that's quite important when you move focus around the page. is to have an easy way to move quickly to a specific part of the page. So there is a measure called Tab

Speaker 1: Stop, which is basically how many times you need to tab to go to a specific bit of content. So we'll turn my TapStops extension on on the CFPB website. That's the good example, just for reference. So We start on skip to Bain content, that's tab number one. Then we add the languages, number two, three, four So that's exactly what you want. These links are the ones that people will be most likely to click on when they just arrive on the site. So it's great to see them at the top. And it's kind of in a logical order. Like visually these elements that are next to one another, then it moves here to the actions in the menu. So submitting a complaint and the search it kind of makes sense So one issue then it moves to something that's not visible, which is probably the search field, but you know

Speaker 1: still it's quite a good example. Then it moves on to the main logo and the navigation. Great job. That's a great example. Now we can look at Wagtail. So two questions here this time around and it'll be much trickier than the last ones. Question number one. How many tab stops to the title field? It is possible. And question number two, bonus question. What will be the first element on the page to receive focus?

Speaker 2: The bird

Speaker 1: Wish really should be uh It really should be a skip to main content link, but we don't have that yet, so it could be something else. No, sorry, no, hang on. This is my setup that's wrong. Uh I need to refresh tab stops. Yeah. Oh. I wonder why. Then it moves to this thing that's invisible. So that's that's not like what I said earlier, it's important to be uh elements that are side by side and usually top to bottom. So that's kind of as worse as it can get, I think.

Speaker 1: It might be worse if it was over there to start with, but yeah, let's not push it.

Speaker 2: Why is that the version one like added in in the code. This is because where it's structured in the each

Speaker 1: mouth? No, this is because of tab index equals free. So someone thought it would be a good idea to have this be the third element that would receive for us on this page.

Speaker 2: So someone did make a pass?

Speaker 1: I think it was uh not a conscious decision. I think it was a copy-paste bug, but no no one checked. Then it moves to the bird and it goes down the menu so search field, search field summates. pages, red categories, and something weird happens for a while. Any guesses for tap stop on the title field You say 34. I think it's 35, so you get it. Um so yeah, what's happening here is that tab is going through, the menus are not open Which is definitely not what you want. It might be okay if you're not a sighted user if you're blind, but if you're not blind, you want the focus to be visible.

Speaker 1: Um yeah then um the banner kind of makes sense the tabs and the title field thirty-five congratulations you you can never guess that. Um yeah, so what should we do about this? The obvious answer is to have a skip to main content link so that this moves from 45 to Don't know 10 age probably. And also the the menu shouldn't swallow focus to start with. Yeah So it's pretty obvious what we have to do. It's not fixed yet, unfortunately, except for the safe draft one. We have open issues about all of these. And I'd love for someone to work on this during the sprint. Um yeah, no one guessed what was the first elementary

Speaker 1: C focus because it's impossible. Which is exactly what the problem is Okay, third test. I'm going to open a page and the page will have an error message on it. Who can see the error message first? Go Oh, it's

Speaker 4: not meant to circuit document.

Speaker 1: Yes. I mean it's quite you you would expect it's quite easy to spot because error messages are meant to be red and it's red, so it's easy to spot, right? Except it's uh on uh yeah turquoise background and we seem to be colorblind right now, so there actually is no way to see this. And even if I switch the color back on Actually is still pretty hard to see. So yeah, the takeaway here is don't style your error messages based on color alone, because then if they are used in the wrong place, they won't be visible And uh Naomi, I think it was you who was the first to spot it. So you get it got a sticker.

Speaker 1: So the last um live audit I have is to do some voiceover testing together on WattL 2. 5. 1. Um I've never done voiceover

Speaker 5: on stuff.

Speaker 1: live um voiceover testing before so I hope it goes well. You have the sound that a deaf person not a that a blind person will hear when they use a screen reader. You also have the text that is read out loud at the bottom here And let's see what we can figure out together while using this. So if when using a screen reader,

Speaker 5: v dot two point five point one. You always work early on a link.

Speaker 1: some indication of where the focus is if you're cited. So here it's at the top around the white table. I don't know if you could catch that but when it arrives on that link it says white table v2. 5. 1 So it's perhaps trying to convey that this link is taking you to the white tail release nodes, which sounds a bit funny. So that's a link to the dashboard. That's the first issue we're going to look at now.

Speaker 5: Search

Speaker 1: and

Speaker 5: you are currently on a text element, search search text field, blank, F search button.

Speaker 1: So here it said F search. Does anyone know why? Why? Oh because of the icon. Yes. Major issue, which is now fixed as well, hopefully. Not fully, but uh somewhat somewhat fixed.

Speaker 5: Navigation.

Speaker 1: Okay.

Speaker 5: You are currently on navigation inside web content. Link. V pages N.

Speaker 1: Okay. You are currently on the link. So V is because of the icon, pages is because it says page and N is the other icon. So that's the link to the page explorer. So if I click that, the explorer will open.

Speaker 5: Press link. V pages N.

Speaker 1: Correct Except the forecast didn't move to the explorer and actually is no way for it to move to the explorer. You actually have no way to know that something happened which is bad and I made that mistake. So I'm very happy to share it now and it's fixed now as well in YTL 2. 6. Um

Speaker 5: link. Bread categories N. Yeah. Heading level 22 items. Bread categories. Link.

Speaker 1: So now we're moving inside of the Manusel and Visible, which is also not good, but we talked about that before So let's do something else which is to go to the rest of the landmarks.

Speaker 5: Navigation banner links. We move to the

Speaker 1: top level banner of the page.

Speaker 5: Visited link. Private link to more

Speaker 1: edit button maybe the button. Maybe to the tabs.

Speaker 5: End of link. Content.

Speaker 1: Okay. You are currently on

Speaker 5: link. Promote. So

Speaker 1: these aren't really links, they are just buttons that trigger the tab, but I guess you could still un understand what they are. Let's click on that. Okay, so it takes us to the right tab, that's great. It announces what's in the tab, great.

Speaker 5: Schedule publishing group.

Speaker 1: Okay.

Speaker 5: You are scheduled publishing.

Speaker 1: Okay. You

Speaker 5: go live eight slash time.

Speaker 1: There's some repetition, which is something you probably don't want. It's not a major deal breaker. Announcing the feeds label. Great.

Speaker 5: Seven. You are currently on a live date slash time. Edit text.

Speaker 1: And remote currently field, which is cool. And then this opens. And again, there is no way to actually move it. Excuse

Speaker 5: date slash buildate.

Speaker 1: Bit of a major fail here. So yeah, that's why I said it was a bit depressing to look at those things because it actually is lots of issues. Based on the changes we made in WattL 2. 6, some of these are fixed already and should at least be possible to move around the WattL admin much more easily. Then there is lots of cases like this widget here where there's still lots of work to do. And you could argue for this really particular day voice of easy way for you to just enter the dates manually. It's kind of a good fallback to be able to do that if you know the magic incantation. But still if you want WattL to be compliant, date picker widget should be compliant as well. Yeah, so that's depressing enough. So now let's actually look at what we fixed and not just what's broken.

Speaker 1: We fixed many things. There are 24 line items for accessibility fixes in the next release. which I think is probably the most line items I've ever contributed to in a maxted research myself. And if we look at the number of issues sorry if we look at the number of issues From here three three forty-six this went down to hundred and seventy, which is Yeah. How how place? I think it's not too bad. We can still do much better. The good news is that most of the ones that are left actually are things that don't matter as much. So lots of duplicates. Lots of things that are on new black tail style guide only rather than the UI itself.

Speaker 1: So yeah, it's not it's not all too bad. Um sorry I'll move back to the results. So types of things we fixed. Um color contrasts, we now have compliant color contrast from between the text and the background across the whole CMS. This is something that Martiki worked on at the last Wagtail Space USA, I think. Great. Okay. Well, thank you for starting this. And I think it's now over, which is wonderful. Increased font size across the whole site as well. This is very subtle, but should be valuable for everyone Added focused outline styles for the focus indicator, which is super important. Added more landmarks and refactored the heading structures so the

Speaker 1: pages are easier to navigate. That's also capital for us, sorry, that's also very important for trimular users. Added a lot more contextual information to links, so just so the links make more sense without the context, the visual context of the pages around them. Fix the icons implementation more or less. So I say more or less because someone in the room here has has a better fix for it that they are working on. And I hope we get to work on it together during the sprint Um fix the focus stop moving to the Pages Explorer. And if you want to see some of those fixes in action, I have a YouTube video that basically shows what I just showed you on Wacket 2. 5 but with 2. 6. And there is a release notes as well. What's next? So the thing I really like to see in the future of Wagtail, I think the most important one would be a bit of a cultural change in how accessibility is handled.

Speaker 1: So it's great to have time and be commissioned by a client to do a one-off push, but it would be much better if accessibility was part of the design and development process for current and future changes to the UI. And that just makes it much easier if it's actually a requirement that you consider while you're designing a new bit of UI and implementing it. So the company that builds ACTS called DECU, they have a term for this, they call it shift-left accessibility testing. So the idea is if you think of the structure development process from architecture, design implementation QA testing release from from left to right. The idea is to move this type of testing and concern towards the architecture bit and the design bit

Speaker 1: so that you don't end up at QA or release time with the big backlog of fixes you don't know what to do about Um yeah, and I I think what I would like to see as well is just uh having more understanding with workable contributors and having more much clearer information for them on what it means for a UI to be accessible and what our standard is. So not just this is what accessibility is, but having some very clear guidelines on if you take the steps X, Y, and Z, then your UI should be accessible. So that means documentation, tooling and talks like this as well. Yeah, and we this is still work in progress. So we have a we have an RFC uh request for comment open for Wagtail about making Wagtail accessible.

Speaker 1: So this is a very long GitHub issue where I talk about things we could do or and or should do to make sure that Wagtail that accessibility is part of the process for Wagtail So you're very welcome to look at it and comment on it. We also have a very big backlog of issues we know about. So something I'm I'm very happy about with this one one three months project is that even though we didn't get everything fixed we at least have backlogged all of the issues we were aware of. So from now on it should be pretty easy for anyone who's interested in it to pick it up and work on those issues. And yeah, it would be great to work on this together during the sprint Um that's it for me.

Speaker 1: Questions, anyone? Yeah.

Speaker 6: Um I'm curious, do you know any tooling to do this sort of audio check with everyone can have to at the end of time? Like as part of the full report?

Speaker 1: You mean during CI, for example? Yeah. So let's take a few steps back React Axe, you can have it running in CI if you have tests for your React components. And Pali is the one that's meant to be used in CI first and foremost So CI for everyone that might not be aware of the term is continuous integration. So it's what happens when you get a pull request to a project. Usually there are some tests that run for you. Pali is a way to run those tests for facility checks. So Pali integrates Axe and HTML code sniffer, which are two different engines, and it has command line interface, that's general purpose, and then some command line interfaces that are meant specifically for CI So for example, for projects that are just like public-facing websites, it has a command-line

Speaker 1: tool that supports taking a sitemap Uh so it's like map definition that has all of the URLs of the site and it just crawls through all of that and reports you all the errors. And yeah. Sorry.

Speaker 6: What's the format that's reporting? Is this drawing?

Speaker 1: There are multiple formats. So there's HTML, JSON, and just command line outputs. And what's important here is that the whole reason we picked Axe is that if it does output an error, it should be a real error so it's usable in CI. Um any other questions? Great. Well thank you very much.