Accessibility wins for Django projects | DjangoCon Europe 2020

00:13 - DjangoCon talks in the past have always been one of my go-to sources of Django learning so it’s really humbling to be here on the other side, so thank you for having me and I also wanted to thank my partner who is looking after our child right now I couldn’t do this without her as well so thank you Deborah.

00:30 - Today I’m here to talk about accessibility and specifically accessibility wins for Django projects so not just generally what accessibility is but specifically for Django work what do you have to worry about and I’m here in particular to tell the story of how we’ve approached this for Wagtail. I’m not sure who has heard of Wagtail before but I’m a core developer of the Wagtail CMS so I’ll also talk to you about this briefly.

00:56 - The slides are available online should you want to look at them at your own pace and the link is at the bottom here (thib. me/django-wins) all right let’s get going.

01:04 - so first of all this Wagtail story Wagtail is a CMS essentially you use it when the Django admin probably doesn’t provide you enough to manage a site that is quite content-heavy so for example the blog with lots of pages lots of fields on each page and maybe lots of different people wanting to edit those pages concurrently translating those pages and so on, so that’s where kind of Wagtail comes in it’s based on Django but the admin is much more geared towards those use cases so of course we do want this admin UI to be accessible, to be usable by as many people as possible and we also do want the sites built with Wagtail to be as accessible as possible so I guess that’s kind of what brings me here right now we learned along our Wagtail journey that accessibility matters and that unfortunately you can’t just rely on best practices and semantic HTML you also have to learn practically how do people make use of a website with assistive technology what things you have to watch out for and so on.

02:14 - So yeah quite briefly why do we care about making Wagtail accessible in particular, is because we want to provide an experience that’s inclusive that includes as many people as possible regardless of their skill level background of how they end up using the CMS and in particular people who do rely on assistive technology well we want them to be able to succeed in the workplace at their jobs if they have to use Wagtail there.

So we don’t want someone to be left out just because they happen to use our CMS one way or another and something else I want to mention earlier on as well is that these accessibility improvements that we tend to think of just for people who have low vision or who are deaf or yeah any and all of these they do lead to usability improvements for everyone this is something called the “Curb cut effect” and I recommend you have a look at this.

03:05 - And yeah unfortunately there are other reasons that are not as positive so currently we’re working on it but the admin interface still is quite difficult to use if you’re using a screen reader, and well practically if you’re one of our clients at Torchbox and you’re choosing a CMS well this might be problematic for you, might be quite a bad option if you do have people who rely on assistive technology or if you do have compliance targets that are quite strict.

03:32 - So those compliance targets actually exist all around the world in the US that’s called Section 508 for public sector websites and ADA for literally all websites, depending on which lawyer you ask, and in the EU we also have similar laws that are enforced.

03:50 - So yeah this isn’t something that’s optional this isn’t something you do just to be nice, you do have to do this oh and yeah it’s not just Wagtail by the way.

03:59 - So whatever thing you’re building whether it’s an intranet, or some kind of dashboard, a Django admin based website, you do need these to be accessible and you can’t just compromise on that just because the audience of the site is smaller you wouldn’t compromise on a website’s security just because it’s used by 10 people rather than 100 it still needs to be 12-Factor and so on.

04:25 - I want to also give you a brief legislation overview here in the EU so public sector websites complying with the directives I mentioned above that’s coming up a week from now whether the site is new or existing for mobile apps still have about a year to go.

04:43 - And there was a new law coming, that got drafted in December 2019 that now is going to make this mandatory for e-commerce banking and transport services as well, not just public sector things. So yeah this is coming time to do this, and yes also worth mentioning that even though all of these things are different laws they are all based on the same standard called WCAG2. 1 I won’t go that deep into the standards that much today but I think this is worth knowing that the things I discussed today they aren’t arbitrary things, subjective things they are defined by very clear standards that lots of people work on at W3C and yeah, this, you look at it online, all the information is there, from first-party sources.

05:33 - Alright, yes so I don’t want this to be all negative.

05:38 - I think I really want to point out that to me there is a bit of a cultural shift in progress and that hopefully a few years from now it will just be like having bathrooms that are large enough for wheelchairs it would just be part of the landscape of how we build things on the web and we won’t have to think about it too much, and things like Wagtail will just have this taken care of for you to some extent, things like Django as well.

06:05 - For now though we’ll look at some common issues.

