Prioritize Accessibility with Wagtail CMS

Speaker 1: Hello everybody, my name is Megan Voss. I'm the Wagtail Community Manager for the Wagtail Open Source Project. Welcome today is our Wagtail Accessibility webinar. I'm going to be your host. And uh just to start off, you know, I have a few uh thoughts to share on accessibility. Um accessibility is something that we're all going to be concerned with at some point in our lives. Whether we live with a particular physical condition or we experience an illness or we have to make adjustments as we age, a more accessible world is one that benefits all of us. And web accessibility is especially imperative because the internet is a increasingly important force in our lives. We're seeing laws and regulations

Speaker 1: like the Americans with Disabilities Act, Section 508, and the EU Accessibility Act catching up to that fact And they are asking more and more of website creators. But it's not always clear what steps you have to take to make your website more accessible. And that's one of the reasons we're having this event today. So we have three speakers for you today from the Wagtail Accessibility Team. They'll give you an overview of how to make your Wagtail projects more accessible. And we'll start out with some practical tips that you can take away and implement in your code. Then we'll go over the different types of audits you can use to evaluate your accessibility in projects. And finally, we'll have a look at the Wagtail Accessibility Checker and some other upcoming accessibility initiatives for Wagtail

Speaker 1: We'd love to hear your questions throughout this event. You can ask them either in the Q<unk>A or in the chat. We'll answer a couple of them at the end of each section and save some time at the end for questions as well. We'll also be sending you a follow-up email with links to the resources we referenced today, as well. We'll also be sharing a copy of the recording. If you need the live transcript, there you can find the three little dots in the more section of Zoom. And that you can use that to switch on the captions during the event. All right, I'm going to be turning this over to our first presenter today, is Scott Cranfield from the NASA Jet Propulsion Laboratory.

Speaker 1: Scott's joining us from Rochester today, and he's going to have some practical code tips for you. Take it away, Scott.

Speaker 2: Hello everyone. My name is Scott Cranfill. My pronouns are he, him, and as Megan said, I work for the Jet Propulsion Laboratory. But I'm giving this talk in my personal capacity as part of the Wagtail accessibility team and not speaking for my employer. I'm here to talk about some best practices for making a Wagtail site accessible. for those of you who work on Yitel powered websites and are looking to improve the accessibility of them. But this title is not quite right, so let me see here. There we go. Best practices for making a Wagtail site as accessible as possible because perfect accessibility is not an achievable goal, but we can keep learning how to do better. And hopefully these tips will help you with that. I want to start by talking about the accessibility checker, which was added in Wagtail 4.

Speaker 2: 2 early this year, and is the hallmark feature of our efforts to improve the accessibility of sites made with Wagtail. It's based on the Axe engine from DQ Systems, and the goal is to make it easy for content editors to identify accessibility issues that they can address themselves. Let's take a quick look at it in action. This is Wagtail's bakery-themed demo site, which you can find at github. com slash Wagtail slash bakery demo. And uh as you can see, I'm logged in and we already have uh in the lower right here the Wagtail user bar, uh the little Wagtail icon that uh shows when you're logged in and it's already reporting an error with the accessibility of this

Speaker 2: page. So if you open this menu and then click accessibility, it will tell you what errors it's identified. And what we see here is that all page content should be contained by landmarks. And if I click this, it will show you that it's pointing to uh the the logo text of our site here. That's interesting. We'll come back to that As I mentioned, the Wagtail Accessibility Checker is primarily geared toward helping content editors find things they can correct, but there is still a lot that developers need to do to set their editors up for success. And that's going to be the meat of this talk. What are our responsibilities or what are the guardrails that we can put in place to help ensure that we end up with a website that's as accessible as possible?

Speaker 2: I'll quickly go through the list of topics I'll cover, which are semantic markup and templates, configuring Wagtails accessibility checker, enforcing proper heading hierarchy. promoting good alt text and not using it where it's not appropriate, and helping editors help themselves. Starting with semantic markup and templates. That error that we saw in the accessibility checker is a good example of needing to start from a base of quality accessible markup in our templates The accessibility checker being used diligently by content editors doesn't mean squat if the code that they can't control has major accessibility problems. Semantic markup is crucial for your website to be understood by machines, whether they be assistive technology like a screen reader

Speaker 2: or things like search engine crawlers. Your primary concern in the context of templates for a Wagtail site is ensuring that all of the landmarks are in place. That error that we got was, again, all page content should be contained by landmarks, and it was pointing to our main logo. Let's take a quick look at the template for this part of the page and fix it. Here my bakery demo code uh in the header. html template partial. Uh This is uh this is not the complete rendered HTML of the page, but this is the part where our error occurred. And you can see that the issue uh is that our header div here does not have uh an

Speaker 2: a role equals banner attribute that would identify it as a banner landmark. But an even better solution than just adding that attribute would be to use the header element instead of div, because That comes with an implicit role of banner, making the role attribute unnecessary. So I'm going to change this wrapping element from div to header Save that template, return to the browser where we had our error, refresh the page, and you can see that the accessibility error has cleared and the checker is happy now. Now that we uh I strongly encourage you to take advantage of the uh implicit roles

