 Thank you, everyone, for coming. I'm really excited and very honored to be presenting this here. I am going to be focusing on, as the slides say, prioritizing accessibility in custom things in Drupal 8. There has been an amazing amount of progress made in Drupal 8 for accessibility, especially for tools. And this presentation will be pointing out the different ways that you can use the tool, specifically in your custom themes, to take what's available in Drupal 8 and really push it forward in terms of accessibility. That's me. I had brown hair. I guess you can still see most of it, but now it's a funny color. I am a technical architect at MyPlanet in Canada. I've been doing Drupal work since 6. I've really enjoyed it. One of the areas that I focus in is accessible front-end development. So we look at developing sites and applications for users that use assistive technology and organizations that have requirements for accessibility. That is my Twitter handle. This presentation goes about an hour, so we may not have time for questions. If you have any questions, please hit me up there. And as I mentioned before, if you can see the URL at the top, these slides are live, so you can follow along with the links. There are a lot of links and resources in here. But if you cannot see it, it's https://emarchac.github.io slash closing-the-slash-gaps. Cool. And as I mentioned before, I work at MyPlanet out of Toronto. What MyPlanet focuses on is building, engaging web and mobile products for the enterprise. So what we're trying to do is to take the UX and the usability that you normally see in consumer-level applications and bring that into enterprise applications and workplace environments. So taking things that people don't expect to be beautiful and usable and making it beautiful and usable. We're at MyPlanet HQ. If you're ever in Toronto, come visit us. We can see a J's game. So for the purposes of this presentation, I'm going to be using a, not an acronym, but a shortening, a term, A11Y or ALI. This is a normal acronym or a phrase to reference accessibility. It's because there are 11 letters between the A and the Y and accessibility. So it makes sense, and it's also pretty cute. I like it. So if you're ever confused about that, that's what it is. What am I going to cover? Why am I here? Not in the philosophical sense, but in the why am I giving this talk sense? And it's going to be a case study and a reasoning behind where we came to these discussions. I'm going to give an overview of accessibility in and of itself, especially in terms of web and mobile products. I'm going to give you an overview of accessibility and Drupal 8, so within that context. For anybody who's not already well versed in it, that's going to be really useful. I'm then going to show you how to identify accessibility gaps in your applications. So I'm going to give you developers, designers, project managers, QA, some tools about how to identify areas that you need to improve. And then I'm going to go through some real world examples on how you can actually fix that in your application as a developer, or help fix that and help address the design gaps that you need to address. And finally, I'm going to give some further resources. So there's a lot. And I'm going to try to talk slow, even though there's a lot to cover. So why am I here? Take a study. So on this slide, we have the title AMI, which is the Accessible Media Inc. And we have a screenshot of their fully accessible website that we've created with them. AMI is a company out of Canada. And what they do is they focus on accessible media. And they're something similar to Rogers, or Warner, or Sky Media that you would have here. But what they do is their role is to focus on bringing media to individuals that require assistive technology. One of their main targets is blind and low vision users. And the idea is, if they're successful at this, they'll go out of business, because they need to be the business case for the larger players to demonstrate that you can have a profitable and accessible media platform. So they're just amazing, amazing, amazing people. And what my planet did is we engaged with them to help build their new media platform. So it was on, it is, on Drupal 8. It's fully accessible and compliant for level two. It is multi-lingual because it is Canada and we have to support the two official languages. And it's entirely accessible, which I said. So users can go in. They can see a schedule of descriptive video. So similar to TV Guide, but they can go through and find content that's specifically available for them in their area with their cable provider. They can watch videos online. They can listen to radio shows online. And it has closed captioning and descriptive video and an accessible media player within there. So it's really focused on catering to that community. And there's also targeted content there. So it was a really, really big build. But the nice thing about it is that the mission for the site was it's really, really easy to get on board with that idea. And us at my planet, we worked with the design team and we went through the whole design audits, design processes. We did the entire build. And at each point, we were more and more aligned with what AMI was trying to do because it's such a great and such an important mission. On this slide, we have our product owner Si in front of a board that shows the different designs and how we broke them out. And then we have a screenshot of my PHP storm with some Drupal 8 code. With what my planet did here is we did a specific user experience testing, which we normally do for any enterprise application. But this was specifically targeted toward accessibility. And engaging those communities. So I'm going to further on, I'll show you what that actually means. We did design audits of the designs in terms of creating the comps and creating the wireframes out of the designs. They were intended to be accessible from the start. And we just went through with a fine tooth comb and confirmed that and verified that. We worked with David McDonald, who is an accessibility expert in Canada and does work with the WC3 a lot. And he did accessibility audits of the designs and just general reviews at each stage of the project. We were also really lucky to have Everett Zufeldt, who was the accessibility maintainer of Drupal 7 and a co-worker of mine and just a really nice friend there as a technical consultant and make sure that there was lots of eyes on the project working around. Thank you. Finally, something that isn't focused on accessibility, but we're also really proud of is we had headless or decoupled components using React.js on top of Drupal to have that really nice dynamic experience. And we were able to do it entirely accessibly. So there was a lot of stuff going on. So this slide has a gift of, oh man, RuPaul in a large wig with the text, put your money where your mug is. So this is what we did. And so the intent of this presentation is we did this. We have all this information, and I would like to share it with you. So this demonstrates in the same way that AMI demonstrates to the large media players that you can have an accessible site. You can have a beautiful aesthetically pleasing site and can have a usable site. You don't have to compromise on any of those. And I really think that it's important as technologists that we understand that we can be our best. Because we're told so many times that we have to compromise this for that and cut this there and keep scope in. But when you build things out initially, whether it's you're focusing on accessibility, security, forward compatibility, you're able to bake these things in if you already have the base knowledge. So that's why I think this presentation is really important. Cool. So that's the background. That's why I'm here. Now I'm going to talk a little bit about accessibility in Drupal 8. And to know about accessibility in Drupal 8, you kind of need to know about accessibility. Makes sense. So it's a little bit, the color is very light on this screen. I'm sorry. But on the slide is the quote by Tim Berners-Lee, who was largely attributed to be the founder of the internet. And a cool dude is, the power of the web is in its universality. And that can mean a lot of things. But for me, that means that it's universally accessible. Whether we're talking about needing to use assistive technology or needing to accommodate for different screen profiles or data types or just usages. The fact that we have this tool here, that we have the power to build and can distribute applications and documents to others, literally around the world, and maybe Mars in 2016, that's its real power. And to have that as something that motivates you and brings you forward to really inspire you to push things forward is great. I like it. I'm going to get Terry. Sorry. So things that will prevent users from actually accessing your content are different barriers there. And when thinking about accessibility on the web, we normally think about a very narrow kind of example. Some of the barriers here that we don't talk about are, I'm just going to go through a bunch. Well, some of the type of barriers are physical, motor, or mobile. So this could be that the user is unable to use a mouse. It could be. A mouse would engage in with your device. That could be because they are unable to physically move the mouse. It could be because the mouse is broken. Being able to have understanding that there are different ways to engage with your device is really, really important. Visual. So the standard example of a visual barrier is somebody who is blind or low vision. And we see that a lot in terms of usage of examples. But visual might also be colorblind. And that's a demographic that I really think is largely ignored for no good reason, is that not being able to understand or parse the colors on your page can be a great barrier, whether or not it is because you are colorblind or because your device's screen just can't render the color properly. Auditory. So if you're deaf or hard of hearing, again, is a dramatic example. On the other scale, an example of a barrier could be for auditory information, is the barrier could be you don't have speakers, or you're in a cafe and you don't have your headphones, or perhaps you don't want to actually you're listening to good music and you don't want to turn on this music. These are barriers that we implement ourselves, but barriers that exist to engaging with your mobile content or your web application. Learning barrier. So this example is a very easy one of that, is dyslexia. So how people are able to learn and interpret your technology and your information and making sure that people are able to take the time that they need to actually go through and consume and understand your application in a good pace. Speech or language. We talk a lot about having verbal interfaces, so Alexa or Siri with your application. And if you are unable to communicate with that, whether you have a difficulty with speech or your accent isn't the one that the device is expecting, that is a barrier. Whether or not you understand the language that the interface is in is another barrier. So in Canada, the example is a French user going to an English site that isn't able to understand the English words. It's a really good example of a barrier. And normally we don't think about these as barriers, because we're so focused on our target market, but you don't know who's coming to your application because the web is universal. And then finally, whether it's a mental intellectual or developmental barrier. So whether or not they're able to properly understand and comprehend in a higher level your content, whether they're in a good mind space to even deal with your content if it's a mental health concern. These are type of barriers that we find we're starting to get into, but there's no large discussion regarding it. So I just talked about a bunch of barriers, and that's super negative and sad. Here are some types of solutions that we can actually use. So for mobility, being able to have redundant ways to engage with your application besides just a mouse, like this is a very basic thing. So I can use keyboard or mouse or touch navigation, and my application works across all of these. Screen reader compatibility and descriptive video for people who don't have the aural, not oral, aural, whatever, sound, sound capabilities within there. And I really want to emphasize that I use descriptive video and captioning so much because I don't like to turn my audio on. And you can see that Facebook has standardized this now. When you go through the feed, they actually have the captioning on by default. So captioning is another thing. With different content, being able to actually caption properly and descriptively capture what's going on is so, so important. Legibility of design and information architectures and clear information architectures are a great way to get around the learning barrier. So people have legible text. There's this awesome example of how the lowercase l and the uppercase i in sans-serif fonts look exactly the same. And it's not only an issue for people with dyslexia, but it's real confusing for technologists because I need to know what that character is because I'm one of those control freaks. But legible design and clear information architecture allows people to properly parse your information at their own pace. For speech, translatable content, where Drupal is great and multi-linear all, and I'm sure a lot of people here works directly with multi-lingual content. But to have the even if your content isn't multi-lingual at release, to have that capability baked in and to have an awareness as a technologist to say there could be potentially in the future, my app goes big and I have to translate it into 30 different languages. Building that in is so, so important. And then in terms of the mental intellectual or developmental barriers, trigger warnings for content. If you have content that is particularly strong in a direction, sometimes it's nice to just give people a heads up. We talk about, I've seen a lot of people say like, ah, it's safe spaces, they're just too safe. Which sounds weird, but having trigger warnings and having discussion and context for your content is really important because you don't know what kind of person is accessing this. I am the biggest wuss and now on Facebook there are auto-playing trailers for horror movies and it just, I can't. I wish that there was a way that I could turn that off but I can't because they've assumed that I just want to engage with it and there's no kind of preparation for like, oh scroll past this, because Erin, you're gonna get scared and cry again. So on this slide, there is a image of three people watching a baseball game. I don't think they're the Toronto Blue Jays but it's a baseball game. And on one side of the image, they're trying to look over a fence and each of them has a box. There's a person who's very tall that can see over the fence. The person who's middle tall that can see over the fence and then a shorter person who cannot see over the fence. On the other side of the image, and sorry, and that side is captioned equality so everyone has equal access to the technology which is a box to stand on. On the opposite side of the image, it shows that the taller, it's the same image, the taller person is able to look over the fence without a box. The middle height person uses one box to look over the fence and then the shorter person uses two boxes and they're able to look over the fence and it's captioned justice. And I think that this is what we need to be aware of as technologists that are building applications is that some people need and use more of our technology than others to access it. They deeply use any semantic HTML which I'll talk about and any kind of proper translation or language and they use that more to access the content. There are people who don't use that at all and they're able to access our content and to understand the differences and to make sure that we are able for everyone to have a great time at the old ball game is important. Cool. So that's Erin's high level. Who here has heard of the W3C? Can you please raise your hand, give a shout or death? Oh, okay, cool. Okay, I should have asked that to begin with. The W3C has the accessibility guidelines. They have not changed since 2008. The guidelines haven't. And this is the general recommendation of the guidelines. I'm gonna be going through these slides fairly quickly since a lot of people raise their hands, but if you need to access this and if you need more information on it, please go to the slides, all the links are there. There are multiple levels of the web content accessibility guidelines or WCAG. Level A is essential. This means that people will be entirely unable to access your site without this. This is the first box that they're standing on in the image before. Level Two is preferred. So this means that the majority of users will be able to access the majority of your content without significant barriers. And finally, the levels that the guidelines provide. Level Three is optimal. It means that there are no significant barriers for anybody to access your content and it's largely universal. When we were working on AMI, the general discussion and the general comments were that level AAA, so level three, is designed as a goal. It's designed as inherently inachievable. This would be ideal perfection. So not to say that the guidelines, when you can hit some of the requirements for AAA, that's ideal, but when building a site, what you need to focus on is making sure that the entire site is actually just AA compliant. And the key points of the interactions to really make the experience beautiful, let's say your main functionality of it, is AAA. So you're not able to, the general discussion that we had with David, with Everett, and with AMI, is that AAA is just, it's an ideal. It's the platonic ideal of entire accessibility. And for you to reach that, it's generally inachievable. But the act of trying is important. So making sure that your application or document is AA is perfect. It's AA certified. You've hit all the AA points and then you really stretch yourself for the few key points for AAA. This is for the recording and anybody that can hear. An audience member said, the act of trying is important, which I think my mom said that to me too. But it is, it is. And it's not trying that gets us in trouble. And it's not pushing the boundaries. And we're at DrupalCon, and we're here pushing the boundaries of technology. We're pushing the boundaries of what our technology can do. Let's push the boundaries of who can use it also. AAA. So on this slide, I have links to the accessibility for Ontarians with Disabilities Act, or AOTA, which requires all of the Canadian government sites and all of the Ontario public and large private companies to have accessible content. As an example of what's required in Canada. In the US, they have Section 508, the Accessibility Program, which is targeted towards government companies, not government companies. Poof. Government organizations required to provide accessible content to their end users. And the European Union does have basic accessibility requirements for any of the governmental websites on there. So there are legal requirements for accessibility that we have to be aware of as technologists. And understanding where your client is coming from, who they're serving, being aware of what's legally required is also important. So if you can't motivate yourself or motivate others from a deeply inspirational speech, you can motivate them through legal means. Which is good but sad, but sometimes that's how we move forward. It's the carrot and the stick. Cool. How am I doing for time? Uh-huh, uh-huh. Okay, so accessibility in Drupal 8. Could you raise your hand if you've built a Drupal 8 site with some accessibility improvements? Okay, cool, so about 50-50. Just as an overview, the Drupal 8 has a initiative called the Drupal 8 Accessibility Experience, date acts, I don't know. But the Drupal 8 Accessibility Experience has largely been a follow-through from the Drupal 7 Accessibility Experience. And we've taken what we've learned and what we've developed in Drupal 7 and really pushed the boundaries in it. But if you want to get involved or participate in the Drupal 8 Accessibility Initiative, you can go onto Drupal.org and Drupal. So some of the benefits that we've, accessibility benefits that we've rolled into Drupal 8 is Y-Aria. So that's the web accessibility initiatives, accessible, rich internet application guidelines. I've also linked two articles in these slides. A lot of them are by Mike Gifford out of Open Concept out of Ottawa, who is the Drupal 8 Accessibility Maintainer and has largely pushed for these changes and been a really, really, really great inspiration and motivation for this whole process. But Aria is a specifically targeted markup designed for accessibility and connected semantics within your documents and allowing you to have accessible, rich internet applications, Aria. And a lot of that has been rolled into HTML5 specification. So Aria exists outside the HTML specification. HTML5 has consumed some of that and has used that to help us with improved semantics on our websites. But it also means that the improved semantics connect to improved accessibility. Because if you're not using, if you're using a device that needs to parse and interpret a webpage, whether you're using a web crawler to go through a page, the semantics help the web crawler understand it. And also if you are using an accessibility device or accessibility tool, the improved semantics help explain it to the user. And I'm gonna be demonstrating this. But using these improved semantics are actually great accessibility improvements. I have more links here. You can read about it on the slides. Again, highly recommend you take a look at the slides. But within there we have a great amount of ability to just out of the box, we already have a more descriptive website. We have an improved content authoring experience and ATEG compliance. And ATEG is authoring tools accessibility guidelines. I hope I remembered that. Anyway, yes, thank you. So what is awesome is that we can, with Drupal 8, it's very easy to build accessible front end websites. But if you have somebody that needs to use an assistive device or assistive technology to add the content in Drupal 7, it was like impossible. God forbid you try to use views with a keyboard in Drupal 7. But with ATEG, we actually have the ability, the views UI is now accessible. People can engage with it. And the improved content authoring experience within there helps guide, shoot my boob, helps guide content authors in creating accessible content. So you can create a beautiful front end, but if the content authors don't follow guidelines or accessibility or they're not trained, they'll break that. An example of this is now alternative text on images is required in Drupal Core in the image field by default. And you need to have those descriptive images or the alt tags in the images as descriptions. Tab control, there is so many, one of the big difficulties of creating a dynamic and rich internet application is that there's gonna be a lot of complex interactions with it. And if you're using a mouse, it's one thing. If you're using a keyboard where you have to control where your keyboard is going and where your tab control is going, it becomes more difficult. There is a tab control library in Drupal 8 now that you can use to constrain tabbing and to control where the keyboard user is going. So if you have, let's say, a really complicated menu or a game or an interactive modal, you can release and control tabbing to allow users to have a greater experience. Finally, there are aural alerts and this is why is it always clicking? Don't be clicking. Within here, this is the same thing. I'll zoom the screen a little bit up. There's now Drupal announced in JavaScript. So frequently when you're engaging with rich internet applications, there are messages that pop up or you get a notification that something is happening. Before, we would have to roll our own version of that. So you would have 15 different versions of this, which you would do with the aria live role. But Drupal 8 gives us a nice standard way to pass translatable strings to Drupal and else that reads it out for the user. So if you have a, the easiest one is a chat screen. If you're using Drupal for your front end and you have chatting going on, you have the ability to announce to the user that there's a new message. If they're not able to take the visual indication as information. So yeah. One of the examples is you look beautiful today and I think everyone looks beautiful here. Cool. So if you're interested in more about the history and about the development of accessibility in Drupal 8, Mike Gifford did an amazing, amazing talk at DrupalCon New Orleans that talks about the history of development somewhere we're going and some of the difficulties we have with it. I really recommend that if you're looking for more context regarding it. And it is available online. So this slide has, oh man, Taylor the creator in the video and it's captioned with I think I'm wasting my damn time. So if you already know all this information, you're like, so I know this. I am excellent, Aaron. Great. Given all of this information, why do we need to know the whole history of it to the whole understanding the different kinds of barriers to actually build internet applications when there are guidelines out there and there are check boxes that we can just go through and check? The reason why I talked about all of this is that for AMI remember, we didn't want a technically accessible site. We didn't wanna go through and check all the check boxes and make sure people can use it. We wanted a really engaging, rich experience for users on the site. On this slide, they have that quote that I just said and there's a picture of me talking to Hoyen, one of our product strategists and us testing on multiple devices. The reason why it's important to understand the tools and understand the barriers and the solutions for people to engage with your website is that if you wanna take something that is okay, it's accessible, it's the emotional equivalent of just checking a box when you pass the guidelines, you need to understand and you need to deeply empathize with what the user is going through. And to do that, you need to be able to put yourself in their shoes to have representation and to have discussion within there. And by understanding the tools available in Drupal 8 by understanding the guidelines, you're able to take what's Drupal 8 which is already fairly accessible and push it and make it beautifully accessible. So it's not only just university accessible, it's universally usable. And that's gonna be the difference when you're talking and catering to the users of your application is whether or not they can use it versus whether or not they want to use it. And that's what I feel is very important. So I have built my application, it's on Drupal 8, I've used all of these technologies. How do I actually start identifying where we can take something that's okay accessible and really push it to be awesomely accessible? So I'm gonna go through different kinds of testing that you can do. With visual testing, this is testing the designs going through the design audits. What you can do to identify areas that you can improve is making sure that the designers plan the heading structure early. For search engine optimization, it's not really required to have semantic, SEO experts are gonna argue about this in both directions, so whatever. That's my two cents. Planning the heading structure early because accessible technology really uses the semantic H1, H2, H3, H4, and to understand what the different headings level mean and what they're communicating on the page. So this is again just visual. But as a designer you need to have visual pattern and visual indicators of what's going on on the page so people can understand that. And to directly map that to understand this is the first heading that I want them to see, then we're gonna follow the page. You create the user journey very clearly on the document. And the second one I have that I suggest is prioritize function over form. If you're a visual designer, really prioritize and look at how people are gonna be using the application you're designing. Look at the functionality of it before you start adjusting the form or the visuals of it. It's nice to have some of these dynamic, some of the more frilly parts of the web. We've always had issues with drop shadows. But I think that that's gone now from design. But prioritizing how people are going to be using the site and how they're able to use it over the sparkle and the visual flair, sorry, flair of the page. So look at functionality, communicate clearly about what's going on on the page, communicate the function before you communicate the form. And finally allow indicators. These are visually, these are icons, colors, shapes, allow redundant indicator, so even text versions of it. So if something happens on the page they can potentially get a sound, a visual indicator, a textual indicator, and a verbal indicator that it's actually happening. And to communicate that something has changed on the page to communicate state properly as a designer is gonna be really, really, really helpful in terms of usability and accessibility. If there's a form error make sure that the error state is clearly designed is a basic example of that. Automated functional testing. So great, you've developed your website. You've passed the designs onto the team. They now have built it and they're like, I guess we should see if it's accessible. There are, I have two examples here and there are others you can get. The Wave toolbar by WebAIM is, oh I have it preloaded with the DrupalCon. You can go into webaim.org and Generator Report for any website that's online and it'll give you a breakdown of the errors, the features, the structure elements and its general understanding of the page. You can also do this on your local. So here I have an example of a local site that I've built in Drupal 8. This site is using the stable theme with the Bootstrap, like Twitter Bootstrap CSS applied because I don't like that font. And I have the WebAIM toolbar installed. I can click the toolbar on top of my screen and it gives me an assessment of just a local page and you can see clearly that I have an empty heading element. I have an empty H1 on the page that I should probably fix. And as you go through the WebAIM toolbar, or sorry, WebAIM Accessibility Evaluation Tool, whatever, gives you context and ways to understand the different errors. So it's a really good way to kind of start guiding yourself through best practices and yeah, the different guidelines of what it is that you need. And it gives you feedback on features, so positive little checkboxes and general discussion of it. The other thing that you can do and use is tenon.io, which is an automated testing tool that you can use to plug in with your continuous integration to test generated pages. So I'm going to, yeah, let's take Drupal.org and pass it to Tenon. We'll see if it works. This is live, this isn't a video. So please forgive me. Ba-da-ba-da, ba-da-ba-da, sweet. So we found some issues, we found some benefits, they generally go through and describe what's happening on the page. And you can, as I said before, plug this into travis.ci to have automated testing on your site. Other things that you can do is manual functional testing. So beyond automation, really go in and try and understand how the user's testing it. Who here has an accessibility device on their phone? An accessibility tool. Who here uses an iPhone? All of you should have had your hands up for the first question. There's voiceover, and also I cheated because it's on the slide. There's voiceover for Mac OS and IOS, it comes with it. Siri is another accessibility tool, but you can turn it on on your phone. And on the Mac, I'm going to show it later. I'll show you voiceover later, it's really easy. TalkBack comes by default with most Android applications. So you can test on Android there. NVDA is an open source and free screen reader for Windows. So you can test on that. And JAWS is a non-open source proprietary one for Windows. It is one of the most popular ones out there. So if you are getting serious about screen reader testing, you may need to look into investing in a JAWS. License, the JAWS license I believe is over $1,000. So it's a great barrier for people to stay upgraded and stay with the up-to-date version. So a lot of accessibility testing is making sure that you're backwards compatible, at least for accessibility in terms of that functionality. User experience testing, so I touched on this before. The final point of this is to really understand how people are using and experiencing your application. So how we do this is we get pairs of researchers. So one person creates a script where they're asking users what they're expecting when they're using the site. And the other person is taking notes. And they go through the script and they ask, what do you expect from this page of my application or this page of the site? And then they get users to actually use the site and go through. And what we do is we're looking for behaviors and attitudes. So is this something pleasurable to the user? Do they get frustrated or lost? Or is this, do I expect them, is the thing that I expect them to engage with, the button that I'm expecting them to click, actually the button that they're using? So you're really able to test called action, verbiage, design, and visual indicators for it. Great, so we now have found all the problems with our application. How do I fix it? Ah, functional solution. So here's to, if there's a problem with your site, here's how you can fix it. And I went through and I pulled some of the most standard ones that we found and stuff that we repeated ourselves and I dropped it into my theme. So landmark labels. So this, I have the, all my slides are on GitHub. And if you go to this URL, which is emarchek slash closing the gaps, this theme is actually available there as a Drupal 8 theme that you can use and base off of. So all the code there is what I'm gonna be demoing today. This is a live demo. Be nice. We'll see how far we get. So step one was landmark labels. So I mentioned before that we have ARIA landmarks and ARIA tags in HTML5. Here I have an example of the main tag. So that's an HTML5 main tag, sure. With the ARIA role of main. So that's kind of redundant, but you understand what's happening here. I'm indicating that this is the main part of my page. There are other landmarks within there and I'll be showing you the different ones. Largely these come with a core and I'll be tweeting and posting the links afterwards. So we're good. I also have the ARIA attribute ARIA label and that label is the translatable verbal text that labels the element. And what we found is that you have to be very aware of what your label is and include a label when designing it. So this is how you turn voiceover on in OSX. There's gonna be a visual indicator that I've turned on and I also have the verbal commands turned on. So we're gonna be getting a lot of information here, but it's fine. Welcome to OSX. Voiceover is on. System preferences. Chrome closing the gaps. Vertical help documentation. Select tab. So I'm here. Visited internal link. Skip to main content. Visited internal link. You can see that I have the visual indicator at the bottom and the voiceover is reading through it. If I go to my landmarks tab, I have here, I have the brand banner. I have main navigation navigation. User account menu navigation. And what I had before, which was content main. So it's reading the ARIA role of main and it's appending the ARIA label to how it's reading it out. Content main right there. And you can see here, role, content main here. I'm just gonna mute that for a bit. And I'll show you what it is on there. But this indicates and this shows you where are we at, Drupal? Where are we at, Drupal? I'll just find it. Oh. Yeah, you can totally turn it on. Here's another one. So I had the banner. And again, this is available on the repo so you can take a look at it. Sorry that this is so small. But I have the banner, the header of a role banner and headers have a banner role. This is just right out as banner in OSX and the ARIA label brand. And if I go back to my landmark navigation, the brand banner is there. So you can see that there's, that's how you can connect and that's one way accessibility users engage with the site. The other way I'll get into. But one of the problems that we have is that you need semantic names of your elements. So here I have a nav element that is a nav role and it's taking the name of the ARIA label main navigation. So it's read out main navigation navigation which isn't an ideal experience to the user. Here I would need to change the default Drupal menu to say main menu and that would be corrected. I also have, so you can see here, this is the theme that I was again referencing in GitHub. Page here, this is the element that I was referencing before if you can see it there. So it was reading main content within that. Right, I had mentioned before this is not an accessible presentation. Cool, another one that we noticed, a lot of pagination when you're doing your custom themes. There are custom pagination elements. The requirement there that we ran into a lot is the verbal or sorry, the visual tools to indicate what the button does. So here I have next and then just a little like chevron arrow on the side. It's not enough to describe really what's going on to the user. So the ideal thing that we did is have two text elements on there. One that says next with a little fancy arrow, little chevron for visual users. And we've tagged that with aria hidden. So it's hidden from the screen reader, but we give a more verbal description of what's going on using the Drupal core class visually hidden. So there's indicators for visual users if you just have a button or if you're using a font icon and then indicators for keyboard users that are engaging with it. And I have that here within a pager. Another one that I would recommend in general, this file pager stable I don't have in the repo but this is the one that comes out of core and I'm gonna be submitting a patch to this. One pattern that we've seen that is actually not great is including a title on a link. So this is the link, it's a anchor tag, a ref with text that says last page and last. And then the title says go to last page. The majority of screen readers don't read out titles on links. You have to actually enable that manually. So this is entirely lost. If you have a question, you can tweet me or we'll go afterwards. So that's a general indicator of what's going on there. And you can see here as I turn on voiceover. So I'll go to my pagination navigation. You can't see it. And I engage with that. So it says press link current page one. Oh, I pressed the link. So I'm within there. Oh, no, this is the live demo. You're welcome guys. Let's get back to it, perfect. So end of navigation, end of list, visited link next page, last page. So you can see an example here that it's reading out last page which is the aria hidden tag that I've written there and then next. And then I have a text in the same pattern that says go to page two which is a clear indication of the link. Another way that users engage with your site and through testing we found this there's a lot of different ways. Sometimes they just go through the links to find what they want. So having descriptive anchor tag elements, having descriptive links within there really helps if this is how they're engaging the site. So I really should have here, I should have said go to last page. That's a mistake on mine. But just to be aware of. Another thing we found with accessibility is that there's an issue with NVDA screen readers in Firefox. This is not something that I think that I should be committing to core but to get around that NVDA Firefox users cannot access HTML required attributes on fields properly. So what we found is if they have required and they start typing text in it just gives them an immediate error. To solve this we actually enable inline form errors. That experimental module. So, and I'll show you how it engages with it when it's enabled. No, that's my Drupal console patch I'm working on. Here we go. I'm enabling voiceover. I'm gonna go to user login on this page. I'm gonna create an account. So I'm gonna create an account here. A valid email address is required. I'm choosing not to include that. I'm just gonna submit the form. Create a new account. There it is. I submit the form. Excuse me. There we go. Ah, what's going on here? And again this is unstyled so it's a little bit hard to see. Two errors have been found. Email address and username. The benefit and the reason why inline form errors is so important is that when I go there as a keyboard user I get content info error. I have just because they're using the title within there the error messages are quite clear to me. Heading level error message is two. I have two items. Two errors have been found. I'm able to go into the list. The email address. I enter that. And I'm able to enter my email address directly. So it's a really nice experience for accessibility users. And that's what in general we recommend is we remove the HTML5 required attributes and just handle that through inline form validation. Another one is we found that the picture element, so the responsive image element, sometimes in some browsers it's not able to actually read the alternative text of the image inserted in it. So what we ended up doing to get around that, and this is the responsive image template within the theme, we insert the image as a fallback so that that's the actual image tag within your HTML5 picture element. Some screen readers can't pick that up if you're using a browser that understands the picture element. So we just inserted the text visually hidden. So this is using the Drupal accessibility class to hide it from visual users. But we just put a paragraph in there that actually adds the alternative text. So it's read out. Google's able to still use the alt text in there to categorize and to crawl the images. But in addition to that, we just have the descriptive text. Given the time, I'm not gonna go into this. But with skip to main content, what we found is that the skip to main content link in Drupal 8, and I can use, I don't actually need to turn voice over on for this. I can use just the keyboard navigation, skip to main content. We find that having JavaScript to handle that scroll allows you to visually create a nice scroll on the page for users who are using the keyboard and still visual users. If you don't have that JavaScript scroll element, it just jumps. And it also manually handles anything that a browser's not able to properly handle. Again, we had issues with Firefox properly passing the focus. So we just did that with JavaScript. And I have an example of the code that actually handles the JavaScript to scroll down in that theme. Finally, this is one that I really like to talk about. Relating block and title labels. What I talked about right now is a lot of stuff that's in HTML5 that you may have experienced as a sighted user. But one of the things that's really important is being able to relate, when you have a block on the page, being able to relate the call to action that's associated with the content and the title. So if I go back to my theme on the front end, where did my block go? Oh, well the classes aren't loading properly, that's fine. But here I have a custom block at the bottom. I have the text within the block and I have a read more button that's connected to my custom block, or my custom title. So this would be a CTA, this would be a call out that you have what you can use here. And this is the ARIA tribute labeled by. You have the ability to create complex associations within your page using this for IDs. So on the template block, I have my heading ID, which is the ID of the heading element, that's H2. So if I was to go here and inspect it, my custom block heading, that's my ID. And then on the call to action link at the bottom, I say it's labeled by itself. I'll show you the code here. The button, I call to action button. It's labeled by itself and it's labeled by the heading. And we do this instead of just writing the text as a title or text as an alt text or a hidden, because we wanna give semantic reasoning and semantic connections between the header of the call to action and the actual call to action. So I mentioned before, some screen reader users just go through and read all the links on the page. I'll show you what this actually looks like for a user. So I go here, I go through the links. There it is, I'm going through all my generic code. And you can see here it's now focused on the read more block. And it says read more, which is the text of my button, which is the first of the ARIA label IDs. Custom block, which is the second of the ARIA label IDs and it's the text of the title. So you're able to have a context in relation between the blocks. And it means that if I'm an accessibility user that only uses, this is an actual way that people just go through the site. Some people wait for the page to read entirely. Some people just go through the links. Some people just go through the headings. There's all different ways that people engage with the site. But this is one of the things that you can do. I told you this would take a long time, I apologize. I talked about technical solutions. Now I'm going to talk about experiential solutions. So how can you solve the non-technical problems? Visual design best practices, what I mentioned before. If you check early and check often, you're going to be able to prevent yourself going down an accessibility hole and have to rework a bunch of your designs. There are other things that you can use to functionally test your designs while you're designing them. If you use Sketch, which a lot of our designers do, there's a color contrast analyzer. And one of the issues is to make sure that you have a lot of contrast on the page so people can read it properly. An example of that is I didn't have enough contrast on my Tim Berners-Lee slide here, so it was hard to read. Checking it there is great. WebAIM, that does the toolbar that I was showing you before, also has a checklist that you can print off and go through. And there's a lot of really good information there that illustrates different things that you have to be aware of. So contrast, content, using true text as opposed to other Elf font alternatives, that's an ideal setup. User testing best practices. And what we did with this was, when we did our user testing with accessibility in mind on AIM, we did a mix of in-person and remote. So when you're in-person, the user testers are sitting in the same room as the other person and you're going through and you're engaging with them. You get a lot more information from being able to read their attitude and their tone. With that, and we did also remote, which means that you're able to, we set up a phone call with the tester and they verbally described what they were going through on the page. Normally, when we do this for non-accessibility, non-accessible user testing, we actually do a screen share, but because of the content of this and because the users normally don't use the visuals of the screen, we just did this over the phone. The benefit of remote is two things. One, you gain access to people that aren't able to come in physically to your spaces and when you're talking about accessibility, there's a lot of groups that have difficulty with mobility and so you're able to engage them in a much easier and more comfortable environment. The second one specifically for testing with blind and low vision users is having somebody describe something that they're going through over the phone verbally puts you in the same situation as them. I was doing a, we did testing and one user clicked a link and they said the menu was gone and then they said the page was gone and they couldn't find out how to go back and they said the website must have been down and we thought the whole site went down and the whole site tanked and they were upset, we were upset and it turns out that they clicked a link that we didn't catch that opened up a tab in a new browser and they couldn't go back and that was it, that was the solution but as a visual user, I can clearly see oh, I'm in a new tab, oh, I just closed the tab and you move back and you're fine but understanding what they went through and understanding how frustrating it is when just a site breaks for no reason really, really, really brings your, was really, really empathetic and a really powerful experience to me. It definitely made me check by a little bit of my privilege. Bring your own device. So we had, on all of our testing we asked the users to bring their own devices so they had the accessibility tools that they were used to using and we could see which different devices they used to engage with. In the in-person testing, a lot of them brought laptops. Some of them brought phones or iPads. One fellow brought a laptop, stopped halfway through, didn't like it and he said, can I just switch to my phone? I use that anyway. So even he assumed that we were expecting a full laptop, a desktop experience when really they're just on their mobile devices and frankly with a lot of users that we found preferred their mobile devices because they have more control about how close it is, how big it is, the accessibility tools are just easier there. And finally, emphasize depth of a breath. Really go into and ask how you want to feature, how you want to focus on how people want to use the small components of your site. Don't get a large broad strokes of it. Go through for each user and really target on something that you want to understand with them because they'll be able to give you a better experience. And I really want to emphasize that user testing with actual users that you're targeting is so, so important here. There's this phrase, nothing with us without us or nothing for us without us and here it's engaging the community to actually be interested in and have an investment in your product and it's making sure that they understand how to use it. It's making sure that you're listening to them. It's really important. This one is an image of RuPaul in a big blonde wig saying I don't want to hear any goddamn excuses. So this is it. This is how easy and difficult it can be to build a really beautiful, engaging web application that is accessible. It's not hard to take the first steps. As you said before, trying is the most important part. Pushing yourself, pushing the boundaries and seeing where your application is going to go is really, really, really critical here. For further resources, I would like to emphasize links are contained within the slide deck. There's so many stuff out there. It's amazing. Tomorrow there is another accessibility talk called Future Directions for Accessibility. Today, Empathy and Future about Accessibility was sadly canceled. I would love to see that again and there is an accessibility buff, I believe, tomorrow. If you want to come join us, check it out on the board. Yeah, I'm just going to tweet the details. It's not on the application or the website because it was when we scrolled into one of the free slots. I'll just tweet the details, but it's at 1545. So people working with accessibility can meet each other. Yeah. Today, great. Or you can tweet me or engage there. Yeah, finally, I just wanted to say thank you so, so much for all of your time and attention.