06:12 - yeah worth pointing out as well that this is live so I’ll make the most of it and I also have the slack chat open should you want to make comments along the way I might or might not find the chance to look at them.

06:23 - So yes, those common issues they are very common and again I’ll try and focus on the ones that are specific to Django, and in particular, the ones that Django developers can have a part in fixing all right let’s dive in, alt text for images I feel like this one feels quite basic potentially.

06:42 - a lot of people know what alt text is how you meant to provide it to describe text for images on your sites.

06:49 - so what the problem might be well let’s look at this bit of UI here “Wagtail is trusted by people you know”, list of logos underneath I’m going to now use my screen reader superpowers to show you how someone with a screen reader would perceive this UI so I’ll switch to what they experience one, two, three and ah well that’s a bit problematic, all of the content is gone.

07:16 - It’s used by “people you know”, which is… No one.

07:21 - So what the problem is quite simply that all of these are images and none of them actually have alt text defined they just have “alt equals empty string” which means that well there is no alternative if you can’t see the visuals of the images, which, yeah it’s quite bad so why is that? Essentially this is a models problem not a template problem when you use an image like this on the page on your site well you need a field for the image file and you also need a field for the alt text so in this case the images aren’t decorative, they are the whole content that’s being displayed in this section, so they do need this one field in the CMS, so that’s why it’s important for Django developers to be aware of things like this these aren’t things you can fix just in the templates although of course you do have to use the fields in the templates as well so yeah solution for this is quite straightforward if an image on your site isn’t decorative there should be an alt text field alongside it and you should make it possible for users to leave this blank if the image is described otherwise, or have this mandatory if there is nothing else on the page describing the image yeah and again why does it matter for Django developers to be aware of this so I’m sure you’ve seen this type of charts many times in the past if you’ve been to conferences.

08:42 - This is a chart showing the cost of fixing or changing code depending on when the change is detectedm whether you find a bug close to launch, or as part of gathering your requirements for your site, so essentially the closer to requirements the cheaper, the closer to launch the more expensive to fix those things well the fundamental problem here is that someone like me auditing a site, I usually tend to come look at the site only towards launch which is a bad thing in its own right but it still does work like that most of the times, whereas if you’re working on your models in Django well this is much closer to the actual design and architecture of the site so it’s worth being aware of things like this as soon as possible so you don’t just carry the issue all the way towards launch, and then you have migrations to do you have to figure out where to add the field how to do that and you have to ask people working on your site to go and add the content afterwards.

09:35 - It’s much easier for all of this to just be something you’re aware of up front and yeah so this isn’t just images.

09:43 - Videos are another example of this, so here we have a blog post that has two video embeds on it again with screen reader super powers, nothing is on there and well that simply is because those two embeds from YouTube they don’t have a title attribute, again something that you have to be aware of quite soon, in order to have this field there in the CMS if possible or just make sure your embeds integration is aware that it has to pull this data from YouTube and I also want to point out here I use the example of YouTube but you might also be tempted to say well I don’t want to rely on a third-party service I just want my videos to be managed directly directly Well that’s all fine but then you have to be aware that you also have to provide captions for the videos potentially transcripts as well and I can’t count how many times I’ve seen people go down that route of having videos managed directly on their site and I have to tell them quite late in their process that they actually need those fields as well you can imagine how you probably would rather know about this upfront so you could make an informed decision on whether to roll this out yourself or use a third-party dependency for this yeah so again yeah the sooner the better if this is me doing an update and putting this out after launch this is going to be a very long fix for you to roll all that content whereas if you’re aware of it up front you can assess at the organisational level do you have the capacity to produce those transcripts or not and if so how.

11:18 - One more that i’d like to point out is heading levels so h1, 2, 3, 4, 5 in HTML screen reader users rely on this to follow a logical sequence for them to navigate the page without having to go through it all top to bottom so briefly what you need to be aware of is: one H1 per page, don’t skip any levels only use headings for the structure of the page not just because the designs have larger text here and there.

11:48 - It’s very easy for me to be critical of Wagtail, having worked on it so much, for once this is something we do quite well where if you define a rich text field in your models you can restrict which heading levels are available in that given field which actually restricts the controls that are in the text editor in the CMS admin which means that your CMS users then can only use the heading levels that make sense semantically in this given field.

12:16 - So yeah worth looking out for things like this when you shop for rich text editors.

