 All right, well, away we go. Welcome one and all. Thanks for being here. Very excited, but like so. All right, get it in the stereo. We're here to talk about accessibility and happy to be here at DrupalCon. First, just wanted to get a little bit of a sense of who we're speaking to, where you're coming from. We want to be sensitive to our audiences. Just wondering a little baseline test if you can raise your hands and snap your fingers to, for maybe anyone you can't see at home or here, if you use websites. Yes, okay. How many of you are technologists? In other words, you're responsible for fixing accessibility issues. Ooh, massive. Okay, who's responsible for accessibility governance at their organization? Good, good. Who's a designer? Yes. Who's done an accessibility audit before? Oh, okay. Well, I think that requires a little round of applause. Good for you. All right. Well, who are we? My name is Andrew Malis. I am a six-foot tall man with long dark hair and a mustache, is here. And I am CEO of Calamuna. We're a digital agency. We'll talk a little bit more about that, but not too much, I promise. Yeah, I'm Mike McCaffrey. I'm a senior architect at Calamuna and I am the lead of our accessibility practice. I am also a tall man, very white. I'm wearing a wrinkled shirt because I did not take my wife's offer of a hand steamer to take with me and I'm wearing a hat because I still cut my own hair because the pandemic is not over yet. So thanks for being here. Calamuna cares a lot about web accessibility. We believe that the internet should be built for everyone, not for fear of legal action, but because it's the right thing to do. Without diminishing the negative consequences of non-compliance, we invite organizations and individuals to approach web accessibility with humans in mind. We wanna share with you some of what we've learned over the past decade plus of doing this work. We're going to, we've already done introductions. We'll start by talking a little bit about some foundational principles and move into some details regarding auditing and remediation. A little bit about design and development practices. I think we'll cover a good round amount of that for you in the room and finish up with some thoughts around governance and a little conclusion. We'll also have a resource that you can download if you want. Beginning with principles, they're important. They're the foundation. What does that really mean? For us, accessibility is grounded in inclusion. Inclusion as a global diversity perspective is defined as an organizational effort and practices in which different groups or individuals having different backgrounds are culturally and socially accepted and welcomed and equally treated. So this means regardless of race, gender, religion, ability, everyone's treated respectfully and equitably. Equity is really the key. We have to recognize that not everyone is equal in terms of their abilities and that's okay and we can take steps to ensure that everyone is accommodated appropriately so they can contribute and participate. Examples of accommodations in the physical world include curb cuts, wheelchair ramps, and auditory indicators at busy street crossings. But being inclusive means thinking about how we can accommodate everyone and giving that attention and energy so that people can feel included. Those differences could be self-evident. They could be more inherent involving educational background, training, experience, even personality such as introversion, extroversion and that inclusion, it creates a sense of belonging. Inclusive cultures make people feel respected and valued for who they are as individuals and groups and that process, it helps organizations succeed. Organizations that are functioning at their full capacity improve morale, effectiveness and collaboration as well as a sense of self-sufficiency and resiliency and that's why we do this work. It's important to consider that compliance does not guarantee usability. A lot of organizations focus on conformance. It's not a bad thing, it's important to make sure we're following some standards but over reliance on it can be a huge distraction. We're seeing as an agency many times in contracts that clients send us, you have to comply to all of these things and there's a really strong push and a danger there that those requirements can push away from usability into a space of conformance because agency are afraid of being in breach, they may not negotiate those contracts and so it can kind of lower that standard or impoverish the experience for users online inadvertently. The reality is no agency can really guarantee compliance. Open source software ecosystems, they can inadvertently introduce issues upon updates and content editors can miss the mark too. All text can be there but is it descriptive? A button is there but does the form really submit? So these are all issues we have to be concerned with. We gave a previous talk with our friends at the American Foundation for the Blind in which we demonstrated how vaccinefinder.org was WIC had compliant according to automated testing tools yet it failed keyboard navigation and screen readers as well. It's important not to fear a lawsuit and hold you back from focusing on what matters most, helping users achieve their goals. All right, I am gonna talk a little bit about site auditing and remediation which basically means finding out what's wrong with your site and fixing it. It's very fun. Three types of analysis we're gonna be talking about is automated testing, user testing and usability or heuristic analysis. There might be more but these are the three we're talking about. Automated testing. Okay, you're on that side all right? All right, there's lots of automated testing tools you can use and that's usually the first thing that people reach for when they think about accessibility like, oh no, I need to see how accessible my website is. So they go and they're like download some browser extensions that will scan your website and tell you how accessible it is. That's one of the easiest ways to do it. It's great, they're mostly free. Two of the, we have screenshots on the thing showing two tools that we use which is Wave and AXDEV tools. Those are just two of many and but that's fine because you actually need many. You can never really trust one tool especially with these scanners. You can see from these two screenshots that we did a quick scan of our site. There are still some issues. We'll talk about prioritization later. And you can see that they came up with entirely different issues like the two different tools are flagging entirely different things. And some of them aren't actually real issues that you used with this face like that contrast error that is the contrast of a visually hidden heading which no one is actually seeing because it's visually hidden. So it really doesn't matter what the foreground and background colors are. Next slide. The other thing that people use for automated testing is site-wide scanning tools. They're really helpful for catching content issues since it scans every single page on your site and all the content within whereas the single page tools are great for headers, footers, navigation, stuff like that. Site-wide scanning, great for catching images mixing all text in your blog post and stuff like that. They do have some downsides. It can be frustrating if they flag a issue that appears on every page on your website and you have to keep dismissing it or dismissing it or every time you get a new page, it brings that issue back. But there are some good tools out there. Two tools that we regularly use at Kalimuna are DinoMapper and Siteimprove, which would be really good. They catch a lot of errors on websites and so they're great to scan your site with. And they're very useful to monitor sites over the long term but that's if you can afford it because these sort of site-wide scanning tools are very resource intensive. They crawl every page on your site and sometimes like frequently so they cost money and lots of places charge a lot of smaller organizations can't really afford them. And sometimes not frequently enough and you have to kick them to get them to re-scan and these scores, a lot of them are proprietary. You may feel really good because you have high score but the score is perhaps derived from an average of your industry. And your industry is doing really poor and you're on top of it but you're below others. So these aren't necessarily all objective measures. Sometimes they are feel-good measures and we talked earlier about the need for compliance. People that are at the top who don't really have like the day-to-day operational responsibility of the website but who are accountable for its accessibility they may need something that's telling them hey we're doing better and better and better and this can help to provide that sense of assurance while we're focusing on what really does matter in terms of usability. So as I mentioned don't rely on a single tool because no tool will catch all of your issues and they all catch different ones. As Andrew said the scores not actually your real accessibility scores are just kind of your related accessibility scores to other sites and the other thing with these automated testing is it takes a lot of effort to make all the errors go away. I'm not sure if people have tried to get rid of all the errors in their accessibility scanning tool but it is nearly impossible to make them all go away. And on top of that only well the common is 30% of issues can be caught automatically of the WCAG success criteria. Only 30 to 57 of them can use automated scanning to catch all the errors. Every other one you need to manually review all of the elements on your website and go through a bunch of checklists which can be very, very time consuming. And even if you do all of those and ensure that your site is the code is compliant that doesn't actually ensure usability at all. So next up we are gonna talk about user testing which can help you find out how usable your site is. We won't go into how to do user testing because that's a whole subject on itself but basically the process that we use with our clients is determine some of the highest priority stories or user journeys in your site, the things that people really need to do when they go to your site. And then we help them find actual people try to accomplish those tasks and report back on how well they do. When we're testing for accessibility it's important to actually find people who use accessibility tools on a daily basis or those that require accessibility, accessible features in order to use websites. And we try to get feedback on not only whether they can accomplish tasks but also how easy it is to do that. Luckily it's really hard for people to find people with that much experience using accessibility tools but there are companies out there who provide accessibility testing, accessibility user testing, a company that we've been partnering with recently is UsableNet. This is a screenshot of one of their reports where we had a client have five tasks that were important on their site and we had four users go through and try to do those and you can see that for four of the tasks all four users managed to complete it but for the fifth task only three of the four users completed it. This is sort of the example of a user journey for user testing not to go much into it but it's basically the journey description like user can navigate to how to apply page and follow the instructions and you'd give the tester a starting URL and instructions on their basically their background where they're coming for and what kind of information they're looking for and then the success criteria of how do you count it as a success. And this is the sort of feedback this is a screenshot of one of the pieces of feedback for one of the testers and one of the tasks. Basically they can come up with lots and lots of feedback which is great if you find people who are well versed in accessibility. So in this case it would be like the tester three is like the program menu element was inconsistent in behavior. There were instances where JAWS would navigate to the development grants page when the programs menu is entered upon and there are instances when the keyboard did not interact with the element. So you can see they actually did complete the task they eventually found the information that they were looking for but they had to take a very secure way through the site in order to do it. So the downside of this sort of user testing is you only do a limited number of tasks because for an example with this it was a 61 page report for conducting five tasks. So that can be kind of overwhelming. So it's useful to have educated remediators that are available and ready to be capturing this information as an organization it can be a lot thrown at them. And sometimes we see that it's like oh we wanna do that we run a test and then oh now we have way more problems than we thought we don't even know where to start and it can be kind of overwhelming and then they're running the automated scans on top of it and now they have like a huge mountain that seems really insurmountable. So it is good to pair these kinds of programs with that kind of support to parse and we'll talk about prioritization later. Yeah, for organizations that are small mission driven organizations you might not have the resources to hire a company to do user testing. So in some cases you might be able to use volunteer testing if you have volunteers who are really into the mission who have experience with accessibility tools. But whenever possible you wanna be able to compensate your testers particularly if you're a for profit organization and don't rely on just your users to test your website for you. And the third thing we're gonna talk about that sort of combines the best of both automatic testing and user testing and it's sort of one of the things that we've been exploring recently at CalMona is a heuristic analysis of usability. So basically if you think about accessibility in terms of usability you actually get access to a whole toolbox of practices that the usability design industry people have been using for years in order to evaluate the usability of a website. And one of those is the heuristic analysis where it involves having a small set of evaluators who are experts in implementing this sort of thing examine the interface and judge its compliance with recognized usability principles or the heuristics. And in this case the heuristics are the different ways that your site needs to be accessible. So CalMona when we do a heuristic analysis we have sort of a blank worksheet that we fill out and it contains a bunch of heuristic items and then we have several different developers and designers go through and test those. This is one example up on the screen now. It's contrast and size allows text to be read clearly which is a pretty simple thing and it's very easy for people to go on the website and just look at it and see if the text is of a proper contrast and size to be read. We do have in the italicized text a bunch of things to look for when you're conducting a heuristic analysis. Now the one way that this is different than what we were talking about before we were talking about a bunch of checklists and manual review and if you've used like the automated tools or have you do a checklist of like check this page for this, this, this, this. That's a very intensive process especially since like not every page is a video element or something like that or not every page has flashing like things and so you checklists involve a lot of time whereas in doing a heuristic analysis sort of look what's on the page and evaluate it. We try to do positive findings first because you know criticism sandwich well open face because we just start with it we don't end with it. But also it's good to see the different ways that a site is accessible because you know a lot of effort has gone into a lot of things so it's really good to call it out for both clients and also to keep you know to tell them what you have checked whereas like you know you can say we check this page for this and it looked good and we try to call it urgent issues and these are kind of the roadblocks the things that would make the site unusable for some segment of the audience. We call those out in a sort of high priority items that really should be solved like if a keyboard user can't tab through the menu that's a you know they can't navigate the site so that's an urgent issue. And then we also just log every issue that we discover and we usually have like three or four people go through this worksheet and then collate all the results and that gets us a vast amount of usable issues on the site. Next slide. I'm not gonna go into all the heuristics we use but in general we do a visual review for all the visual elements to make sure that everything is clear and identifiable and readable. We have five different navigation, five different navigation categories for basically different interfaces, mouse, keyboard, mobile, and screen reader. You really should have voice command navigation there I had in the other slide. And then we also check robustness. What happens at the site is JavaScript is disabled on the site or something doesn't load and then also cognitive considerations which is how comprehensible the site is and that's a little bit of like content accessibility and how easily understand. But also just like is it clear where you are in the site? Like when you're navigating through the site you know where you are, do you know what section you are, do you know how to get back to another section and stuff like that. It's a lot of considerations around navigational cognition. And so the pros of doing heuristic analysis which we all recommend, I love doing them is it's really efficient resource use. Instead of paying someone to spend hours and hours going through all the checklists you can have skilled developers look at your website and spend maybe like 10 hours total and find a whole bunch of accessibility issues. And since it's looking at what's on the page and just trying to use it with a keyboard and a mouse and a screen reader and stuff like that it's really focused on usability just like with the user tests. And it finds issues that like automated tools might not flag because automated tools look for code compliance and not necessarily usability. And the heuristic analysis when we're going through the pages we might use tools for that like for color contrast we would use a color contrast calculator just to make sure because it's like that great it might be a bit too light. But yeah so there are some drawbacks and one is that it does require expert knowledge that you need actual people who know how to build accessible websites to look at your accessible websites. It's really good to be encouraged other agencies to do this because if your agency has experienced developers with accessibility knowledge having them help do heuristic analysis of clients websites is really a positive way to catch accessibility issues. It does require like two to four people to actually do a heuristic analysis lots of people are just like oh we'll have one person go and go through the entire worksheet and find all the issues and that doesn't really work. The whole point is you have multiple people look at it and you catch more issues. Some of the usability folks who do heuristic analysis did a study and found that four people is ideal cost to benefit ratio in terms of the amount of people versus the amount of issues identified. So that four people will catch like 90 something percent of issues on the site. Now heuristic analysis isn't comprehensive it won't find every single issue because you're sort of time boxing it you're spending a certain amount of time like 10 hours, 20 hours or something like that looking at the site but it does find the highest priority issues. And it's not really focused on legal compliance and making sure there's no errors and stuff like that it's really focused on usability. But those cons could also be pluses we don't necessarily want to focus on compliance first and whereas expert knowledge is required when you're building a team of practitioners and you've got three, four people on it you can have uneven levels of understanding and lift more people up and spread more of that knowledge across the organization and create a broader and more resilient accessibility practice. I mean we usually do have like at least one junior developer working on one of these teams and they learn a lot about the issues that we find. Cause after like everyone gets together right and talks about it it's not completely blind. So after everyone goes through the worksheet to come together and discuss it and sorry I didn't include that but like the high priority issues before you deliver to the client we definitely have a discussion about which are the highest priority issues in here which actually goes on to the next. Oh, okay. Not every organization though can probably afford to pay a wonderful organization like Helena to do a heuristic analysis for them but that doesn't mean you can't sort of do it yourself. Lots of people are intimidated in order to like try to test the accessibility of their site but it's actually really easy to start. Load up your website and then just start hitting the tab key on your keyboard and see if you can get through the whole page and see if the focus is visible the entire time and see if you can do things like open menus and stuff with your keyboard. Really easy, don't need anything special. Cause keyboards are like most of the assistive technologies leverage the same fundamental characteristics as a keyboard. So if it works with a keyboard chances are it works with more specialized human computer interfaces. Yeah, and you know I encourage everyone to try using a screen reader it could be very intimidating and as soon as you turn one on for the first time it just starts yelling everything your screen on you. So, and then you don't know how to get to stop and it's a whole thing. But you know if you push through that and you know just learn a couple of basic screener things like especially navigating a webpage by region and by headings you can really tell that the page structure of your site is clear or not when using a screen reader. And also try out voice control tools. You know, we're sort of getting to that now. Most operating systems have a voice control tool built into them where you can tell your computer dude and just go, you know, hello computer and it feels like the future. Yeah, and since you might not be an expert in building an accessible website you might not catch or using, you know these accessibility tools you might not catch every accessibility issue but you can really catch the obvious ones. So, you know, if a novice person can catch sort of an obvious, you know usability accessibility issue that is a good win. So now you found a whole bunch of issues. And now you have to figure out how to fix them and you only have limited about a budget. Since most organizations do have limited time and resources you can't actually fix every accessibility issue, like I said before like if you take one of these automated scanning tools and fix everything it is expensive and time consuming. And really there's no end to the accessibility issues that you can find with a website. You know, we build accessible websites and you know, every single day or every single week we're like, oh if we change this it would be more accessible and more usable. So it's kind of a, you know, it's a process. It's a process to go through a time with always trying to make your site more accessible and it's not an actual thing you complete. Partition is also important because you really want to identify the user, identify the accessibility issues that are actually roadblocks for your users that will keep certain segments of your users like screen users or something from using your site and you really need to identify those roadblocks and solve them before, you know, minor accessibility issues like a, you know redundant ARIA role attribute or something that the tools will flag. Also look at like what user journeys in your site are more frequent or important than others. Like if someone's coming to your site to do, like if 99% of the people are coming to your site to look at the time of something or something like that on your site you want to make sure that user journey is accessible because that's where the most people are going and it's less important that they read your blog post on your company picnic or something. Yeah, or any sort of emergency alerts is often an overlooked thing. If your site has an emergency alert you kind of want to make sure that those are accessible so people coming to your site to find out about the emergency can do so. I wrote several blog posts on that on alert banners and emergency landing pages so check out hellamoon.com for that. And also prioritization, you might identify some quick wins where some spend an hour or two fixing something you can, you know, solve an accessibility issue and it feels really good to get those quick wins done. This is just a big intimidating, screenshot of a spreadsheet of a whole bunch of issues. This is sort of kind of the way we work through this stuff with clients is we just log every single accessibility issue we find in a big old worksheet. We flag them by the issue type so they can be kind of grouped and then we estimate how long it would take to complete them along with the priority and the importance of solving that. And that just sort of lets you prioritize your issues based on how important they are and also flag some of the quick wins where it's like, oh, this will take 10 minutes to fix so we might as well do it. Can be really useful, you know, getting, especially if you're starting early on, you know, doing an activity like this, getting clients in the mindset of like progressive enhancements and something that you can continue to iterate upon and getting a sense of, you know, relative effort. So we also will identify things that the client is able to fix themselves and differentiate or areas where, you know, training is needed. Okay, this is a list of high priority issues that, you know, we tend to find on websites when clients come and have us review them. I am not allowed to read them all because I can talk about this for hours and Andrew says we don't have time. So we will come back to this if we have time at the end. Go on to the next one. I thought we didn't. Yeah. Just one thing to note that, you know, we talked about the different types of identifying things. We talked about the automated tools and the heuristic analysis and the user testing. But just one thing is try to fix the issues you know about before user testing. If you're having humans actually go through and try to use your site, you don't really need them spending time describing the issues you already know you have. So if you are doing a redesign or a remediation project and want all your accessibility stuff, but you do want to use your testing, usually do two rounds where we do all the things we flag, either automated testing, heuristic analysis, and then we bring it to users who hopefully then will have a very pleasant experience and won't flag too many issues. And the sooner you can fix an issue, then the less painful it is over that period of time for someone using your website. So why wait? Yeah, quickly, oh, this is yours. We're gonna talk a little bit about design and development practices. You know, there's doing your best and there's best practices. And we're always learning and that's what we're here to do in conference. So I mean, hopefully some of these are helpful and hopefully we'll learn some from you along the way. This is a diagram that we like to show our clients about the different phases of a project. And it's important to incorporate accessibility considerations early. It starts at the very beginning. This works best for new projects, but like a redesign, but you can also leverage this for new features. And it really helps if everyone on the team from content producers, designers, developers, even project managers all have a basic knowledge of accessibility concerns. And if not, then you gotta find someone to bring them onto the team so that perspective can be represented. Now during discovery, we're defining our user types and our goals and this is super important. It sets the stage for the entire project. It's really crucial to incorporate these goals and identify accessibility concerns. For example, we might have a user type or persona that represents people with disabilities and they might have a specific goal that turns into a user story like navigate the site with keyboard. And this gets the design and the development team and the client on the same page about ensuring that adequate accommodations will be considered later in the project, but also early on. Now sometimes the client has a mandate, but if they don't, it's an opportunity to educate them on the importance of ensuring their site is accessible and reassuring them they can still have a beautiful and highly engaging website. It's a lot harder to do later. So once that buy-in is there and that those guidelines are set, then in the design phase, which also includes content strategy, but often content production, those considerations start to get incorporated. For example, content as it's being written should be structured semantically even while it's still in Google Docs or Word or whatever tools are being used rather than kind of imposed after the fact. Wireframes can take into account things like labels, menu structure, wayfinding, important interactive elements and then later in visual design, things like links, focus states can consider progressive enhancement techniques for motion, including animation and transitions. Then when we're prototyping components, which would be in the delivery or support realm, there's opportunities to test the designs. It could be a low fidelity, low fidelity clickable wireframe, fully responsive HTML, CSS prototype, or we can, and then we can test those with real users to flag potential issues before building them into the final product. But we're defining it early, those considerations, we're dealing with them through the design and implementation phase and we're not waiting until delivery. It's important to do some final QA before you launch a site, but by that time it's really too late. You're gonna end up with a very costly or expensive type of conversation or something that could delay the launch of a website with some small measured approaches. The raising of that consciousness can happen much earlier. At the end of the day, we want to design with usability in mind from the start. Early on in the process, define what the success criteria are, most of the time that looks like WCAG AA for us. And those design choices need to be documented and validated. We're looking at those, again, progressive or enhancement or graceful degradation options and some strategies for motion reduction and in-browser prototypes. I mean, this is really important. We really enjoy doing these. It's hard to test a wireframe. It's hard to test navigation and usability unless you're using the native medium of the web. It can be more expensive to generate in-browser prototypes, but they are kind of the gold standard for being able to test with real users and assistive technologies along the way. I should also mention that accessibility isn't just limited to the final product. You really want to pay attention to your stakeholder groups and make sure that your process of designing your website and developing your website is also accessible. Diagrams can be really fantastic, but screen readers will have a really hard time with them. So if you have low vision or blind users on the client side, consider using spreadsheets and other kinds of tools that can be made more accessible and ask before you just assume that all of your normal processes are really gonna be inclusive. Here's an example of some aspect of documentation and an improvement program. So colors can be set, corporate colors are set. You've probably seen these brand guides and they're all made for print. You've got one page with something for the web and you're just like, oh, great, here we go. So we gotta modify the colors and make them more accessible. And so we did that, we highlighted a few of them that were going to be made. There's an accessibility green and accessibility blue now. But what is often forgotten is how these colors are gonna work together. So here's an example of a chart. It's sort of a grid that combines all the different colors and evaluates them for how closely they pass the different WCAG standards based on contrast. So you have a little contrast numbers and we'll tell you as well based on where those numbers for font size are and this will allow you to safeguard against inaccessible combinations because someone will point to their colors and say, look, no, I use the colors, right? But purple on blue just doesn't fly. All right, let's talk about sort of an overlooked part is the gap between the designers and the developers. Kind of wanna make sure the design team needs to make sure that the developers have everything they need to create an accessible website. For example, you need to define for all your links and buttons like hover and active states to make sure that those are available. If designers don't define basic things like hover states, then it's kind of like up to the developers to do it and they might not choose colors or an effect or something like that that is accessible. So the more that designers can try to define that stuff, the better. It's really important that during the design phase you think about the keyboard and screen reader focus order. This is especially important with sidebars because people love doing sidebars with menus in them and then you're like, when it goes to mobile or when a screen reader is reading it or when someone's tabbing, do they go to the sidebar first to read the important menu or go to the content first? So during the design phase, think about that, including obviously layouts across screen sizes. I mean, developers know what it's like to get a design that's just desktop or just desktop and mobile and you're like, what's in between? So the more you do that, heading levels and sort of visually hidden headings. Basically, there's a lot of, we see a lot, there's a lot of sections of a website that are apparent their purpose from how you look at them. If you see a series of cards that all have dates in them, you're like, oh, this is a calendar section, but obviously for screen readers, they don't know that it's a calendar section so there really is an implicit heading there of upcoming events. So the more designers, if the designers choose to omit a heading of a section, they should also say put visually hidden heading here that says upcoming events because it might not be apparent. Same thing, try to remember do all icons and stuff like that. Tell the designers what the alt text should be. I'm constantly sort of going back to the designer just saying when you put this icon of a telephone there, should it say call me or a telephone number? And then also just make sure that all form elements and forms, all the forms on the site are thought of and the proper labels and types are applied. When things are actually in the developer's hands, there's some sort of important principles. The first is use code that is proven to be accessible. Like Drupal, we as a community have spent a lot of time resolving a lot of accessibility issues and coming up with new accessibility features and affordances and when you use a content management system like Drupal, you get a lot of accessibility out of the box. You get a lot of code that your site is doing that you know is accessible because it's been tested. Any custom code you write? You've got to do a lot more work testing to make sure that it's accessible. Watch out for front end libraries like sliders. A lot of them have not been designed with accessibility in mind, but for example, sliders, the one we tend to be using is accessible slick, which is basically a fork of the slick slider that someone has tried to make accessible because there's no real good sliders that are made accessible from the ground up. If anyone knows about any, please let us know because we're trying to find out. When doing markup, do things like trying to use HTML5 elements that have implicit roles like header and footer and section rather than trying to add aria attributes to it like role, content info and stuff like that. The more you can use this plain HTML that has good semantic structure the simpler it is, there's actually been studies done that have recently that have shown that websites that have a bunch of aria attributes and stuff where they're trying to do accessibility actually end up having more accessibility issues than just regular websites where they didn't think about it at all. And one thing we've been doing a lot is pretty much everything that expands when you press it we've been using details elements for because they are a native browser structure that have a summary that you click it and it opens things and it works without JavaScript and you don't need aria controls attributes and aria expanded and anything else like that. It just works and screen readers tend to all support it now and yeah, very useful. And then sort of as I keep harping on pay extra attention to the navigation and page structure it's really important for screen readers to make sure that you have proper headings and are able to use the navigational elements on your site because they're really hard to do excessively. And also cautionary computers, not very good at making your site accessible. Lots of people try to use accessibility overlays where they're like pay some people to put a little JavaScript on your site that like messes with your code and it doesn't work, just it tends to break things more than fixes it and yeah, it's not great. And another disturbing thing I've seen, I've seen people trying to ask chat GTP to give them accessible code for their websites and yeah, it doesn't work well. The one example I saw like you know, thought that like you know, for just an HTML button they were asking for an accessible HTML button and it's like oh and put all these tailwind classes in it and it's like okay, yeah, so don't do that. And you know, we're not saying don't use code and develop code of course, you know we're up just contribute back, make these projects work better, be vocal about things you find don't work as well and you know, we'll make the internet a safer, happier place. Another big thing is that like after the initial development of your site is done, people are still gonna change it. There's these people who just keep trying to add content to websites, sometimes every day. And you need to make sure that over time your website stays accessible and it's sort of good to try to architect, especially your editing interfaces to make accessibility easy for users. Try to define sections with proper heading structures so that the users don't have to do everything in a big whizzy wig. Personally I like using the paragraphs module for sections on the page and they can just add section after section after sections with paragraphs. You know, I usually add a text field where they type in the H2 tag as a section heading and make it required so that each section on the page has to have an H2 heading. Sometimes they don't want it visible so I give them a little checkbox to hide it. So that's a good way to ensure that you know, every section on a page, including things that should be implicit like introduction. No one wants to add a heading to the first thing because anyway. And try to restrict whizzy wigs like headings three and below just so less of the page structure is left to the whims of the content editors. And then just try to do things like, definitely use like the media library for images and make alt text required and try to have the interface enforce some best practices. Well, how do we make all this happen or keep it from falling apart? It has a lot to do with governance and governance are systems of rules, agreements, conditions that we set to ensure success and adapt over time. Organizational governance can vary a lot depending on the size of organizations and Suzanne has a talk later that's focused solely on governance which I would encourage you to check out. And education is a really big part of it. It's important to create pathways to knowledge that empower a broad set of users and a broad set of organizational members. It's great to have champions. You actually, you need champions. You need at least one champion within the side of an organization for accessibility initiatives to really be successful. Someone needs to care, someone needs to be the rallying cry. It's kind of like, I don't know if you've worked in a corporate setting there's like someone who's the fire marshal and they've got the little hat on their desk and they take it seriously but then when the fire alarm goes people don't keep working, they get up and they do the fire drill because there's the person they don't want to let down. But you can't have that knowledge all be concentrated in one person otherwise it's just, it's always their fault. They feel like they're the enemy trying to tell people they're doing things wrong and it gets to be a lot of pressure and pressure can break people. So instead, larger efforts, reinforcing peer support, learning, encouragement, all really key ingredients to having strong governance. But what is all of that without accountability? It's great to say things but it depends who's saying them. Buying from the top is really key. The organizations that we've worked with that succeed the most at making accessibility inroads, at seeing their sites be available to the broadest number of users all have someone who at the top set the tone and that's really, really key. Policies, accessibility policies, other internal policies, those are important to reinforce the culture and last we mentioned earlier some aspects of content governance but ensuring that accessibility is enshrined in those processes. A lot of them are internal and part of how content teams work. So that's really key. Making content accessible means making it so a wide range of people can use it including people with physical and cognitive disabilities including reading disorders, attention deficit disorders, memory disorders and accessibility it's important to remember it can also be situational in the event of a crisis your brain's not working the same way. And you might have heard a lot of people watch videos with captions on because they're in a library setting or it's just a common place. So it's really important to consider these things more broadly but emphasizing plain language is really key. There are tools like Hemingway that can highlight and suggest when words are too complicated sentences too lengthy. Sometimes I wish I had a real time Hemingway because I could be a little verbose but Flesh Kinkade is a test that you can perform to report on the grade reading level of your content. And if you're able to make your content at an eighth grade level or below you're going to be reaching 80% well if it's all eighth grade you'll reach 80% of Americans and more and more the lower you go to give you an idea of what that means. Around the world in 80 days by Jules Verne is about a level eight. Harry Potter and the Sorcerer's Stone is a 5.2. Right for inclusivity that means being aware of writing gender inclusive language and all of those are also I think bound into a broader governance conversation. Gatekeeping, yes, for posting inaccessible PDFs. PDFs, the scourge of the internet. But just because things are wrong doesn't mean they have to stay that way. Just don't post more bad stuff. You may not have the ability to fix all the stuff you've already done but at least moving forward don't let those things fly. Don't post videos that don't have captions. Before you make some moves and someone gets upset and you take everything away and no one gets anything. Make sure you've got guides internally tying back to education that help craft meaningful alt text and more and if you can deploy an automated monitoring solution that reports on those changes as they occur so that time isn't passing by as users are suffering. Invest when you can as well in manual versus automated translation and work with experienced ethnographers who will understand the cultural context for those translations and can even extend into areas of design because color, imagery, all of those have meaning and that meaning, it can really affect how your message is transmitted, how people are perceiving your organization from a business standpoint, it makes sense but from an equity standpoint, even more sense. In conclusion, incorporate accessibility throughout your redesign process. Every automated test is different but all are verbose. Heuristic analysis helps reveal usability focused issues. User testing is ideal with specialized organizations but no, you can do it your own, you can start. Prioritize and address accessibility issues once they've been found and content governance, really foundational. And look at us, Mike, we did it in time. 30 seconds to spare. Here's a resource, if you like, we put together and compiled the list of tools. You can download it from hello.calamine.com slash a11y-tips. It's just a PDF, a bunch of tools and different things that you can get. There's a QR code too if you wanna use your cameras and there's lots of tools. This is some of them. I'd love to hear more from you about what we have some time for questions and if you wanna connect with us, we've got socials and people here. We have a booth come chat with us, really excited to hear about your accessibility journey and how we can improve Drupal as a platform and the internet as a whole. Thank you very much. Great. So questions, all right. Yeah, so. Well, I mean, I- Sorry, I think we're just gonna repeat the question because it's important. Oh, go ahead. He was basically asking how to document issues that you're not able to fix in the moment. Good summary? Yeah, no, document them. Add them to the spreadsheet tickets or something like that. You can't actually fix everything and some things are frustratingly unfixable. Like if you're embedding some video player or something and there's accessibility issues and you can't do anything about it or an email sign up letter that, anyway. Yeah, no, just log them in your JIRA or your spreadsheets and just try to get to them when you can based on prioritization and ability. I can't speak in terms of legal but usually these more. I can. Okay, I was just gonna say the technical issues tend to be less, yeah, go. Yeah, from a legal perspective, everyone's afraid, oh, they're gonna come after us. We're gonna get a notice. We've helped organizations that have had notices. What's important is demonstrating that you're trying. And so the act of logging those things of actively showing like we're doing things, they're improving, that's, and you have a timeline in which to demonstrate that. There's no expectation you're gonna solve 100% of all of the issues. But as long as you're making progress towards those and documenting them, that's going to help relieve the pressure on the organization and the legal obligation. I'm not saying like do the bare minimum, do as much as you can. But that documentation is gonna be instrumental from a legal perspective. Yes? Yeah, just tag me so you should have those. At least I'll find out. All right, so like you're saying if there are known issues with your website, then in your accessibility statement, document them, let people know, hey, by the way, this map is not that accessible for an alternative or contact us or maybe something that you can do to help walk them through the information delivery. Any other questions? If anyone has to go because they have to make it like 12 miles to their next session, please, it's not really just get up and go and we'll be offended, but yeah. Well, I mean, I think we've been touching on, oh, the question was how do we feel about universal design generally as it applies to accessibility? And I think we've been talking about that, having a user-centered design practice is really fundamental. Users and guidelines, those are all like other legislation, they're sort of working to catch up to where things are and where people are and where their experiences are and when new technologies come out, it takes some time. And so if you're not rooted in what's happening today, I don't know how much WCAG is talking about, the use of AI and a lot of tools that are coming out, it's not there yet. So unless we're relying on our audiences to have that connection, we'll lose touch as practitioners for sure. Yes. Sure, so the question is like where's the bar, how do you measure it, how do you cover your bases? And it depends on the industry you're in, like if you're in government, Section 508 is really a guidepost in higher education, typically universities will have a mandated accessibility standard, triple A is really more common, double A, you know A is hard to, am I going the right way? No, you're going the wrong way. I'm going the wrong way, sorry. I always do that. Triple A is basically impossible to reach unless your page is just like black and white. So as far as helping to meet those standards, right? Like again it comes back to education, there's a lot of fear, right? And the people who are accountable don't always understand what they're accountable for, right? And they just, they'll be like no, you've got to follow the rules or else I'm in trouble, right? And so finding ways to help create more resiliency around that governance in those spaces, we found that we've worked with universities to help create guidelines as well internal to those universities that are both educational and resource-based. And what tends to work super well is showing and describing that there's a practice, that there are people that are kind of leading that. If it feels really diffused, then you'll have more of a heavy hand in that kind of enforcement. Whereas someone who feels like maybe there might be a finger they can point to is probably gonna be like a little bit more lax around it. But ideally they're more educated in the practice and can appreciate what the goals are. The goals are really key, right? It's about how do we get there? If you're focused too much on the how, then you lose sight of the why. And then where are you? You're just kind of lost and who are you designing for? You're designing for a set of standards. And I think in an educational context, you can draw analogies between standardized testing at times and that can kind of lose people, right? And so there's some analogies that can be drawn to help in that space. All right, thank you all so very much.