 We're coming to this talk about WCAG 2.1, Web Accessibility in Drupal 8, although I will have to be a bit upfront. I have been working on this talk for the last week or so, quite a bit. And when I flew over here, I practiced the talk in the flight, and it went for one hour. So I had to cut half of it out, so if you don't like my talk, it was the other half. So anyway, I'm going to get going with this. I'm going to get going. Ah, there we go. So what am I going to cover in this talk here? I'm going to talk about accessibility and why it's important. I'm going to talk about three standards, WCAG 2.0, 2.1, which is new in Web Accessibility terms, June 2018, and WAARIA. I'm going to talk about some approaches to making websites more accessible. Look at some accessibility features of some front-end frameworks and common Drupal themes. And a big part of this will actually be just showing you some useful resources and tools. So I will be making these slides available so you can get these links. So I should get started with who I am. Hi, I'm Morgan. I'm that guy in the photo there in the corner. I started with Drupal way back in 2009, so that's 10 years with Drupal 6.0, and I implemented that as Digital Services Manager at the WA Museum. And I've been facilitating meetups and conferences and the like in the accessibility space since about 2012. I now don't work in government. I work for an environmental technology consultancy, but I still do a lot of Drupal in the GLAM space, more in the museums and archives, but elsewhere as well. And I still run the meetup group in Brisbane for accessibility. So I did get started in accessibility because I was at the museum, which is a very inclusive organisation, and we had a very, very large number of resources that we had to make accessible. So I will talk a lot about what I call an accessible mindset, which is more about approaching accessibility pragmatically and inclusively rather than just making it a means to get through an audit. So what is website accessibility? It's underpinned by this principle of access for all. It tries to ensure that all users, regardless of whatever disability, mobility issues they might face, they can use your website easily. Generally accessibility is used interchangeably with compliance with some standards. Usually we go to Buena. They are different things, but that's when you hear I need to make the website accessible. Often that means compliance with some standards. Now these standards were developed to ensure many common disabilities are not excluded from using digital resources. It does have a very heavy visual focus. Now that makes sense because the web is a pretty visual medium, but more recently we've got a little bit more about cognitive and mobility access, and in particular with 2.1 that came out, there's a lot more about the mobile web and being able to use the phone if there's mobility problems. So why is accessibility important? This is a kind of stock standard slide that I use, but 1 in 5 Australians have a disability. For over 65s, that gets right up to about 1 and 2, and a lot of that's going to be low vision when you get into that over 65 groups. So if you're making your web resource not accessible, you're kind of excluding 20% of your potential market. So what are the types of disabilities? I've just got a few points because it's a very broad term. About 5% of people with disabilities are in wheelchairs. So although that's the iconography and that's the common symbol, it's only a small proportion of that. 30,000 people rely completely, rely on Auslan as their main form of communication, so that's Australian sign language. About 350,000 people in Australia have low vision, and that's predicted to hit half a million by the halfway through this century. And mental health, which is increasingly when you look at the cognitive use of digital resources, is increasingly important. About 3 million people suffer through depression or anxiety, and about 45% of people will have some sort of mental disability somewhere through their life. So outside of the fact that it affects so many people, there's some good reasons from a legal standpoint too. Living against somebody in a digital sense is the same as doing it physically. Now we have a long history in Australia of this because of Maguire versus SoCog, that's the Sydney Organising Committee for the Olympic Games, where back in August 1999, it was the resources that were put online to buy your tickets were inaccessible. Maguire took them to court, and it was deemed that they had to make all of the resources accessible to people with disabilities. At that time, the bar was pretty low, they had to add alt attributes to all of their images and stadium maps so that they could get around. And although it's in the US, very recently, a couple of months ago, Domino's Pizza, which is different to Domino's Australia, which does the worldwide, has pretty good accessibility, went through appeal to ignore their accessibility requirements, and whether or not that would be part of the Disability Discrimination Act over there. It was rejected. So it's important. And if you don't pay attention to the accessibility of your resources, there can be legal consequences. Also, a lot of government projects require WCAG double A compliance, increasingly we're seeing 2.0 double A compliance. So is making your accessibility resource, is it making accessible websites and digital resources hard? Well, it can be, and it doesn't have to be. So what I'm going to talk a lot in this talk about is what I call an accessible mindset, and it's a way of approaching accessibility more so than looking at the standards. So when is it hard? It's hard when design is made independently from accessibility. It's hard when you get a style guide that's signed off by the executive that haven't thought about this yet, and then you've got to rework it or come up with some pretty funky combinations to make it work. It's hard when accessibility QA happens after the rest of the projects happened, and then all of a sudden, you do an audit at the very end, and then you've got to change a lot of things. It's even harder when that happens after the resource has been signed off by the client or the executive. And the last one is very difficult too when there's a definition of done and it's shifting. And when it comes to pragmatic accessibility, there's a very long tail. So you can achieve a lot with not too many changes, but trying to make some particularly dynamic web resources work in all kinds of voiceover on every derivative of Android can get very difficult. So if you've got a definition of done that, yes, we need to hit these major browsers up to this level, up to this thing, and then there's mechanisms that if you're using different unsupported devices, they can get in contact. It becomes easier. That definition of done is part of the accessibility mindset. So when is it easier if you consider it while you're building, if it's built into the process of creation and digital authoring rather than just a step at the very end? So this accessible mindset, and I'll come back to that a little bit more, it's about making resources a pragmatic exercise and making things more accessible when needed. Sometimes if you're inheriting a very large thing that you need to own, there could be thousands of pages, there could be tens of thousands of resources, and trying to make all of them accessible like that isn't necessarily realistic. However, as I get to my second dot point, doing what's pragmatic and engaging with the community is something you can do. So involve these people in your design. Make sure that I'm quite heavily involved with the accessible community, and I often talk to people who are completely blind or low vision and say, what's this like? And then usually, even if you're trying, you will get a long way, where you will not get a long ways if you ignore the requests that come back. And that's what the last thing is at. It's about being responsive, not reactive. So sometimes you might get an approach of there's too much, let's not worry about it. Or this is going to be too expensive, let's not publish it. It's more about, well, how are we going to be responsive? How are we going to make this work? So we'll return to this accessible mindset again and again. The first little caveat, then we'll talk about the standards. I should really add some caveats to that earlier slide. When else is accessibility hard? What's when you inherit something that's totally inaccessible? And when is accessibility easier? It's when you start fresh. Sometimes it's a little bit, sometimes it's hard to forget, remember these points that if you've got something that's really quite difficult to work with, there's a lot of work involved in order to get something even marginally accessible. So let's talk about WCAG. So these are the standards that you hear about. And if you're working for government or applying for government projects, you'll often see these acronyms used as things that you need to be compliant with. So WCAG version 1.0 came out in 1999. WCAG 2.0 came out in 2010. In 2.1, a draft was in 2017 and ratified in 2018. So you can kind of get a bit of an idea that it's about every 10 years. And the next version is going to be called Ag, because it's moving away from website. And it's got the code name Silver, element AG. And it's more about accessibility guidelines for content. What's quite interesting is a lot of work went into WCAG 2.0, and that's still the dominant standard that you'll see out there. Came out in 2008, which is really before mobile phones kind of became a dominant way of visiting the web. So 2.1 was really developed as a way of filling some of those gaps. 2.0 has 12 guidelines. They're organized in four principles, perceivable, operable, understandable, and robust. And they have 12 guidelines, I've written that twice. Well done, Morgan. And 61 success criteria within those. So the success criteria can be classified as AAA and AAA. Generally, if you're making something AAA, you're making it specifically for a particular audience, because there's parts of AAA that you can't really do with this certain content. Sometimes, though, level A, if you're looking at scale, can be harder than some of the hardest parts of AA. So rather than talk about all 61, which I have done in some talks in the past, I'm going to try and make these guidelines a little bit more accessible by talking about 10 things that I would take into my accessible mindset, that if I'm thinking about these when I'm developing, I'll probably make things a bit more accessible. So provide text alternatives. Now, I don't know, you probably heard a little bit about alternative text attributes, which are on images. There's often a lot of confusion about how they should be used. Generally, if the image is decorative, you just leave it empty. Don't put a space in there, because that makes the screen reader pause on it. You just have it empty, and that gets computed as just an alt attribute with no value. If it does convey meaning, then you should actually explain what's inside that image. Organize your code logically. So by the way, text alternatives also mean that if you've got a PDF, you need to provide other text mediums, which is kind of where sometimes the scale gets a bit tough with this one. Organize your code logically. If you use semantic HTML, you'll get a long way with accessible websites. If you chuck everything in a div, you won't get so far. And if you use different heading level sizes to signify bigness, then you won't get very far either. But if you organize your code logically, it will make it a lot easier. Now, there's a bit of a misnomer and accessibility that in WCAG, sorry, that if you have headings, you need a H1 to a H2 to a H3. Technically, you don't. You can actually skip levels. However, because it's a convention, people who use screen readers generally look for the next level when they're tabbing through content. So, although you can technically go from a H1 to a H3, it's best idea to not do that. And another really good example of how to organize code logically. Say, for example, you've got a heading, a H1 on your page, and then you've got a whole bunch of action buttons like a Facebook share or a print icon. Group those icons together under a H2 and hide that from the screen using a screen reader-only attribute. That way, when your screen readers are using the content, they'll read the screen reader or read out the name of the page, then they'll say page actions, and then they'll know, oh, well, if they want to do actions, they want to get to the content, and they can skip through that rather than have to tab through all of the buttons. Then you might have another H2 on top of your content that says page contents, and therefore they're able to move from the actions directly to the content. Mark up your forms correctly. Use labels, even if you can't visually see them, and make sure that the label for attribute means the label is matched to the form element. Make sure it works with a keyboard. That's a pretty simple check. Tab through the content, make sure it's logical. If for some reason you've got some JavaScript changing the tab ordering, make sure it's doing it for a good reason. Use transcripts and captions. Sorry, just make sure I'm not taking too long. Ooh, use transcripts and captions. If you've got a YouTube video, and by the way, I've done some talks on using speech recognition APIs, they've come a long way. They could almost understand my accent now. So a long time ago, you really had to hand transcribe everything you put up as video or podcasts and so on. You can now use some APIs from AWS or from Azure or from Google and just correct it. It's so much easier than it used to be. And YouTube actually automatically transcribes, you just need to correct it. Check your color contrast levels. So if it's a double A, you need 2.5 to one. Now, here's a really interesting thing I've noticed through my testing is often when you have a background color and say your style guide says you gotta use, say, a dark blue. And then your logical reaction is to put white text on top of that to get enough contrast. When it comes to some of the darker colors, believe it or not, you're gonna get more contrast with a darker color. So if you get a style guide and you try and put a white on it and you don't get enough contrast, try using black, you'll be surprised sometimes that works. Avoid seizures. It's good to do that. Now that used to not be so much of an issue until Animated GIFs kinda came back into fashion. And someone I work with who I run the accessibility group in Brisbane with works at the ABC and they have a really accessible website and they got some feedback one day which is like, I love your website but it causes me lots of seizures. And it was because of the way that their Animated GIF player was doing a refresh rate that had a lot of different colors in it that if there's red, green and you've got epilepsy you can get seizures from different types of GIFs. So try and avoid that. Try and avoid time limits. Sometimes you do need them but make them generous. Using headings to organize content. I did talk about that earlier but use them, you can technically get, if you're using a front end framework and a single page app you can get there with JavaScript but if you can use HTML, use HTML native. And use meaningful link text. You've all heard about this. Read more, click here is not great. Click here to read more is not even that much better but if you've got contextual links then they make sense to whoever's reading it. So now we have 2.1. After 10 years we finally have this new version. It's backward compatible with 2.0 but it has 12 new double A criteria and five new triple A. They're the 12. If I have time at the end I'll come back and I'll explain what all of these are. But a lot of them are very much about mobile orientation. Can it make sure that your content actually works if you turn your phone sideways? It can't be locked in one particular way. You might, may or may not know that if you hit command or control plus you can resize all of the elements in your page but a lot of browsers like Firefox actually allow you to independently change the size of the text from the elements themselves because some people want to be able to read that. So if you use hard coded pixel or point values rather than using, so you would use M and REM when it's relative to the base unit that allows the text to resize a lot better within those units. You can't rely on people being able to do say three complicated gestures like three finger strokes or so on. So I'll come back to that if I have some time but these are the 12 that are there and if you have a look at that table I will share these slides that link underneath it is a fantastic explainer because it uses use case for all 12 of these but you can kind of see that nine of them are in the mobile camp. So one interesting thing about 2.1 is it actually has a provision for capture within the accessibility community. Capture is notoriously hard. I would recommend, recapture is a bit better but I would recommend anyone to listen to those audio captures or try and squint your eyes and try and read the letters that are all jumbled up. So, but 2.1 kind of doesn't really give you a good answer because effectively in the draft they say, well if we said don't use capture we know a lot of people wouldn't even try and adopt 2.1 so try not to use it but they gave a few pragmatic advice about capture. So like use two modalities. So if you have some way of, if you have to use capture or recapture is there another technique somebody can use your service? Is there like a phone they can call? Is there some other way that they can get past it? And the last point I think is a really good one which is not requiring captures for authorized users. So that's another way of getting a modality that if they have a user account you've got some sort of authentication therefore you can drop captures on putting comments on and so on. So now Aria. I'm going to go out there and say I'm not a huge expert on it. I do have a person I work with at the accessibility meetup in Brisbane who developed my last dot point and this is a big takeaway. Get the Chrome extension visual Aria. It's developed by Lawrence Lewis who is a genuine expert in the area and he does great talks in Brisbane if you're ever there. Come to my meetup group every first Tuesday of the month. And you can kind of see in that screen grab there that you turn it on for a page and it will identify all of the Aria regions and tell you if there's a label, if the button's marked and give you some really good advice about where to look to improve your Aria. There's 50 tags of Aria. If you use them badly, as is the saying, no Aria is better than bad Aria. If you use something like Aria region live that means the screen reader's always focused to that region when there's changes and what if you're right at the bottom of the page filling out a form and Aria live refreshes you've lost all of your context and you've got to go all the way to the top to find out the cricket score. Not even interested in the cricket, I am, but so you've got to make sure that you use these kind of regions well. Lawrence tells me that if you look at those particular things I've put into MonoSpace, Roll Region, Aria Expanded, Aria Controls, Aria Label, Aria Label Buy and sometimes Aria Described Buy, you're going to go a long way. When you start getting into some clever parts of Aria, Aria Described Buy is a really nice way to describe an image or an infographic that has a lot of information that an alt attribute won't do it justice because then you can use Aria Described Buy to go to a lot of information and explain everything that's happening there. Or you could actually use a paragraph element or some other block element that explains that image. So you've got Aria Described Buy this attribute, therefore you're kind of making that cross-reference. So there's some cool stuff you can do. I'm not an expert, but it's good. Okay, so the accessible mindset. I talked about this a bit. This is what I meant. Don't be scared. There's a bit to do, but like, if you just think about it, just don't be scared. Think about, start small and high value. Using alt attributes, checking your color contrast, using headings properly. They're not difficult things to do. They are hard to retrofit, but they're not difficult things to keep in mind when you're creating content or websites. You do that and you've already created a lot of value and accessibility. Being responsive and not reactive. Be open, so it's like I know this is really hard for government people to swallow when I used to be there, and I'm sure there's some in the audience, but you may not get it right first go. So be open about it. On your accessibility page say, hey, if there's any problems, let us know, we'll work with you to fix it. And that goes a long way. When I was at the museum, that's how we released 10,000 PDFs that were somewhat OCR, somewhat. Being proactive, having inclusive principles. So when you're building your products, you're proactively embedding these things in. So the inaccessible resources aren't getting more inaccessible. Understanding your audience. Now I do say be pragmatic. However, some things are going to be used by certain segments of the community more, and therefore make sure you work around those a bit more. If you're, for some reason, one of you guys are in food delivery, that's something people with mobility issues use all the time. So you need to make sure that you're concentrating a lot on those particular elements of your accessibility audits. Be clear about testing and QA steps. I talked about the long tail. And by the way, these are guidelines. They're interpreted by people. So your definition of done, get that amongst the team. You understand what you mean to make something a bit more accessible. Use tools. Lighthouse is a good one. Wave is a great one. We call Colorchecker is a good one. Visual area is another good one. There is not any technique out there where you can run an automated test, and it will tell you straight away that you have an accessible resource, doesn't exist. So they're important, but the human touch is also important. So I'm now 25 minutes into my talk and I haven't mentioned Drupal. Yes, this is why I came to Drupal South. So what I did is a little bit of a test here is I took a couple of themes and I ran some tests to see out of the box how well they would go with some accessibility steps. So I ended up running the test with Bootstrap 3 and a foundation theme. So a couple of accessibility notes that Bootstrap has really good accessibility out of the box. However, you need to change the color straight away. So if you use the default color elements, you don't get enough contrast. And the RE elements should be a bit more generic than they are. One of my favorite features, and I actually use Bootstrap pretty much for everything, is I love SR only. It just, that is, it visually hides it but allows screen readers to go over that text. You combine that with screen reader only focusable to make the area findable for sighted readers when focused. And it's just a really powerful, just two attributes that you can use throughout that to organize your content and then bring focus to those areas as needed. Most of the elements in Bootstrap have some pretty good accessibility features as well. Foundation. Foundations building blocks are generally pretty accessible as well. It doesn't have as much focus on RER and JavaScript as Bootstrap does but it does have good keyboard accessibility out of the box. Interestingly, I just did like a lighthouse test on the accessibility pages of both foundation and accessibility. Bootstrap's really good. Foundations are not particularly good, which is quite interesting because if you take the themes out of the box, the results kind of reverse. So rather than try and risk a live demonstration, I recorded just this... I had to shorten this video quite a bit but I just did this one-minute video where I effectively got a local site and I bought up a web form because web forms is where a lot of accessibility things fall down and bought out their accessible template and then looked at a sample page and then out of the box used bootstrap and foundation to test the scores. So that's what it looks like. It's a pretty big form. It's got some input areas where things could go potentially wrong. And then I ran a lighthouse test on the pages and on something that had no CSS and there you go. Should be under a perfect score of lighthouse and the form itself has a base of about 78 scores. So that means that there's a few issues with some of the contrast because of the native buttons and a few other areas. So when you look at bootstrap, out of the box you get 90 and that's because the color contrast is not high enough. So the first thing you should do is change some of the color contrast you get with bootstrap out of the box. It also doesn't use ARIA particularly well on regions but yeah, that's not too much of an issue. Now the difference on the form is again down to the color contrast a bit more, which is not too surprising because there isn't really anything particularly different from the default theme but it doesn't affect any of the form controls, which is nice. Foundation on the other hand just has a little bit of an issue with the default colors on the A-links. Everything else is pretty good out of the box so there's not a whole lot of difference. So the foundation theme works pretty well. And then when you look at the actual web form page itself again, not a huge amount of difference because all it's doing is changing some of the colors on the buttons and it gets the text sizes. Pretty good. So the point I'm making is that it's really up to the authors of the themes to actually implement some of the accessibility features and maybe give you a little bit of a heads up when you get started. So if you read my bio you would have said that I was gonna talk about the accessibility features of the Drupal admin theme, including layout builder. This is the first bit I cut out of my talk because there's quite a bit to it. However, it is quite good the way layout builder has been done. A lot of effort's gone into it because it's actually quite well controlled with keyboard. But what I'm gonna do is I'm gonna bring up... So this is a local Dev site I've got, I've got layout builder there and I'm just gonna show off how Visual Aria works. If anyone, is anyone using Visual Aria as an extension? Nope. But if you look closely it kind of tells you it brings up all of the Aria elements and will tell you if a label is not defined or a landmark is not defined. So when you're doing your audit you can very quickly look at it. So what happens with layout builder is that the accessibility of it's very good. The Aria is a little bit affected by the theme that you're using there. So I'm using Bootstrap so I actually lose some of that a little bit. So out of the box if you're using some of the themes it's a little bit better. So because I'm going to now share some resources and guides. So what I will do quickly is show you two guides. One of which unfortunately I don't have permission to share but the other one I will. I'm actually gonna host a birds of a feather session tomorrow afternoon. I'm gonna run an accessibility audit using the template on the left. So if you wanna see some of these principles in action come along to my session. We're gonna take a little look at a lightweight audit. So this is about how would you do... You've built your accessibility mindset into the project. You're now gonna run a bit of an audit midway through and see how it's going. Then if we have a bit of time I'll have a look at a much more comprehensive resource that's Department of Education in Queensland developed. So this was a site. It's actually a Bootstrap 3 site that is built in Drupal 8. This is actually very tiny on my screen so that's why I'm getting close. See, I'm only 36 and I'm already got that low vision thing happening. So what I did with this particular one is I looked at the page and each of these is a view or a content type. So effectively just took one example of all the views that are used in the site and one example of all of the content types that exist. Then rents three tools, which was Wave, Lighthouse, WCAG Colorchecker and then did a manual audit on all of those pages. So you kind of look at it and you have a report on how many warnings and errors there were. Interestingly, when I used Google Street View on this page I returned 25 audits from Google's Lighthouse tool but I was able to get through with zero everywhere else because I was kind of keeping stuff in mind. There were a lot of warnings but a lot of them aren't particularly worrisome and actually a bunch of them were from Bootstrap. So that was Wave, that one, sorry. With Lighthouse, I did a test. I was a little bit disappointed that I could only get them around the 90s and the high 80s but a lot of it, again, was because I'm not an expert in ARIA and it was telling me that the role was required on the attribute of the main column but I couldn't see how to get it to work any other way. And again, the only real errors that I got were on the Google Street View player and I had used the list element maybe not particularly generally correctly on one of my pages because I'm better than Mapinear and that's not good. Lastly, I did the color contrast checks and that was that the logo itself was being treated as content and there wasn't enough contrast. And this will be, if you come to my birds of a feather this is what I'll actually run through is it's basically an Excel template and it tells you each of those 61 success criteria and gives you some pretty simple instructions about how to check each one. Like this is really about doing enough to go, yep, I've definitely considered all this stuff and I'm doing it right. So I've done the test and passed it or made it not applicable and put some comments about how things should or shouldn't be done if something wasn't quite suggest. So at the end of the order, I had Masonry running and I should have really been using ScreenRidder. I should have been using an SR only attribute which I missed. So that is, oh sorry, I should show the other one as well. So if you get, if I can get some permissions as well, this was one that's a bit more comprehensive that's used inside Queensland Gov where effectively it gives a detailed explanation of each selects criteria if it's 2.0AAA and what the rating is that you've given it. So whether it's a fail high, fail medium, fail low and they are defined, a high means you need to actually remediate this before you can go live. Medium is you might be able to live with it if there's some techniques and low is more of an enhancement. And then based and then conditional passes and then you go through looking at each of your content types and at the end it's able to generate a report of which areas you need to focus. So both of them are pretty cool little tools that you can use to run your own audit and if you come to my session a bit later we'll have a look at both of those. So as I want to have some time for questions because this is a pretty high level, I've included a lot of resources that I think might be interesting to you. So if you're doing an audit up at the top there, W3C actually give you a report template that you could use. I mean, I use my own but that's a really nice one you can use. I highly recommend Visible Aria for Chrome just so Lawrence gets more than like 700 users of this plug-in as well because it's really good. There's a link there for some conformance rules, knowing how to use Aria labels, having a bit of an introduction. There was an article by Lullabot on the Drupal front talking about what the heck is Aria and it's probably one of the best written introductions I've seen to it. Accessibility tips for team. For a little bit of time I'm gonna show you that because I really love what the ABC have done here and then some organizations. Tools I recommend, Lighthouse, Wave, Visible Aria and the WCAG Color Contrast Checker. So this is something that the ABC developed and they recently updated for 2.1. It's called Accessibility Tips for Teams. And what I absolutely love about this thing is it really fits into my accessible mindset thoughts that effectively what it talks about is that you've got different roles that you're generally doing. You may do multiple of these roles. You might be a product owner as well as the dev which is not ideal but that could be the case or you could be the dev in the QA tester, again not ideal. But nevertheless what the idea is that for each of those particular roles that you're performing it breaks down what the accessibility requirements would be that you should be owning inside that role. And it's written in an actual quite friendly way. And if you do align these behind the scenes if you look at all of the roles this gets you 2.1. Effectively if you're looking at this this gives you an accessible mindset over the entire 2.1 standard. And as you're doing your role what they do at the ABC is they just print this out if you're in the digital team and Jerry put this together recently and says that the people have that on the desk and they're able to reference that. So I really love it. It's on ABC's accessibility page there's a link right there and it's definitely worth taking a look. And I promise to stop switching media as of that last one. So actually that can perfect about five to 10 minutes for talking so that's what I was hoping for. If you need to wanna drop me a line that's my Twitter, that's my email, that's my LinkedIn. And that is my little talk. Sorry, when I cut out 30 minutes out of my talk I'm mostly cut out the Drupal bits because the other parts you kind of you need that foundation knowledge to then put it into Drupal. But thank you. Questions? What do you think of SQUIS's accessibility tool? I haven't used it, I'm sorry. And you also spoke about videos and captions and that YouTube can or to description it. What if a client embeds a video so they don't know what tools can you use to make captioning easier in that case? Yes, great question. So if you've got, I actually use my personal account but if you take the audio track out of that video and upload it to an S3 bucket or Google actually has a better API you can run via the UI without any code now which is great. That's just after I wrote some scripts for it that will automatically transcript that and actually time code it. It also provides, it pushes a confidence rating on all of the words as they're transcribed from it. As you use that more, it works better. And one of the better tools that AWS have that I don't think Google has yet is allows you to add a controlled vocabulary. So if you're using particularly particular industry specific terms you can actually define those and update that as a reference library for while the API does the transcription. So like I used to work at the museum so somebody in a talk would just talk about pseudoscorpions and they're like, oh yeah, this genius is pseudoteranoclethonia day. You could then define that term phonetically and therefore it would automatically use that. It's pretty good. Midwestern, if you can get all your speakers to just speak with a Midwestern American accent it's gorgeous. Unfortunately, I have an Australian accent. So, but it's getting better. We do speak a lot through on those though. But no, my advice is that still use those APIs and you can output that to an SRT format which is time coded on particular things. There's a bit of an art to using visual to breaking up the captions into logical pieces as well. So it's the API's help. They just kind of do a lot of the grunt work. Just wondering if you could ban designers and developers from developing one common element like a carousel or a dropdown menu or like an animated background image or something like that. If you could, if there's one that's just terrible for accessibility that you wish everyone would stop using. I'm gonna pick a really obscure one because it actually creates a lot of mayhem. And that is when you fix the background of an image while you scroll past it. Simply because that can create a lot of motion sickness and it's very difficult to override using your device. So like with a lot of other things that you put in bad accessibility features you can increase the contrast. You can change the tech size. But if you fix the background image as you scroll past it you can't do a whole lot about that. It's a good question though. One of the things we're starting to look at in the New Zealand government web standards is actually having picture-in-picture sign language translation as part of videos. Great. I guess, sorry, not really a question, just a statement, your reaction to that? Well, it's one of the AAA standards. Guidelines, sorry, a success criteria is to use why you can't 100% get a lot of AAA is that if you say, for example, you're servicing Australia and New Zealand, Auslan is different to New Zealand sign language. But no, if you're doing that, that's great. That's just another technique. I think, as I said in one of my points, I can't remember the exact figure. But in Australia, 30,000 people rely on Auslan as their primary goal. If you're part of the government, I mean, it's about one eighth of that, so it's probably gonna be about seven or 8,000 people whose primary communication mode is New Zealand sign language. So that's a great initiative. I'm just wondering, is there any build script like LinkedIn sort of tool that you can use rather than manual plugins for Chrome so we can catch stuff, have the robots catch basic errors? Probably. Jana, you might be able to answer that a bit better than me. Because generally, I'm a project manager, technical project manager, so I generally do the audits. But yes. Yeah, you can actually use Lighthouse. There is a NPM Lighthouse version, and it extracts, so it does basic accessibility test on contrast on all of that, and it gives you a score so you can pipe it into your CI and you say, oh, accessibility of this page is like 90%, it's good. But then you will still have to do manually checks. But Lighthouse from Google. There you go. Increasingly, the trend is to make alt empty because we went too far and said, put an alt on everything and then all the sudden decorative images are screened and people are screened, they just want the content, they don't want all of that stuff. And a lot of the time you use visuals to reinforce what's already in the text because that's a design technique but it doesn't actually add any semantic meaning. Just on the alt there, I use GovCMS a lot and one of the inbuilt parts of the media upload is that the alt field is mandatory. So you would suggest removing that as a mandatory field? It's quite interesting. A month ago we had the guys from Tiny MC come to the accessibility meetup and we were having this discussion where it's tough because a lot of the time, if you're putting inline images via the WYSIWYG, it probably has semantic meaning. A lot of the time when you're putting images in that when they're decorative, there could be like the background image toward banner, they could be something fixed in which case you got a little bit more control and it's in the code. But if you are putting text in there, it's potentially the lesser of two evils because you are at least forcing authors to just not go, oh yeah. Because as I said, there's a trend towards using alt empty because it is decorative but if everyone's got that choice then it's very easy to just say, hey, I'm doing my job because it's decorative. But in the idea, there's still a fine balance and there's that human element. So it was actually, we had a bit of a dialogue back and forth and it was a pretty split call between the people on the email thread as to people who think it should be mandatory and people who think it shouldn't be. I kind of think when WYSIWYG makes sense because not everyone's aware of it and at least it forces people to add a bit of meaning to the text. Thank you. You just had a question about pop-ups and like with screen readers, you can make them sort of accessible but for the one, the case I've got a problem with is people using those Zoom sort of magnifiers. That's just waiting for them to come across how to sort of make them interact with those sort of things. I just wanted to also enter the debate about the alt thing. I was taught that to make it null, you put it like an empty quote in there. The screen reader wouldn't accept that as a blank. And then it would keep the, if you use an automated checker, it wouldn't flag that as error because you've got something in there but it's null essentially. I'm not aware of that last part. Generally, like if I can hand code it I will just go alt equals double quote, double quote with no space in between because then the browser will compute that as just an alt. So you still have to double quote. Yeah, yeah, yeah, no, it's only computed empty. You still mark it up as equals double quotes on that. So sorry if I wasn't clear on that, that is what I meant by empty. Yeah, as for the question about making Zooms within modals more accessible, it is more difficult. I mean, a good example would be that you click on an address location, brings up a modal and it has a map that allows you to go in and out of that. If you inherit good keyboard controls it should make it a bit easier. Yeah, so if you try to be a bypass, if you try and bypass standard behaviors that the browser gives you and embedded kind of zoom functions then it gets a bit harder. And I know that's not a great answer but it's gonna be horses for courses depending on what you're zooming in on. Thank you, thank you. I have a question about adding skip link inside the content. So the recommended one is to be just one at the top to skip the content. Skip content and skip to nav, yeah. What about skipping galleries or skipping carousel? Yeah, I recommend it. Look, the minimum would be skip to the main content area and skip to the nav. But yeah, if you wanna go down that further I'm sure many of your screen reader users would enjoy not having to tab through a carousel. Thank you. Sorry, one step ahead there, which is good. Cool, all right, thank you all for listening.