12:22 - Yeah so just to hammer the point home this is an example of this thing gone wrong, this is the djangoproject. com website and this is a bookmarklet called “h123”.

12:33 - Here I have the results of that bookmarklet I can see the document outline on the page I can see there is one, two, three, four H1s here.

12:43 - H2 for some reason I don’t now why, “latest news” is underneath “Support Django”.

12:48 - So yeah this is this is not what you want, this is the type of thing that you need to be aware of.

12:56 - One last one for the road, forms, yeah I kept this one short, Django has convenience as_table and as_ul methods to render all of the forms at once as tables or lists please, please avoid them as much as possible.

13:14 - Yeah tables layout that’s the thing we did like 10 to 20 years ago.

13:19 - it doesn’t have anything to do on modern websites anymore and tables are very hard for screen reader users to navigate lists is somewhat okay but tables in particular is really problematic so avoid this and yeah also worth pointing out that even the vanilla markup from Django without these helpers really doesn’t doesn’t give you much so basic things like showing which of the fields are required, that’s not something that Django provides as a default.

13:45 - Sure the field has a required attribute in HTML but it doesn’t have any visual indication of which is required, which is optional, so be wary of those defaults like this that only give you the broken half of usable forms.

14:00 - Alright lots of negative stuff, but we’ve got it out of the way and now we can look at more positive things that will help you get there so next section is called “Developer wins” I want to point out early again I’ll focus on things that are specific to Django as much as possible I wrote a blog post recently about audits generally not just for Django from the perspective of developers in particular so do check it out (torchbox.

com/blog/accessibility-audits) if you want to learn more about what I’m describing here.

14:31 - So “developer wins”, again we want to focus on things that help developers making more accessible Django projects and again the idea is to not just have things that you run towards launch here the idea is to shift, to “shift left” as they say towards the requirements and coding stage.

14:48 - So if you compare this to security or performance you wouldn’t only start to worry about your site’s security or performance after launch you’d presumably worry about having a sound foundation, whether that’s a framework or something else, having best practices like 12-factor again, and then having potentially static analysis of your code to check for those concerns, essentially runtime analysis so monitoring as well, and tests.

15:15 - So again like spreading the “how concerned am I” about those things throughout the whole project, not just there.

15:22 - Accessibility is the exact same. First thing first that I won’t cover but I wanted to give you a few links on, the training, obviously the best way for people to be aware of those things as early as possible is for them to know about the issues and the only way for that to happen is education, learning resources, and so on here are two links if you have the time to check them out.

15:46 - I’ll move on to again Django specific things but before I get there I wanted to show you my three favorite tools: 1. Axe, it’s a free and open source accessibility testing engine, has all the rules you could wish for WCAG and Section 508 compliance 2. Accessibility Insights, it’s a browser extension that bundles Axe and much more, and 3. Pa11y (“Pally”), essentially it’s Axe on the command line.

16:13 - Try these out they will help you tremendously and yeah I also wanted to mention static analysis so people might not be aware of this unless they spend lots of time in the client-side front-end framework landscape but these days things like React and Vue, they have quite well established ESlint linting plugins specific to accessibility issues so yeah worth being aware of these.

16:40 - so now back onto things that are Django specific there’s a package called Django HTML validator, I’m not too sure how people feel about HTML validation these days but it definitely covers quite a lot of basic things.

16:54 - About 15% of issues according to numbers I could find so this one package uses the official V. nu validator and essentially bundles that in Django so that HTML validation happens whenever you render pages, so either because you’re loading the page in your browser or as part of your unit tests, and yeah you’d be surprised how many HTML validation issues you can find on a major website built with a major CMS on top of a major framework in 2020 so yeah these actually cause real issues for people who rely on the semantics of the page, and worth knowing about and yeah something else I’m quite excited about is this linter I’ve been building over coronavirus.

17:42 - So this is Curlylint, it’s an experimental linter for Django templates and Jinja templates the idea being again – to bring this type of static analysis that gives you feedback as soon as possible – to bring that to the Django world so Curlylint is again very experimental but still available as a PyPI package it’s a command line tool, you can install it, run it on your templates, and it finds issues.

18:10 - It has rules that are quite basic but still useful nonetheless like checking that your page HTML has a lang attribute so that the screen reader will actually read the page in the correct language yeah other basic rules like avoiding autofocus on form fields other basic rules like avoiding Django’s as_table and as_ul, essentially as close as it gets to having me on your team without paying me, I can just complain via current please don’t do this.