Speaker 2: provided by HTML elements like header, footer, main, nav, aside, etc. These keep your markup cleaner and they help avoid a bit of the div soup that we so often fall into these days. There's something that I haven't mentioned yet about that error that the accessibility checker gave us. By default, on a fresh Wagtail installation, that error would not be shown. Remember, the Accessibility Checker's primary audience is for content editors to be able to preview the pages that they are building and identify changes that they can make in their content. Errors of the kind that we saw, missing landmarks, are not something that editors can help with, so that wouldn't be shown ordinarily. But the accessibility checker is configurable to show more kinds of errors, in fact, all of the kinds of errors that are supported by the X

Speaker 2: engine, and that is how the Bakery demo is set up. So I recommend that Wagtail developers configure your site similarly so that as you or other developers on your team browse the site, you can catch errors that may need to be addressed through code rather than content. There's a handy recipe on this page in the Wagtail docs linked at the bottom of the slide. And again, we'll be sending out these materials after the webinar for you to reference those links. Let's move on to one of the most common accessibility errors out there, but an easy one to address, incorrect heading hierarchy. I'll demonstrate a couple common errors on the bakery demo, one that is a developer responsibility and one that is an editor responsibility.

Speaker 2: If we take a look at this breads page here, you'll see that we are getting an error for incorrect heading hierarchy. And it's pointing to the heading on this first listed bread card for Balani. The issue here is that our H1 breads , we have this H1 , but we're skipping right to H3 for this heading of Balani with no H2 in between. Screen readers and site crawlers rely on having a logical document structure to understand the content of your page, and headings are the primary way in which they interpret that structure. One way to think about this is like a big multi-level numbered outline in a Word document. If you wrote a research paper in high school, you might

Speaker 2: remember your teachers having you format them this way. If you have this big numbered outline and you indented two levels at once, that would look pretty strange, wouldn't it? Similarly, web page headings should avoid skipping levels as they create the outline of the page So the checker is telling us we have this error, but if we look at this page's edit view in the YTL admin, You can see that there's nothing an editor can do about this because the page is coded to automatically pull in these cards and the heading level is hard-coded in the template. So let's take a look at that. Here is our listing card template where each of the cards like the Balani card

Speaker 2: use one copy of this markup to output on the page and you can see right here is the H3 with that title of that bread. We change this now to H2, save and reload the page. Again, we've cleared our accessibility error and all is well. The text has gotten a bit bigger, you might have noticed that, but you can either live with that or make a simple tweak to the CSS to bring the text back down to the size that it was before. Now, if we go to one of our blog pages, we have another heading hierarchy issue, and this one is an editor-controlled issue, where the first

Speaker 2: heading entered into the page content is an h3 instead of an h2. We have our h1 at the top of the page and then no h2 before getting to this h3 Switching over to the editor for this page. We can see that this is entered into a heading block in our stream field here Wagtail 5 introduced some new ways to validate stream field blocks. Hat tip to Wagtail Core developer Matt Westcott for this feature. And using these, it is pretty simple to validate on Save whether or not the headings in a stream field

Speaker 2: block are in a proper order. So if we return to our editor and look at the blocks. py file We have this base stream block class that defines a common set of stream field blocks for all of the stream fields on the site. In a pattern that may be familiar to you, if you are experienced in Django, you can override the Streamfield Block Parent Classes Clean method that is used to try to validate the stream block on save. Rather than write this code on the fly, I'll copy and paste it in here from uh another location. So here's the custom clean method that I have written. And

Speaker 2: what I have here is some logic that loops through all of the child blocks in the stream field, in the stream block that we're saving. And if they are a heading block, store their size in a list of a new list of headings, which I pre-populated with a placeholder for the H1, because that's not part of the stream field. Then once we've built that list of headings, we can loop through that and starting with the second heading in the list, skipping the H1, compare the size of each heading's of each heading to the previous heading's size. If that difference is greater than one, we've identified an error in the heading hierarchy. We have skipped a level. So we can add that to the errors dictionary And then once we're done, if we have any errors, raise a stream block

Speaker 2: validation error to present that error to the user. I just need to import a couple things to make this code work at the top here Save that. Return to our editor. And if I try to save a new draft of this page, We've triggered our error. The page could not be saved due to validation errors, and if we scroll down, we see on the heading block itself, incorrect heading hierarchy, avoid skipping levels. So if I change this to an H2 and oh, sorry.

Speaker 2: Live demos. Okay, I moved my doc back. Oh my gosh. How embarrassing. If I now publish this page, it works. The uh validation error goes away and the page publisher is just fine. All right. I can also quickly demonstrate if we added a second heading to this stream field and skipped from H2 to H4. We would again trigger the error in the same way.

