 Cool, so I'll be talking about the presentation is called Beyond Screen Readers, and what I'm gonna be focusing on it, I'll go into more detail, but what I would like to do is kind of take everyone here on a journey to look at some of the ways that we can improve our accessibility work beyond the base level of expectations that we frequently set. So who am I? I'm Erin Marchak. I'm the person giving this presentation. You may have already known that. My Twitter and my d.o profile are up there. If you have any questions or concerns, during this presentation, please tweet or message me. I will be posting the slides later on. There's some resources in here. I will be posting them and tweeting them out. So if you don't write everything down, don't worry about it. And I work at MyPlanet, we're a enterprise UX firm out of Toronto, Canada. And what I do is I specialize in the Drupal practice lead. So I coach and I mentor developers on top of embedding on them on teams as a technical architect to build out projects. And I'm really passionate about my work with accessibility. And I hope that I can bring some of this experience that I've had to you. I almost poured water on my computer. It'd be exciting. Cool, so what we'll cover. I'm gonna cover four things here. I'm gonna share some understanding of what inclusive design is. I think that's a really important idea for us to understand. I'm also gonna share, after that, I'm gonna share some methods for inclusive design and how you can help content managers and designers start thinking about inclusivity. I'm gonna then share some techniques. Once you've built the site and once you have this beautiful site, techniques for identifying accessibility concerns. And then I'm gonna show you some code for hard tactics for how you could actually use this idea in your custom themes. So I have a timer. We should be on track. It should be okay. Cool, so the first part, understanding inclusive design. Who here has heard of inclusive design before I mentioned it? Can you raise your hand? Okay, great, cool. This is gonna be like super old hat for you, but I'm gonna go through it anyway. So inclusive design, on this slide here, I have some descriptions that I'm gonna read and on the right side I have a graph that I'm gonna describe what's gonna be on there and how it relates to inclusive design. So in Toronto we have a really fantastic center of inclusive design through our OCAD University and what it does is it focuses on the idea that there is a mismatch between the needs of the individual and the environment or the service or product offered. So we encounter the idea of disability when there's a mismatch. And that's really important for us to understand because as the graph on the side illustrates, that mismatch doesn't necessarily have to be how we understand or phrase or frame our minds on what disability and what accessibility needs are. On the graph it's images of individuals. There's discussions about permanent disabilities, temporary disabilities or mismatches and situational ones. Touch, if you're not able to operate a touchscreen, if you're missing an arm, if you have an arm injury, if you're a new parent or if you're from Canada, you're wearing gloves. Touch itself is gonna be really difficult and so you need to make sure you're catering to that. And understanding that this is situational all the way to permanent and kind of catering to this broad spectrum of individuals. On the next row it's called, there's a label of C. Under permanent it says blind. Under temporary it's someone with cataracts. And in situational it's a distracted driver which is always something that we have a problem with but you can understand how there's a spectrum of ability and a spectrum of needs that need to be met here. Finally, here, if you are deaf, if you have an ear infection or as the situational one is if you're a bartender, the other one that we frequently talk about for hearing is if you're at an airport, it's frequently hard to hear announcements clearly. That's a really good example. At the last row we have speak. So if somebody is unable to verbally communicate, if they have laryngitis or a throat problem or if they have a heavy accent and I think the illustration is a Viking woman but I have not figured that out what it is. But the, I think when we talk about accessibility and we talk about a lot of the work that we do, a lot of it's framed around the top two but we don't really delve into and really kind of investigate what's happening when we handle audio or language problems. And I would really like to focus on, not necessarily focus on that but I'll be really kind of covering that here. And that's especially relevant in terms of the conversational interfaces, the more verbal audio tools that we're using and how the web is kind of expanding out into internet of things. So here I have the levels of the web content accessibility guidelines up and they're broken into three. We have level A or priority one, which is a must have. It's defined as a web content developer must satisfy this checkpoint. If you cannot satisfy this checkpoint, groups will find it impossible. So when we talk about accessibility, these guidelines that we have here, they start at level A and you really need to focus on making sure that you have a level A baseline for people to access your site. Users will find it impossible. Level AA or priority two is should. So we should be striving to this. And this is when if you're doing work and if you're able to invest in budget and time and teams, double A is what we should be striving for because it allows groups, without it groups will find it difficult to access your content. So when talking about accessibility, a lot of the times that we talk about it, we talk about the web content accessibility guidelines for priority two. And what I think a lot of people don't understand is what priority three is. And when you look how it's phrased, this is pulled from the WCAG. So a web content developer may address this checkpoint, which is optional. And as a note underneath on the guidelines, if you follow it, level A should not be a goal that is achievable because it will be impossible for all content to be fully accessible for every individual for across the full spectrum. But it's something we may hit. It's something we may strive for. And when trying to understand accessibility, it's important for us to know that what we're trying to do is make it available for all users, for whatever user agent they're using, whatever browser they're using. And it's the act of trying. It's the act of striving for this idea of perfection, which we acknowledge will never hit. But we should be focused and learning and improving ourselves to gain that. So I think that that's really important when framing conversations around accessibility, whether you're building it for your own tools, whether you're building it for someone else, whether you're talking it in general, is that the idea of trying is so critical and so important. So on top of hitting all of these check marks and hitting all of these guidelines and going through all of the section 508 and all of the different items that you have within it, the act of doing it starts the conversation and starts the design process. So I'm gonna have a video on here that's pulled from Microsoft's Inclusive Design series. And I found it really relevant for this topic. And I just wanna, when watching it, try to see how the Rosemary describes how she exists within a physical space and how we can map that to a digital space. When I'm in an accessible space without other disabled people using the space, I feel alone. She enters through a revolving door. For me, the best environment that I'm ever in is Washington, D.C. So when you go to Washington, D.C., it's very moving because you're in an accessible public environment, transportation, public spaces, and it's used by a wide, wide range of people with disabilities and other people that use accessible environments. Passengers wait for the metro in D.C. So one of the things that I think is most important about a disability perspective is to make life work, to make things fit between body and world You change the environment, not the body. You change the environment, not the person. You... What Marie talks about is that at one point, when she's in an accessible space with nobody else using it, it's very lonely. It's not this exciting, dynamic, creative environment. And whether that's a physical space or a digital space, we need to really respect that as content creators and tool builders. If we're creating one-off tools, interfaces, techniques, or digital spaces targeted to individuals with a very specific experience of the world, we're gonna be isolating them and we're not gonna be bringing them into our content and in our products together as a group. On top of that, we have to understand that we have to be really agnostic for the tool set, what Rosemary calls the body when she talks about the physical space, but how somebody engages your tools and your devices, we need to understand and know that even though perhaps I'm designing it on this giant 30-inch screen, there will be people who don't have access to a screen or a large screen or a static screen. And so understanding the different perspectives that users are using your tools allows you to build a more inclusive product that doesn't isolate users. Knowing that and knowing that our goal here today is to build tools, is to build communities, is to bring together people for the web and digital products, is that we need to start building tools with a mindset of inclusive design and a mindset very, very early on in the process. And without bringing people in and including them in the process early on, we're gonna be continually always refactoring our work later on to hit some check boxes. We're not actually gonna be developing tailored content. We're gonna be retrofitting English castle with a wheelchair ramp in which they still have to go over cobblestones. Like it's not a great experience and not a lot of people are gonna be excited and passionate and engage with our work. And so the idea of bringing inclusive design into your work, whether you're a designer, developer or content manager, is really, really important to do it early on. And how we do it is, I'm gonna show you some of the few methods within that. At my planet, we do a lot of user experience design. And a lot of that, we found that the same principles for great user experience echoes out to a great accessible experience. The assuming that an accessible user is going to require different ways of excluding an accessible user or a user that uses assistive tech from experiential design is just excluding them from the space that you're building. So by including groups of users early on, a diverse group of users that use different tool sets, that use different ways of engaging your product, it's gonna really help everyone design, develop and understand what you need to do to actually meet the needs. So what we do is, at the first point, we do user testing. And what we do there is there's, it's a step in the process where we engage users, either we have a prototype built or it is a more conceptual wireframes at that point, or we do it all the way right before release where we do validation on a fully built product to see if there's any tweaky tweaks that we can make. What UX testing is, is it's pairs of researchers, you can be a UX expert professional, or if you're just starting off with a small team, there are guides to how to engage and format interviews. But what you need to do is pairs of individuals meet with the actual users and talk to them. And what we're trying to do is we're trying to find assumptions and biases that people bring to the product. And we either, if we're not challenging or catering to those biases and catering to those assumptions, people aren't gonna use our product, they're gonna hit cognitive dissonance. And the benefit of that is with user experience testing is it's very easy if you already have a community around your product, if you already have users, you can reach out to underrepresented groups and ask them to participate in it, which we found absolutely amazing for building accessible products because the communities that use these tools are so excited to finally participate in the building of it, because frequently they're appended as an afterthought. But when you have accessible design and inclusive design built in at the beginning, it's much easier for you to kind of accommodate different users. The other thing that we do with specifically accessibility user experience design is that we ask people to bring their own devices. And what that means is they use their own tool sets, both assistive tech and any kind of hardware to engage with our product and our design. And it allows us to see the exact point in which that user's ability and technological tools that they use to see how that exists. One example was I was doing an interview with an individual and we asked everyone to bring their own computers. And so he sat down, we opened up his computer, his computer couldn't connect to the Wi-Fi, which is like a standard thing when you ask people to bring your own devices. And he asked at that point, could I just do it on my phone, because I use that anyway. And it allowed us to identify the fact that not a lot of users that we were targeting actually used a full-on computer, such as a laptop. They were all on tablets or mobile devices. And you won't know that until you actually talk to users to see how they engage with. We can have analytical data from Google Analytics or any kind of statistical interface, but you'll never see how that one person chooses to browse in such granularity as with actually talking to them. And that gives you so much more information and insight into how people use your tools. Finally, what we do with this is it's usually a combination of in-person where we ask them to come into an office or a common space, or we engage with them remotely either over the phone or with screen share if they are comfortable with the screen share type thing. What that allows us to do is we get the fine-grain detail that we have when you're talking to somebody in person. You can hear the tone and see how they move and see how they can become uncomfortable or really excited when using your product. There's just more detail you can gain from that. And remote engagement, one, it allows you to access underserved communities much easier. It's just a phone call. And if you're able to connect with your users through that, it's much, much easier. Also, specifically with non-cited users, when you're asking them to access a prototype, you're just over the phone, how they describe the product to you is so informative and interesting. We had one interview that was done over the phone. There was no visuals. And the person at one point just said, the website went away. I was like, is it down? Has our server crashed? And the menu went away. I can't get back to the site. And we were frustrated because of this because we thought our prototype went down. They were frustrated because they weren't being able to use it. And it turns out that it's the basic accessibility problem of somebody put a link that opened in a new window. And at no point before then had I understood how frustrating and disorienting it was. I knew it academically, but I was just as frustrated as the user was. And to build that empathy in yourself, you need to actually communicate and talk with people and how they use the product. So it's really, really, really beneficial to engage with users and have these UX testing experiences. And because the information that you're gathering is so rich, UX testing, it's not the same as analytics where you need quantitative data. This is qualitative. So you can do smaller groups of people. The sweet spot that we usually try to do is four for each round, targeting their individual tool sets and individual assumptions. So the barrier to entry for running these testing scenarios is really, really small. Finally, in terms of content authoring experiences, once you have built the tool sets, the importance of continuing to train and maintain your accessible work is so, so important. Because you can build, as a developer, you can build this amazingly beautiful, totally compliant site. And then you hand it off to a content team that has never received training. And they'll definitely, not maliciously, but they will build content and they will make decisions without the context that they need. So in terms of sharing the accessibility initiative and sharing the idea and the pursuit of inclusion, it's really important to make sure that everyone involved in building your tools is trained and understands the goal. For content authoring, the CK Editor has an accessibility checker and there's a little module. Let's see if this works. That you can plug in and what this allows you to do is there's a, it's not an accessible tool. So if you have users that need guidance for accessibility, the content managers, this will not be suitable for them. But it guides users through how to audit WYSIWYG content for accessible benefits. Another thing that you can do with this is if you use the Drupal 8 content authoring defaults, a lot of them out of the gate are really, really accessible and guide your users to understanding it. So we have title and alt text or by default available. And on the link here, the lovely Mike Gifford has a whole article discussing how to use this and how to actually cater to the users. The other thing that you can do, and we actually do this, is have somebody internally to the content authoring team go through the WYSIWYG checklist on the site. You should get an external team to audit it, but if that's a barrier for you, again, the idea is striving. So as long as we're going through and we're checking it and maybe every month or so you just audit new content and be like, do we see anything from any automated auditing tools? Which I will show in a minute. That actually helps people understand where they've made a mistake and if it's internal to their teams, it's not like it's this big idea, a big barrier, a big weight of somebody coming in and be like, ugh, I'm gonna get a slap on the wrist. This is something that they can use to strive for. From design tools on a design perspective, again, training and understanding the different techniques and understanding the guidelines is really important to engage with your designers, whether they're visual or user experience is really, really important. As an easy thing, I have like literally passively, aggressively posted this on our wall at the office. There is a lovely infographic that is accessibility for designers and it shows the different things that you can do or different things you should consider when building accessibility into your designs. One of the things on here that I find is really important that this is just a user experience concept but are indicators on your site. Have nothing happened that is not explained or reversible by the user. So when designing tools, if they make a mistake, if they click on a link, you can always go back a step and that is a user experience principle but it follows the same results that you're always able to recover from any error which is the problem with the blank link is that there was no indicator of how we got to this page, how the menu went away or what was going on that was inside the context of the web app. Additionally, if they use Sketch, this is the exciting demo, Sketch has a color contrast analyzer plugin that you can plug in, it's a plugin and it's really easy to actually use it. You can see my beautiful design here, so exciting. I highlight my text, at the bottom it gives a little screen that it says it's AAA pass for the large text and it gives you the color contrast ratio. So allowing designers to check their work themselves really speeds up the process once they understand that we need to have color contrast concerns. Very few designers intentionally do bad work. I'm gonna say none but maybe there's a guy and giving people the tools to solve these problems themselves is really getting them engaged in the initiative and allowing them to continue through it. The other thing that you can do is they can install CSS paper. So as a developer I saw this and I'm like this is the web inspector tool? It is, no dowd, I don't need to talk to you right now. But it allows developers to go through and see the different colors and to see the sites and to understand what the details of the fonts are. So once they understand what's going into the site and understand the color palette, does it have enough contrast and really allow them the tools to engage with the live content you're building lowers the barrier for their participation. So those are some methods outside of development that you can use to kind of prevent things from happening on your site. As I said before I was gonna touch on things that you can do to actually help identify problems when they occur. There are two ways to identify problems on your site. One is an automated tool. From a DevOps perspective we use the idea of behavioral driven development which is behavioral tests. And again this pulls it back to user experience where there are automated tests that go through user behaviors to make sure that users can click and access different buttons. And it's really easy for you to go through if you have these automated tests set up to test workflows. And when you're building these tests you can assume that they have different access to mouse, keyboard, or different APIs that are available. Beyond that these are two APIs that do actual accessibility testing. Tenon.io is a third party. You can pass a URL there. Let's see what happens here. And it analyzes your webpage. You can push this through an API. Ooh, nine issues. So it's fine. So you can push this through a third party API. You're able to hook it up to your Travis tests. So every time you make a change on the code it actually gives you this lovely reporting. Now this does do an automated test. So it looks through for any kind of flags such as this link has no text in it. There's a little error. And it allows you to quickly catch basic compliance concerns beforehand. The issue is that this is a third party so you do need to have access remotely if you're behind a firewall. I recommend checking out Axe Core which is very, very similar but it's self-hosted so you can run it on a local site if it's behind a firewall or during your DevOps process. All the links are in the slides and I will be tweeting out the slides later so if you're like, ah, it's okay. Don't be like, ah, cool. So those are two kind of like DevOps-y tools that you can look at. I'm gonna call these dev tasks so these are manual things that you can do to help test your work. There's two kind of toolbars that we'll use with a wave toolbar and the totally or whatever plugin. The other, and I'll be demonstrating those, the Devel Alley Module. What this does is it allows logging for some of the APIs in Drupal 8 so you have more explicit logging for the accessibility APIs. Such as the announcements and the tabbing manager to kind of give insight to people who are not comfortable with perhaps testing using these accessibility tools. So the two toolbars I mentioned, I will be testing on Accessible Media Inc which is a site that we made so those nine errors I'm gonna hear about later. And what Accessible Media Incorporated does is they focus on distributing media content to Canadian users in an accessible fashion. So the users on their site use assistive tech to engage with different TV shows, closed captioning, podcasts, news stories and everything's catered toward their experiences. So, boo boo boo, I have my Chrome. The first one is the wave toolbar. Man, I wish the screen was bigger. So what I can do here is I click it and you can see that it actually gives contextual tooltips for what's going on here and I can go through and I can step through my site. If you're using content, like if you have content managers that would like to audit their own site for accessibility concerns, I really recommend these toolbars because they can go through the articles or the content they've created and just kind of see what's going on. Because the benefit of this here is even if it's an error or a feature, you can click for more information and it gives you contextual information based on the guidelines. So while I wouldn't recommend just passing this to somebody without any training or guidance, it's very, very easy to do self-service auditing from it. The other one, Totali, looks a bit better. There it is, it comes up with little glasses and then it goes through and you can see any concerns. So they're a little bit different. I found that Totali doesn't really respect a lot of mobile work that you're doing. So if you're hiding and showing content from a mobile versus desktop, Totali kind of catches everything. So it doesn't really use the DOM and the DOM is what the actual assistive tech uses to engage with, which is a note that a lot of people, or a concern that a lot of users used to have and a lot of people with accessibility work said was that you weren't able to use JavaScript on the web and the majority of users that we talked to who use assistive tech prefer to have these rich internet applications that they can actually engage with. So they want the same UX, they want the same space as everyone else and right now that there's so many assistive technologies that are able to properly parse the DOM that you can use technologies such as Angular and React with accessibility in mind. As long as you're still building those technologies out with the same principles and practices that you would do a static HTML. And I'll actually show how you can do that. So these are two tools that you can just install on Chrome and people can kind of self-serve their own work and developers can go through and check at a very basic level. If they're not aware of the guidelines at the back of their hand, if they're not super comfortable these will guide them in ways that they can at least understand and explore their work. The other way, which I think is much more important is manual testing. Because the tools that I showed you parse a static DOM as a machine would. They don't engage and connect with something. They don't use it in the same way that a user would. They're not looking for the same keywords and the same structure that a user would. So manual testing is actually important because despite the fact that our robot overlords are definitely gonna come soon. Most things that we're concerned about are people using our tools. It's not the robots and it's not the certifications and it's not the Wave Toolbar. The Wave Toolbar is an indicator for how somebody would actually use the site. It's not an example of how somebody would use the site. So manual testing is the key part of actually making sure that your work is accessible. And that does tie back to the user experience testing is whenever anybody manually steps through something, whenever it's a developer, a user, a content manager, a QA person, a designer, they are testing it as a user would. So it's really important. I've broken it into three large groups. This by no means encapsulates all the possible ways somebody may engage with your site. But when thinking about manually testing your site, there's kind of three ways you can go through with it. There's site or any kind of visual aspect. There's sound or auditory and there's touch. Beyond that there's definitely more but I'm gonna show you how you can actually test some of this. Now, how many people here have assistive tech on their computers? Could you raise your hands please? Okay, pretty good. Could you keep your hands up? How many people here have a Apple product? Could you raise your hands to that? How many people here have an Android product? Could you, no, hands up, hands up. How many people here have a Windows product? You can't put your hand down. Okay, so look around. All of these, it was a lot of people. All of these tools already have assistive tech built in. There are voiceover for Mac and iOS, including Siri. Android has one built in that you could turn on with the assistive tech. Windows has a free voiceover application called NDVA that you can install. And these come out of the box, except for Windows, but that's like Windows. And so what we're able to do is we already have the tools to test this. So again, we're talking about barriers to entry for accessibility testing. It's still quite low. So what am I gonna do? I'm gonna show you how you can actually test this on a Mac. I don't have Linux, so you can use Google. But you can see how easy it is if you're on a Mac platform. So under system preferences, if you go to system preferences, there's like a little accessibility guy or gal, or gender neutral folk. And you can see here that I have voiceover right here that I can actually turn on. And I'll be showing you how to use voiceover in a second. But in terms of site, what a lot of people have, an easy way to test this is there's a guideline that says nothing should be indicated by color alone. And so you're like, how do I do that? I always see color. One, hire a developer that doesn't see color. If you can't, use grayscale. You can turn it on and you can see your site actually with grayscale. And you can go through and engage with it and see if there's any problems with it. A lot of the time what this is gonna do is actually tell you a contrast problem. You're like, well, how do I test if I have a contrast problem? You increase contrast. That's one of, and these are the settings that users would actually try on your site. The other way you can increase contrast is this. So you can see like most of my interface is not super accessible at this level. But if I increase it up to here, it's pretty legible. Turn those off. Did you know that the shaky mouse thing? Oh, come on, man. There it is. Actually an accessibility benefit. The other thing that you can do and the other thing that how people engage with your site is if they have low vision, they actually use zooming to engage with your site. If you've ever done the like pinch and view on your phone, the interface is very, very similar. So it is option command eight. There we go, and I can start engaging with the site as a zoom person. And you can see here that if you have very large images or areas without context, it's really easy in the same way that any sighted person would use pinch and zoom on a phone. It's really easy to get lost. So always making sure that you have pointers and context on your site. And I haven't set up anything special here. I'm not like doing anything wizardry behind the background. I'm just going through and clicking and trying some things. So again, barriers are quite low. Finally, voiceover. A lot of people have like a concern about using voiceover because if you work with anybody with assistive tech, they usually have it on very loud and very fast. And it sounds like terrifying. Or if you're near somebody that is testing something with assistive tech, they have voiceover on and it's just like the slowest computer voice for half an hour like just droning on. Plot twist. If you are testing it as a user, you can also click voiceover. And I can turn the audio off. And then I have a little toolbar right here. Chrome busy. Welcome to Macbutt muting. Now you don't have to hear the voiceover voice, right? And you can go through. I can skip to main content and I can then access different ways to get to my site. And you can see here that it's the tools that we were using before such as the toolbars that describe different things on the page. It makes way more sense if you're actually doing it manually. So you have context. I can see that it's heading level three, how to videos. I can scroll down. And what I think is really important with manually testing it is that you can actually see points in which you're non-compliant but it's a better user experience. So I'm just gonna show you one thing that we've done. Here we have the digital video guide. And I'm just hitting tab. There are different ways to navigate throughout it but tab is the main one and we're very similar to tab. We have this thing called a combo box here and it says jump to today at noon, go. And if I were to turn on, also if you turn on any of these accessibility tools with voiceover on, it's like bad times. So don't, they're not very accessible which is ironic. But we have here this combo box. We don't use labels properly so it always gives errors whenever we do audits. But when we tested it with the users and we spoke with users, they said that it's way better for me to understand what's going on here when it's read like human language. So you can see here that I'm going through jump to and I'm tabbing through our combo box right now. Today which is collapsed so I know I can choose it at noon, collapsed, go. And when reading that as a non-cited user it's really, really helpful for me to have this very kind of descriptive human language sentence that isn't constrained by labels. So consistently we've always had this discussion with the users that they don't want us to follow these guidelines blindly. They want something that is usable for them that is tailored to that. So the importance of manual testing, the importance of user experience design and the importance of actually talking to users is great. The other thing that we have here as a side note is if there's a really complicated interface that people are having a lot of problems with we found that if we tweak it one way one group of users gets confused and we tweak it the other way the other group of users gets confused. You just explicitly state it if you're using a keyboard. And we have this here because we have cited users that use the keyboard on our site. And so just describing to them what their expectations should be and how they can use the tools is actually really helpful. Again this goes back to training. When you actually sit down with somebody and give them the tools that they need to do their job they're gonna be much happier and they're gonna do it more efficiently. Next week. So I talked about some larger testing concepts and I'm gonna go through some individual tactics that we use in our Drupal 8 themes to actually help with different items. So what we do, a lot of these right now that I'm gonna be talking about are focusing on keyboard users and non-sided users. But some of the things actually do help. When building a custom theme there is a, we use a lot of regions in HTML5 like main and navigation, sidebar, or sorry, a side footer. And we found that unless we explicitly state it the user just hears navigation, navigation, navigation, navigation. Here I'm just gonna turn that on so you can see it. So if I go back to the AMI homepage I'm gonna turn on what's called the web router. Of course I forget it. Of course a live demo. Anyway. So what accessibility tools do is that they go through and they read the HTML5 regions as main. But what we're doing here is we're adding the ARIA label of content so when it hits it it hits main content, which you're like okay, whatever. When you have three different kinds of navigation such as a top level navigation and a footer navigation this starts getting confusing until you actually start describing it to something useful. So when users hit the web router they can actually target the individual content. Additionally how Drupal renders entities is we always have nodes and they have like teaser views and the teaser views are pretty sweet. But the teaser views are always rendered individually. The entities are always rendered in their own context they're never rendered as the context of the page. So what we frequently have to do is give the individual nodes context to what's going on. So we set the heading level dynamically based on where it is on the page. There's a benefit for following the individual numeric numbers of the headings. So it's H1's followed by H2's followed by H3's. So users can quickly jump between heading levels they understand when they're nesting into content and nesting out of content. So what we do is we set the heading levels. This is a twig template I have here. I have a variable called H that I'm printing. I set that in the preprocess function so by the time that I hit the template we're not doing any kind of funny ridiculous things in the template. It's very clear for designers to understand. And I'm passing also that heading level as a class onto the actual markup. So then when we target it with our style sheets it can be an explicitly targeted style even though it's a heading level two we know this should actually be styled as a heading level one. Because visually the visual patterns of it for users who don't use any kind of reader it's very helpful. Another thing that you can do very, very easily is enable inline form errors. The module is amazing. What it does is it gives very descriptive contextual links when you're completing a form and allows you to actually target any errors and validation. The only thing is you do have to remove the HTML5 required attribute because NDVA screen readers do not like it in relation to everything else because it only reads like required, required, required, required, required, required which you would get if you were testing with a screen reader. We talk a lot about alternative text image elements. Something that we need to realize is as we move forward with the modern web is we're starting to use different elements. The picture element itself doesn't properly inherit the alt text. So the picture element contains a handful of picture sources markup and then image that is the fallback. If a user is on a modern web browser, that image fallback is never rendered in the DOM so they'll never see the alt text. It just looks like empty images. So what we do is we add a visually hidden class explicitly in that element and set that as the alt text. So users who are using modern web technology with assistive tech can actually access that proper alt text. This one's a little more complicated. If you're building learn more text, there's a pattern that is encouraged that you just set more like the context of that as a span. So if I've read more at the bottom of my article and my article is titled like hot dogs are great and at the bottom it would say learn more about hot dogs are great as hidden text. You don't actually have to do that thanks to the ARIA tags. So what I have here is you can see that I have above the learn more text I have a attribute on my anchor element that says ARIA labeled by. And I'm passing it the ID of my link and the ID of my header. And what happens when a user with a screen reader hits that is that the screen reader reads out the content of the first ID and the content of the second ID. So it's read, learn more, Aaron likes hot dogs. But it means that you can have semantic text. It's you're not hiding and you're not messing with the DOM and you can still have clean understandable markup while also catering to users that need more context. And this is much more semantic and it shows that there's a relationship between these two elements more so than adding hidden duplicate text. So you can do this a lot. ARIA labeled by doesn't have to be about links. It's a way to build and collect relationships on a page. Cool. So there's some tips. There's some tricks. And I think the most important thing that I wanna remind people about building accessible tools is that when you hit the web content accessibility guidelines, they have a quote by Tim Berners-Lee who's part of it. And it's forefront on the page and I think it's really important for us to understand as people who build tools and content is that the power of the web is in its universality. It is, it should be universally relevant. It should be universally accessible and people should be able to access it. We're at a software conference for open source software. We, you're already interested in helping people gain knowledge and gain access to tools. And to say that we're passionate about how people use software and that we wanna keep our community open and inclusive without additionally catering and focusing on the content that we're building and the tools that we're supporting is a real double standard. So when you're building out content, whether or not your organization has a strong initiative and a strong reason to build accessible technology, we need to understand that as creators we are responsible for ensuring that the web is universal. Whether it's language, technology, tools, building out that universality is our, literally our job, that is my job. I build tools for the web and if the web is universal and if the web, if its power is the fact that everyone can access it, then I need to make sure that I am not a gatekeeper, that I keep these gates open. So understanding that there are tools and techniques and procedures and different processes that you can use is not as important. No, my slide. Is not as important as making sure that your teams are diverse from the get-go. Because when you have a diverse group of people building a tool, it's gonna encourage a diverse tool. The Harvard Business Review, this article, it gathered a handful of studies and in each study it verified the fact that if you have a diverse team people are gonna question their biases more. They had one study where it was a fake jury. One group was all white jurors, one group was four white and two black and in the all white jurors, they were given a case to read and they had to determine who the murderer was. The white jurors never questioned the facts as hard as the jurors in a diverse group. When you have a homogenous group, people make assumptions and people don't rethink those biases and having people rethink the biases that we're bringing to the tools of the web, having people understand that perhaps there might be different ways to engage my content is so important early on because you're preventing conflicts, nobody's a footnote at the end but building diverse and inclusive teams is the first step that we have to actually make sure that we're building a universal web because if we don't have content creators and tool creators bring their perspectives to it, we're gonna be continually marginalizing groups. So beyond all these tools and techniques, I really wanna emphasize that bring in people whether it's user experience testing or hiring or just general interviews, feedback forms that are from different groups so you can constantly re-examine the facts and re-examine your biases that you're bringing to the project because I know every time I engage with a user interview, I am being shown a new intersection of ability and technology to myself that I will never be able to create and revealing those biases to me makes me a better developer. So if you want to start catering to edge cases, catering to unique perspectives, catering to new tool sets, we have this whole world of internet of things that already existed. We think that voiceover in Siri and Alexis, this cool new thing, but there's already been people using these for decades. So when building out tools that are for a diverse group of people, we really need to start building out our teams first. And that's it. So thank you. Yes, questions? So this is in reference to the Axe Core tool that you were talking about. So I've been using the Axe Browser extension for a while and I really like it. And I was just wondering if you have any thoughts on one versus the other. As far as I'm aware, Axe Core is a DevOps tool so you can use it during your deploys or your post-commit hook so it's automated. But I mean, other than that, is there any benefits of it over just the extension? I mean, yeah, I see like one versus the other in the purpose of like what points you are in testing but like is the actual testing any different? It's the same as automated testing versus manual testing. If it's automated, it's on a cadence. You know, it happens every time if there's one person that skips it. Yeah. But if you can manually test it, it's always better because you have that context that you're bringing to it. Okay, but other than that, they pretty much catch the same kind of things. Okay, thanks. Hi, great presentation. In your user interview slash testing, are you guys finding that users are using the native accessibility functionality opposed to third-party software like JAWS, you know, window eyes, Zoom text, things of that nature? Specifically, it depends on the user and it depends on the context. We found that users with JAWS, because they're such a barrier entry for JAWS, they tend to stay with JAWS for a very long time and they just tend to stay on older tech. Specifically what we found out that people tended to use JAWS in their computers and then we're just using the built-in stuff on their phones or tablets. So people tend to use a lot and it depends on what the context is. If your users may have access to JAWS funding, because I know there's assistive programs for them to purchase it, they may use JAWS more than users that don't have access to that kind of funding. Okay, thank you. So I have a client that is going to need to become section 508 accessible for the very first time. They do a lot of content updates. What is a good resource where we can both learn more about how they can stay accessible as they update content? If you follow Mike Gifford, who is here, he's amazingly nice. He does a lot of education and work within the Drupal community. In addition to that, there are a lot of groups, specifically university groups that have training and documentation on how to build accessible tools. I know Stanford has a ton. So what I would recommend is see if you can get somebody who is an accessibility expert in to kind of sit down and show you how to use these tools, give you context, and build that empathy that you need. That would be ideal. Okay, go ahead. Thank you for the great presentation. I'm at a government agency in Canada, Statistics Canada, and one of the issues we have is we tend to work on our projects and then accessibility is kind of an audit step at the end. And then there's a lot of rework, design rework. I know you addressed it kind of in a bit, in a few pieces, but is there any general recommendations you can make how we can get folks, stakeholders at the table earlier so we can do less rework? If the issue is design, train and access your designers, because again, designers are just trying to do the best job with the information they have. They may not understand the concerns with design, and the sketch plugin is frequently with the design, you can normally tweaky-tweaky it, and it's okay. But unless it's a color contrast issue, giving designers the tools to kind of audit their own work early on is really helpful. And if it's a tech-building concern, the benefit of automated tools, such as these DevOps tools that you can go through, whether it's not every commit, but it's least like, maybe once a sprint, you just do a little audit, or once every few sprints, you just do a little audit, and you're like, guys, we kind of suck at this point. How can we adjust our code so that it can be catered to it? And educating developers early on is really, really helpful because they're gonna make accessible decisions before it goes to the audit stage, which is gonna be cheaper. So you're basically saying, in your agile sprints, do you build in tickets to address accessibility audits at periodic steps, rather than just at the end? It depends. On larger projects where we need to have an audit for compliancy issues, we build that into the sprint. For other projects where we're not gonna be audited, we encourage developers to make accessible decisions. And I'm really, really lucky in that I work with somebody that uses assistive tech, and so when testing out tools, we literally say, you need to make sure that he's able to use this, otherwise he can't test it, and he can't develop it, and it really sucks if somebody on your team, developers feel really bad when they're like everyone, but ever it can use the thing that we're currently building right now. So educating them to make early decisions on by themselves towards an accessible choice is much, much easier and cheaper. So a little bit of training, DevOps tools to give that kind of hard, kind of slap on the back of the hand or the back of the wrist. If you do a lot of stuff with accessibility, then, ooh, I better get out of here soon, then an automated DevOps process is helpful. Is there another person in this room after me? Oh, there's 50 minutes, let's keep going. Hi, Sean Heavey, Freelancer. My question's about accessibility more broadly and sort of the future of it. I was watching the new Bill and I show last night and they had on a blind man during the A at the Artificial Intelligence episode who has an app on his phone that has a deep learning algorithm that can describe things that he's taking pictures of. So my question is all this stuff we're talking about now is sort of just the kind of things we already do. Are you aware of any sort of emerging technologies in terms of AI, mobile computing devices, wearables, or the voice-activated assistance that everybody's got now that are really pushing the envelope or stuff that we should be looking more into? Well, I think that when building assistive tech for assistive tech is usually done as an afterthought. But how we're building out conversational interfaces means that people that have mobility or visual concerns, they can actually engage with it. So my humble opinion is that we're actually gonna see convergence because we have so many different ways to engage with a product, you're gonna be able to choose how you engage. So fingers crossed, accessibility should be built in from the ground up. But that being said, trying out different ways of engaging with a product. The wearable tech is great. I don't have to have my phone on alert with a sound. I just have a little vibration on me all the time and I can understand what's going on and I can engage with it directly. Yeah. So internet of things I think will kind of converge in the singularity for our glorious robot overlords. Okay, thank you, that was really good. Oh, did anybody drop a phone? Thank you, I'll bring it to the... Do you think it'll call mom? No, it looks dead. Okay, yes, sorry. This is probably a tough one. If you know roughly how much it would cost to build a site without paying attention to accessibility, is there any kind of rule of thumb for figuring out how to extra it would cost to build with a high level of accessibility? It depends on the complexity of the site and it depends on the maturity of the developers because if the developers can make early accessible decisions early on, then like refactoring the homepage is not gonna happen or refactoring the menus. What we do is we usually try to do one week of audits at the end and then we estimate based off of that and then we usually prioritize for accessible concerns because some of the times, if it's always gonna be at the end and that's something that you're not able to actually sprinkle through, you need to understand how bad it is before you can start estimating. Knowing that you have the audits either in line, like every few sprints, you just have an expert come in and be like, you need to tweak this or it's done at the end and then you can actually prioritize the development of it. It depends on the context of your site. Okay. I was really thrilled to see you talking about accessibility framing it in terms of user experience because I've been trying to figure out how to think that way myself. The tricky thing is when people have questions for me as a developer about how we can make our sites accessible that I can't really give them answers, I can only give them opinions and I'm just trying to figure out if there's any kind of a group or network I can go to to discuss different strategy ideas for how to improve user experience. Since there's no simple answer for a lot of questions that I can just look up. The cool thing about going to these conferences is I have a ton of resources at home that I could be like go to the Inclusive Design Institute and they have a weekly meetup but maybe reaching out to any specifically universities or government organizations that would kind of cater to this, Stanford, Yale, Harvard all have accessibility inclusive design initiatives. Start there and try to see if there's a group that you can participate in or reach out to the community because yeah, I can give opinions on things but until there's somebody that uses this that is impacted this that has the perspective that you need you're only gonna be putting yourselves in their shoes and that's not gonna get the full intersectionality of their perspective, if that makes sense. So reach out to universities, reach out to groups, go on Twitter. There is a great inclusivity and accessibility group on the Drupal Slack. If you wanna reach out there see if anybody is in your region you might be able to find resources through that. Cool, thanks.