18:42 - Yeah I’m not sure how you perceive this from your side but from my side I wanted to point out that you actually do find issues with this so yesterday just for fun I tried to run it on my personal website and well I found I was missing a lang attribute on one of my templates and I found that one of my very old talks didn’t have any alt text on the images, so yes the issues are real and I also ran it on the Django codebase and found an issue with Django as well so yeah there is a template in Django that also doesn’t have the lang attributes on the HTML template which means that the page will be read out with the wrong language yeah I also found a parser bug with Curlylint, because yes, try it out but don’t necessarily like yeah so that was static analysis which I think is amazing you should try and have as much of it as possible regardless of what you’re looking at in your project QA wise.

19:45 - Now I want to show something that’s on the opposite side of the spectrum so this project called Django Pattern Library that is from Torchbox, my employer, this is what we use to manage UI component libraries for Django projects so the basic idea is to have a way to work and test your UI components in isolation from where they are used in your project and the reason this is relevant here is that, well.

20:13 - This is kind of unit tests for UI stuff so the whole idea is that well you have this data in the pattern library and you can try all of the variations of your components based on what data requirements they have and of course you can run accessibility tests quite easily on those components regardless of where they happen to be displayed in your site.

20:35 - So yeah if you are building patterns I definitely recommend checking it out but yeah this is quite a fundamental change of approach.

20:41 - One other thing I want to mention is to learn how to use a screen reader.

20:46 - So I’ll give you a quick demo of that, I will switch over to Safari and open VoiceOver.

20:52 - On there, VoiceOver and Safari, there are only three keyboard shortcuts you need to make use of a screen reader like VoiceOver and most other screen readers the first one is how to open it, that’s Command + F5 [VoiceOver Off] on the Mac the second one is [VoiceOver] how to close it.

21:12 - that’s also Command + F5 and then VoiceOver has this thing called the rotor which I’ll open with Control + Alt + U [headings menu] that allows you to navigate through your page [view heading level one, Django administration] so here I can see all the headings on the page I can use the arrows [tables menu] and look at all the tables on the page I’m not quite sure why there are tables here but [windows spot] [links menu] I can look at all the links on the page and right away find issues just based on this and this is exactly how people who use screen readers use them so this is worth knowing about just because at the end of the day that’s how they actually experience your sites.

21:50 - Yeah I’ll leave it there but yeah this is really inside a minute [VoiceOver off] and again I just showed VoiceOver because it was fast for me on the Mac but there are other options I can also show you VoiceOver on iOS if you can look at my camera for a moment I also have it next to the microphone.

22:06 - I just need to triple tap the home button [VoiceOver] to start [Safari address] and then to navigate all right we’ll leave it there and yeah it’s that simple to get this going and use them for testing, so worth knowing about.

22:32 - I want to end on Community Wins. And again call for that cultural shift I mentioned earlier on, to me, Django, it’s quite clear, Django developers have a role to play in this because again this matters for all projects and the standards are well defined and there are lots of tools you can use for those types of checks, so yeah do take some some time to be aware of those standouts even though you might only spend most of your time in the back end you do need to be aware of those constraints on images, heading levels, and so on when you model your websites and the tools that you can use to actually run tests before someone like me steps in and does an audit, these are already available, there’s lots of free and open source options as well, and I think that Django as a framework as well has a clear role to play in this.

23:21 - There is this study by WebAIM called the WebAim Million which tracks how accessible the web’s one million most popular websites are and the numbers are horrendous honestly there’s no other way to put it so yeah I feel like frameworks like Django have to step in and provide better defaults, whether that’s the actual framework, or whether that’s just their documentation of how to implement those things.

23:47 - Yeah this is actually happening for Django so quite recently Tom Carrick started the discussion on the Django developers mailing list and out of the discussion came this process DEP for Django to have a dedicated accessibility team I really think this is worth considering and worth your time and feedback.

24:09 - So things that could evolve – well obviously making the Django admin WCAG compliant, making the Django docs and websites WCAG compliant, having Django features that you use to build your sites be compliant by default as well, better documentation, and so on.

