 So yeah, my name is Erin Ullman, and this talk is about making accessibility official. It's about integrating accessibility into the project process and organizational processes. We're not really going to discuss a whole lot about what accessibility is or what constitutes an accessible experience. Now before I get started, let's get a sense of who is in the audience. So how many of you are freelancers? Okay. How about small agencies? People who work on a team, okay. How about larger agencies with robust codified processes? All right, we've got a few. Anyone just, I should say just, anyone who just blogs or has their own little personal website and they're interested about accessibility in general? All right. So I mostly develop this talk with freelancers and smaller agencies in mind, but we certainly talk about the larger organizational context of accessibility. Can you hear me okay? Or do I need, okay. I'll move over. Okay. That's better. It's just a just computer placement. There we go. Okay. Okay. For the purpose of the 45 minutes that we have together, let's agree that we are going to make our stuff accessible because it's the right thing to do. We make our websites accessible because not because of laws or fear of lawsuits, but because everybody should be able to access, understand and use the websites we create. One of the things I love most about the WordPress communities that I lurk in is that we seem to in general really embrace this idea of inclusive design. And am I preaching to the choir here? Just a little bit, maybe. Yes. All right. A couple of thumbs up. Thank you. So what are we going to talk about today? So first we're going to have a disclaimer. I'll talk a little bit about my history with accessibility. What inspired me to prepare this talk? And then we'll talk about where accessibility can fit into the process, where it can be client-facing, where it can be internal, and then we'll talk about some resources. After that, I'd like to take questions as well as I would love to hear any of your experiences with integrating accessibility into your processes. Disclaimer. I'm not a lawyer. This is not legal advice. There may be things in this talk where you may want to consult with your lawyer, but not legal advice. Okay. So what I am is I'm a user experience practitioner. That means I guide people through the user-centered design process. I research. I plan. I design. I love WordPress, and I code when I need to. I first became knowledgeable about accessibility because my former boss told me to. And I'm actually really glad he assigned me the role of team accessibility expert because I find working in the accessibility space to be incredibly fulfilling. I am particularly interested in the needs of people who are neurodiverse or people who have cognitive disabilities. Now that job that made me figure out what accessibility is, that's no more. But I had a lot of opportunities to evangelize for accessibility and to maintain our internal accessibility resources, to conduct accessibility audits, and to ensure our processes met the minimum accessibility guidelines, which was the previous section 508. So the inspiration for this talk. I don't actually have it up on here because I couldn't find it again. So we're going to categorize this under web myth, but a couple months ago I was looking through the accessibility hashtag on Twitter, and I ended up on an accessibility listserv where a freelancer was upset because his client was suing him because somebody sued his client for due to an inaccessible web experience. And that was just kind of shocking. And it sort of highlighted how there's a need to incorporate accessibility into our processes, especially when we're talking with clients about the basic needs of our websites. So other inspirations, again, it's the right thing to do. I'm going to say that a lot in this talk, accessibility is just the right thing to do. So it's required for websites that are for governments in many countries, as well as like libraries, schools, et cetera. Now also the lawsuits keep coming. Hulu, I believe, just settled a lawsuit, and they will be beefing up their subtitles. And also an explicit paper trail is a really good thing to have. Now it's sort of hard to get good statistics on disabilities. Most of these statistics rely on self-identification, and many people don't consider themselves to have a disability. They might say, well, my vision is just a little bit weaker than it used to be. I know mine certainly is. I need my reading glasses. But I don't consider myself to be disabled. But I definitely benefit from, you know, websites with really large text size. So designing and developing for accessibility, what that means to me, and for the purposes of this discussion, is creating our sites to be usable by the most people to the greatest extent possible. And in the U.S., the base level of accessibility is generally considered to be defined by section 508, which in turn refers to WCAG 2.0 AA. All right. I think the number one characteristic of organizations, whether the organization has one person or 10,000, who have successfully integrated accessibility considerations into their process is that accessibility is a priority from the highest levels of leadership. Ensuring inclusive design is everybody's responsibility. It's not some annoying quality defect. It's in an organizational value. And I really love seeing when companies appoint a chief accessibility officer that really demonstrates that they have a commitment to accessibility within their organization. Now where accessibility is very poorly driven from, the bottom. If you ever want to feel like a significant portion of your work is spent nagging engineers and developers and QA about accessibility, I actually don't know anyone who wants to do this. But without strong organizational support and ingrained values, accessibility is this negative thing. It's something to deal with. It's a new sense. But we've already agreed accessibility is the right thing to do. So how can we nimble small teams and individuals integrate accessibility to be part of our organizational values? Designing and engineering a quality user experience for people with disabilities requires an organizational commitment, shared responsibility and accounting for usability. So there are ways to achieve this. I'm going to talk about things we can do client-facing first. As with a lot of our processes, it doesn't help to make the nitty-gritty very visible to the public. But for example, personally, I very rarely talk about custom post types or the nuances of categories versus tags or specific plugins with people. But so in that similar vein, we don't really need to go into deep accessibility discussions with clients unless, of course, the client is heavily invested in accessibility. For example, if you have an organization that tries to meet the needs of dyslexic individuals. So I think some client-facing places where we can make accessibility visible is to make it a line item in the proposal, associate a cost with it. Now accessibility from the beginning is significantly less expensive than retroactive accessibility. So honestly, this cost doesn't have to be terribly significant. And then in terms of deliverables, we can deliver an accessibility process to our client just high level. Here's what we do to help ensure that your site is accessible. Have an accessibility policy on your website. This is showing up more and more on websites. Be able to provide audit or verification results that a site meets the minimum accessibility standards of WCAG 2. And also, you know, there could be a document that explains how a website includes different people, especially if there is a particular audience that would be adversely affected by a lack of accessible consideration. So let's talk about what a website accessibility policy might look like. So this is yet another policy that we can start including in our footers. This is the city of Eugene, their website, and they have an accessibility policy. I think this is a good place to start, especially with your own sites. You can develop an accessibility policy that defines what level of experience people can expect from your website. And that should actually be true. So if you say, well, this website is compatible with the JAWS screen reader, it should actually be compatible with the JAWS screen reader. Here's another example of GOV.UK's accessibility policy. And GOV.UK has fabulous design resources and accessibility resources. But they have a very nice policy which asserts that the site is accessible and as usable as possible. And then further down on this policy, they start calling out which technology the site is specifically compatible with, as well as additional resources for people who use assistive technology. Now accessibility does not typically require significantly more resources to implement from the beginning, especially for just working with HTML and CSS. However, the constant effort to add accessibility after the fact can be extremely prohibitive like can't do the project prohibitive. And because of that, it's so important to start thinking about accessibility from the first moments. So some internal assets that we might have refactored accessibility guidelines, possibly an accessibility checklist. There are so many accessibility checklists out there. And developing one for your own organization will help you have this repeatable accessibility checklist process that works for you. Also an audit checklist, possibly how-to's, libraries, job aids, style guides. We can integrate accessibility at all parts of the life cycle. Now, so there's a really great article called accessibility in practice, a process-driven approach to accessibility by Sarah Horton and David Sloan. And they suggest creating an accessibility infrastructure. Having an organizational policy that applies to accessibility. Having a content strategy that considers accessibility. Having code repositories with accessible chunks of code, style guides that reflect accessible design consideration. And also content and development tools. Now you might think an organizational policy doesn't really apply to an agency of one, but it can help define your guiding principles. If you have a mission statement on your website, just a little bit about accessibility would really fit right in there. I think a-so just to show of hands, who's looked at the WCAG2 guidelines? Some-a fifth of you, baby? What about the old section 508 guidelines? Like five people. This might be a bit of a spoiler, but it's not really friendly. It's not the most super friendly set of standards or guidelines. And it's definitely cognitive overload. So I think one of the most beneficial things that you can do for yourself or for your team is to refactor these accessibility guidelines to be human-friendly. Whatever that means for your organization. That might mean creating a document that explains the accessibility responsibilities of the developer role, which probably does not include color choice. Developers are probably not defining-I mean, they might be. You might be. The role of developer is not defining the colors, but a separate document that defines the accessibility responsibility responsibilities of a designer role might include color choice, among other things. This also might mean creating some sort of documentation that you can adjust the amount of discussion so you can have more or less explanation when you need it. And then once you have this human, readable, friendly accessibility guidelines, you can refer back to WCAG2 and get the specific details when you need them. So you can identify roles to specific accessibility guidelines, identify which guidelines are relevant to which roles that are present in your team or organization. And even if your organization is an organization of one, that means that you're just filling all these roles. They exist. It's just not, you know, separate people. So some roles that you may want to have specific accessibility guidelines or strategies for would be a project manager, a developer, a designer, a content producer, maybe an engineer, a tester. There's the WAI-engaged team. They worked on this accessibility responsibility breakdown back in 2012. And it's kind of hard to parse, but it's a really, if you're looking for inspiration on how to assign the different accessibility guidelines to the different roles, that's actually a really great resource to start out. It shows on how it has quite a couple of matrices and breaks the accessibility guidelines down into their various components. Also planning for accessibility. This is something that you would do at the beginning of a project, especially. Think about are there groups of people that would be particularly adversely affected by a lack of inclusive design? For example, if your website hosts a podcast or a course or it's a site for charity dedicated to the cause of dyslexia, those have some very specific accessibility considerations. That said, you know, HTML is fairly accessible, as it is. There's some gotchas, especially with CSS, but in general, if you're using HTML in appropriate semantic ways and headings have their correct hierarchy and you've separated forms, you're probably a lot of the way there. The big accessibility issues tend to come up when we're using technologies that might change the DOM or rely heavily on scripting. Like, for example, making an interactive scheduling calendar from an HTML table. That has some accessibility issues, for sure. If you have a project where that's your solution, you would really want to dedicate extra resources to ensuring that this particular element was accessible. When not using HTML, extra care should be taken to ensure that you understand the impact of accessibility and that it can be mitigated. You want to research the accessibility quirks of the technology you'll be using. Plug in UILibraries. I find calendars never work. Is that anyone else's experience? We've got some nods in there. If you're not using HTML technology to generate the websites, for example, Adobe Flex, this is a place where Google is helpful. You can usually find out if there's an accessibility gotcha for specific technology just by Google search. You'll probably end up on Stack Exchange, and that's great. So what else can we do? For assistive technology, we want to do it. For sure, test early, test often. Does the code work? Does it work with assistive technology? Can you use keyboard-only navigation, a screen reader? And, I mean, for sure, the success criteria for a website should be achievable using assistive technologies. When conducting and testing the website, you want to ensure that the audiences with disabilities can successfully use the website. So, for example, if you created an e-commerce website, a person who cannot use a mouse should be able to successfully choose a product and go through the checkout process. Or a restaurant website. You would definitely want to ensure that a person using a screen reader on a mobile device can easily understand the hours, the location, and the phone number. Speaking of restaurant websites, they are notorious for providing PDF menus. PDFs may need a little extra help to be accessible. Personally, I think the solution is to make an HTML equivalent. But sometimes it's just not possible. So I think Linda has a course on PDF accessibility. There's also plenty of resources on the web. And I've not looked for it, but I imagine Adobe also has a resource on how to make PDFs accessible. So here are some things that we can do to help integrate accessibility into our process. We want to read the accessibility requirements for our country and understand them. We also want to incorporate accessibility into our systems and processes. And that includes transcripts and subtitles. If you will need extra things on the website, these would be really great things to put in a proposal line item. So if you know that the website is going to require transcripts or subtitles, make that part of your proposal. Add that into the cost. Learn to use a screen reader. There are three major screen readers right now, I'd say. There's Jaws. There's one I can never remember the acronym of. NVDA, is that it? And for Mac, we have VoiceOver. Unless you need to be an expert user and a screen reader, you're probably never will be an expert user of a screen reader. And that's OK. Just the ability to go through a web page and evaluate whether the content is screen reader friendly. Just a couple of weeks ago, I was doing an audit on a website. And for some reason, it was for the most part screen reader friendly. But somehow, ARIA, the use of ARIA roles had been added when it wasn't necessary. And it made the screen reader experience very weird for certain parts of the website. And that's something you might not see unless you're actually using a screen reader. And also put together a standard set of tools and plugins that you know to be accessible. And plugins specifically, it's a great idea to have these plugins that you go back to that you know to be accessible. I think a danger point in having an inaccessible product is using plugins. And you don't know what the result of the plugin is going to be. And then finally, develop an accessibility policy. You can start by creating one for yourself. And also use one for your clients. It will definitely, for certain audiences, it will make the website more authoritative, trusting, trusted. And yeah. So some resources, the Web Accessibility Initiative. And also, there's a great list of web accessibility-related litigation and settlements. I think it's current to last year. I know there's definitely additional court cases that have come up since then. But this is great. This is especially great when people ask, why does my site need to be accessible? I'm just a little site. No one's going to sue me. That's not really accurate necessarily. There's also a couple of really great books, A Web for Everyone by Sarah Horton and Whitney Quisenberry. Also, that's a web for everyone. And Accessibility for Everyone. And then this fabulous article, Accessibility and Practice by Sarah Horton and David Sloan, a process-driven approach for accessibility and the Accessibility Project. So that's my formal presentation. And now I was hoping we could have a discussion on how you create an accessible organization and also some questions. Now, before we get started, we have microphones. And so I can repeat what you say. But it would be even better if we just use the microphones. So I'll identify a couple people. And then if you could wait for the microphone, that would be great. Questions? Discussion? Yes? As far as formal training goes with Accessibility, other than WebAIM down at Utah State, is there any other recommended formal training for employees or team members that you guys would recommend? That's a good question. So I know that there is some training on Linda. I was pretty much self-taught. And we developed formal training for our organization based on what we knew. There are consultancies that will train on Accessibility. And so for those of you who are local and live in Washington County, I know for sure that the Washington County Library will offer a free subscription, AccessFree to Linda. And there are definitely some courses on there. There's also quite a few WordCamp talks. So if you go to wordcamp.tv, there's some great talks. In terms of formal, I think you would have to work with a consultancy to get something really formalized. Does anyone know of any other formal accessibility training? Yes. There's a training called WebAIM? Yeah. Yeah, WebAIM. Yes. So I do work for a school district. So we're really always on our mind about this. But we've used the WebAIM Accessibility Evaluation tool. Do you feel like that is accurate? I think it's accurate for what it reports. Sure. One of the things you will hear over and over about accessibility is that it's possible for something to be technically accessible and be not at all usable for people who require assistive technology. And so there are actually many tools for analyzing websites and finding accessibility problems. But even when you go through all of those, what you should, you absolutely should, you should find a tool, learn it, and use it. But even after you use those, you still need to do some final steps of just going through it with a keyboard, going through it with a screen reader, and making sure that the experience is usable. Does that answer your question? OK. Yeah. Do you know if Selenium or anybody has the automated testing for accessibility? So this is one of my weaker spots, is automated accessibility testing. I'm not really, I develop as much as I need to, which is not that much. From what I understand about automated accessibility testing is it's actually incredibly difficult. There are some accessibility tests that you can automate, but not all of them. Are there any developers here who can speak to automated accessibility testing? I saw a couple hands go up. Any developers? I've got one gentleman. I'm not a developer, but I have done a lot of accessibility testing with automation. And so WebAIM, sorry, that better. So WebAIM has a tool called Wave that can be used as a Google Chrome extension. And it gives you a lot of really good information but what they say right off the bat is any type of automated testing is just that it's automated. So having your own agency or if you design websites for clients and you point them towards that, it can be very demotivating because they will see a lot of potential false positives. Also, when you get into the world of automated testing, a lot of people feel like, kind of like we saw with Yoast in the previous presentation, you see a lot of red dots and you feel like you have to change them to green or the client may feel that they have to be changed to green or your boss may feel that they have to be changed to green so it passes. But if you have an image of something and then you have a caption of it right under it so you don't have a description of that image like an alt tag because it's accurately describing it in the content, you're probably fine. But that's going to be a red flag in an automated tool. So automated tools are automated and really the best thing to look at it is from the human side of it and know that those tools will have lots of false positives and setting the expectation for it. They're really good to bring that to mind so that you see, oh, I didn't think of this but the things that do come to mind when it brings them up take them with a grain of salt. Yeah, so follow up on that. I would say don't show your clients the results of those tools. One, they will freak out. One of the benefits you bring to the client is that you can interpret this and appropriately report on this and prioritize it. But yeah, don't show them that. And if they show it to you then you should be able to help talk them down. Yeah, does that really answer your question? I wish I could say yes, you can automate accessibility testing but it's just not true. There are libraries that go with certain toolkits but they're still not going to get you all the way. Next question, discussion, yes. Hi. So this might be a bit of a noob type question. I'm not super familiar with this area but when accessibility comes up it's often focused on people that aren't using a mouse so make sure to test. You can use the keyboard and screen reader but for example, you've also mentioned people that have dyslexia or other cognitive disabilities. Could you maybe highlight a few of those other things that maybe aren't covered by check that you can use a keyboard type of thing? Right, so that's a great question. In my mind, I break accessibility up into two areas and I promise I'm going to come back to this question. I break accessibility up into two areas. There's the technical aspect of accessibility which has to do with, does the website work with assistive technology? And then there's the design aspect of accessibility which is, is the design accessible to people? And that's where we see accessibility, excuse me, accessibility considerations for people who have cognitive disabilities or who are neurodiverse. So this is just a fascinating to me area of accessibility. So people with dyslexia, I am not an expert on this. So if you are signing for people with dyslexia, please find an expert. But it is my understanding that they really benefit from websites that have more images. I once was fortunate enough to have someone dyslexia who was taking part in a user study for something totally different, had nothing to do with accessibility. But his discussion on how he interpreted and used the web was extremely valuable. He told me that he sees an image and then he parses that image. And so that's understanding that audience is extremely helpful. If you are designing a site and you know that a lot of your audience will be dyslexic, I would definitely add that into your proposal to conduct research with people in that audience. That's gonna give you the best insight. Some other accessibility, I am so sorry, considerations for people with cognitive disabilities or who are neurodiverse. I think one under-recognized group is people who have anxiety disorders. And so when we talk about how to content marketing strategies and inspire a sense of urgency, can you imagine how that sense of urgency feels to someone who has an anxiety disorder? I don't have an anxiety disorder and I hate that, I don't like it. It doesn't make me feel good. And so there's a population of people where that could be an even bigger problem. And so that's an accessibility consideration. People who have ADHD, they would be adversely affected by a website that has lots of fleshing things or animations. One thing you can do for that group is to have the option to just turn off all animations on your website. I personally don't believe in having a lot of animation on your website or any, but if you do, it's nice to be able to turn it off, just like it's nice to be able to mute all the sounds on a website or not autoplay videos. Autoplaying videos would probably have adverse accessibility consequences for that audience of people who have ADHD. And so that's what I think is really important for that audience of people who have ADHD. Content, content is key for this audience. And this audience, I'll also add in people who are non-native language speakers and older adults. They sort of also benefit from these strategies of very clear, actionable language. So instead of the click here links, you want read the proposal or some very actionable directives. Yeah, does that start to answer your question? This is a huge area and it's very audience specific. I think that in general, it's best to always consider people who might suffer from, suffer from, they don't suffer, who might have ADHD or just need a clear, non-distracting interface. Other questions? Okay, gentlemen in the back. Yeah, do you have any concrete examples of either common design problems or development problems that you see all the time that contribute to something being non-accessible? Well, I eat like hamburger menu sucks, and here's why, like that sort of concrete. What was the last thing you said? Like if you think the hamburger menu. Oh, hamburger menus. Yeah, so the hamburger menu, I would always, always add like the word menu after it. You'd see this happens. The minority of hamburger users do this, but it really should be the majority. Hamburger menu, the word menu. The big design example is with color blindness. There are several different types of color blindness and you really can't anticipate what color people are gonna be able to perceive. So ensuring that color is not the only thing that imparts meaning. So if your links are just a color, I don't think that's good enough. Some people have tried to make the argument that if you have a blue link without an underline, that's okay because blue communicates meaning. An example from my own childhood, this is because I was young. My dad is red-green colorblind and so back in the day we were using the Nero CD burner and I was telling him how to use it and to burn a CD you just push the red button and he could not figure out how to burn a CD and I was getting a little frustrated and then later I felt really bad because I realized he probably couldn't see the button. So yeah, use more than color. Can anyone else think of some other design modern design issues with accessibility? Yeah. Slide shows? Slide shows, yeah, slide shows are good and they're especially, so slide shows have some, in addition to accessibility concerns, they also have some usability concerns but that would sort of fall under from a design point of view the issue with people who have different cognitive needs. It would be distracting. It might, I would say slide shows are more prone to being technically non-accessible. What else? Overuse of caps. I just heard that there's a tool that can remove caps from a website. I just read about that yesterday. That's great. So yeah, all caps is difficult to read. I think there's some newer typography guidelines for accessibility that exist in WCAG level AAA. It looks kind of weird, I'll be honest but there's also like little tools that you can use to convert your text to be this even more accessible version of typography. What else? Interactive maps are hard. I don't even know what to say about that. Maps are just hard. Yeah. Graphs and charts. Graphs and charts can be made more accessible than sort of by default. SVG has a lot of opportunity to add alternative text and descriptions with charts, at least with data tables, ensuring that you're using all of the table elements semantically as they're supposed to be used and what I'm specifically meaning is use the table heading element that can drastically improve the accessibility of a table. Infographics. Yeah. If it's an image, that's a big description. That would be another place where SVG could potentially solve that issue. Other examples? Do we have another question? Yes. I had a question about process. You mentioned how important it is to build accessibility in early on but a lot of modern software development is kind of iterative and agglomerative and just growing thing. Do you in your development process have like a reset point at which you take like prototype code or things like that and kind of back? Or I'm just wondering how to deal with those sometimes conflicting kind of development methodologies here but the need to roll back to build accessibility in at the bottom. Does that make sense? Yeah, that's really hard. That's just, it can be really hard. So there was a project, it was an auditing project for me and we were basically determining if it was even possible to make something accessible and the answer was yes, with millions of dollars it would be possible to make it accessible. I'm not exaggerating here. Millions is probably an understatement but that's a good question. Like can you have a point in your process where you say, all right, we just need to take stock of accessibility and I would say that if you're using like an agile methodology I would almost include that sort of in the testing phase of each iteration. Just make it part of your testing, like when you test your little units, make it part of that process. Is it accessible? Yes or no? And if you build enough small accessibility into your products in the end, theoretically, you will have at least a technically accessible product. This is definitely something that is better to catch earlier rather than later because it's just, it's so prohibitively difficult. To go back. Other questions? Discussion? Okay. I just wanted to mention another training option we've used which is nobility.org. Oh, nobility.org, yes. You have AccessU which has a seminar that they do once a year. Yes, absolutely. Nobility.org is great. That is a fantastic website and fantastic resource. Yes. I just wanted to know if there was any SEO benefits to using accessibility? I would say yes, there are. So in general, if the more accessible a website is, the more usable it is. Now, one of the other audience members said that, you know, people might push back against accessibility because it might stymie their creative creationism, creation. But that's not always a bad thing, I think. So specifically for SEO, you're going to have better content. You should have better content because it will be more direct. You're using your alt tags. You should be using alt tags. The heading hierarchy needs to be correct. You shouldn't be skipping headings or using headings to hook CSS definitions into. And so what you just get is you get a better formed HTML document and that will feed into SEO. Does that answer your question? Great. And so actually along the same lines, I know Google is getting very into structured data as part of the SEO, making your at least site readable to bots. Does structured data methodology also adapt to accessibility? You know, I don't know the answers to that, but I really want to know the answer to that now. If you could do both at the same time. Yeah, so to me what that question is, it would certainly make search results more accessible because the information is there. But what I wonder is if assistive technology picks up on the schema. And I don't know the answer to that. There's probably an answer to that, though. Yeah. That's fine, for one more question. No questions. Does anyone want to share with how they have integrated accessible and inclusive design into their process? So I've worked for a large public school system and I'm also working for a software company. Well, I mean, now I am. And what we have to do because people are using our software, we have to make sure that we're giving people the ability to add alt tags and to their images. We are also adding in points where they can only use certain headers. We're educating the people that are using our software. And then prior to that, I had to create policy, post it on the website, try to change the culture of the organization to use content rather than PDFs to write concisely and clearly. And one thing I would like to say is that when we're talking about the 20% of people who have a disability, we also need to toss in there people with low literacy levels, people with outdated software, outdated hardware. And so in that, you'll be constructing your inclusive content. So it's a process. It's not a project, it's ongoing forever. I have tons of information if you wanna reach out because I've been doing this for over two years based on Office of Civil Rights Complaint that our school district got, so. I know more, I got it. That must've been interesting. Yeah, so I think that's great. Making accessibility part of the organizational culture part of the organizational identity makes it less scary, less negative, less of something to put up with and deal with. And that's when you can really have accessibility success. So thank you. Thank you for your questions and your discussion. Thank you, thank you, Aaron.