Speaker 2: So it works both in conjunction with the H1 and for multiple levels within the stream field. Alright. So heading hierarchy issues are sometimes the responsibility of developers like you and sometimes the responsibility of editors, but in the latter situation you can use custom validation to help them out. I demonstrated how it can be done for a heading block, which is not something baked into Wagtail, but a common pattern. But the same approach could be applied to the built-in rich text block with headings enabled. You would inspect the rendered markup from the block, looping through the heading elements and doing the same sort of comparison as I did for our heading blocks. Whitetail also has a rich text field, a standard Django model

Speaker 2: field, that can be used to provide a rich text editor outside of a stream field. And in that situation, you could subclass the rich text field and add your own custom clean method to it. If you have a page that supports combinations of the above, you can override the page models clean method, looping through it all to build a complete list of headings on the page, and then checking each of those in succession Let's move out of the realm of issues that the accessibility checker will flag and onto a topic that always gets a lot of attention called text. If you're not familiar, Alt Text is a way to provide a textual alternative of an image to screen readers, which is not displayed visibly, so that people who cannot see the image can hear what it is depicting.

Speaker 2: This is done using the alt attribute on an image element. The key question to ask yourself when considering alt text for an image is, what description of this image would be useful to someone who's hearing this page read aloud? Bear in mind that the answer to that may be none. Decorative images do not need alt text if hearing a description of them would not be useful. However, all image elements should have an alt attribute and it should be left empty if the image is decorative. You can find many articles on when and how to use alt text, but let's discuss how we implement it in Whitetail. Wagtail has never had a field for alt text in its default image model, but it will default to using an image's title for the alt text

Speaker 2: if you render an image with Wagtail's standard image template tag. We know that this isn't great because the title you want to see in the admin interface may have no relation to useful alt text. In Whitale's early years, the standard advice was to use a custom image model instead of the default and add in your own field for alt text, along with other fields you might need on your images, such as captions or credits. More recently, we've determined that it's a good thing for there not to be an alt text field on the image itself, because any given image may be used in multiple places on a site, and it's important that alt text be relevant to the context the image is in. The context could be different from page to page, so having a single piece of alt text for an image would make it hard to write alt

Speaker 2: text that is suitable for all usages. You should probably still set up a custom image model when starting a new Widtail project, even if you're not sure whether you need additional fields, because it's much harder to transition to one after real image content gets into the database. Because we don't want to store alt text on the image itself, and because we want to override the automatic generation of alt text from the image title, we need to set up a way to set alt text in each place that an image is used. For White Tail Stream fields, this means that the best approach is to create a custom image block that incorporates an image chooser and an optional alt text field. So if we return to our editor where we're where we were editing this blog page, you might have noticed that we have

Speaker 2: a custom image block already. And it has uh some custom child blocks to input a caption and attribution. And here's a reminder of what they look like on the front end. The image itself and the caption and attribution If we inspect this image, you can see that the alt text for this image is just baking soda, the title of the image. One problem with this specific example is that the screen readers are going to repeat themselves reading baking soda for the image alt text and then again immediately after that for the caption that's visible here on the page. Let's add a dedicated alt field so we can give this some better alt text.

Speaker 2: In our blocks. py file, here is the code for the image block, and you can see again the image chooser block and the caption and attribution character blocks. We'll add another character block here for alt text. Make it not required because again we do not always want alt text. Save that. Turn to the editor. Refresh the page uh after correcting this Heading. And you can see we now have our alt text field. So let's enter. We've got some pre-filled text here that I think will be good. A small porcelain bowl of baking soda with a carved wooden scoop.

Speaker 2: I'll publish this page, refresh the front end, and uh Seems to not have saved. Oh, I forgot to add it to the template, which is an important step. All right. We have to update our image tag to use the custom alt text, passing in a new alt attribute and referring to The new alt text chat block that we created here. Now I'll return, refresh the page. And we have our new alt text

Speaker 2: shown here in the uh in the inspector. So that is the primary alt text recommendation that I have for you. Ensure that you have a place to enter it alongside every Streamfield image chooser block. Hopefully this will get a bit easier in the future. Keep an eye out on our proposal for a new contextual alt-text feature that would eliminate the need for developers to add their own alt-text fields. Or comment on it. More enthusiasm from the community might help nudge it into existence more quickly. Having individual alt text fields can't prevent an editor from entering bad alt text, but hopefully it will at least Prompt them to pause and think about it and not ignore it or accept the default of the image title.

Speaker 2: Still, we could give them even a little more guidance. And so the last subject I want to cover today is about providing timely help to editors as they are editing their page to help them catch accessibility issues before the checker or an actual human reports them. Something you may have noticed as I was doing my earlier examples, especially if you are familiar with Django, is that I didn't include any help text attributes. which are a built-in way to provide hints about a given field to the user as they are editing. This is due in part due to space constraints and a desire to keep the text large enough to be readable, but normally I am a huge fan of help text. Let's take a look at what we could have done. Looking back at the heading block example,