24:26 - There really is lots of room for improvements if I’m honest so yeah worth being involved with those conversations and yeah providing your feedback on these, and again coming back to my Wagtail story, well I guess this is where we were at with Wagtail about a year ago, we initially had discussions about our CMS, the admin, websites, the docs, and the conclusion of this discussion well we’re still very much in progress on actually fixing the issues but at least it feels like as a community we do have quite a consensus that those things matter and we want them addressed as soon as possible so yeah that’s where I’ll leave you.

25:04 - And thank you I hope this was good! yeah I forgot there was a recording for this as well all right recording is on [Laughter] yeah please fire away all the questions you want in the chat or on vocal if you prefer.

25:31 - On Slack I’ll be around for quite a bit more time after this as well first question was “where you can find the DEP that I just mentioned” so I’ll probably try and share my screen and show it to you at the same time as I answer the question.

25:46 - This is essentially on a repository that Django has just for – all right you should see my screen now, so github. com/django/deps/pull/69, this is where they have all of the in-progress ones.

26:02 - And this is yeah still just a Pull Request for now so I think the feedback process is as simple as reviewing a Pull Request.

26:15 - Asker: Ok, thank you Sweet Does anyone have questions? Question: I know your talk focused on screen readers but is there any other kinds of accessibility that we should be aware of? Thibaud: Yes! [Laughter] that’s a very tough one because there are so many things I could mention but I guess I’ll try and keep it brief, while other people think of other questions, so I’ll quickly share my screen again and show you a few things just as a kind of demoing what those things might be that you have to consider I’ll show you the extension I talked about during the presentation so this has automated checks that essentially cover any and all types of issues if I run this on the Django website all of the ones that are there are most of them actually are related to contrast issues so this idea that the text needs to be readable enough regardless of how good the vision of people are.

27:32 - So it’s not just whether you’re completely blind and using a screen reader or not but just how good your vision is and of course as you grow older well your vision declines quite a lot so this is pretty much for everyone who wears glasses to just happens to be older than the average.

27:51 - Another example I like to mention is. Keyboard accessibility so again if you’re using screen reader you likely use it with the keyboard but even if you’re not using one well you might be navigating the web with the keyboard and you might expect that to work so this extension also has a check for you to see the order in which your page is navigable with the keyboard the idea being that well this should make sense and you should be able to follow along the page and interact with all of the parts of the page with the keyboard alone that’s a common example as well.

28:25 - And I guess the last practical one I would mention is that if you’re using a website on a small screen well there are lots of other concerns here, so for example on the small UI you might be tempted to make very small buttons.

28:40 - You don’t want that to happen because if someone has to use your UI with a big thumb they want to be able to press any and all buttons without accidentally doing something else so yeah just kind of the practicality of working on small screens having the right input targets sizes yeah I think that’s a good few ones but it doesn’t stop there the list is quite longx if you want to learn more about this there is a thing called the Do’s and Don’ts posters that have been made by the GDS in the UK, can I find them so these do’s and don’t posters they kind of cover all of the things you have to worry about so again screen readers just one of them I might share this link after the questions Asker: thank you that’s wonderful information Thibaud: yeah my pleasure Gaetano you asked what’s the name of the tool I’m using right now to see the links that would likely be Accessibility Insights which is the browser extension I was showing in my talk so this is well I’ll be honest there are many extensions like this out there why I like this one in particular is that it contains all of the different tests you could wish for in a single package so both the automated ones with Axe but also the kind of semi-automated ones and even more interestingly it also has fully manual tests like I go through the page the whole page myself as a tester and I take notes of what I’ve gone through don’t gone through so yeah it does pretty much everything I hope my talk made some sense I would be keen to hear what people think of Curlylint as well in particular because I’ve been working on this for a while, and yeah not quite sure what to make of it, but yeah.

Any questions fire away Question: you said about the pictures that you can’t see the alt text at the start I didn’t understand why you can’t see the alt text because at least as far as I can tell most of the times you use the template to do this not just take a picture from the model? Thibaud: so I think I understand what you’re saying and essentially that only applies if someone took the time to – well it has to be defined in the models but it also has to be entered in the admin you know like if there’s the field someone needs to fill that field and that’s why those types of fields when the images aren’t just decorative they do need to be mandatory and someone needs to be there adding the alt text.

31:53 - Does that make sense? Question: how are you supposed to show the image if you because as far as I remember it’s not a Django templating system that builds the HTML tag for image how am I wrong here so you would you know you would use the Django templating system to create I guess you would use HTML to create the image tag and in Django templates you just map the images src and alt attributes to the correct but you need to be aware that the alt one needs to be there as well and not just src if that makes sense.

