 So I'm Cara Galrap and thanks for coming to my session. It's called Inclusive Digital Products. If this is not the session you thought it would be, I won't be insulted if you get up and leave. So we're gonna go over today why web accessibility matters. A little, we'll do something like level setting and then we'll get into some more specifics. So a little bit about me, I'm Cara Galrap and I am a front end developer at Message Agency and I also oversee our web accessibility initiatives. I've been using Drupal since roughly 2012. So a little bit about Message Agency. We are a full service digital agency in Philadelphia. We're a certified B Corp and we work a lot with nonprofits, universities, foundations and government and other missions aligned for profits. So I'll give you guys a little bit of an outline of what we're gonna be talking about today. First we'll go over what is web accessibility. We'll go into a little bit why should we care about it. Where do I start, how do I get people to care and then we'll have some time hopefully for questions and answers. So what is web accessibility? In our physical world we understand why we have things like ramps into buildings and push plates on doors. It's to provide access to areas, information and functionality that any given person may need. So web accessibility is an extension of those considerations. It's a set of best practices and guidelines that reduces or removes the barrier to entry. It's also used to ensure that all users have equal access to information and functionality. So where do these standards come from? They come from the World Wide Web Consortium or the W3C which is led by the inventor of the internet, Tim Berners-Lame and he has this great quote, the power of the web is in its universality, accessed by everyone regardless of disability is an essential aspect. The W3C for those of you who don't know is an international organization that sets protocols and guidelines for ensuring the long-term growth of the web. And inside of the W3C is the web accessibility initiative which publishes the web content accessibility guidelines or the WCAG for short. The first one came out in 1998. The next one 2.0 came out in 2008 and then last year 2.1 came out. It was used to expand coverage for folks who have cognitive disabilities, more considerations for people who have low vision or no vision and also since a lot of people now have mobile devices, it was more guidelines and standards about how we can make our web projects more inclusive to people who use mobile devices. So the WCAG divides its guidelines into four principles, perceivable, operable, understandable and robust or poor for short. I'll be giving a brief overview of these principles as well as calling out some of the new additions that's in WCAG 2.1. So the first one is perceivable. Information and user interface components must be presentable to users in a way that they can perceive. So whether it's their senses or their devices such as a screen reader, users must be able to get your information in some way, shape or form. Even in our language, the way that our content is written, we should remove reliance on shape, location and color and sound to navigate. So if you have like a blog post and you say, see the highlighted text at the bottom of this page, to assistive technology or to someone who might be blind, that means absolutely nothing to them. So the next one is that on your webpage, if you have something that's not text, you must add some text that gives your users that same information. So things like our videos. We need to have closed captions. Even for our live events, we should have real-time captions, audio descriptions and we should have transcripts for these things. Also, think complex images. Things like infographics or flow charts and these visuals that typically hold a lot of information. We need to have that same type of text equivalent for users who might not be able to see these images. The next is we need proper color contrast for everything. Prior to 2.1, this was really focused primarily on our text, but now things like icons, information like on our flow charts, now all of those things also have to have proper color contrast as well. And also I would imagine since it's 2019, a majority of us are using some type of responsive framework, but with WCAG 2.1 and there's since there's such a strong focus on mobile devices, now it's mandatory that you have some type of responsive framework that your site is following. It also means that websites must be able to function in all orientations and all breakpoints. And then with WCAG 2.1, our full page conformance now includes all of those breakpoints. So we need to make sure that our mobile apps or our tablet views and our mobile views are just as accessible as our desktop websites. So the next is operable. This means that users must be able to operate your interface and the interface cannot require an interaction that a user can't perform. So our devices allow us to interact with them in a plethora of ways, especially when we use different accessories like let's say a stylus or some type of input device like a keyboard or speech input device. So and websites should really be allowed for users to not only use these accessories, but switch between them. So let's say I'm filling out your form with my keyboard. I should be able to switch my device and use a let's say a speech input tool and I shouldn't have any types of functionality delay and I should be able to just pick up where I left off when I switch between these devices. Next is we wanna make sure that we have our properly structured site content and we have a good site architecture and having multiple ways to access information and find pages, something like a sitemap is super useful for somebody who's using assistive technology. Let's say you have a hundred pages on your website. It might be really hard for somebody to, if they're using something like a screen reader to find exactly what content they're looking for so they can go to the sitemap section of your site to help them navigate your site a little bit better. I know this also means that we wanna use the right heading levels. We don't wanna skip any because assistive technology a lot of times uses that to navigate through a page and we also wanna make sure that our pages have titles. Simple things like this, not a lot of people but I've seen that sometimes these simple things are really easy to forget and sometimes omitted. So we also wanna give people control over animations or auto updating contents. This helps users who have inner ear disorders or epilepsy or users who find moving content very distracting. And then we also wanna make sure that we're providing enough time for our forms and we don't have any timeouts that our user isn't alerted to beforehand. So if you guys have ever used ticketmaster.com or something like that when you go to buy a ticket, a lot of times it says you have eight minutes to complete that. Some folks who have cognitive disabilities they might need some more time not only to process the information or the questions that's being asked of them but also they might need some additional time to understand how to appropriately and correctly respond to what's being asked of them. The next is understandable. So things like identifying the language of our page or the language of certain parts of our website if we're using, if we're let's say our site is in English but we have Spanish content. Appropriately tagging those things helps assistive technology interpret it a little bit better. Even things like if we use a bunch of abbreviations we can use an abbreviation tag. So assistive technology knows how to interpret that. As for example, Christmas we use Xmas but if you don't wrap that in a proper abbreviation tag a screen reader will likely pronounce it as Xmas. So we wanna make sure that we do have those types of considerations as well. And the next is we don't wanna have any surprises from interactions. So that people shouldn't be asking what does this button do or how do I undo what I just did? If I focus on an element it doesn't trigger any major changes of context or content. If I select a value in a select box that means I'm not going to a different page or a new tab is opening. So we wanna be able to have our users, they should be able to know what's gonna be happening when they interact with some type of component on your site. And next is we really wanna give clear instructions and definitions of our elements and especially for our errors. A lot of times if you're filling out a form and you're not exactly, let's say the instructions or the labels a little bit unclear that could be particularly confusing for certain users. And if it's possible, if somebody is making a mistake or it did make a mistake, let them know what that mistake is but also suggest ways to fix that mistake. So if we have a let's say a telephone field on our form if we use a certain structure, we should either force that structure or let the users know what that is. And we also wanna make sure that we have consistent navigation and naming of our user interface components. So let's say if we have a search bar somewhere in our navigation and our button says search, if we have that search bar on another page that submit button shouldn't say fine. So consistent naming and consistent navigation is really huge because it helps people identify patterns a lot quicker. And the next is robust. So things like this helps us ensure that our sites are backwards compatible and but they're also future proof. So content must be well formed enough that it can be interpreted reliably by a wide variety of user agents and obviously assistive technologies. This also means that users must be able to access your content as technologies advance. So obviously we wanna prioritize the present and avoid hacks, but if we're using, let's say the W3C markup validation service, it ensures that our HTML doesn't have any errors and as technologies advance or if a new tool comes out, users are still able to access our content and our site's functionality. And it also means that the names and roles of our user interface components so like your form inputs, your buttons, your links should be able to be programmatically determinable. So let's say if you're using or you're developing your own user face components, you must make their names, their roles and their properties, states and values available to your user's browser and their assistive technologies. And that should also mean that we should make them as accessible as possible by using standard HTML elements, like a link or a button. We shouldn't be using spans with certain like JavaScript tied to it for a button. When it's possible, we should just be using our standard HTML elements. And also we wanna make sure that when we have status messages on our website that assistive technology is alerted to them but it's not interrupting the user by focusing them on another component or bringing them to a new page. So we wanna be respectful of the user's actions and we wanna let them know that there is an error or there is a message but we don't wanna interrupt them. So why should I care about all of this? Well, we all know that it's the right thing to do and we as project managers, designers and developers are gatekeepers. And it's our responsibility not to gate people off and it's our responsibility to make sure that every aspect on a web project can be accessed by anybody, regardless of their limitations. And when we don't plan for creating accessible products and integrate ways for our sites to be used by all, we're undervaluing people based on things that are out of their control. In yesterday's Accessibility Deep Dive Workshop, the speakers brought this great quote by Cindy Lee saying that we're all just temporarily abled and that we're aging daily. So in effect, when we're designing for accessibility, we're really designing for our future selves and for our future children and generations after that. So there's a, luckily, sometimes doing the right thing isn't always the best way to convince people but luckily there's some business cases that we can make for making our products and our projects as accessible as possible. The first up is social. And it's the idea that as good corporate citizens, we have the responsibility to ensure equal and fair access to all users. So the first on our list is the idea that when we're solving for one, we're extending to many. For instance, you might not have a vision limitation but if text on a website has proper color contrast that benefits users who might have a color blindness but also if you're using your phone in the sun and the sun's glaring on it, it helps you see that as well. Or if buttons on our site, if we have a large clickable area for them, not only does that help people who have limited motor skills but it also helps us if we need to go get an Uber and we've had a few too many apple juices at the bar, it makes things like that a little bit easier for us too. And the next is we, and this also decreases the digital divide. 10% of Americans lack high speed internet and that number particularly affects people in the low income bracket. So when we conflate our sites with these insane animations and upload three megabyte pictures into our WYSIWYG, we're creating a barrier for that population. So even though things like compression benefit everybody, it benefits users especially who their only way to get on the internet might be their mobile device and that might be over a 3G speed and not internet. So next is we wanna make sure that we're friendly to first time internet users too. And in the coming years, we're gonna be seeing a lot of them. So for my numbers folks, I got some stats for you. But in the next coming years, 1.1 billion people worldwide will be accessing the internet for the first time and 23 million people will be in America accessing the internet for the first time. And I've been on the internet since I was about five years old so I'm able to pick up on user interface patterns fairly quickly and navigate through some atrocious information architecture pretty well. But there's a lot of people out there that aren't as tech savvy or don't have the level of digital literacy that I do. So we wanna make sure that the patterns that we are using on our websites are intuitive or if maybe they're breaking a common pattern that we give clear instructions for these people. We also wanna make sure that we offer a way to undo or back out of tasks so users don't get stuck in a place where they don't know what to do. And a lot of these people who are accessing the internet for the first time are senior citizens. So we may have to adjust our designs to allow for larger text sizes and larger clickable areas and things like that. And we also wanna make sure that we're accounting for low literacy and different types of fluency levels. We can't anticipate the reading levels and the fluency of our users. And the WCAG says that we should write our content to about a sixth grade reading level when possible. So things like chunking information and writing in clear, concise language that we're not and we're not using a whole lot of metaphors and things like that really helps this population digest your information. Even things like using icons to identify things helps people who let's say English is their second language. It helps them just give them a little bit more context about what's on your site. And the next is financial. By making our websites accessible, we're actually increasing our market segments. 15% of the world has some form of disability. And if we add that to the number of first time internet users, that's a whole lot of people that we're ignoring. And one in five Americans have a disability. And that one in five people, that disposable income is estimated at $645 billion annually. So if we're selling products on our site, it's imperative that your store is accessible. And it also makes Google love you. This goes into SEO. When the Googlebot comes by and it knows exactly what our page is about and we have perfect well-structured contents, all of our heading levels are on point, we rank higher. So stuff like using correct semantic markup, our grade six reading level, and all text on our images helps with all of that. And then it also helps us be eligible for more contracts. Some organizations might site WCAG 2.0 or 2.1 in their procurement policy. So staying in compliance lets us be eligible for those types of contracts. And on the flip side, if you're like a chief information officer or like a chief acquisition officer or somebody in a similar role, you can consider adding accessibility compliance to your procurement process and only accepting vendors who meet that level of compliance that you're looking for as well. And the next is probably the biggest reason is legal reasons. One thing that I always like to say is that developers are cheaper than lawyers. So this is one of the biggest reasons for wanting, unfortunately one of the biggest reasons for wanting to stay in compliance. So this really stems from the Americans with Disability Act or the ADA. And it's a civil rights issue. It basically means that we can't discriminate against people with disabilities pretty much plain and simple. And you likely need to be compliant. This covers a wide range of people. Includes state and local government, non-profits, and basically anything that touches the public or the public can interact with, you likely need to be in compliance. Dominoes and Beyonce was just sued. So it's pretty risky to gate any users off from your site or your site's functionality. And since there is little in the way of federal web accessibility law, some states are moving forward with their own decisions. So you really need to know your state. For example, California's government website requirements indicate that vendors can use WCAG 2.0 or the latest version of WCAG, which would be 2.1. So it will be very inconsistent across states and institutions. So you really need to maybe consult with your legal counsel about what level of compliance you actually need to be in. So where do you, so where do we start with all of this? This is a 30 minute presentation and I've had a lot of coffee. I'm talking really fast. So hopefully we're covering a lot and you guys are all following me. So this really needs to be an organizational wide effort because it's not the sole responsibility of a developer or a designer or a project manager in order to get us across that accessibility finish lines. So we really want to make sure that we're instituting this at an organizational wide level. And we should, and by doing that, one of the things that we should be doing is standardizing our interpretation, our goals and our tools. When we're not using the same tools or have the same understanding of what each requirement means to us, it creates inconsistencies and will likely cost an organization more money than needs to be. If I flagged something as, let's say, that wasn't an issue, but then somebody goes in with another tool and they interpret it differently, that can be a little expensive and a little annoying too. But there's different interpretations of it too. So we can be going for a minimum approach, an optimized approach or an idealized approach. So a minimum is just I am, let's say I have a website and I'm just trying to check my boxes off. Let's say I'm retrofitting something. So we're literally just trying to make checks on a checkbox. Optimized is more, we're taking the spirit of the standard or the guideline, but what we're really doing is trying to make a better experience for somebody who's using assistive technology. And the next is idealized, which you really need to plan for that. That type of approach is really for, we've thought about this in the beginning and so that there's gonna be no sacrifice in quality for anybody who's using assistive technology. And we also wanna make sure that we're using the same tools and testing methods as I touched on before. Certain tools will flag certain things a different way. So we wanna make sure that we're using the same approaches for those things. And also we wanna identify our Achilles heel. There might be an area of your website or web app that you're even afraid to touch. For a number of organizations, this is their PDFs and their videos. So if you have videos on your site, you need captions or you need transcripts. If you have flow charts on your site, you need a text equivalent of that. PDFs are kind of historically inaccessible, but if you're using Adobe Acrobat, you can actually scan your PDF's accessibility for that. And we also wanna be sharing knowledge and responsibility. As I said before, it's not solely the project manager or the developer or the designer's responsibility, it's all of ours. So things like joining an accessibility group on Slack or subscribing to a newsletter or just talking to people, it's a way to be a reminder, like a constant reminder that we're here to serve all users. And then wanna be a little mindful of time, so we're gonna zoom through these a little bit. But we'll go through some ways that no matter what your role is in organization, we can still, things that we can actively do to increase our site's accessibility. So for a project manager, we wanna make sure that we're building in and not building on. So it's imperative that we are using, we are citing accessibility as a requirement and that this is launch critical. We wanna make sure that we're building this in and so that when it comes to QA, we're not getting all of these tickets like, hey, I'm using a keyboard and I can't access any of your dropdown menus. And yet we wanna make sure that it's a requirement from the start. So if we need to communicate that to a client that maybe there are certain things that they need to plan for, like I touched on before about text equivalents to things. Some things take time and they take money, so we wanna make sure that everyone's on the same page. And this also might mean that we might need to train some of our content editors. So we wanna make sure that we are, we're accounting for that in our time and also our budget. So the next is when we're in discovery and design. So when we're thinking about accessibility in discovery and design, we want to incorporate either universal or inclusive design practices. And it's the idea that we're putting the human first. It's a very human centric and epithetic approach to design. And your designs will be stronger and more intuitive of it. With accessibility we consider things like vision and cognitive and mobility limitations, but human centric design encompasses accessibility but also takes things like location and gender, education and age into consideration as well. And one of the ways that we can do this is creating personas with limitations. For those of you who don't know what a persona is, personas are putting names, faces and attributes to who our users are. It's a way to make our users a bit more real before we actually go into development. So creating a persona that maybe has a limitation, whether it's temporary or permanent, helps remind us throughout the process that we're here to serve all users. And the next is we really wanna, we wanna be vetting our mock-ups and we wanna be vetting our wireframes. So this is where we'll check for things like color contrast and make sure all of our elements have labels, things like that. And an interesting fact about, that I learned about color vision deficiency. So a lot of times when we think about color contrast, we think of people who have like a color blindness. But a study recently came out that people who actually suffer from depression, whether they're on medication or not, depression reduces your contrast sensitivity. So which means that the difference between black and white isn't as strong for people who don't have depression. And it's a lot of times, we do think that it's more about these specific things like, oh, this person's like color blind, but there's a lot of sometimes hidden disabilities that people have that we should be taking into consideration as well. And this is also when we can, there are things like we have like an infinite scrolling section of our website. Those can be particularly problematic for users who are navigating by keyboard because they can't get to the end of the content or somebody who has an inner ear disorder where some type of auto loading content that has an animation to it can trigger some type of episode. So the next in development, we can use a number of web extensions and command line tools in order to check for accessibility. The Wave Evaluation Tool is a really great extension. Microsoft recently came out with Accessibility Insights which is a combination of doing automatic checks but also if you have to do a manual test for things which you, if you are doing an accessibility audit or if you are checking for accessibility, a majority of the things you have to check for are manual but this tool actually walks you through how to test manually for something. And then we want to use correct semantic markup and use our year rolls if absolutely necessary. So things like we don't want to reinvent the wheel and then give it a flat tire. So we shouldn't be using spans when we can just use a button instead. So things like that. And then like I said, it's 2019. So if you're not using a responsive framework like wake up, let's go. It's time to download Bootstrap like. But we want to make sure that our sites are responsive. Compression comes into play here so it plays well with smaller devices and people who don't have high speed internet. And then test, test, test. There is no use developing with empathy if we're not actually going to be testing with this type of assistive technology or users who are actually using or who have these limitations. And then if you're a content creator, there's a lot of things that you can do and you're usually the person who will ensure that any new content that's on the site is staying in compliance. And since we're at DrupalCon, a lot of you guys probably use a CK editor. There's a great plugin that you can get called the Accessibility Checker which actually scans your content and flags any error that might have. And then if you do have an error, it will likely either change it for you but it also explains to you why it's wrong. We also want to be mindful of image sizes. So seriously, do not upload three megabyte pictures into the WYSIWYG. It's a horrible experience for everybody but particularly those who are on a mobile device. And then we want to make sure that we learn to write awesome alt text especially for our complex images. So a little bit of what I was saying before about our infographics and our flow charts, there's actually a way that you can write those called long descriptions. And if you are interested in learning more about that, just flag me after this because we have 30 seconds left. And we also want to make sure that we're checking our content's reading level. But let's say if you have like a really technical audience. So for instance, we have a site that deals with a lot of medical terminology. That's a very technical audience. So it might be impossible for us to write that at a sixth grade reading level but there are still things you can do. Don't have a wall of text. Make sure we're breaking up content with our headings. Don't have like 35 words in a sentence. So even if you do have a very technical audience, there are still ways to make your content more reader friendly. So how do we get people to care? Think about accessibility as an investment. It allows more people to have a positive experience with your brand and it'll likely create brand advocates for you. We also want to make sure that we keep talking and we keep asking questions. Be a constant reminder that we're here to serve all users. Don't be afraid to ask your designer why it takes a mouse user. One click to get to a contact us but it takes a keyboard user, takes a keyboard user 15 tabs to get to that same thing. And it's also important to share responsibility. Like I said, it's not just one person's responsibility. It's all of ours. And I don't think we have time for question and answers but feel free to grab me. I'm Kara and thank you for coming to my session. We have a booth in the exhibit hall so feel free to grab me. This is my email address. I have a green button on so feel free to come talk. So hope you guys learned something.