Speaker 2: this is an example of the kind of help text I would add to its size field. Note that you can use Django's MarkSafe utility to be able to include HTML in your help text, which is very useful for linking to more detailed guidance. So I might say, please ensure that you do not skip heading levels. For example, the next heading after an H2 should only be either an H3 or another H2. And then you could link to a helpful reference material. Similarly for alt text you could say for information on how to use good alt text, here is a reference link. This is the result in the editor of of that kind of help text.

Speaker 2: One other thing that you can do if you're looking to give editors some guidance at the page level rather than the individual field level is to add a help panel I won't go too deep into explaining Wagtail editor panels, but in short, a help panel has no fields for content entry. It simply lets you define any arbitrary HTML to display to your editors. You could use this, for example, as a cleaner alternative to having help text on every image's alt text field on an image-heavy page type. To learn more about making Wagtail sites as accessible as possible, I strongly recommend that you check out the accessibility considerations page in the Wagtail docs. In addition to specific technique recommendations like the ones I've given, it also has a list of links to other great resources if you want to learn more about web accessibility.

Speaker 2: I'll uh in closing, I'll note that this talk was excerpted from a talk I gave at GenkoCon US in October, and uh you can find the slides and code examples and soon the video. at github. com slash scotchester slash DjangoCon dash Whitail dash accessibility. Thank you very much, and I hope you're inspired to make some changes to help your White Tail sites be more accessible.

Speaker 1: Awesome. Thank you so much, Scott. Uh we do have a few questions that popped up in the chat. There was uh there were a couple questions about your validation code from Graham. It blocks saving entirely on air. And then John asks, why does it offer the option for the H4 if it's only going to trigger an error? So maybe some clarification around that code.

Speaker 2: Good questions. Yes. Yes, it it will block saving the page entirely. That is the point. If you're trying to avoid introducing an an error like that. You know, more commonly that sort of validation is is used for required fields. So, you know, if if a field is required, you don't want to save the page without it. Um I think you might find some friction if you try to introduce this level of validation with your editors, but uh I think it can be worth it to help get yourself an accessible, a more accessible website As to why you can't uh only show the the next valid um uh level of headings that That would be possible, but it would it would be a far more complex

Speaker 2: customization involving um using JavaScript to to on the fly, uh look at what headings you have in the stream field and and modify those options in the widget. So that that'd be possible but very difficult.

Speaker 1: All right, and we have a uh question from Monique uh that I gave her a quick answer to what we do on Wagtail. org, but I'm curious what you have to say too. Somerush apparently will be uh providing notifications on all empty alt texts uh in the future. So kind of measuring sites based on the number of empty alt tests. So when it's decorational, how do you make the alt text hidden?

Speaker 2: If um it comes down to what's in the HTML. If if you don't input alt text and you have an empty alt field, you know, alt equals empty quotes. That is interpreted by browsers to be a decorative image and nothing will be read. Does that answer the question?

Speaker 1: Well, that's up to Monique. Hopefully that helps Monique. We have one more question in Q<unk>A. Why don't you have alt text mandatory when images are placed in context? on a page?

Speaker 2: Good question. And I would say one one example reason for this is that even if it's in the context of content Uh if you have a caption that goes along with the image that's visible to users, um again, you could have a re a repet repetition situation. um where it might be fine just to read the caption and uh and know alt text or adding alt text would be redundant so you could leave it empty in that case

Speaker 1: All right. Thank you so much, Scott. I know we have a couple more questions, but we're going to keep moving on. uh keep things going a bit. Our next speaker, Albina Starkova, comes to us from Torchbox where she's a prena developer. You have Albina to thank for the initial creation of the accessibility checker in Wagtail, and she's going to talk to us about audits. Take it away, Albina.

Speaker 3: Hi everyone, my name is Albina and I'm excited to share some insights on accessibility audits and how you can ensure that your website is an inclusive space for all users. So when it comes to website accessibility, the gold standard and the rulebook is Web Content Accessibility Guidelines, short VCAG. Created by the World Wide Web Consortium. And these guidelines, they are not just a legal benchmark, but they are also a pathway for you to make your website usable for the widest possible audience. As Megan mentioned, accessibility goes beyond addressing some permanent disabilities, affecting 15% of the world's population already. It also extends to those with temporary impairments

Speaker 3: And with some situational challenges like uh being in a noisy environment or while driving. Here on the screen you you may see like some other of the conditions. that you might not have thought about. So essential accessibility benefits literally almost everyone at some point in our lives So let's uh delve into the VCAG itself and its nuances. Uh there are a few versions uh floating around And here is a timeline of these versions over the years. The most relevant one is VCAC 2. 2 that was released just this October. Uh think of it as an upgrade from VCAC 2. 0 that was released back in 2008. And since then there were two updates, VCAC. 2.