32:37 - Question asker: ah okay I understand you mean that you will need to put something in that because in other situations it would be something generic at least if not there and then, yeah it’s not empty spring Thibaud: yeah so if you don’t put anything in the alt, if you still have the alt equals empty attribute in your templates then screen readers won’t read the image at all they’ll just pretend that nothing is there but if you don’t have the attribute at all, then it will actually read the url to the image file, which as you can imagine is quite bad so the alt attribute always needs to be there in the templates.

33:24 - Then the question that you have to answer in the CMS, sorry, in your models is whether the alt attributes need to be defined or whether it’s okay for it to not be there.

33:36 - So essentially it might be better if I showed you an example actually how can I show you an example, screen share, all right should be back on my screen share.

33:49 - So this is a website we built with Wagtail but again that applies regardless of which flavor or Django you use so these images right there that I was showing in my talk well this is the whole content of this section so here the images clearly aren’t just decorative you do want to know what each of these are so if you can’t see the images well in this case here you want this to say Google, NASA, MIT, Mozilla, and so on, you just want to have the textual equivalent to all those logos whereas if I go further down the page so for example here I have this list of websites built with Wagtail so the images are still interesting I assume but if you didn’t have the images on there if you couldn’t see them you could still see the text underneath it will still stay which website this is so in this case the images are mostly decorative there isn’t that much value in you describing what exactly the Icelandic Opera’s website looks like.

34:53 - All you care about as a user trying to go through this page is the fact that those websites are built with Wagtail you don’t really care what they look like precisely I’ll have a quick look on Slack see whether there are any questions there I was trying to commit to reading Slack as I went through, but of course this was harder than I thought Coen: Thibaud, I’ve got a question, Coen here from the Netherlands, Can you elaborate a bit on the accessibility tools in tests like do you use Curlylint in a test suite or how do you integrate accessibility checks in tests? Thibaud: yeah so I probably need to get a couple of links up before I can answer this just so it’s a bit more visual all right and the link I need in particular is somewhere on there so there is a great, well, very interesting audit again from the GDS in the UK they went through how many accessibility issues each of the common accessibility checking tools find, and.

36:26 - When you see a number like this, 40% of issues were found I’m not sure what what you would say but personally I feel like that’s quite low.

36:34 - I would expect a tool that you have to pay for to find as many things as possible so what this means is that no matter which combination of tools you’re going to use ideally there should still be someone who manually audits the websites, whether that’s as part of code review per feature, or whether that’s towards launch you can do it however you want to some extent but there needs to be some manual auditing but of course manual auditing takes a lot of time it’s the same as doing penetration testing for security you can’t do this just all the time so that’s why you need to have automated tools to help you with the testing, with the QA, and well the problem with those tools is that even though they found quite a big chunk of issues generally you can only run those tools on the rendered page like literally once the site is built and you see it in the browser.

37:27 - That’s where you can run the tools that find the most things but ideally you wouldn’t want to have to wait that long like have to wait for the page to be displayed in the browser for you to run those tests.

37:37 - if you did this in CI well you need to have a continuous integration capability that displays your whole site in CI which can be quite problematic so that’s why it’s important to approach this in some kind of layered way where you have different checks that happen from you typing the code to the site being live, that hopefully means that when the site goes live you can focus on only the things you could find this way.

38:08 - So I guess that that’s what my blog post that I mentioned is about to some extent.

38:13 - Essentially you want to spend all of your time with the tools that find the things as close as possible to the actual code so that’s where Curlylint is useful.

38:24 - Curlylint works on the Django templates not just HTML which means that you can run it as part of actually typing your code whereas things like Axe or the HTML validation well these don’t support Django templates you only can run them as part of your unit test essentially or integration tests.

38:45 - So yeah what I would suggest practically these days is you could try using Curlylint as part of a pre-commit hook for example and then you could use Django HTML validator as part of your unit tests, and then in CI where you have more time for the test to run, you could use something fancier like Pa11y that includes Axe in a headless browser.

39:09 - that was a very long answer so I hope it kind of makes sense.

39:17 - I think we probably run out of time for questions but someone will probably let us know, but if anyone has any other questions again I’ll be around on Slack.

39:28 - All right I’ll be around See you all!.