Jay McKay: We'll go ahead and get started then. Hello everyone and welcome to Be A Digital Ally again. It's our favorite time of the month. For us, it really is. We have a great time. Today is a really fun one. I'm super excited to talk about it. This topic is very personal to me in a strange way, but we'll get to that in just a second. But today we're going to talk about your website's toolbox or your content management systems and what you need to know about those. And we'll dive all into that. But if you have a chance, please go ahead and check out the BIT.LY Link. We'll put that up again for you. It is B-I-T.L-Y/B-A-D-A-S-E-P-T. Those are all capital letters, and I'll have one of my lovely coworkers here go ahead and put that in the chat for me as I move on to our next set of slides.
Welcome. And again, thank you for being a part of the journey. We really want to make sure that this is an enjoyable event for you, that you get a lot out of it. And so we always strive to make sure that we create inclusive and accessible spaces. We want to be kind and polite and respectful. I know some people, especially if they're new to accessibility or technology, they feel a little shy about asking questions. And please know you are in welcome company. Everybody wants to learn from each other, so please, please ... We do appreciate that. And then of course, we always try to ensure accessibility to the best of our abilities. So putting on auto captions, and of course, if people need additional services, they can always request those in advance so that way we can make those arrangements. So thank you again for being here.
Just a quick review of our agenda. First we're going to just of course do our usual welcomes and introductions. So if you are used to coming here every month, as I always say, this is time to grab your extra snack or drink if you need one. If you are new, we want to make sure that we catch you up to what's going on and what you're doing here today. And then after we do our reviews on what accessibility is, then we're going to dive into today's specific topic, which is content management systems. So we're going to look at things like vocabulary. If you're somebody like me who, if you work in accessibility spaces, but you are a non coder, so you don't really touch websites beyond maybe just changing a picture or changing content in there, but you're not really getting into the back end, we're just going to go over a couple things just to try and make sure we're all speaking the same language together. Then we're going to look at some things to consider and some accessibility features when you are looking at these different types of systems. And they all have their pros and cons and so really it's trying to find what's going to work best for you and your purposes.
And then lastly, we're going to also look at some tips and tricks for how to work with the current CMS that you have in place. So maybe you're one of those people that's like, well, this is the one I know. I know it may not be perfect, but what are some things that I can do to make the most out of it if it's not quite living up to its accessibility promise that I thought it would. So first of course, we want to invite you to be a digital ally. So this is our monthly series where we're going to cover those basic skills and principles behind accessible digital design because we want to make that content accessible to people with disability. So we want to make sure any audience that's coming to us, any type of content creator, regardless of your skill level ... Maybe you're new to accessibility. This is the place to be.
So we'll just do some quick introductions. I've already told you who I am. I'm Jay McKay. I'm the director of community programs. I am a white female in her early 40s. I have short brown hair, but it's really hidden behind this big huge microphone and headset that I've got on. And I do wear glasses. And I'm going to pass it over to Melissa Green. So this is her first time joining us for BADA. So Melissa, say hi.
Melissa Green: Hi. Thanks so much, Jay. Hello everyone. My name is Melissa Green. I'm a new member of the Knowbility team and I'm thrilled to be joining Jay and Erica for my first BADA session. I'm a white female in my early 40s. I have red hair and freckles. I'm joining from my home office. There is a purple background behind me in the Zoom window that reads Knowbility. Looking forward to learning with you today and in future session. Erica.
Erica Braverman: All right. And I'm Erica Braverman. I think I've met some of y'all before. I'm one of our community engagement specialists here at Knowbility, and I also run our Access Works program, which is usability testing with participants who have disabilities. And I'm a white female in my mid 30s. I wear glasses and I have shoulder length brown hair. And Melissa, thanks for popping that link in the chat. You beat me to it. I'm the slowest person, so I appreciate you figuring out the chat faster than me.
Jay: Excellent. All right. For those that may not be familiar with Knowbility, maybe this is your first time joining us, we are a nonprofit. We are founded in 1999 based off of our success of our community programs such as AIR, which is our Accessibility Internet Rally. We are based in Austin, Texas, but really we operate globally around the world. Melissa and I are actually in Alabama in two different cities. Erica's in Austin. We have staff from everywhere. I was taking phone calls today with people. I don't even know where half of them were today. So we work everywhere, which is lovely. And our mission is to create an inclusive digital world for people with disabilities. And one of the ways that we do that is through these different types of community programs. So I mentioned AIR, which is our Accessibility Internet Rally. This is a website design competition where we pair web developers with nonprofits who need websites or redesigns with the purpose of having those web developers learn about good, accessible design while helping that nonprofit expand their reach to people with disabilities.
AccessU is our ... Excuse me. Annual web accessibility conference that happens every year. Last year we did our hybrid, which was in Austin as well as virtually online through Zoom. We are gearing up to start planning for that again this year. We're very excited. We have our Access Works program, which Erica talked about a little bit. Our usability testing program. And then we have K12 Digital Accessibility. And we have a couple different arms. Our K12 Access Summit, which is our virtual conference, and then Toolkit Tuesdays, which is going to be gearing up again at the end of this month, which is a monthly webinar series talking about digital accessibility inclusion practices in the K12 space. So we love doing these programs because, again, it's to the heart of our mission. We want to educate and empower people in making these digital spaces accessible. And to do that, having you all come and join us is great. And if you can, we always encourage you to go to knowbility.org/donate to help keep these programs going.
Next we want to talk about accessibility. Because that's what we're here for. So if you're new to accessibility, we really want to make sure we define what this word means. Because sometimes when people hear something being accessible, they might just think of it as being available. Like, oh, it's right here, I can go grab it. It means it's accessible. Or it's turned on so it must be accessible. But we really want to be very specific in how we talk about accessibility. So what I've done here is there are two definitions that I've combined. One is from the w3.org, and then the second one is from the aim.cast.org. And they've both talked about accessibility and I really liked their definitions, and so I wanted to combine them. So for something to be accessible, people need to be able to perceive it. So can they hear and see the content? Understand. Do they know where to go? Do they know what to expect? Navigate. Can they independently navigate using their preferred tools? Oh. Thank you very much for letting me know that those slides did not move.
So we should be on the definition of accessibility now. Excellent. So just to quickly summarize again, to perceive. Can they hear and see the content? Are they going to miss out if they don't have the ability to see the content? Is there some other way it's being provided for them? To understand. Do they know what to do once they get to that website? Sometimes when people say, "Oh, go to the website and register," well, you go to the website, but can you figure out where the next step is to register and after you click that button, do you know what to do next? To Navigate. Can they independently navigate using their preferred tools? Not everyone is able to use a standard mouse and keyboard. Not everyone is able to use a touchscreen on a mobile device. So we want to be able to make sure that if they're using some type of assistive technology like a switch or eye gaze system or something like a screen reader, that they can use those tools to navigate all aspects of that website.
And then next is to interact. Can they independently complete tasks and explore all the areas? Again, we don't want them to just get to the page. We want them to be able to, again, fill out the form to register, go to a survey, explore additional options. We want to make sure that they can get to all of those areas independently. And then lastly, to contribute. Can they fully participate in an authentic manner? I know sometimes when I was working with students that had disabilities and they're using some form of assistive technology, they were hindered in able to really, truly expressing themselves or participating in certain activities in digital spaces because the space was not designed for their assistive technology to independently interact. So they're having to give their answers to somebody else and dictate it, and then somebody else would have to enter it in for them. And that's really not letting them fully participate because then they're having to rely on somebody else. And we want to make sure people are able to be their true, authentic selves.
All right. So why is it important to design for accessibility? Well, 15% of the world's population lives with some form of disability. And when we talk about that, this can include several people who may not even consider themselves as disabled when defined by the World Health Organization. And what we mean by that is as people age, their vision starts to decrease. Or somebody with hearing loss may not necessarily consider themselves as being disabled, but that is a classification under that World Health Organization. But then also there are people without disabilities that also benefit from accessibility or accessible design. How many of us love turning on our captions when we're watching streaming platforms? How many of us are using the audio descriptions? Those are things that we are finding beneficial, even though we may not have a disability ourselves that it's necessarily designed for. But it's something that we all benefit from.
Next I want to talk about the term assistive technology. And I had mentioned that a little bit earlier. And I have two definitions here. One, again, from the World Health Organization, and the next is from the Assistive Technology Industry Association. And I'm not going to read both of them in full. They're pretty lengthy. But I want to hit some highlights. When we talk about assistive technology, we're talking about any piece of equipment. It could be purchased, it could be software, it could be a tangible item or a product system. And its purpose is to increase, maintain, or improve the functional capabilities of a person with disabilities. And I want to also touch on with the World Health Organization. Their definition really talks about it, not just improving their capabilities, but improving their independence and their wellbeing. So again, it's that quality of life that we want to make sure. Oh, thank you so much. My screen's not set up properly, so once I get off the screen, I will make sure to fix it for the next set of slides. But thank you.
All right. Next we want to talk about examples of assistive technology. There are wide variety. Some of you are probably already familiar with most of them. But things like screen readers. These are the tools that when you are accessing a computer, if you're somebody with a visual impairment and you can't just click a mouse to get to those different icons, a screen reader's going to tell you what's on the screen, where it is, and when you get to that item, then you can select and do your next task. Refreshable braille. That's a device that will pop up the braille that they see on the screen so if they're looking at a computer screen and there's text, that will then convert into a braille on that refreshable braille display. Alternative navigation methods. We talked about these a little bit. Using a keyboard, using a switch if I can't use something like a touch screen or a regular mouse. Closed captions, transcripts, screen magnification, dark mode and high contrast. Those are big ones that sometimes people don't think of as being assistive technology, but are really important for several users. And we have a link here when you get a chance to explore on your own. WebAIM has provided some great examples where you can dig a little deeper into these different types of tools. How they work.
Oh, there we go. And then lastly, before we dive into our content, we want to remind you that accessibility is a journey. I love this quote from Maya Angelou. It says, "Do the best you can until you know better, then when you know better, you do better." And we like to remind people about this, because sometimes if you're new to accessibility, it can feel scary, especially if you're not familiar with some of the terminology. Sometimes people are afraid of offending somebody or making a situation worse, and so they say, "Maybe I just shouldn't do anything so that way I can just fly under the radar." And really, it's better to start. Start small if you have to, but then you do one thing, then you do the next thing. And again, accessibility is a moving target. Technology changes and we have to grow with those changes as well. So it's a journey for you, it's always a journey for us as well.
All right. We're going to go ahead and get started. And I just popped up these little bonus resources. I thought they were really interesting. This first one is from The WebAIM Million. I'm going to see if it's going to take me to it. Is it showing up on your screen, everybody? The website?
Melissa: Yes.
Jay: Okay, excellent. This is a report they did looking at the top one million websites. But what I found really interesting for me was when I scrolled all the way down ... Where is it? There we ... No. There it goes. When you scrolled ... And it's probably about three fourths of the way down. They talk about the different technologies and they talk about the different types of content management systems. This was just something I found interesting. We're not going to spend a lot of time on this screen, but we just thought it was interesting information to look at. And then another one that we found ... And this is a little older. It's from 2019, but this was just a neat article from Smashing Magazine just talking again about some things to consider when choosing your CMSs. Like I said, we're not going to hang out there, but those were just some things that bubbled up for us in our discussions.
All right. Now we're going to go onto the vocabulary review. What I'm going to do here is I'm going to talk about some terms that if you are that non coder, these may not be familiar to you, or maybe you've heard them, maybe when you're talking with maybe your web manager or somebody that you're talking to about doing some type of web design for you, maybe they're throwing around some of these terms and you're just not sure what's going on. So we just want to provide some very simplified definitions or descriptions, just so that way you can see the relationship of each other in their role of web design. So for those of you who are very familiar with these terminologies, wonderful. If you're new to it and you're like, "Well, this seems very basic," and that's its purpose. Is because we just want to give you that overview, because then as we start talking about content management systems and talking about web design, you'll start to see how these things all fit together.
All right. There we go. Our first one is URL. And this stands for Uniform Resource Locator. And really, you probably know it as a domain name. And this is just the address that people type in to get to your website. So knowbility.org, that's our URL.
All right. There we go. The next term we're going to cover is HTML. And this stands for hyper text markup language. And so what does that mean? Well, it's a markup language, and that's going to sound a little funny to you at first, but once you start seeing the other terms, it'll start to make a little more sense. So what we mean by HTML is it's going to be what's on your webpage. So it's the stuff that you see. Now, when you're coding it, that's what we're talking about. So when you're typing it all in, it's the markup language that then puts things on your site. And with HTML you're going to use other language systems to help create your website. And one of those would be CSS which is the cascading style sheets. And it's a style language. So we had our markup language, now we have a style language. So this is looking at how the content is presented. How does it look to someone?
Next is JavaScript. JavaScript is a programming language. So this is more about the rules for what happens on your webpage. And then the last one is ARIA, which is accessible rich internet application. It is another type of market language. And really the joke is you'll hear the first rule of ARIA is you don't use ARIA. And its purpose is to provide that additional information to those utilizing assistive technology when they're accessing your website. So if somebody's using that screen reader, and I'm trying to do something with HTML, but maybe I need to give some additional information to my screen reader user that I can't do it in a good way with HTML, ARIA can provide me with that ability.
And then lastly is of course, what you're here to talk about today, which is content management system. There we go. And this is the software to edit or manage your website. And depending on the type of system that you're using, typically you're not using coding to edit that website. Some may have that coding ability there or some type of coding option, but typically when most users are utilizing a CMS, they're not really having to go in and use the code.
All right. Oh. Okay. Sorry about that. My mouse is getting a little trigger happy. All right. And I want to talk about the term of CMS versus hand coding. If you are talking with developers and things like that, you may hear something or a phrase called hand coding. And I want to talk about what the differences are between those. So typically people who are using a CMS, again, like I said before, they're not requiring coding if at all. It usually requires very little technical knowledge. So you're not having to be an expert in web design and things like that. Typically, there's multiple templates to choose from. However, there may be limited customization. So I may go into that CMS and say, "Oh, I love this ..." Terrible. I can't think of a good name. But sky blue on the horizon template. And I think it's great, but if I want to tweak something, I may or may not be able to do that based on how that CMS works. Typically, also you're looking at easy editing and management of your website when you're using a content management system. Like I said, if you don't need coding and very little technical knowledge, and it's just somebody going in and clicking on a square to put a new text or drag a picture into the box to add a new image. Very easy to manage.
However, the thing to be cognizant of is it could possibly inhibit accessible design. And that's just based on several different factors that we're going to talk about when you are looking at these different systems. So that's CMS. Now want to talk about how that's different from hand coding. Hand coding is requiring coding skills. That's when I'm actually going to type out that HTML and JavaScript commands, which means I'm going to have to have very technical knowledge. I'm going to have to have that high technical knowledge to do that. The benefit, of course, means that I'm going to fully customize that site to my specific needs because I'm building everything from scratch. I'm putting every single line of code in there.
What that could cause, however, is limiting the ease of editing. So if I have somebody coding my site, but I need to go in there, is there a good way for me as the non coder to go in and fix it? So you may be limiting how many people can go in and do those edits. And then lastly is it does give you that ability to make the site as accessible as possible. So we're not saying one's better than the other, it's more of we just want you to know what those differences are, and so that way you can plan ahead.
All right. Next one is wysiwyg. And we wanted to throw this one in there because it's a term that I was not familiar with either until I started hanging out with coders and designers. And what that means is what you see is what you get. And typically when this term is used, they're referring to those block editors or those templates on a CMS. Something like MailChimp as well. Also could be known as drag and drop. So the idea of I can just go in, drag the block over and it puts it in that template. Or especially MailChimp's a really good example. I drag the image onto the area for me to edit my correspondence or my email that's going out.
Erica: Hey Jay, sorry. Your slide is stuck.
Jay: Oh no. It's doing that a lot lately. There we go. There. Excellent. Like I said, very, very cursory, just basic information, but we just wanted to give you some of those terms because for myself, I know when I was first looking at CMSs, these were things I was not aware of. I didn't know how CMS worked versus hand coding. So we just wanted to give those terms for you. I think, Erica, you wanted to touch on a question, and I'm going to refresh my slides so that way they don't get stuck
Erica: Would help if I unmute myself. We had a question come in via email ahead of our presentation about ... And I'm going to read the actual question to myself just to make sure that I'm getting all the information. This is a question about a hand coded from scratch site, and they wanted to know if they're the owner of all the source code, is it more secure? And my answer, Melissa, you might have a better answer, is that the ownership doesn't necessarily affect the security one way or another. It's more about how well that code is set up to protect the site and how secure it is rather than where it is stored or who is the keeper of the keys. It sounded like this person was working with a well versed developer, which is great because even though they have the extra labor of a from scratch site, it seems like that experienced voice is helping them a lot. Melissa, did you have another piece to add? I know you were talking about this early day on Slack.
Melissa: Yeah. I fully agree with what you've said. The only additional thing I'll share is we'll be talking a bit more about user communities and the benefits of choosing a CMS as a robust user community. I think one possible advantage of using a web content managed system rather than a site that is hand coded and maintained by an individual developer is that there generally will be an organization or company shepherding it and/or a robust user community that keeps an eye out for things like security vulnerability, needs to update frameworks, things like that. You would have the benefit of having a larger group of folks keeping an eye on it and contributing to its functionality and security. But I agree that it's not necessarily whether it is hand coded or a CMS or self-hosted or hosted with a provider, it's more of how that's implemented in the first place.
Erica: And I think that's actually one of my slides talking about user communities and things, but I'll get more to that later. But there's also a very robust hand coding community out there of people working together too. So when I was looking up some resources to answer this question, I found a really great quote. The question was, is a CMS or hand coding the right way to build a website? And the answer is just yes. Both a CMS and hand coding are the right way to build a website. So I'll touch more on that later. I'm glad you brought that up, but that was a good question.
Jay: All right. And I think I have my slides fixed so with that, we're going to pass it on over to Melissa to talk about things to consider.
Melissa: Sure. Thanks Jay. One of the benefits of using a web content management system is its ease of use. As we've talked about a bit in the previous few minutes, pre-made website templates, things like drag and drop interfaces and other advanced tools make it possible for users to customize their website's design and manage its content without coding. However, these easy to use interfaces may not be designed with accessibility in mind and they may not produce content that is fully accessible. When selecting a content management system, two primary things to consider are the accessibility of the authoring tool itself. So is it accessible to the folks who will use it to create and share web content? That's sometimes referred to as backend accessibility. And the other factor is the tool's ability to help authors produce accessible content. The authoring tool itself must be accessible so that people with disabilities can create web content, and it should enable, support and promote the production of content that conforms to web content accessibility guidelines.
The World Wide Web Consortium, the W3C, is the governing body of the web, and they produce a number of guidelines and standards that are used in all kinds of web development contexts. They are the authors of the authoring tool accessibility guidelines, or ATAG. I'm sharing a link to those in the chat. That link is also included in our resources slide. These authoring tool accessibility guidelines, while somewhat technical, they provide a good framework for choosing an accessible content management system. In order for a CMS to be usable by authors of all abilities, its interface has to be accessible. When considering a web-based content management system, you might ask, does this tool conform to WCAG, web content accessibility guidelines, 2.0 or 2.1 as the case may be, or otherwise follow accessibility guidelines. Sometimes that information is available on the tool's website in their documentation or help content.
It can sometimes be found in a voluntary product accessibility template or VPAT. Other times you'll have to reach out to the CMS provider to ask, "How accessible is your product to users with disabilities?" Or, "Does your product conform to web content accessibility guidelines?" An accessible CMS ensures that editing views are perceivable. Jay started off with a great couple definitions of accessibility, and one of them was the perceivable component, that the content can be perceived by folks of varying abilities and through various senses. So for example, a user who does not have full use of their sight is able to perceive content in an image of a chart, let's say, through alternative text. So an accessible content management system, on the back end, ensures that the editing views are perceivable. For example, some web content authors require alternative content in order to interact with the content that they're editing.
For example, I mentioned descriptions for non-text content searches such as images. Web content authors may also need captions and audio descriptions for video or time based media and so on. Additionally, when it comes to the editing and production of content, authors need access to information being conveyed in the editing view, such as spelling indicators. So if the browser or the CMS itself has a spell check tool, that those indicators, those errors, those warnings are presented in such a way that they're perceivable to users of all abilities. Tracked changes, hidden elements, other information. An accessible content management system makes this content available to authors and ensures that authors can access status messages and other information about how the end user will experience the edited content.
The next component of an accessible CMS speaks to the operable principle of web accessibility, which states that all users must be able to operate the interface across browsers and operating system. When it comes to a web content management system, the operability of all of its components and the navigation is key. Some of the ways that an accessible content management system accomplishes this are by providing keyboard access to authoring features. So ensuring that no authoring features have to be completed with a mouse or that anything that is available to a mouse user is also available to a keyboard user. I'm thinking of a date picker, for example, of choosing the date on which a particular post might be published. We want to make sure that a keyboard user can access that date picker and then exit out of it when they're finished. So it's not a keyboard trap. Another important component of an accessible CMS is that it provides authors with enough time. In some instances, it might take an author a little longer to type and publish their content.
Avoiding unnecessary countdown timers or timeouts is a way that a CMS can be more accessible and inclusive. Helping authors avoid content that could cause seizures, enhancing the navigation and editing via the structure of the content, allowing tech search of the content, allowing users to manage their individual preferences. And finally, ensuring that a preview of a page or a post is at least as accessible as the published version or the version that will appear in the user agent or browser is another key component. Finally, an accessible CMS ensures that editing views are understandable. Everyone makes mistakes, but some people with disabilities may have more difficulty creating error free content due to difficulty making fine motor movements or for example, speech recognition system errors. An accessible CMS helps authors avoid this. There might be an undo action that authors can use to reverse the previous action that they took, or a cancel button that enables authors to reverse changes that have already been committed. Authors with disabilities that need to use the CMS's accessibility features should also be able to easily find descriptions of what those features are. And another important component of CMS accessibility is ensuring access to good documentation. So an online help or an in context prompt or description that helps users identify what a feature is and how to use it, that's key to providing an accessible concept management system. Can we go the next slide please, Jay?
I've talked a bit about considerations of for accessibility on the backend or the author or content creator side. Now I want to talk a bit about the tool's ability to help authors produce content that is accessible. I've used this terminology before, but I think it's a good way of summing up all the things and accessible content management systems should be able to do. That content management system should enable, support, and promote the production of content that meets accessibility guidelines. If authoring tools such as a content management system automatically produce content that includes accessibility errors, then this will impose additional repair tasks on authors. An accessible CMS produces content that is accessible without this need for fixes or remediation. So it's going to generate content that is valid, HTML is valid and meets applicable web accessibility guidelines. An accessible CMS might also prompt authors to check for accessibility during the authoring process, either through a dialogue or perhaps by offering built in features that can help check for and produce accessible content.
The creation process. And what I mean by accessibility information is information that web content must include to meet a web content accessibility guideline success criteria. So alternative text for images, ARIA roles, state, information for widgets, relationships within complex tables about column and row headers and so on. An accessible CMS needs to take that information when it's input by the author and ensure that it's translated when that content is actually published and presented to the user in the browser. Some of the ways that an accessible CMS supports authors in producing accessible content is one, ensuring it's possible with the programming, ensuring that the tool generates content that is as accessible as possible, guiding authors to produce accessible content, for example, through the use of dialogues or prompts or accessibility checkers, guidance within context in the tool itself, assisting authors with managing alternative content for non-text content.
That doesn't really seem like a real sentence to me, so I'm going to rephrase it as an example that I've experienced when working within a content management system. In the WordPress content management system, for example, when one uploads an image to the media gallery, there is a field where an author can input alternative text or a textual description of the image's contents, or if applicable, indicate that an image is decorative. So that's a way that the content management system assists me as an author with making sure that I'm providing that vital accessibility information. It's right there at the point at which I add the image to the media library or insert it into the page or post. Assisting authors by providing accessible templates as well as assisting authors with accessible pre-auth authored content if that is a feature offered by the content management system.
These are other ways that a content management system can help an author produce accessible content. A couple additional notes about this accessible content production. Content produced by the web content management system should be accessible out of the box without need for additional plugins, widgets, or overlays. These tools claim to improve the accessibility of the content by applying third party source code when a page loads in a user's browser. However, they are problematic for a number of reasons. One of which is that they do not remediate or fix accessibility issues at the source of the original error. I mentioned that one of the ways an accessible CMS might support authors in producing accessible content is by providing accessible or accessibility ready templates that adhere to accessibility best practices like sufficient color contrast, keyboard navigation, visual focus indicators, accessible forms. Many content management systems have collections of templates that are labeled or categorized as accessible or accessibility friendly.
And these templates are a great place to start, but when choosing a template, it is important to verify that the elements I mentioned are in place. Sufficient color contrast, support for keyboard navigation and so on. You can do this by using a resource like a color contrast checker. I believe we've included a link to one we like in the resources. You can also tab through the content using the tab key on your keyboard, other quick manual checks for accessibility. That's a good practice when selecting a template. Even if it's already labeled or advertised as accessibility ready, investigate that further before assuming that it's fully accessible.
Moving on. An accessible CMS also supports authors in improving the accessibility of existing content by assisting them in checking for accessibility problems and assisting authors in repairing accessibility problems. And again, that's often accomplished through a built-in accessibility checker that checks for common accessibility challenges and offers guidance about how to address those challenges. Finally, an accessible CMS's authoring tools promote and integrate accessibility features, which essentially means that those features are easy to find and use. Next slide please.
In addition to looking at the accessibility of the CMS itself and its ability to support the creation of accessible content, you might also look for these things or consider these things. First, whether the CMS enables you to add fixes yourself and the difficulty of and support for adding those fixes. Erica's going to talk about some of the ways you can fix or improve your CMS or the content produced by your CMS, but depending on the tool and its features, these fixes may require HTML, CSS, PHP, or other programming skills. And even users familiar with web development could find it difficult to access and edit the necessary files. So something to consider is the CMS's ability to let you fix accessibility issues and how difficult that might be, whether that's a good fit for your skillset or the skillset of the other folks who will be using it in the context in which you're using it.
Just as important as the presence of accessibility features is the ability to disable unnecessary features. Many content management systems or some content management systems provide unnecessary accessibility features like access keys that are specific to that content management system. So rather than using standard keyboard shortcuts or access keys that most users are accustomed to, they might have their own special set of keys that requires ... It's not very user friendly. It requires learning a separate set of access keys. Confusing tab order, overly long titles for elements, hidden text intended for screen readers, overly descriptive alt text. These are all some accessibility features that may not actually be beneficial to the users and would be better off turned off. You want to make sure that these features are necessary and if possible, disable or repair the ones that aren't, especially those access keys that may interfere with other keyboard actions.
Ask yourself if the more complex features are necessary. The same thing goes for things like polls, calendars, chat features. Again, you might ask, does this feature contribute to the user experience or does it serve a necessary function or is this just something that's here because we have the ability to turn it on? I like a technology tool that has a robust user community, as I mentioned before. When choosing a web content management system, you might ask, is there a forum where I can post accessibility related questions or accessibility related suggestions? And if the web content management system is an open source tool, you might ask can users contribute accessibility fixes to the community? And this is really beneficial because it often results in changes made to the CMS and future updates that are again coming directly from the community of users that need them.
Finally, keep in mind that while today's session addresses general challenges and solutions around accessibility and content management systems, every content management system is different. So some of these issues may not apply to a specific content management system or the content management system that you're considering may offer accessibility challenges or solutions that we haven't addressed here. I see that one of my colleagues has shared the link to a recent blog post on the Knowbility site about content management systems. This includes a little more specific information about some of the most popular content management systems and their accessibility. So that's a great resource if you're looking to learn more. There also, again, as I mentioned, is generally documentation about a CMS's accessibility on the website where that tool lives. For example, wordpress.com or Wix for example.
Erica is going to talk a bit about how to improve the accessibility of your content management system and share some work arounds for when that is not possible. Erica?
Erica: Yeah. Well thank you Melissa. Melissa's given some really great tools on when you're shopping for a CMS, what should you look for, what should you do and think about. But for some of us, we might be volunteering for an organization that already has a website and we're just coming in to help. For some of us, we might be part of a team and there's five other people working on the site and they're really committed to the CMS that they have. There could be a lot of reasons why maybe you're only working right now with what you have and what you have might need some help. Which happens to the best of us. I would say everyone on this call from Knowbility has had to go back and fix their work. So if you do need to reassess and edit, there is absolutely no shame. It is good for all of us when we do that. I'm going to talk about some kind of overall considerations. Brevity, keeping it short and sweet. What to do if you run into accessibility barriers that you cannot fix on your CMS. And then some other considerations for design in general, and then where you can go for help if you have more questions. Besides us. We will always help you.
Some key considerations. When you think about the accessibility of your CMS and the site that you build on your CMS, it's not an all or nothing outcome. It's a scale, it's a spectrum. So even if you have some problems you can't fix right now or you're really stuck, it's still good to work on what you can fix. The more you can do the better. And if there's something that you can fix today, fix it today while you're still thinking about how to plan for the thing that will take you two weeks. If you have to use a CMS that displays certain things in an inaccessible format, try to find alternatives or other things you can do, kind of thinking of workarounds. But in addition to that, good design across your site is key. Beyond the CMS, your own content should be accessible. And this is to sum it up. Just use your knowledge and resources to design for accessibility in the best way that you can. We are all learning. We're all here to learn. And whatever knowledge you can apply today, you'll have more knowledge next month and so on. So just keep working at it and keep learning.
I think we're ready for the next slide. Remember, KISS, keep it short and sweet. Numerous acronyms, but I like keep it short and sweet. Why do we keep it short and sweet? Is the simpler your content is, the easier it is to keep your site accessible. This could include interactive elements, this could include how people find information, and this could include anything that requires specialized instructions for how to do what they need to do on the site. So for example, you might have come across this on a website. Let's say you have a website showing photos or pieces of art.
A simple way to display these images would be a webpage with static images, kind of like a gallery. They're just posted individually on the page and then maybe a caption saying who the artist is, when they made the art, what materials they used. And then there could also be some alt text describing the image, a non-visual description of the image. There should be some alt text. The non-visual description of the image. That would be a very simple way to display this information. A more complex way would be a carousel gallery. When I say carousel, I mean a gallery where you might hit an arrow key or button on either end of the gallery and it moves it around. It rotates. And then if you click an image, sometimes it pops out. Those carousel galleries are frequently not accessible. And that's a more complex way to view the information. Maybe someone wants to compare two pictures and they can't or they can't figure out how to make the gallery stop. Even though it's a neat trick. We like fancy moving things. I do too. Sometimes it's more helpful to go a little simple and not get the latest innovative feature to keep the accessibility more within what you're able to modify and what you're able to control.
I think we're ready for the next one. Thank you. So what do you do if you start bumping into accessibility issues that are just in your CMS and you cannot fix them? And we're going to go with some of the common issues here just as a baseline. What if you have a login or password protected page that the CMS just gives you, you can't customize it and it's not accessible? What we recommend is think about who needs to view that private information and then set up a different way for them to get that information. So that could be a shared drive. And when people sign up for that password protected information, they get access to the drive. If it's just five people, let's say, or even 15, you might just email them that information. Of course, that depends on the quantity of information. If you're adding more and more stuff, maybe something like the drive is better. If your site has an inaccessible media player. So if you want to post your podcast, if you want to post a video and the media player they give you for that content is not accessible, you can't get to the controls without a mouse or maybe they're not labeled. Find a media tool that is accessible. YouTube or Vimeo. Those are sites also where you can edit your own captions and add captions.
So then you can put the video on that service and then embed it or link from your site. Oh, thank you. If you have forms on your site, can visitors save their work and finish later? This is especially a big one if your organization does something where you're collecting a lot of information about people. Maybe who's in your household? What are your needs in this area? What is your transportation? Different things. That can be a barrier if people aren't able to ... Maybe they run out of time or they get distracted or they need to go find their driver's license or whatever. Those long and complex forms might not be the best choice. So if you have a long or complex form and you can't give people a save and finish option, maybe you can provide an editable digital worksheet or a template, like a document that people could open, fill out on their own time, save as they go, and then return to you.
Make sure if you do that, and also for your forms, make sure that you give instructions for the user on how to complete and submit that form if they're not used to doing things in that format. And then also what's very important is providing a phone number or email address that users can call if they want to share their information verbally if it's arduous for someone to fill out that form and they want to talk to you. And then an email can be a good way to ask for help.
Does your template leave out skip to main content links? And if that's not a familiar term for you, that's a little link. Code wise it's right at the very top of the page. And what it does is when someone arrives to the site and they're only tabbing, so maybe they use a screen reader, not a mouse, or they're not using a mouse, they're just clicking through, it will give them the option to bypass that top menu so they don't have to run through it every single time. Saves a lot of annoyance. What you can do is you can add your own link to the menu or to the top of the page that would take the user to that first item on the page.
And then the other piece ... Those are all things that when someone's visiting your site as a guest, maybe they want to sign up for your program or see what you're all about, come to one of your events. But what happens if you're using a CMS and you have a volunteer or a web developer who has disabilities, or someone who wants to contribute a guest blog post or something that they're sharing and they have a disability and it's the contribution side, the developer side is not accessible to them. This one's a little trickier because a lot of CMSs are drag and drop and those are not screen reader compatible. They're not keyboard only compatible. But there are still workarounds. If your CMS is not accessible to contributors with disabilities, you might try a social media tool instead.
It would be a different layout, different format, but it could be a good workaround. Not all CMS or social media tools are accessible. So take that into consideration. You'd be evaluating the accessibility of a different tool, but those social media tools, because they get a lot of traffic, have a lot of people who can find problems on them. So that's one option. If you have a newsletter and you want people to contribute to the newsletter, maybe writing a story or adding a photo, consider creating your newsletter in a digital document and sharing it as a document file.
That could be one option. It's a little more low tech, but it works and it's very inclusive. And if you're starting to think maybe I'd like to try a new CMS and I'm really looking for one with an accessible development side, WordPress can be an option. If you've never used WordPress, they do have a block editor, which is more like a drag and drop, but then you can also edit the HTML directly. You get two options. And the editing tool for WordPress that is most successful is WordPress Classic. They have another one called Gutenberg, which is on its way. But one of the cool things about WordPress is it's open source. So that means that it's this big community all working on this software together and you can actually see the issues that people have noted and documented and are working on and have finished. So you can see where Gutenberg is in progress, where they're accessibility. But for now I think classic is still the way to go.
And then these other considerations ... And I should have called these two slides something different. Other considerations sound like and these two. Yeah, that. But really these are actually very important things and I want to go back to something that we got a great comment and the chat from Bowton saying that you could have the most accessible CMS in the world, but you can still have inaccessible content that you add. A CMS won't magically make your content accessible. You have to do that. It's kind of like you could have all the right ingredients for a cake, but then you still add too much salt. You have all the tools and the pieces, but you've got to pay attention and follow good guidelines.
One thing to consider is, especially if you're using a template, do you like how the headings look in your template in order? Sometimes people will look at all their headings and they really like that H2 or H3 so they make that the main heading on their page. And that is not accessible because it will send people there. It'll think of that as the middle of the page and it can really mess with people using screen reader. They won't read the page in order. So style your headings so you like how they look in the correct order. Maybe you need to look at the color and the size and the font of that heading that you really like and then make that your H1. And it can be helpful just to take all your headings and put them in order. Do a sample page. Make sure you like them, and then play around with the style if you don't like them until you get something you do.
Are your menus and navigation intuitive to use? Do things make sense? This might be something where you find a friend outside of your organization and bribe them to go through your site and see if your content makes sense to someone who's never seen it before. Sometimes we get so used to our own stuff that we don't realize that we're confusing people.
And are your links clear about where they take the user? Descriptive links are really important so people know where they go. Do your images have alt text? So are you including a non-visual description that people with a screen reader can use? Another thing is if you have complex images like charts or graphs, you also want to have a full no sight required description. So for example, if you have a graph showing how many people have come to the farmer's market that owns this website, how many people come to the farmer's market every month. Instead of just saying graph showing how many people come to the farmer's market every month, you need a description that gives all the information that the graph would. So in January we had however many people, 258 people. In February, we had 302 people. So on. That describes all the information in the graph.
And does your audio and video content have text alternatives? This would be your captions, this would be a transcript. If you have a podcast, a transcript can be great. I love podcasts with transcripts. And then for your written content on your pages, is it easy to read? Is it broken into sections that help give people a break? Time to think and process? This could be another good ask a friend. Have you checked your text for color contrast? Is it large enough and does it have enough contrast against its background? Are your form fields labeled correctly?
If you're asking for name and people need to put in first and last, tell them it's first and last. Or give a field for first name, last name, things like that. Make sure that the form field is labeled and there's not extra text hanging out on the page that's not connected to the form that should be the label. And do you have contact information on your site so visitors can get in touch with you if they find an accessibility issue or if they just need help in general?
Lastly, we're all on our phones. Is your mobile site just as easy and intuitive to use as your desktop site? Again, ask a friend. I keep saying that, but it really can help. And find a friend who you're still going to like, even if they really don't like the website. But yeah, have someone pull it up on their smartphone and see how it looks.
And then finding help and guidance if you are stuck. There's a lot you can do to help yourself out, to help other people on your team to get more background on how to use your CMS. Some CMS tools have online tutorials available. If you are working with a brand new CMS and you don't know how to add alt text to images, they probably have a tutorial for that. If you don't know how to edit the appearance of your headings, they'll have a tutorial for that. Check around. If you need to go beyond the company created tutorials, and especially if you're using an open source tool like WordPress. Also, because we had hand coded sites mentioned, this is also a great resource for hand coders, this very codey place. Stack Overflow. If you haven't heard of Stack Overflow, it's like a big forum for asking all kinds of web development questions.
If you use Squarespace, there's a separate Squarespace forum for anything on Squarespace. And then if you are a Meetup person, it's meetup.com. You can find virtual or in person accessibility meetups if you've got accessibility question. There are also some meetups for people who use a particular CMS. I know there's lots of WordPress development meetups out there. And then we have another option, which was Reddit I think. Reddit has some communities for people who use different CMS tools as well. Lots of people ask questions on Reddit. And then I think we can go ... Perfect. So we have some resources and tools in addition. If you want to check your color contrast of your text, we have the WebAIM contrast checker. If you are new to heading structure or need a refresher, we have the Guide to Heading Structure from the Big Hack, which is an accessibility blog/resource.
We have a link from the Web Accessibility Initiative on authoring tool accessibility guidelines. This is interesting because it's a tool for people who develop these CMSs. How do they assess the accessibility of their product? And it's not necessarily for the end user, but it's cool to see how they can check their work. And then we have Deborah Edwards-Onoro, her company's Lireo Designs. And I think wasn't she at AccessU? She was at our conference. Yeah, I met her. She's very cool. She is a graphic designer and she does all kinds of cool accessible graphics. So her work is really interesting to follow. And then if you need some guidance on alternative text, descriptive links and plain language and captioning, as you put together your content on your site, we have our Be a Digital Ally resources, our videos, our transcripts available for you. Or slides.
Jay: Excellent. All right. Well, we have come to the question time, and I know some people were already putting some things in chat earlier, just making comments and things like that. But this is the fun part too, where we get to see if anybody has any additional questions. So as you type those, I'm going to go ahead and go through our next couple of slides. We would love to have your feedback. We have a BIT.LY for you. It was the one that I tried to give you earlier today. For those that watched that happen as we got started. So let me go ahead and get that link up there. It is B-I-T.L-Y and then in all capital Letters, B-A-D-A-C-M-S. And we do look over those surveys. They're very helpful for us. In our next email out to you, we're going to start doing some polls as well to get some ideas of what you want to see in the next couple of months from the Be a Digital Ally series.
We have ideas on what we think is going to be helpful for everybody, but of course we want to make sure we are meeting the needs of our users and our participants, which is you. So look forward to that in our upcoming emails. When the next video is up and available, we'll make sure to have that poll for you as well.
And with that ... Man, my mouse is just super touchy today. So with that, our next session will be in October. On October 20th, we will be talking about accessibility checkers. So if you're somebody like me and somebody says, "Oh, use this wave Chrome extension to let you know how accessible a website is," and if you're like me, you can kind of glean some information, but maybe you're not sure you're interpreting what you're seeing on the screen correctly. So we'll go over tools like that to let you know what it's actually telling you, how you can use that information, maybe what it's not telling you as well. So we'll go over all of those on October.
Next, we have our Toolkit Tuesday. So for those of you that are in the K12 space or in education space, this is our monthly webinar where we talk about making educational spaces and K12 spaces accessible and inclusive. Our next one will be coming up September 27th. We'll get you that link that will take you to our Humanitix page so you can register. We're really excited about this one. We are featuring one of our presenters from our most recent access ... Excuse me. K12 Access Summit conference that we did. This was our free virtual conference that we did just this past summer. So we're going to revisit the topic, talking about how assistive technology and instructional technology can work together, speak the same language to create those inclusive environments in the classroom and really make sure that all students are benefiting.
So let's take a peak if we've got any other questions. Did we forget to talk about anything, ladies? I feel like we covered so much today.
Erica: And this can feel like a really dense topic because it's so hard to ... Unless you've got your website open and you're looking at your work, it can be hard to think about questions you have. So if people are stewing, no worries.
Jay: And you've always got our emails, events@Knowbility. We're always happy if we need to swing back on some of these topics. That might be a fun thing to do in future Be a Digital Allys as well is go like, "Hey, let's go back and hit some of those questions people had." Thank you.
Erica: The nice thing about using a CMS is that they update. So we could do this topic every year, honestly. I have a little story if there are no questions.
Jay: Oh, go for it.
Erica: This is in the vein of what we were talking about with workarounds and things. People on this call don't know, before I started working at Knowbility, I was a volunteer. And during the same time that I was volunteering, I was competing in our Accessibility Internet Rally, which is happening now actually. And I had had about 10 weeks of HTML and CSS in my user experience program. And I really didn't know much of anything, but I had this fantastic team and one of the guys on my team ... Where was I volunteering? I was just helping with general community programs, helping with our conferences and some of the marketing. And I was actually here in the office. Yeah. I was volunteering at Knowbility before I got started. And we're a nonprofit, so that's okay. I wasn't volunteering at a for-profit business, just to clarify, in case you missed that on the slide. That would be not good.
So there was this guy on my team, and he's brilliant. His name is Derek. At the time, he was working on some of the IT for the Harvard University library system. So really bright guy. And we happened to be using Squarespace, and at the time there was no skip to main content button that you could add. And Derek was able to use something called markdown, which functions similarly to HTML to make our own little skip to main content button. And we were all eating lunch one day around the office and people were asking me how is my team doing and I mentioned this. And everyone was just amazed because this hadn't been done before at all. And I had no clue. To me it was just, "Oh, cool, Derek figured this out." It was a really big deal. And we actually worked with Derek to ... He wrote a wonderful two part blog post for us about the issue we'd run into and what it meant and what it meant to have the skip to main content button available on the site.
And by the time the second installation of the post went up, Squarespace had fixed the issue. So I mean, speaking up really does help. I always joke that we need some really famous musician or actor or someone to start talking about the accessibility of the CMS that their team uses. But I have a feeling that a lot of those folks are not sitting up at 2:00 AM reading Stack Overflow so I'm not sure how much traction that's going to get. But it was really cool to see Squarespace respond and add that feature. And now if you get, I think it's version 7.1 or later, it comes with the skip to main content on every template.
Jay: And I think it's important to remember having those conversations do help make changes. Even with our blog posts that we posted earlier this month, and we put the link in, we talked about one of the developers and they saw the post and they were like, "Oh, hey, by the way, we want to let you know, we've updated some things and we're working on some of these tools." And so it was nice to make sure that they were getting to have part of that conversation too. Well, thank you everyone for joining us. This has been great. Of course, you-
Erica: We had a question.
Jay: Yes. Oh, we do have a question.
Erica: CMS recommendations for mobile accessibility in particular? That's a very good question. I would say that mobile accessibility is based off of the underlying accessibility of the template and CMS in general. If it's built well with good accessibility for the desktop version, pretty frequently that will translate over. The one thing that can happen with sites going from desktop to mobile is we've experienced when we view a site on our computer and then on our phone, the content rearranges. And the key thing is making sure that the content rearranges in a way that makes sense to the user and that they're not, for example, scrolling past a giant image. What most CMS tools have is a way to view the display in both desktop and mobile even when you're working on your desktop. You can find an option. And it's different for every CMS. They call it different things. But you can view how your page is going to look on mobile as you develop it.
A lot of CMS tools also have editing in mobile format. So that means that if you go into that viewer and you don't like the way that two objects are positioned relative to one another, you could edit directly in that format and switch them. So I would say the best practice is one, look for a CMS that's putting out good content in general, and then two, look for a way to edit the mobile version. And that's a good point from both Bowton and Melissa. Responsive design is what we call sites that work well when they move from desktop to tablet size to smartphone size. And so Bowton mentioned that accessibility and responsive design are complimentary. They actually work together and support one another. And then if you find a template that says it's responsive, that means it's going to translate well on different size screens.
Jay: Thank you all. Have a wonderful, wonderful rest of your day. And we'll be emailing you all to let you know when this recording is available.