 Wonderful. So thank you everybody for attending. I'm going to say a few, what I hope are very quick words as an introduction here and then I'll turn things over to our panelists. So this, as you probably almost certainly know at this point, this webinar is focused on web accessibility, which is an issue that I think LSE cares very deeply about. We did a major assessment of the statewide legal information websites that are either managed by an LSE grantee or an LSE grantee participates in as part of a broader community of folks managing the websites. And that assessment had nine focus areas. And I would say one of the most prominent focus areas, both in terms of doing the evaluation, but then also talking about the evaluation after it was over, whether it was with our LSE board or at a conference, was this topic of web accessibility. And our report and our toolkit covered a range of kind of things about web accessibility, but I would say the two most important takeaways were first, this is an area where there's a lot of opportunity for improvement among most legal aid websites. That's not a knock on the legal aid community. A lot of sites out there struggle with this, the issue of accessibility and making their site accessible to folks who are dealing with a disability. But at least among legal aid sites, there's also a lot of opportunity to improve. The second major takeaway that came from our evaluators as well as directly from the website community was the folks were very interested in learning more about this topic. People kind of, you know, knew a little bit about Section 508 guidelines or the WCAG guidelines or some of the other ones that were out there. But they didn't really have an extensive understanding of what those guidelines meant and how you could actually apply them to your website. And so one of the things we took away from the assessment was we wanted to do more around training and tools around web accessibility. And this webinar here today is one of our kind of first attempts to make this information more available to the legal aid community. So on our webinar, we have two great panelists both work for Reingold Incorporated. Reingold is a digital agency that's based outside of DC. They work on a broad range of website and technology projects. And they're currently working with LSC. We're a client of Reingold's on a major initiative to develop a flood preparation and response website in the Midwest, which has been a really interesting project. We're about six months into it. And if you're in that region, you'll probably hear more about that really soon. I've been very impressed with the depth of their expertise around web design and development, but also around issues like web accessibility and usability. So I'm very happy that they're able to come on and give this presentation here today. And with that, I think, Faith Allison, I'll turn things over to you and let you take things over. Faith here. Hi, everyone. Thank you for joining us today as we talk about accessibility on the web. We are really excited to be sharing this presentation, and so we appreciate you sending us by your time prep. Before we start, just one quick note, we'll be providing a transcript after this presentation for anyone who was unable to join or was unable to listen in. We want to mention that now, because we'll be referencing tools you can use, a website you might want to visit later on in the presentation. So if you don't want to write all of those down as we're talking, you'll be able to find those in the transcript as well. And before I go any further, I'm just going to pause and introduce myself. So my name is Faith Lambanak, and I'm a senior user experience designer at Reingold. And my role in a typical project here is to ensure that when we design a website that we understand the audience who will use that site and that what we design needs that audience's needs, and it is easy and enjoyable to use as possible. With me is Allison, who all that introduced herself. Hello, I'm Allison Karnwas. I'm the Director of Frontal Technology here at Reingold. And I'm on the team that basically translates designs into code and then makes it appear correctly in your browser. Three major portions. First, we'll be talking about what accessibility means and what it includes. Second, we'll be talking about how it's measured on websites. And third, we'll be talking about some of the overall results and benefits of creating an accessible website. So to begin with, what does accessibility mean? Well, let's start with how accessibility is defined by the WC3, which stands for the World Wide Web Consortium. This group purpose is to develop the protocols, guidelines, and specifications for the web code itself, which browsers then implement. So they're kind of an authority in this area. According to the W3C, accessibility means that people with disabilities can perceive, understand, navigate, and interact with websites and tools. It also means that they can contribute equally without barriers. There are also some other terms that you might hear that kind of fall into the same realm of accessibility, and that we'll be mentioning throughout the presentation. Let's talk about two of those terms next. So first, we want to talk about user experience design, which may sound familiar, and this is my.cloud.it title. In general, user experience design is focused on improving the usability of sites. As the W3C defines it, usability is about designing products to be effective, efficient, and satisfied. And the next term is inclusive design. So inclusion is about diversity and assuring the involvement of everyone to the greatest extent possible. In some regions, this is also referred to as universal design and design for all, and it addresses a broad range of issues, some of which could be considered accessibility, but also include other things like a consideration for literacy and geographic location. So our talk today is going to focus primarily on the subject of accessibility, but accessible best practices can also cross over into the usability and inclusion category. So you'll hear us refer back to these terms at times as well. Talking about this, you know, the idea of accessibility, we're going to talk about how the seed design approaches kind of work in practice. And let's start by actually thinking about the physical space, since the way we approached accessibility on the web is kind of similar. So in the physical space, we can start by asking the question, what do we need to do to allow people to participate? So let's say that we had a store. What do we need to do to allow people to shop at our store? The first thing we need to do is to navigate people to our location. So let's assume that they'll be driving a car to get there. So what's the first thing you do when your GPS says you've arrived? You look for a parking spot. Sometimes this is not the most joyous of tasks, and people may get frustrated with the lack of parking and drive away. But to make our store more usable, maybe we'll invest in a parking lot. So now fewer people will drive away. However, just because our store is more usable does not mean that it's accessible. We still need to consider people with disabilities that may be driving away out of frustration, because though there's parking available now, there's only spot left in the back. That's because our store is the popular, of course. Maybe they're driving away because they aren't able to walk long distances, or maybe they use a wheelchair and the parking lot is still too tough to navigate. So we reserve some special parking places for them to reduce the amount of walking. And we provide a space for the wheelchair lift to operate. So now our store is more accessible to people who have mobility issues. So now let's think about people who maybe don't have a car and took the subway system to our store. Here in DC we call it the Metro. So what has their journey looked like so far? So the Metro in DC is pretty accessible to a lot of different audiences. For people who are deaf, there are a lot of visual indicators to let them know what station they're at. Like the station signs, LED signs on the train itself. And then on some of the new cars, there's screens that provide a lot of information, like what station is next, an alert, like elevator outages. And then on the platform itself, there's blinking lights on the edge of the platform to give them a heads up if the train is incoming. For people who are blind, there's audio announcements at each station, and there's safety features. Like on the edge of the platform, there's bumps to warn them that they're close to the edge. And then there's barriers between the cars so they don't have that way of thinking it's an open door. So all of these features combined allow the Metro to be safely accessible to a wide audience. So getting back to our store, now that our customers are in the right vicinity, how do we get our potential customers in the front door? Easy, just walk up the steps. But wait, what about those customers that were in the wheelchair? We'll put in a ramp. Now our front door is easily accessible. So then when our customers get close to our store, we want them to know which door they should go in. Typically, that means that we should put up a sign, but what about people who have vision problems? They won't be able to see that sign. So let's add some brails to the sign so that they too can confirm that they're accessing the store that they're expecting. Our customer's journey isn't complete. They only just entered the store, but let's stop here and take some of these considerations that we've learned about here over to the digital space. And just a heads up, just to look at a little technical as we move forward, we know that you aren't all developers and designers, but hopefully this can help you start a conversation with your web team. We also understand that a lot of you went through an audit recently as David mentioned. So hopefully some of these terms and concepts are familiar. So we can think about accessibility in the digital space similarly to how we think about it in the physical space. We'll need to address a similar set of questions or needs that our users might have that they're visiting our website. So for example, how will they navigate on our site? Can they get to where they want to go? Do they understand the content being presented? Overall, what do we need to do to allow people to participate? Let's start with that navigation question. Just like in the physical space with the car versus the metro, there's a lot of different considerations depending on the method of navigation. A lot of people navigate by clicking links using their mouse. But what if they're on their tablet or phone? They wouldn't use a mouse, they would tap with their finger on a link that they want to navigate to. And as I'm sure you've experienced when you visit a site on your phone that's a little on the older side and the links are teeny tiny, it's kind of frustrating to interact with, right? So now think about how much of an annoyance that would be for someone who may have an issue with their fine motor control, who may not be able to use a mouse precisely or hit a small target. So a common solution we use when designing a site is to make sure anything that's interactive is big enough for a finger to tap on so that a user doesn't miss or tap something that they didn't mean to. The rule of thumb, haha, is that the tapable area should be no smaller than 44 pixels by 44 pixels. So not only does this larger target help the usability for people who use touch devices, but it gives people with limited mobility a more accessible experience. Another option for someone with limited mobility is to use their keyboard for navigation. Using your keyboard, you can use arrow keys to scroll on a site like you would do with a scroll wheel on your mouse. However, like with a mouse, an interactive element needs to be specifically targeted in order to interact with it. With a mouse, in order to target something, you point to it and click to engage with it. But with a keyboard, there's a slightly different way to target elements, referred to as changing the current page's focus. To bring an element into focus with a keyboard, you can press the tab key to navigate between interactive elements, and an indicator will show you what element is currently in focus. In the slide showing the default focus indicator, a glowing blue outline. So once something is in focus, you can engage with it in different ways depending on what it is, but most of the time you need to use the enter key to simulate a click. So one of the common issues we see that limits the accessibility of keyboard navigation is when the default focus indicator is removed, because it's not super pretty, and then a style that matches the rest of the site is added in after. That's not inherently a bad thing, but sometimes by removing that global style, some elements may be missing a focus style, or sometimes a style that replaces the default isn't prominent enough for a user to notice and understand where they're currently focused. So if the global style is to be removed, one of the quick fix kind of tricks that we sometimes use is to make our focus state the same as our hover state, as long as it's prominent enough and makes sense in the context. So now what about users who don't see well? How do they interact with the site? With a degree to which people can see very widely, and there are considerations to think about when it comes to the design of our website to make sure that everyone can access the information we're presenting. So making text larger is a simple but effective way to engage with an audience who may have issues seeing fine details. They can also benefit from the color of the text having a higher contrast ratio to the background. So for example in this image here, the lime green text and the white background is hard to see, since those two colors don't differ in contrast enough, but that same lime green color on a black background is much clearer because they have a higher contrast ratio. In addition to simple theory and vision, we also need to consider users who may be colorblind. There are a lot of different kinds of colorblindness, and there are different considerations for each kind, but at the core, increasing the color contrast makes text easier to read for everyone. So taking a look at the last piece of text from this text may be alright, it's not great for someone who is not colorblind. If we test it on a site that can simulate colorblindness, applying what is referred to as a blue blind filter, we can see that secondly, our green text is now blue, and that last block is blue on blue now, which is much harder to see. It's good to test your site in grayscale as shown here. This is what someone who is completely colorblind would see, that last block got even tougher to read. And this is because the contrast ratio between the text color and the background color is not significant enough. There are also tools you can use to run through these scenarios and check color usage on your own site, and we'll tell you more about those later on in the presentation. In addition to text readability, people who are colorblind may also have trouble understanding elements that depend on color to communicate an idea. So for example, maybe be frustrated at attempting to understand a bar graph where the bars are brown, yellow, green, and red without any additional distinguishing features, especially when referencing the graph, one of the bars is referred to by color only. So in this slide, you can see what this bar graph looks like in full color on the left, versus what it looks like to someone who is redblind on the right. If the description of this graph refers to the brown bar, it would be impossible for someone who is redblind to know which bar that is. We can fix this by adding labels in each bar that we can then use to refer to instead of only referring to the color. So in this example, we could refer to a bar as item two. And then to further differentiate each bar, a pattern is also applied, which really helps each bar stand out against one another, something the only color was doing before. But what about users who are entirely blind? The web is 2D, which obviously means that we can add gray all likely might in the physical space. And often used assistive technology, such as a screen reader, helps them navigate their computer. There's many different types of software that are available to assist blind users, and so they vary in their capabilities at their core, a screen reader does what it sounds like. It grieves what's on the screen, allows to a user. Most operating systems have this technology baked in. You can visit the accessibility section of your settings on your phone or laptop to check it out. Taking a visual message to a user on a screen reader can be pretty challenging. What you'll see in a picture is worth a thousand words. But if a user can't see a picture, words are going to have to do. So keep in mind, the goal of accessibility means that we want to engage with our blind users equally. So all visual messaging should be communicated, not just the important thing, but silly puns and implied jokes too. So on an image and web code, or HTML, there's a concept of providing alternative text on what's referred to as an alt attribute. For the purposes of describing the image to someone who cannot otherwise see it. These alt attributes are not visible to users who can see the images, so it's something that you're providing under the hood through code to screen readers. So adding alt images, like the one shown here, can be relatively low-hanging fruit to improve the accessibility of your site. But things like charts, graphs, and infographics can be particularly challenging to provide an equal experience user complex nature. So leveraging something as structurally simple as an alt attribute to try and describe a complex image can be kind of limiting. But there's a rich library of different kinds of tags that websites are built from. There's specific tags for a lot of different things, like an OL tag is for an ordered list and have LI tags inside of them for each list item. Screen readers read a site most effectively at the core. The HTML that the site is built with needs to be semantic, meaning that the code itself should be descriptive of its purpose. So don't use a P tag, which is for paragraph, or a list, using OL tags. So getting back to those complex visualizations, providing a semantic description, in addition to that alt tag, can help to communicate more complex ideas and relationships accurately with the availability of headings, lists, and paragraph tags outside of that alt that should be used across the site, not just in cases of visualization or images. So in this slide, we're showing a popover box, which shows up on top of the content of your page. So in an effort to make the code for this popover accessible, you might try to find a semantic HTML tag, maybe call something like popover, but unfortunately, there are not codes explicitly for all purposes. So in that case, there's additional code attributes that can be added, including aria and roll attribute, which can be used to provide additional cues to the screen readers for how to read it. So for example, they can be leveraged to communicate labels for things that might have a visual indicator. In the example on the slide, the button in the top right looks like an X, but in the code, there's no actual text within the button for a screen reader to read. So it would just skip over it, or maybe say that there's an unlabeled button existing, but that doesn't really help your user know what it's for. So we've added an aria label equals close, which the screen reader will read instead as a button labeled close, which allows the user to understand what controls are available to them. Additionally, the HTML shown here is also describing our popover as roll equals dialogue to help communicate to the screen reader that this element is sitting on top of the page. Read attributes can do a lot of things, including describing with something currently hidden on the page that a screen reader doesn't read it, or to help understand the relationship between two elements, like saying something is labeled by another element. So there's a lot of different types of aria attributes and roll attributes that you can assign in your code, but the first step is HTML, making that semantics first and then supplementing it with these attributes as necessary. And actually, additional labeling can sometimes be detrimental to a screen reader user if things are identified well in the code already and then have additional aria attributes added on top of that. It might actually be read out several times to the user, adding kind of noise and clutter. So while aria attributes are useful, only use them if they're needed to improve the user's understanding of the site. So like we talked about previously when accommodating keyboard navigation, it's also important to screen readers that interactive elements are coded in a way that it can also identify that they are interactive. So for example, someone with a screen reader might tell it to read me all the links on a webpage, and we want to make sure that the code is written so that all of the links will, in fact, be read. On that note, the content on the site, the actual writing, can also be improved for screen reader understanding. So take for example that, read me all the link props. If every link on your page says, read more, how would a user know what they want to interact with without having the entire page read to them from top to bottom. So being descriptive in the interactive element is not just important in this scenario, but it also helps cited users confirm that they're headed where they want to go. Instead of using learn more at the call to action, using something like find out your flood risk, helps all users, not just those using a screen reader, to know what to expect, should they click that link. Please standard, advise with the information on your website and be organized and written in a way that's easy to follow. And that is not to say that you should cut your message short, because as I just mentioned, being descriptive is sometimes needed, but you should avoid jargon, be as concise as possible and organize your content in a way that is easy to skim. Some of the ways that you can make content more skimmable is by using headings, bullets and keeping paragraph short. This helps users to take a breath and to find the information they are most interested in quickly so it's less frustration. So as you can see in the two images on this slide, these are two versions of the same webpage and they both communicate the same information. The version on the right, however, uses shorter paragraphs, bullets, and visual space to make the content easier to follow. And in that same line of thinking, it also helps users to internalize your message as the language itself is simple, like you would use in your day-to-day conversation. So the rule of found is to write web content at a reading level consistent with 6 to 8th grade. To make sure that the broadest audience can understand what you're trying to communicate to them and you're not talking over them. Different audiences with varying disabilities. And the last group that we want to talk about today are the deaf users. So in general, the web is a pretty visual place which means that it's pretty accommodating to deaf users with the exception of audio cues and communication. So engaging a deaf user with your video content can be as simple as adding captions or maybe for your podcast, you can provide a transcript like we're doing with this presentation. Further engaged deaf users consider providing a visual indication of audio beyond just which words were spoken but how they were said. This screenshot was from a video where a kitten was meowing and the video had these three little lines animates to show the cadence of the meow which really helped to emphasize that kitten's cuteness. And you didn't even need to hear it loud. So maybe you don't have cute kittens meowing in your videos, but this concept can also be achieved by using a sign language interpreter who can use spatial expressions and body language to emphasize what is otherwise only communicated through someone's voice such as tone and cadence. Some of the most common problems that we regularly address as we design and develop websites and there are a lot to keep track of. So let's talk a bit now about how to find probable areas on your site and determine how it measures up. So in the world of web development, you'll commonly hear people talk about 508 compliance. This is an amendment that applies to all federal agencies and their electronic and communication electronic and information technology communication. So the amendment applies to information beyond just the traditional website, though. It also applies to things like emails, word documents, and TDS. Basically anything that's delivered to another personal electronically. And due to that broad spectrum of applications, the amendment is also pretty broad and open to interpretation. But at its core, federal agencies must give employees with disabilities and members of the public access to information that's comparable to the access available to others. So while 508 is a good guideline for best practices, no one other than the government is actually legally required to comply, at least from a federal standpoint. The web content accessibility guidelines, sometimes referred to as WTI, is a publication by the W3C we mentioned before. Within these guidelines, there are three levels of compliance. The least to stringent being level A, the most stringent being triple A. And these guidelines are specific to the web, and they overlap with 508, which is recently updated to indicate that on the web it should correlate with double A WCAG compliance. So for example, when presenting a video to the user, level A compliance would not update that there's a text-based alternative, for example, a transcript relative of this video content. For double A compliance, the accessibility improves a little bit, and it states that there should be synchronized captions available to the user. For triple A, the most accessible guideline, a sign language interpretation would be provided for that video. So with such a wide array of guidelines, it's important to test your site in a variety of different ways, both quantitatively and qualitatively. So there are many different tools that will crawl over a webpage and provide a report of how it measures up. So we'll show you a few of the most popular ones. Some of these tools were likely used to generate that audit on your site. The first one here is Google Lighthouse. It's a Chrome extension that will run many different audits on your site, including accessibility. And it'll provide information around any failing code and where that code exists in your page. DAX is another Chrome extension that specifically runs an accessibility audit and provides clear instructions for how to improve any violations. And then to test something like color contrast, there are a lot of different tools that you can leverage in similar ways. This slide in particular is showing the web aim contrast checker, where you can provide your foreground and background colors. And it will indicate what the current mathematical ratio of those two colors are and which of the WTAG compliance levels it passes or fails. So there are different guidelines between a normal tech size and a large tech size. So with large techs, the contrast doesn't have to measure it strongly or larger, which compensates for some of that visibility. So on this slide we're measuring the blue color as our foreground or text color against the white background. This contrast ratio is 8.59 to 1, which passes AA guidelines as well as AAA guidelines for both normal and large techs. So while the qualitative testing tools are great to get a start on improving the accessibility of the site, it's also important to test from a qualitative perspective. And getting qualitative feedback on our site is important because we can check the boxes and try to meet accessibility standards, but we need to make sure that we actually help users and don't put them in a frustrating or bad situation as you can see on the images. We want to make sure that users are able to achieve their goals effectively and without frustration. And this is where qualitative testing really comes into play. Getting qualitative feedback on a website is usability testing. And at its core, a usability test simply involves asking someone to pull up a website and complete a series of tasks that represent the major goals users need to be able to accomplish on that site. To accomplish these tasks you can note what questions they have where they get confused and anything that blocks them from achieving their goals. After using web tools like the ones we just talked through to audit your site running a usability test of your site with someone using a screen reader for example will give you a fuller picture of how accessible your site truly is. All of these more official audits and tasks there are other ways of getting quick feedback on a site. What you can do is just get a fresh set of eyes on it. You and your team have likely been looking at your own website forever and you know exactly what to look for and where to find it. But what about a new user? Will they understand what to look for? Will they even be able to see the primary call to action that to you may seem very obvious. And a quick way to test this is to phone a friend, ask someone who hasn't seen the site what they think. Similar to user testing, just at a smaller scale, you can gain valuable insight just by getting some fresh eyes on it. And asking someone like a parent or grandparent, like in this slide may also before you invite into many of the things we've talked about. Is the text large enough? Are the touch targets large enough? And is the content easy to follow? We are about how it's helpful to have organized sites and organized content. And a quick way to see if a page on a website is visually organized is just to take a few steps back from your computer screen. Literal setting up to the page still seems organized at this further view. What stands out on the page? Is that what should be standing out? The quiz that the page becomes blurry and asks the same question. Can you still see an organizational pattern on the page? Or does everything sort of blend together into one blob? If so, it might be a page that could use headers or lists to better organize the content and break up the test. Neither of these tests are going to catch every issue and should not be the only way that we assess sites. We've just found that it's helpful to be gathering feedback on our work all throughout a website design process in as many ways as possible to catch as many issues as we can. We just had a pause and take a breath. We've given you a lot of information and while we really hope that you're excited to go right out there and implement everything that we just are feeling overwhelmed or a bit nervous about this newly discovered pile of work that we just gave you. So we just want to say that it's important to take this one step at a time. When you go on a quick squint test and see if any swearing issues stand out to you or you can take back to any feedback you may have heard from actual users of your website. That feedback may indicate problem areas and it's a great place to start when looking for updates and improvements that you can make to your site. So just remember that each step forward, even if it's seemingly small, means that your site is accessible to more people. I think that making your site more accessible can have effect on people outside of the targeted audience who have disabilities and this is because accessibility, usability and inclusive design are related. Accessible practices can improve the usability of a website for everyone including people facing situational limitations and we'll show you some examples of this in a minute. Accesses can also support inclusion by creating better experiences for people in rural areas. Lots of people can benefit from them, not just those that are in a wheelchair. People with strollers or a shopping cart that keeps in mind if you break your leg and are temporarily in a wheelchair you would benefit too. Bringing that into the digital space when you're in a public place and you can't find your headphones but still want to enjoy video, having captions is really nice. Or when the internet is spotty or slow images and videos take a lot longer to load than text does. The content that's in your alt tag can appear in place of the image that fails to load, which allows users to continue to engage with your content when the images are not visible. And as we mentioned earlier to make your site accessible, content should be organized and that organized content likely ends up benefiting every website visitor you have. There's a wall of text about heading and that's difficult to skim, it's overwhelming and makes the process of using that website more difficult. And the same goes for the simple language concept. This supports inclusive design by meeting your website better for people with low literacy. And in general, people will be more likely to stay on a website that uses simple terms and labels to make the process of getting to the information they need easier and faster. And this is especially true for people who are in a time of crisis. If you are looking for a hospital address, for example, you probably don't have time to read through complex. True of some visitors to LSD websites as well will be going through a stressful situation. Those visitors are going to benefit from clear and simple language that helps then find your phone number, for example as quickly and easy as possible even in a moment of crisis. And those accessible best practices don't just help your human users but it helps the Google have specifically downgraded results that don't provide what they consider a good experience for their users. This includes a good mobile experience as well as good results on our accessibility test. So more semantic HTML leads to better automated understanding of content. It provides a clear site architecture and navigation path and allows the search engines to crawl through the site taking note of the content so that they can return results more effectively when someone searches for a term. Normally rich media like videos and images may not be able to be read by search engines due to their formats. So this means if someone had searched for legal aid programs for low income Americans, they may not find that senate briefing video on your site that they were looking for in their search results. So the artificial intelligence in search engines is improving. To understand what the subjects are in a photo or video, it's still not super reliable. But by providing captions and transcripts for videos and good alt tags in your images you can help improve their interpretation by a search engine as well as for your users. And good news that search the senate briefing video that I referenced earlier optimizing a site for search engines, addressing usability and designing for accessibility alone will not address all accessibility issues. A focus on specific accessibility needs is still important. So in closing, as you're working on your site, don't forget to ask a do to allow people with disabilities to engage equally with an experience. We can go ahead and open the floor to any questions. So we've covered a lot of content here. What are your thoughts on some of the automated checkers that are out there that like wave that give feedback on a site? Is that a useful first step for people or how accurate are those tools that type of stuff? Yeah, there are a ton of tools to test all this stuff. Wave is another good example. I think that they in particular have a pretty good interface for the color contrast checker. But not all tools catch all things. So if you want to be really broad in your accessibility of your site, you should run it through multiple testers as well as the qualitative testing as we mentioned. It's absolutely a great first step though. Running it through just a simple test and seeing what pops up. It'll catch the most glaring issues right off the bat. Excellent. So with regards to videos and creating transcripts, what kind of tips do you have for doing that? Because I know a lot of the legal aid organizations are starting to use YouTube as a way to distribute self-help content. YouTube has some tools available to caption your videos. They also do have some automated captioning in their interface. That being said, I don't know if you've ever tried it out, but sometimes you get some really funny results because it is automated. The highest quality captioning, the highest quality transcript would be somebody manually going through and making sure that it's correct. But there's kind of some quick shortcuts you can take to get at least the first draft done. For example, in this presentation, we had written out some notes and we're basically going to go back once we get this recording and fill out our transcript just kind of scrubbing through, filling in our notes as we talk through them. It's unfortunately it is a bit of overhead, but it is a great way to make it accessible for deaf users. And then I appreciate it when I'm on the metro and can't listen to my headphones great for people who don't have their speakers turned on. Excellent. Thank you. What is a good tip for creating clear alt text for links? Are you referring to images, alt text on images, or for the content in a call to action link or both? Either one of those. I believe the question was targeted at images, but both those use cases are useful. It's really you want to make sure that you capture why you're using that image, what somebody who is cited would, how they would benefit from that image. So for example you might say that image that I showed was of a woman holding a young child and it helps kind of reinforce the relationship that was being described in the content itself of the article. So you might say something like Mrs. Johnson was snuggling with Elizabeth, or something like that to describe the image in a way that you can understand how it helps reinforce the content and how it relates to that content as well. You might use the same image for another article and that alt text might change because now the context is different and you use that image to enforce a different point. So it's really if you close your eyes and somebody told you I saw this image if it's guy in a baseball cap that doesn't tell me a whole lot about why you used it and how it relates. So it's really it's not important to be kind of contextual and descriptive. I don't think that you can be too descriptive for one of these images. And then the first link was the time are sort of find more, read more, learn more, see more and often times it's as simple as adding to that question is learn more about read more about below to making sure that that link is descriptive. So do you have any examples you can share about a particular organization who's received feedback on how to improve their website and then it had an impact on individuals or groups. The kind of feedback that we'll see as more ad hoc it's not usually super formal but we'll notice somebody might say how did you find that? I was never able to find that on the site and somebody says well okay so maybe it's a navigational path that we're giving to our users or the buttons that we're leading to this page aren't descriptive enough so they don't know where to go to find some content. Something, you know it's usually if you're looking at a website and somebody says wait how did you do that? That's usually an indicator that they didn't understand how to use it or they couldn't access it themselves. That kind of feedback usually happens in a more ad hoc fashion but if you've got something a lot of sites have a little like do you have feedback kind of prompts or something like that that's also a way to collect that kind of stuff. If you've got analytics on your site and your primary call to action is not being clicked on that's an indicator that maybe something needs to be addressed there. Nobody's interacting with this part of the site that doesn't mean that that part of the site is wrong it might be triggered a little bit so that people can interpret it better or get to it better. It's interesting because with accessibility often the user will just give up and leave the site because they're not going to assume that the feedback form is accessible. Yeah, that's true. It's an unfortunate, you know accessibility literally is about access but something isn't able to be accessed they're not going to know that it exists to give feedback about it so that's where that qualitative testing really comes into play a lot I think putting it in front of somebody who's actually using a screen reader or turning on your voice over on your computer and listening to what it sounds like to somebody who might be using a screen reader you can identify some problem areas pretty quick. It is definitely a different experience I will say that. So we've got two questions here relating to ARIA first what does it stand for and then someone would like to hear more about ARIA attributes and mobile devices. Yeah, so ARIA is one of those ones that everybody talks about ARIA and nobody knows what it stands for. I think it's something along the lines of accessible, rich internet applications. I think is what it is. I looked it up right before this one and it emptied right out of my brain. This A-R-I-A and there is a ton of different attributes. I think the most common ones that I've seen are labeled by. So something that, you know, maybe a tool tip pops up on your site that button and that tool tip, the button that you use to open that tool tip and the tool tip itself in code can be miles apart on the page. So you can say hey this tool tip is labeled by that button. So a screen reader kind of knows to draw that relationship so that if somebody clicks on that button they know which tool tip is related and that that should now be read. I don't know, there's a ton of them. The hidden one I mentioned sometimes it's not super clear in the code with visible on the page versus what's hidden. So you can say like hey screen reader don't worry about this, it's hidden right now. Somebody who's cited wouldn't see it either. I think that there's indicators to if it's an application or a tool on your page to indicate that it's kind of a widget on your page and it's kind of separate from everything else. It might be more interactive so that it knows to kind of pay attention more to that and things that are changing within that. Maybe you've got some script running on your site that's changing out content or something like that and there can be an ARIA label to point that out to the screen reader because they notice to pay attention to that. As far as mobile goes there's not a super strong relationship between ARIA labels and mobile specifically. ARIA labels really are mostly for screen reader accessibility and then any other automated crawling of the site along the accessibility side of things. Oftentimes your mobile site is the most simple version of your site so when you're looking at how to make your site accessible it's often easy to take a peek at what it looks like in mobile and if there's problem areas in mobile it's likely a complicated situation that you might want to pay attention to particularly around accessibility. Like we mentioned that the task targets and stuff like that that's something that if it's accessible in mobile it's accessible in desktop as well. But there's not a super strong relationship between ARIA and mobile specifically. There was a comment here with regards to the fourth to sixth grade reading levels. Just the importance of actual client testing there because even our colleagues often have kind of a background around law and don't realize what terms we're using. There's also a community tool called Read Clearly or Write Clearly that will audit your website and show you common alternatives to some of that language that were taught in law school that actually doesn't help clients. Well I would just add one of the concerns that I often hear about plain language in the legal context is it's so hard to get to a fourth grade level or a sixth grade level because you're throwing in these specific legal terms which are clearly not a fourth to sixth grade level. I think one of the latest versions of Write Clearly actually allows you to filter out legal terms so you can still see if the rest of your language is presented in plain English without that unlawful detainer having to be in there because that's the term you're going to have to tell the judge in skewing the results of your analysis of the readability of the material. Very good point. And to that point if you guys have a lot of legal terms in your content while the legal term itself may be complicated you can kind of help the framing of that word saying you might hear something like this phrase or look out for the form that's labeled this this is what it's for or you can kind of help the frame of that so that the actual legal term itself doesn't scare people off or do something like that. So here's a question that's a bit more on the technical side how do the ARIA attributes work with the Drupal CMS? It depends on your theme and which plugins that you're using something like Bootstrap which is kind of a foundational piece for a lot of different websites will come with ARIA labels already but again the ARIA labels are only kind of the last stretch really the core of it you want to make sure that your HTML is solid and that your content is solid. The ARIA labels are kind of just to, they're band-aids more or less to fix problem areas so don't think that you need to add ARIA labels for every single little thing if your HTML is solid which a lot of Drupal CMS are good to go it's mostly to address problem areas so if you want to see if you've got problem areas go after your computer and turn on that read me my website setting on your computer and you can kind of you can pick up on things pretty quickly. So how do we handle dynamic UI content like it's spanning or collapsible sections or floating buttons although certain sections are visible because the content is code some screen readers may or may not see it. There are a ton of different screen readers out there and they kind of vary in their capability so some of the older ones may not know how to interpret JavaScript which is what kind of handles that interaction on your site so if you have all of the content on your page you can structure it in a way that a screen reader without JavaScript could understand it but if something is being bloated from another site or you've got pages of content something like that is a little bit tricky. There are some ARIA labels that you can add to kind of indicate hey this section is going to update or you can throw kind of like an event saying like hey screen reader attention change but again at the core if you've got something that's expanding and collapsing likelihood is there's a header and there's a section of content inside of it so using a header tag and using a section tag can kind of help the user when they're being read the site to understand kind of what where things are labeling your buttons expand and collapse not just some little cute arrow or something like that can also help them to interact with the site but it goes back to solid markup or sorry solid HTML it does get tricky and it really is hard to target specific screen readers as web developers we always run into when I'm on Internet Explorer 8 it's like oh that's not going to work very well people are getting better about updating their browsers screen readers can be kind of expensive because it's a piece of software that you use so people don't update them very regularly so you need to kind of know what you're going for which ones you're going to target and prioritize but again at the core of it good HTML should be accessible kind of out of the box ready to go one of the WCAG level A requirements talks about automatically changing the site language based on the browser's language is this common and just generally on the level A how common is the adoption of those and how would somebody go about prioritizing them I'm not super familiar with that requirement in particular which makes me think that it's not super common I would imagine that that's kind of making sure that you're using language that's very similar to your user in their in their current environment so maybe it's referring to something like if somebody is familiar with legal jargon maybe you can use legal jargon more comfortably versus if you're dealing with somebody who in their environment is not dealing with legal terms very frequently you might need to change the complexity of your language I'm not entirely I'm not entirely familiar with changing it per device that's a little bit odd in my opinion but it might be something like a Mac uses expand and collapse versus Windows uses open and close something like that might be something to look at using as many familiar cues as possible helps your users to understand so and something like that you can probably look at your analytics for your website and something like Google analytics or something like that to see what kind of browsers people are using that would also indicate if they're using screen readers what browsers what how big their window is if they're on a mobile device or desktop you can kind of get some clues there to see kind of what your users look like from a from a browser perspective you know when they come there are there any other questions? yeah there's a a few other comments on the color contrast stuff wanting to I'm trying to parse this I'd like to see examples of color contrast that show the best examples that's positive instead of negative text the we know that dark on pale background is more readable than reverse I think I'm getting that through correctly I don't know we've got a although I think I've made it through substantively all of the questions that were here and I've taken some of the comments also and redistribute those out to the complete group so yes I think we've got the comments we just did that because our slides were white so we wanted to show a light color on top of that white background I think that the problem likely comes into play a lot more like if you've got a primary brand color for example that's like blue do you use gray text on it do you use black text on it do you use white text on it it all depends on kind of what that shade is and usually brands colors are not super bright they're super dark but kind of somewhere in the middle which makes it tricky to figure out which way do you use so I think that that's usually the problem that we run into sometimes there's a very light blue text that somebody has for their brand color and we think oh let's use that for links but when it's really small it's very difficult to read so I think that the swim test can really help kind of identify some of those issues early on but there are so many tests out there for color contrast that you can run through and sometimes it's just or putting it on a lighter background or something like that can really help it out excellent I think that covers all the substantive questions I've got a link that I'm dropping in here which is to the YouTube channel we should have the video up along with a transcript and slides here within about a week or so thank you so much for coming out and putting this on any last words or last tips before we head out information up on here if anyone has any questions that kind of come up later that you think of later or didn't get a chance to ask please feel free to reach out to either of us or to Ryan both broadly and you know we're happy to answer any questions that come up excellent thank you all greatly appreciate it