Speaker 3: 1 and 2. 2 that has some additions. For example, some of them are particularly for mobile devices. And it's important to know that VCAC 2. 2 will be a foundation for the upcoming VCAC. So VCAG 2. 2 is our target here. Another thing that it's important to understand about VCAG is conformance levels. There are three of them out there, the essential, recommended, and enhanced. Level AA is usually considered as a baseline, aligning, for example, with Section 508 regulations. And uh it's also important that conformance levels, uh higher uh conformance at higher levels indicate conformance at lower levels

Speaker 3: So if you want to get AA conformance, you need to basically have met the success criteria for both A and AA levels. And as you can see in VCAG 2. 2, the new rules, six out of nine , they fall under A and AA levels, setting the new standard themselves. So the release of VCAC 2. 2 may prompt you to conduct your very own accessibility audit. So how do you do that? With VegDail, we uh do such accessibility audits for years already, and we employ a mix of semi-automated and uh manual checks, semi-automated tools and manual checks

Speaker 3: in order to ensure comprehensive coverage for all the accessibility needs. Our goal to semi-automated tools are accessibility insights, Lighthouse and Sally. If you are just getting started, Accessibility Insights is actually a nice one to start. I can show you a quick demo. You just go ahead and install the browser extension like this. Then you go to the page that you want to check. In our case it's the Vactail admin. You click on the accessibility insights icon here. And you can easily launch let's say the FastPass that can help you to find the most common accessibility issues in less than five minutes, or like a full assessment, for example, that will take longer time

Speaker 3: Let's do it quickly, let's uh click fast pass. Here we see that it's it's really great that this tool has post automated checks and some of the guidelines on how to conduct your manual checks yourself. So this is a really useful and beginner-friendly tool. Can't really recommend it enough. It's also important to know that to remember that automated tools they can only uncover so much and typically it's between 30 to 60 percent of the potential issues. So it's crucial to conduct your manual checks as well. In our case, in BacTel Admin, automated tools don't uncover many issues anymore

Speaker 3: due to ongoing accessibility improvements. Just to give you an idea, like this is how our accessibility audit report looked like a couple of years ago, uncovering a lot of major issues. And this is how our accessibility report, recent one, looks like. It's still a work in progress, but it already shows that we need to actually like actively search for errors and aiming for uh new rules mostly and for some uh established practices that go beyond VCAG. So manual tests are really great for all of these, for new rules and for some other established practices. Uh and if you are talking about the manual checks, um

Speaker 3: our manual checks uh cover keyboard navigation, of course, screen reader. uh testing, uh mobile touch interaction, zoom testing, contrast themes, and and much more. So let's do some quick demo here and see explore the new uh rule, the new VCAC 2. 2 rule. It's 2. 5. 8, the target size. And this is uh this rule concerns mobile devices. And basically uh according to the requirement now the point the target for pointer inputs should be at least 24 by 24 pixels And this adjustment ensures that users can easily tap on what they want without um without accidentally hitting something nearby.

Speaker 3: So let's uh go ahead and check our Vectail admin and see if we can find spot any issues here. So for example, this one, it looks like potential uh error uh because it's tiny, uh it's visually tiny. But the looks could be deceiving because if we check here the actual size of the target, you can see on the top right uh um in the top right of the tooltip 24 by 24 pixels so this means that the uh the target area the button itself is large enough to be accessible and this is not a violation And it shows that even in busy interfaces like Vegtail Admin, you can it's possible to make accessible targets without uh changing the design that much.

Speaker 3: Another potential issue is this little toggle here. It's also not a violation because it has another like this part, heading, preface heading. that uh clicking on which we also can toggle and achieve the same adjacent functionality. So this also uh looks like an issue but it is not What is an issue actually is this little anchor over here. Not only is undersized, if we check, it's just 20 by 20 pixels. But it also lacks sufficient space around it and it's very hard to avoid some interactions with adjacent targets like this pre-phase. uh toggle for example. So in this case, this is indeed a violation of specified standards.

Speaker 3: So if you want to uh start testing your website for accessibility, I recommend uh using this new rule as well because uh I think that it enhances the user experience for literally anyone who utilizes mobile devices And another check worth highlighting goes actually beyond VCAC. I know like we know that VicAC is a great standard, but it's not perfect and it doesn't cover some useful features and scenarios. For example, Windows Contrast Teams. It's a built-in accessibility feature. That uses a limited color palette highlighting links, buttons, and inputs to help identify them for people with color blindness or low vision. And surveys indicate that

Speaker 3: majority of people with such conditions, they rely on some sort of contrast themes. So we can go ahead to our Webtail admin. By the way, if you don't have access to your Windows device, You can emulate these contrast themes in uh in the Chrome DevTools. It will work just fine. And we can uh uh I can show you some of the violation here. For example, the close icon here It's almost invisible on contrast themes. The same page suffers this information icon. For example, the tooltip here has broken design without a border and a proper arrow. And this could be confusing for users who rely on contrast teams.

