No Skill Required: Easy Accessibility Improvements Anyone Can Make

Episode Thumbnail
00:00
00:00
This is a podcast episode titled, No Skill Required: Easy Accessibility Improvements Anyone Can Make. The summary for this episode is: <p><span style="color: rgb(50, 51, 56);">We’re not web designers, but with just a few small changes we made a huge impact on the overall accessibility of our online community. Learn how web accessibility creates a better experience for all members of your community and how you can make simple, impactful changes to improve your site. No coding skill required. Lauren Kocher, Sr. Manager of Community Engagement at ISTE shares how she's made their community more accessible.</span></p>
Making Accessibility Improvements an Organization-Wide Priority
01:17 MIN
webAIM's WAVE Browser Plugin
00:31 MIN
Accessibility Setting On Colors
00:33 MIN
Considering How the Color Contrast is Perceived
01:03 MIN
Looking at Alt Text
00:28 MIN
What Meaning Would I Miss if This Image Weren't Present?
00:39 MIN
Developing Your Knowledge and Skills to Continue Making Low-effort, Big-impact Changes
00:36 MIN

Alex Mastrianni: Welcome to the Member Engagement Show with Higher Logic, the podcast for association professionals looking to boost retention, gain new members, and deepen member involvement.

Heather McNair: Throughout our show, we'll bring on some experts, talk shop about engagement, and you'll walk away with strategies proven to transform your organization. I'm Heather McNair.

Alex Mastrianni: I'm Alex Mastrianni, and we're happy you're here. Hey, everyone. Welcome back to the show. I'm excited to bring today's episode to you because it's all about accessibility, a topic that we've been hearing a lot about in the market and from our customers, so hopefully, it's definitely timely for you as well. We're bringing Lauren Kocher, senior manager of community engagement at International Society for Technology in Education, today to share how she's made her community more accessible and to give you some tips as well. Lauren is talking all about a few changes that ISTE made that had a huge impact on the overall accessibility of their online community. She'll share how web accessibility creates a better experience for all members of your community and how you can make simple, but impactful changes to improve your site. No coding skills are required for this one. So take a listen and let us know what you think, as always, over on our Higher Logic community HUG or on the LinkedIn post about this episode.