Speaker 3: These are not certainly not blockers, but we believe in addressing these even like smaller issues in order to make Vactail experience more enjoyable for everyone. And I recommend you to check your contrast themes in your audit. even though b it goes beyond VCAC because it's a useful feature, it's simple to fix and it's uh it's a nice one. Uh so we'll use to wrap it up, we'll use the results of our uh audit in our Webtail uh roadmap. And if you want to know more about accessibility audits, please join our discussion on GitHub. We'll be sharing all the relevant links and insights there. Thank you

Speaker 1: Awesome. Thank you so much, Albina. We got one question here of the new things in uh Wiccog 2. 2. Are there any that have flagged issues in Wagtail?

Speaker 3: Uh yes. For example, this 2. 5. 8 issue uh which I showcased. the mobile uh the target size issue that we actually had at least one validation on the page editor. So yes. They did have. Yeah, sorry.

Speaker 1: Oh, no worries. Are there any other tips that you have for organizations that uh want to start doing accessibility audits themselves?

Speaker 3: I think for start it's really like better to uh to start with some automated tools because they are super easy, super like beginner-friendly. And they will uncover like up to six percent of the accessibility issues. So this is a great place to start. And if you want to go ahead and proceed with some manual checks uh I would recommend to go with keyboard navigation uh checks because uh this area requires uh least expertise and it can uncover really common and really uh severe accessibility issues as well. So you can start with these two and you will uh you'll be good to go to start.

Speaker 1: Yeah, as as somebody who uses the keyboard quite often, I definitely appreciate that one. All right, folks, let's uh keep it rolling a bit. We're gonna move on to our final speaker today. He's from Torchbox. He's also a member of the Wagtail Core team. And uh he's a Wagtail consultant at Torch Fox. So Tebow Colas, take it away, sir.

Speaker 4: Thanks very much, Megan. Hi everyone. I'm Thiba. My pronouns are he, him. Just give me a second while I get my screen sharing started. I thought I'd start by saying quite simply how amazed I am that we have such an event today. We honestly do not have that many occasions to focus on activity in our fields. And in Wagtail specifically This event, I believe, was very much made possible by the work of the accessibility team for Wagtail, who has been pushing for accessibility improvements. in the CMS since 2020. And Scott here today as a speaker and I are founding members of the team.

Speaker 4: This is our biggest team outside of the core team behind Wagtail itself And it's very much a community-driven team. So I'm honestly super happy to see that we have such a huge turnout for an event like this. And that we have many um things to report on, simply enough. And right now I'm screen sharing a blog post I just posted about all the things this team did this year. And I won't go through it now, but I definitely recommend. If you want to know how the sausage is made, uh this is how we make bright tail better for accessibility, uh release to release And um yeah, this very talk is is very much about uh behind the scenes, how we make activity improvements happen. And I thought I'd start by sharing our roadmap for Wagtail

Speaker 4: just to highlight how many items on there are about accessibility. So I'll just do a quick search, text search on the page for that. In the very next release, uh we have four items. About close to half of what the release is about is accessibility improvements, which just to me is Fantastic. I saw a question popping up. The questions I'll look at them during this, so do feel free to keep asking them. I'll do my best to answer them on the spot as well as later on. So yeah, four items coming up in the next release and way more in the future as well. And if we take a look behind the scenes as how we manage this roadmap page. we we head over to GitHub which is where we keep uh track of all of the roadmap items

Speaker 4: and I'll take you to our roadmap projects. where we can see every single roadmap item for Wagtail both in the future and in the past. And I'll check for accessibility here as well. And what I find really um Again, just wonderful to notice is if we're looking at right now, again, we have those four items, but in the past as well, we haven't had a release in almost two years now that hasn't had at least one item related to accessibility and and some of those are really heavy hitters um and again like things that people on this very call have have helped make happen so it's just amazing for me to notice that As far as my presentation today,

Speaker 4: my colleagues uh Albina and Scott have talked about the web content accessibility guidelines quite a bit already For me, I'll focus on another standard called ATAG. A tag isn't nearly as popular or well known of a standard. If I scroll down quite a bit. Towards the bottom of W3C's navigation of web standards, it's right there. And for us as a CMS, it is definitely a very relevant standard. which is a standard for authoring tools specifically, just like a CMS. So I thought I'd start by essentially rather than having us go straight to the standard document have a look at examples of authoring tools and practical ones at that.

Speaker 4: So I thought I'd start by showing you Twitter, where I recently shared a post with a video in it And as you interact with this post, you of course want to make sure that this video also has appropriate alternative text. maybe captions, things like that. So as a user of this kind of interface and this content, there are very clear guidelines as to how the content is meant to behave. A tag on the other hand is about uh the platform that provides this type of content editing, which features should it have so you can create accessible web content with it? So the Twitter or ex post editor, what features is it meant to have to support people in creating accessible

Speaker 4: posts with videos and it's very interesting to reflect on how different platforms do this. So on X from memory I had a way to upload a caption file for my video. while on LinkedIn for the exact same content, I had a way to update both a title slash caption field and the caption file. Well on Mastodon, I only had a way to update alt text for the whole video in one go. So definitely interesting to consider how those different platforms essentially implements those kinds of requirements of editing as relevant for accessibility. That's very much what ATAG is about, is requirements for content editing platform, content authoring platforms on accessibility.