Lauren Kocher: Hey, I am Lauren Kocher. I'm the senior manager of community engagement at ISTE, the International Society for Technology in Education. We serve educators around the world in their use of educational technology in their classroom. And I'm really excited today to talk to you all about accessibility today and accessibility improvements that you can make in your community. But first, I'm a lot of things. The member community I manage is full of educators. We're a member association and we're also a nonprofit, so I'm no stranger to the idea of wearing many hats, which I'm sure resonates with a lot of you. I'm a community manager, I'm a copywriter, I'm a copy editor, I'm a marketing strategist, I'm a volunteer wrangler, a webinar host, et cetera, et cetera, et cetera. But perhaps most relevant to today, I'm actually not a web developer, so I don't have any formal training in web development, web design, UX, web accessibility. I have a light familiarity with HTML and CSS and an innate inability to never let things go, which always serves you well when you're working with things like a website. I also have a pretty big passion for accessibility in all spaces, including online, but this is also something that I don't have any formal training or education in. I'm not certified or anything, which is all I'll say, that you don't need any formal training either to do a lot of good work in this space. All you need is a passion for doing the work and the capacity to do a little bit of independent study. So my goal today is to give you some concrete examples of improvements that can be made to your site, but just so that we're on the same page, I want to quickly go over some accessibility terms and ideas and basic definitions so that we're all on the same page. But before we do that, I want to give a huge amount of credit to webAIM, which is an organization- based center for persons with disabilities at Utah State University. Their website and their accessible documents course that I took were cornerstones in my developing my own knowledge, and based on web accessibility. And a lot of the information that I'm going to share today is in my brain, thanks to them. So when we're talking about web accessibility, we are talking about things that we can do to make technology, specifically our websites, functional for people with disabilities, and there's a wide range of people with disabilities that can be impacted by poor web accessibility. So for example, people with visual disabilities, like a blind user, may be using a screen reader or a keyboard to navigate your website, or a color- blind user may struggle with differentiating color combinations if you're using them to denote meaning. Even if you're not using them to denote meaning, if you're color- blind, you struggle with differentiating colors in the same way that other folks do. And for people with auditory disabilities, a deaf user may need captions or transcripts inaudible for audio content. For people with motor disabilities, users may not have access to pointing and clicking with a mouse and may be accessing the keyboard with a mouse stick, an eye- tracking device, or some other sort of accessible technology. And then for people with cognitive or learning disabilities, users may struggle with content that isn't structured in a way that's easy to understand. So one particularly useful concept for approaching web accessibility is POUR, which stands for perceivable, operable, understandable, and robust. Definitions are here. I'll also read them for good accessibility. Perceivable means that users can receive and recognize content regardless of their ability. Operable means that users can navigate and interact with content and functionality, such as links inaudible media. Understandable means that users can interpret and process the content, meaning it's readable, legible, comprehensible, and consistent. And robust, which is the content and functionality, works in the assisted technologies used by people with disabilities. So I think it's important to recognize that all of these concepts make web content easier and more pleasant to navigate for all users, not just users who might have a disability. Making content accessible to people with disabilities should be reason enough to engage in this work, but I know that it's not always easy to get buy- in from the right people to begin this work in earnest. And so, a common argument, I think, can be, well, we don't have any users with disabilities, which you actually have no way of knowing because those sorts of disabilities that can make web navigation challenging are wide- ranging. But even if you could somehow state with 100% certainty that you have no users with any sort of disability impacting their ability to navigate your website, it's still worth making your web experience as strong as possible for the users that you do have, whether or not they have a disability that makes it challenging for them to navigate that content. So before I get into more specifics, I want to talk about the situation that we started with, because I'm going to talk about a number of changes that we made on our site and our journey with making some accessibility improvements that you can also implement on your own sites. So at the time that we started this work, web accessibility was not an organization- wide priority, but more of my own passion project and something that my team had a lot of interest in. We were slated to begin work on a major web overhaul of our organization's main site this year, which would have involved considering accessibility more than we had in the past. But as with many things that have happened this year, that has been delayed as a result of the pandemic and its impact on the rest of our work. Also, at my organization, our community team of two owns our community website, independent from our IT or web teams, so we essentially had carte blanche to do whatever we wanted without needing to get buy- in from anyone else at the organization in order to make those changes. So I'm really lucky that my direct supervisor, who's here today, and the rest of our team are really supportive of this work. And so, we didn't have to do any of the relationship management, getting by and getting permission, to make any of these changes, which might be the case for you. You might have to do some more of getting people on board before you can start this work. And we're also working with a beautifully designed site, which you can see some images of on this slide, thanks to eConverse, which we launched in 2019. So we weren't working with any of the basic Higher Logic templates, but a custom one, which may be a little bit different from what you're working with, but most of this should apply the same. You just might be starting from a different place than we were before we did any of this accessibility work. So what changes did we make and what does it look like to approach this work on your site? So the first thing that anyone should do, and you could even do right now, as long as you still pay attention to this session, is to get webAIM's WAVE browser plugin or to use the web version at wave. webaim. org. I found it much easier and more convenient to have the plugin because you can swap pages and it's really easy to just turn it on and off, whereas you have to put in a web address in the web version. But you'll really easily be able to see the things that you need to address first as it will read your whole site and point out where your issues are. So with WAVE, you're going to see a couple of things. On the sidebar here, you're going to see errors, contrast errors, alerts, features, structure elements, and instances of ARIA on whatever web page you're viewing while running WAVE. And not all of these are bad things. Features, structure elements, and ARIA are all, more or less, pointing out where you have things like headings or alt text, present things that you want to have, so pointing out the good things, whereas errors, contrast errors, and alerts are where you will want to focus, because those are the things that could use some work. So this is a screenshot from our site, actually as it is now, so you can see that we're not even completely error- free. I wasn't forward- thinking enough when we started this work to note down exactly how many errors we had before we began since it wasn't necessarily a formal project, just something we were doing kind of ad hoc. It just goes to show that anytime you're doing something, engaging in a project, that you may want to tell people about later, but I can say we probably had about twice the number of errors and three times the number of contrast errors when we started this work. So we really improved a lot on our site, which is a couple of small changes. Our worst offenders were what I assume most people are working with, which is color contrast, link color contrast, and alt text, so we'll get more into all of these and how to approach resolving them as we go on. But depending on your organization, this is probably the lowest hanging fruit and the easiest and most visible place to start, it was, for us at least, to start with color contrast. So again, we're lucky that we essentially own our own community site, and for better or for worse, not many staff outside of our teams spend a lot of time on our community site, so most of the changes we made would generally go unnoticed, and so we didn't have to worry too much. Both WAVE and the webAIM color contrast checker, which I do have the URL for on this slide, were huge assets here. WAVE inaudible pinpoints every place there is a contrast issue, making it really easy to scroll through your webpage and see where the problems are, just a big help to us. You maybe could have guessed that that bright green was going to be a big problem. I find that bright green a little challenging to look at. But we also found some things that we weren't sure were going to be a problem. The teal blue that we were using for all of our smaller headers or we had as our link color was also a problem when on a white background, which we never would have known had we not run WAVE. So the size of the color contrast problem could vary depending on what colors you're working with. When we designed our site with eConverse, we were working with our organization's brand standards, our brand colors, and the norms for how they were used. We use that green with white text on buttons all the time and no one had ever thought that much about how legible it was. It's possible that your colors are way better than ours or using combinations that are way easier to read than ours were. But if your organization hasn't gone through and done an accessibility setting on your colors, it could be that this is where you resolved a lot of errors. But obviously, we couldn't unilaterally change our organization's brand colors, and while I am bringing it up every chance that I get, I would really have held up our ability to make changes quickly if we had to wait to reassess our brand's entire color palette. But we did have the liberty to work established color palette, which I'm sure you all do as well. So I spent some time with inaudible checker, seeing which of our colors passed when paired with byte text since we usually use text on buttons or on top of any of our brand colors. And we were able to swap to another color in our brand palette, this dark blue, and clear up tons of our contrast errors. And we also took the link color and I just bumped it down a shade, made it just a shade darker. It basically looks like the same color, to my eyes, and it totally resolved all of the issues with links on our site. And that carries through anywhere something is hyperlinked on our site, was failing accessibility standards, which on a community that uses a forum, is most things, so that was a big problem and a big win for us. So like I said, since we have a custom theme that primarily affects the homepage, which has a slightly different appearance, whether you're logged in or logged out, so we had two different versions of our homepage to work with, a large portion of our changes were made in the theme editor, in Higher Logic. In the backend, we had a custom theme as long as I have worked at ISTE, but if you're working with a model theme or something out of the box from Higher Logic, you should also be able to find that theme here as well. As you can see, we have several of our old themes on this screenshot. But just as a general blanket statement, your mileage may vary if you're working with something that's not accustomed. And then, beyond once you're in your theme list, have your theme, there's a section called Override... and this is where having some familiarity with HTML... really did come in handy for me. Mostly, I just knew what I was looking for. I can read it better than I can compose it, but when looking for something, I was more or less able to identify where that was in our CSS. But for us, most of our custom theming is on that homepage because the rest of our Higher Logic site is just how a Higher Logic site looks. It's a forum. It's pretty standard. And so, in case anyone here is brand new to literally all of this, in very basic terms, CSS is the code that affects the way your site looks, like your colors or your font size, and having some familiarity with how that language is structured, like I said, helped me look for the pieces of the page that I was planning to change. But when it comes to colors, you actually don't need to know anything other than the hex code for your color, which is really what I did. I just did a Control + F page search on this page and plugged in our hex code for the color I wanted to get rid of, that bright green. And then, every time it came up, more or less, I replaced it. I didn't actually change it everywhere, which I will talk about why in a moment, but you absolutely could. If you had no idea where that color was showing up, based on the inaudible code around it, you could just change every color and get rid of whatever that problem color is. But either way, this was still a fair amount of trial and error for us. We did all of this work on our live site rather than on a staging environment, which is maybe not the recommended way to go about this, but we were making small... again, kind of ad hoc, that wouldn't impact functionality. Changing the color is not going to impact the functionality of your site. And yes, in the chat, make a backup copy of your CSS. You absolutely should, and we did. I did do this. I did copy everything, pasted it into a word pad, just in case we massively mess anything up. And anyway, so we did do a little bit of trial and error of changing things, going and looking at the site, refreshing and seeing how it looked, going back and fiddling with it again, which if you're a little more nervous about web design than I am, definitely doing it in a staging environment would be a big help, so might be something you want to think about if you have a staging or a sandbox copy of your site, and that might just ease the nerves a little bit. But honestly, not a single person has ever mentioned noticing the colors change at all on our site, so I think it's probably pretty safe. Maybe your members are more observant than ours are, or maybe they would care more about the colors changing, but ours didn't really seem to. I believe your mileage may vary again, but if you are using more of a model theme or something out of the box, you might find more of your colors here in this color picker tab, which is in that same area. It's just another tab on that page. So you might find some of your colors here on the color picker for changing text, especially your link color, you might find here instead of somewhere else, just depending on what your theme is and what you're customizing on top of that looks like already. So one thing I want to make sure to mention about color contrast is that the big problem is when the color is impacting whether something can be perceived on your site, so that bright green in the background... Well, that bright green as a background to white text, for us, was a big problem because it made the white text difficult or impossible to read, so someone with a visual impairment may not have been able to read that text at all and would have no idea what that button or that piece of the site was telling them. So when color though, is used to depict a graphic, like we have here, these small, green graphics on these buttons, on the dashboard, on our site, they're not... I mean, they're descriptive in the way that they sort of go along with the text there, but they're not the only thing in imparting meaning on those buttons, and so they could stay that bright green. It's okay if someone can't perceive it, because they can read the text. The text does pass color contrast, and they're able to discern the meaning of that button and they can still use our site in a way that's functional. So a quick recap of the color contrast issues that we resolved. So when paired with white text, we replaced the bright green with our navy blue, was mostly on our homepage, and there were some tabs or areas where the color changed when you hovered, which hover color changes really threw us for a loop because there were still, like I say, so many errors, and then WAVE was still turning up errors, and it was because when you hovered over a button, it changed the color to the offending color, which I also changed those in the Override CSS. And usually, things are marked, in some abbreviation, as hover, at least it was in our CSS. I also took our brand teal, like I said, and I bumped it a shade or two darker because that was the color we were using on all of our links until that passed a color contrast check, and then I went in and made sure all of our ribbons... which this does apply to everyone, make sure all of your ribbons pass contrast checks because sometimes it's just some random color combination that doesn't pass, and it's easy to go into those ribbons and change what the colors are and the color of the text. And we also built all of these same concepts into the process for our community ads. I don't know if you use community ads on your site, but we use them quite a lot, and so just making sure that in any graphic that's going on our site that includes text, that it passes color contrast so that it can be read. So this is definitely the most visible part of the process, or at least it was for us, and was the most fun and immediately gratifying to see change, plus the clearest example of why web accessibility improves the experience of all users. Like I mentioned, I also found that bright green really difficult to look at, and I have a much nicer time on our site now that we've changed it, so a rising tide lifts all boats, as they say. All right, so the next thing is quite a lot less visible to most users, but deeply important for anyone using a screen reader. So the other big thing that we did a lot of work with was an alt text on our site. So alt text, or alternative text, is just the text that gets paired with any image on the web that describes what that image is for users unable to perceive the image with their eyes. So for sighted users, you can often see it when covering your mouse over an image on a website. So on our site, when I hover over my profile picture, I get, of course, that standard pop- up, but it also brings up my name. That's the alt text that we have on all the profile pictures. inaudible not my name for everyone's profile picture, but the name of the person whose photo it is. And so, we did have to be a little creative, specifically for the profile photo, but I will talk more about that later. So here I am, throwing Simon and his pet in the spotlight again. But as far as what images matter for alt text, you may find that not every image actually needs alternative text on your site. But generally speaking, an image needs alt text when the content or meaning of the image is not also present in nearby text, or the image is not hyperlinked and it's not providing any function, like a button. So ask yourself simply, what meaning would I miss if this image just weren't present at all? And if the answer is that you're missing any amount of meaning, then you need alt text. So just keep in mind though, that the reason not every image needs or perhaps should have alt text is, a screen reader will generally read all of the alt text on your site, and so it'll also read all of the surrounding text. So you could be giving users who are using a screen reader duplicative text, and that just slows down their experience of your site or any other material you're producing that could be read with a screen reader. So the most common places that you're likely to have images on your site that do need alternative text are profile pictures, ads, and in most cases, images inserted into discussion posts since our community is made up of members who we have no control over. I'm sure your communities are also made up of people you have no control over. If you are managing a community for people you control, I would love to hear more about that and see how I can get in on that game. But images in discussion posts are where things really get tricky. Our community is not one that posts a lot of images, so it's not a big hurdle for us, but it could be for you. You could be working with a community that is really image- heavy or posts a lot of graphics. And again, you can only do so much to control what your members do. So you can either commit to fixing any images that you come across that's necessary, or you could recruit some trusted volunteers to help out with that, or try and do some community education to encourage your members to up their accessibility game when it comes to alt text on images they share. But again, your site is probably never going to be perfect because we all have more to our jobs than making sure our sites are fully accessibility- compliant at all times. It's probably more worth your time to focus on fixing the things that you have control over. So in most cases in Higher Logic, when you post an image or upload an ad, there are obvious places to insert your alt text. Sometimes, it's called alt text or common description or a long description. There are a couple of different things that it could be named. And my understanding is, different browsers and screen readers will pull up different fields here, so it's best practice to just make sure that they're all filled out. Unfortunately, in the case of the profile photos in Higher Logic, they're being populated around the site by a widget that, while the code for the profile pictures does have an alt text tag in it, doesn't actually put anything in that tag. It's just a blank space. And so, as you can see on this slide here, we didn't know how to fix this, so my colleague, Simon, reached out in HUG to get us some help, because we were totally stumped. And lucky for us, Phil Foss, who some of you may be familiar with, and if you're not, you should be, had the solution that we needed. I was not the one who actually implemented this fix. That was Simon, who is here today, so bother him in the chat if you need some more specifics. But Phil's video, which I put in a big link here on the slide, helped us out. But I do believe that we talked with Phil one- on- one for some additional help because there was some, I believe, JavaScript that we did need to add to our site to make this fix work, to get alt text into the profile photo, because there is... The name of the user is in another piece of the code associated with the profile photo. It just needed to be moved to the actual alt text piece of the code. So this is maybe the level- up work after the improvements anyone can make. Anyone can still make this, but it might require just a little bit more head- scratching or reaching out for support. After those easy fixes comes the stuff that is maybe a little more challenging. You may have noticed when I shared the screenshot earlier, and I pointed it out, that we do still have a number of errors on our site. As people who are not developers or web designers, it's unfair to expect that we alone could produce a perfect site, if such a thing can even exist, which WebAIM's site, I think, has virtually no errors on it. So such a thing can exist, but that is their expertise. The remaining errors and contrast errors on our site are a bit less intuitive than what we've already cleaned up. Some are things that I can only really find when styles are turned off. WAVE has that little ticker for styles to be on or off, and sometimes if you can't find something, but WAVE is throwing an error, you turn off styles, it'll show up easier. But some are things that are just blank, white spaces when styles are turned off and not there when styles are turned on, so I don't really know what's going on there. Some things are carried over in the footer bar from our main site, which is something that I do not have control over. That's someone else at our organization who decides what that looks like and what goes there, so that will require a little more talking to figure out. And some things are just maybe items that are part of Higher Logic's base code that I'll never be able to access, to figure out what's going on or implement a fix on my own. Maybe some of those new model themes have resolved some of that issue, that I have heard rumors about, but it might just be things that we'll never know as users. So this is the never- ending bonus step of accessibility fixes, is continuing to dig deeper and develop your knowledge and skills. It also means collaborating with your team or colleagues outside of your team and doing the work to get your organization on board with prioritizing web accessibility across all of your web properties, which is, of course, a pretty big ask. It's work that I'm doing at my organization, and it's not always easy. It's definitely not fast, but lucky for all of us, there is work that we can do to lead by example by making these easy, low- effort, big- impact changes for our communities. So in review, to recap, we talked about developing an understanding of what web accessibility is and why it's important, identifying where your site stands right now, how many errors you have, and what they are, resolving issues of color contrast, ensuring functional images contain alternative text, and then, of course, digging deeper into the problems that are a little harder to solve, and keep promoting the importance of web accessibility in your community and your organization as a whole.

DESCRIPTION

We’re not web designers, but with just a few small changes we made a huge impact on the overall accessibility of our online community. Learn how web accessibility creates a better experience for all members of your community and how you can make simple, impactful changes to improve your site. No coding skill required. Lauren Kocher, Sr. Manager of Community Engagement at ISTE shares how she's made their community more accessible.