Speaker 4: And back to Wagte for a second, the reason this standard is very relevant to us is that we managed to do a full audit of the CMS for ATAC 2DO. There aren't that many ATH2Dolo audits out there, so we spent months, if not years, of Accessibility team efforts to figure out exactly which requirements were relevant to us. how best to audit for them. And this is a very much behind the scenes look at how Wacted operates, but I'll share the link to this audit right away. You'll see if you're familiar with GitHub, this is opened as a pull request. The idea here very much isn't to do a one-off audit is to drive the future of Wagtail and have all those future roadmap items be based on an audit.

Speaker 4: So we'll spend the next few months for sure reviewing this audit line by line and making sure that for each and every area where we could do better, uh we have a clear plan. So if we look at this audit in a bit more detail, there is 63 separate success criteria which we had to follow in the audits. And if we look at our results at a very high level, we got 22 passes, 28 fail. 12 not applicable. Might feel a bit underwhelming that we don't have more passes than fails, but just to be completely clear. uh the way that a tag audits are structured, even if something is a tiny fed with an overall, I guess, with an overall structure

Speaker 4: that we implement correctly. it counts as a fail. So some of these might be very simple for us to turn from fails to wins. And to be completely honest, we're very happy to report things as failures if there is clear ways for us to improve on them. That's the whole point here to find improvements to Wagtail. And I thought next I'd show you like a specific item that's relevant within the A tag standard. so that you're well aware of the types of requirements we're discussing. So I'll go back a few screens and we'll look at the ATAC standard. Can't stress how weird it is for me to have a video call where we get to look at points of details of web standards like ATAG together. My colleague

Speaker 4: Scott again spent quite a bit of time today talking about alt text. I saw lots of people as well in the chat commenting about, oh, why is the CMS not allowing me to save with those errors? Shouldn't I be able to? That's exactly what standards like ATAG are about, defining how code managements are meant to implement those requirements in a way that leads to the best possible accessibility. So for alt text specifically, there is this point of standard that says if you can display non-text content, such as an image, then there is alt text for said content. That's about making sure that as an author in the CMS

Speaker 4: you know what the alt text is for an image That's the final requirement of WICAG is the CMS itself has to be accessible. Now I'll go back to my list at the top And we look at part B of A tag, which is about supporting the production of accessible content. And on there, there's also points about alt text that are very relevant to us. which is how exactly the CMS should behave with alt text. So here it says alt text should be editable Might seem obvious to some, but very well woof being on there just so we have the same baselines across CMSs And if we look further down, it also says that whenever you enter alt text, we should save it for reuse

Speaker 4: as uh suggestions for other occasions where you might need alt text. So that's very interesting for us to consider. Scott might have mentioned we were working on better like default behavior for alt text in Wagtail. I think someone mentioned in questions that maybe we should just make it mandatory. This is exactly why A tag is there again, defining exactly what makes sense so that authoring tools don't have to reinvent all those things for themselves. So back to our results for uh ATAG. I thought I'd show you one other very interesting thing we learned from ATAG. which is how important automated checks are directly in the CMS. The type of check that Scott has shown earlier, that is very much a type of check where you're 100%

Speaker 4: sure there is an error that you want to make sure isn't there in the contents. So you use what we call validation errors in Wacktab. But as of uh as of a year ago, um Albina here on this call helped us introduce a brand new activity checker in Wiktail where the errors are reported as Scott has demonstrated already, but the errors we don't enforce that you have to fix them. And we've been trying to improve upon this checker , month over month, release to release, simply because it is a fundamental aspect of how we make Wagtel sites, as Scott said, as accessible as possible. And the latest update on this, which I'm very happy to report on, is the integration of this checker

Speaker 4: directly inside the page editor. So we're now inside the CMS, I have my live preview, and I now have a new panel for those activity checks. And the intention there is very much that it's a type of check that my non-sale want to enforce as part of saving a draft. But you do definitely want to be aware of those errors anyway. And we see this as quite foundational work for us to be able to report on how accessible the site is site-wide potentially Right now we have this data in the page editor only. This will go live in the next release, but in the future we'd really like this to go to your page reports, to your dashboard, everywhere where you might want to have some awareness of how accessible your content is.

Speaker 4: And as far as A tag, I can't help but mention that those automatic checks for accessibility, there are requirements for all content managements out there. And not many of them have this as a built-in tool owned by default, which is very much what ATAG recommends. So we try our best to work with those other CMSs and learn from them. And this is something where we'd like to think we got it right and we take things, our industry, in the right direction. And yeah, if you're keen to hear more about this, we have a whole blog post just about those automated checks. and essentially how people with organizations using Wagtail can help accelerate this vision of having them well integrated in the CMS for the benefit of all

Speaker 4: Wagtail users. So talks about how we want to surface those reports on the dashboards and how we want to make this experience better. As an example, just having a way to dismiss those errors when they aren't relevant, whether some errors might prevent you from saving or not. That's exactly what we're trying to figure out here and what we're looking for a partnership with organization to make happen. And yeah, finally, I just want to tie this back to our roadmap, which again contains many, many accessibility improvements. over the next few releases. So I hope we get to report again next year in 24 with uh how we made those specific things happen. And I think we have a bit of time for questions now.

Speaker 1: Yes, we do. We have a question here from Boris. Uh Boris says, I'm a UX designer and quite often I end up designing stuff for sites uh that semantically speaking are not correct. For example, sometimes I use an H3 instead of an H2 because the space before this heading makes it clear that this is something new. And then H2 would be just too big. So visually everybody would recognize this as something new starting here. And what I tend to do is use an ARIA level to achieve the propher semantics What do you think about that? And are there any plans to integrate more ARIA possibilities inside Wagtail?

Speaker 4: That's a great question. So I guess just to start off. Wagteil doesn't have that many opinions about when people create a page, how exactly the page looks and how it renders. That's something where we expect Wagteil City implementers to take ownership. So we don't necessarily enforce it one way or the other. We do have plans to have better built-in support for headings because as Scott mentioned, correct heading hierarchy is what a fundamental aspects of web content. So for this specifically, I think what I would say is area level. That sounds like a bit of a red flag to me. Area attributes like this, they tend to have quite hit and miss support with technology out there. So I'd recommend just using a different heading element with different styling, having the heading elements show the correct structure.

Speaker 4: And if you want to style them differently, use CSS for that. Oh, I hope that makes sense.

Speaker 1: All right. And we also have a follow-up question on the alt text. Tivo, you responded to a question about alt text stating that some screen readers do not announce the alt attributes. So some organizations suggest putting the text equivalent into body text. What evidence can you cite about passing that recommendation along? I th I think that's what John is asking. skin here.

Speaker 4: Yeah, uh that's a great question as well. So I just to be clear, I do not know whether specific screen readers process alt text differently. What I do know is screen readers process a lot of things very differently from one another. Text specifically, I am not sure. So I guess there's two things here As far as how different screen readers work, I think it's good to be very clear that we cag and automated checks, as I have discussed. They're just a baseline that we have to get right. But from there, you want to make sure that what you put together actually works for real users. And the best way to do that is to be in touch with people who have those needs in your audience. Back to alt text for a second. I guess I want to address that as well.

Speaker 4: Different organizations have different requirements on this, again, because of the fact that they're more or less strict about it. So if we work with people like the NHS, for example, they're very clear that alt text should not be used in the CMS and that you're meant to add a caption or text directly in the page content. And for me, that makes a lot of sense because you definitely can use image descriptions, even if you're a cited user, which you wouldn't get to benefit from if they were in alt text only. But for the organizations, maybe it just makes sense that you describe images more extensively in alt text only. So coming back to Wagtail, that's why we want to make sure that we have defaults that make sense

Speaker 4: and a clear story for site implementers who want to customize this.

Speaker 1: Awesome. Thank you, Tebo. We have a question from Sylvain. To access the list of accessibility issues on a page, we have to use the Wagtail admin bar. But the admin bar itself is not accessible, is it? I can't access it through keyboard navigation.

Speaker 4: Really? Oh, I really hope it is. We've tried really hard to make it keyboard accessible. We're aware of some issues, but I really like to think that it is accessible enough. So if I jump back to my demo and use the keyboard Okay, it this is this misses on tab key, but I can get to my admin interface with it and I can Ah, yes, we found a bug. Okay, so clearly there's something where we can contact test the actual list of issues. So I think what this is what I would say is make us well aware of those issues and we'll fix them as immediately as we can. So this admin bar specifically, as far as I know, we spent quite a bit of time making sure that it has good support for navigation through the list.

Speaker 4: and summoning the bar. It does require site implementers pulling the bar towards the top of the page so you can access it with the keyboard without having to go through the whole page. But it looks like yeah there's an issue specifically with surmounting this accessibility dialogue. So yes, I will be working on this soon.

Speaker 1: No doubt about that. All right, everybody. We are out of time, but maybe we can fit in one more question if anybody has anything burning in their minds. Anybody? I think I think that's all we have for today. Thanks so much, everyone, for coming. Thank you to our speakers for speaking. If you have, we'll be sending a follow-up email with a recording and the list of resources. Please stay tuned to more, like to get some more events. We'll definitely be hosting more events like this in the future. And one of the best ways to keep track of that is to sign up for our Wagtail newsletter, which you can sign up for here if you haven't signed up for it already.

Speaker 1: All right. Thank you so much, everybody. If you're observing holidays, we hope you have great ones. And we'll see you in 2024. Take care.

Speaker 2: Thank you, everyone.

Speaker 4: Thanks, everyone.

Speaker 3: Bye.