A tech tip from v c three. Free public Wi Fi may be convenient, but it's also risky. Hackers can intercept your data or trick you into connecting to fake networks that look legitimate. This can expose your emails, sensitive and confidential data, and even login credentials to hackers. If you find yourself at an airport, coffee shop, hotel, or other place with public wifi, keep the following in mind. Avoid using public Wi Fi for work whenever possible. If you must connect, use a VPN to encrypt your data or use a personal hotspot for a more secure connection. Be cautious of pop ups asking for login information. Never access sensitive systems such as financial or HR platforms on unsecured networks a little extra caution while traveling or working remotely can go a long way toward protecting your municipality's data This tech tip from VC three. From the North Carolina League Of Municipalities, this is Municipal Equation, a podcast about cities and towns. Hello, and welcome to another episode of Municipal Equation, the podcast of the NC League of Municipalities. My name is Ben Brown. And off the top, I wanna remind everybody that a few days from now, on 09/03/2026, we'll have another important webinar on ADA requirements with regard to local government websites. This is something we've been doing a lot of communication about because there are important requirements and deadlines for compliance. So on 09/03/2026, we'll have the next in a series of webinars and information dispatches that we've been putting out there with our preferred partner, VC three, about getting local government websites into compliance in time for the federal deadlines. Again, this is federal. So you recall an episode we did in the podcast a few months ago on the subject, kind of an overture of what we're talking about and why. What does it mean to provide an accessible digital experience, for persons with disabilities? What does an ADA compliant website look like? What kind of strategy can we adopt to get there? How is it maintained? All of that. So in recent newsletters, we've highlighted another webinar that we have coming up with VC three on this important subject, again, 09/03/2026. That webinar is titled developing and implementing an ongoing web accessibility plan. And the point of this upcoming webinar is to emphasize that ex accessibility isn't just a one time change or a one off project. It's a behavior. It takes an ongoing commitment over time. It's just gonna be the way that we do things, and it'll be more natural to incorporate. But there's a lot to know. So the webinar is gonna cover key components of an effective accessibility strategy, roles and responsibilities, ongoing mentoring and practical steps to help your municipality maintain compliance, and provide an accessible digital experience for all residents. So the registration link was in our league letter this week. That's a weekly newsletter we put out there. It's also in our need to know newsletter and it's on our website nclm.org. You'll find it in the events calendar for September 3. Again just go to nclm.org, check the events calendar September 3. What we're gonna do in this episode is play a different webinar that we just did with VC3 on the subject of accessible websites in local government, specifically, how to test your website for accessibility. How do you know how close your website is to compliance? Where is it out of compliance? What do you do or need to do to update the website as such? So this is a webinar we just did. You'll get to see it or listen to it today here on Municipal Equation. I'm gonna kick it over to my colleague Olga Melanson and we'll get that

you. Thank you, Olga. And thanks for the folks attending. You know, this is a fourth part of a series where we're focused on ADA compliance, so it's a very timely and important topic. So, thank you for being here. Today, we're gonna focus on how to test for web accessibility. In the previous session we did a few weeks ago, we talked specifically about documents. Prior to that, we talked about, overarching concepts around accessibility, so we're getting more specific as we go. It's a little bit be a little bit under the hood. We want you guys to be armed with the tools. So, hopefully, it's just enough for you guys, but not too much at the same time. But yeah. So we'll we'll get started. I don't assume that anyone's here has been through part of the the other three parts of the series. So I just wanna restate very quickly why we're here and what this role means, and then we'll get into the specific testing. Alright. So why does this matter now? Well, here we are in 2026. Some of these statistics, may be familiar with you if you've been in a previous session, but one in four adults, US adults in the in The United States live with some form of a disability. Ninety four percent, ninety four percent of municipal websites have detectable accessibility issues, and this is based on a third party analysis. And some common things we see, eighty one percent of websites have low contrast issues. That's usually the most common thing. We're gonna specifically talk about how you find these issues, and how you can resolve them as well. Okay. So a little bit about the DOJ rule. It is the new federal standard. It was released in 2024, but the deadlines, and I'll mention those in a bit, are depending on the population. So I'll I'll speak to those in a bit. Documents are included. So when we think about your website, we're gonna focus mainly on web content since we already did a series on documents. But I want everybody to understand just because you have stuff in a document doesn't, doesn't remove compliance guidelines if it meets certain conditions. And so, just just to FYI there. Okay. Here are the deadlines. Please screenshot this page if you, if you don't know these dates. Put it on your calendar. If your population is 50,000 or more and you're a local government entity, you have until 04/26/2027 to make your website compliant. Special districts and under 20 50,000, 04/26/2028. I restate these deadlines in every series because I want everybody to be mindful. So keep keep these deadlines in mind. You're not gonna get someone from the federal department of justice knocking on your door on 04/27/2027 or 04/27/2028. What's probably likely to happen is if a citizen feels, that they are unable to navigate your website because of an accessibility condition, they may simply let you know, or they may decide to file a complaint, a lawsuit, in reference that you should have had this done by now, which is what these deadlines are for. So not to not to bring fear to anyone. We're trying to protect you and make sure that you are prepared for these dates. So keep those dates in your mind. Okay. So when we talk about accessibility, it's built on four principles. If you've been in a series of a previous webinar, you've heard the word poor. But these are the key concepts. Your website needs to be perceivable, to folks that have some kind of conditions such as, let's say, vision impairment. So they need to be able to understand the content even though they can't see the page. It needs to be operable, which means you can navigate the website with only a mouse. It needs to be understandable and predictable, and I'll explain what that means in a bit. But it needs to read clearly, predictably. We kinda take for granted things that we can see, changing as we interact with the web page. If we can't see the change, then assistive technologies, assist screen readers need to announce the change. And it needs to be robust. There's a lot of tools out there that you may or may not use. Screen readers are a great tool, really easy to use. I'll actually show you an example of how to, experience your website as a screen reader would do reading it to you here in a bit. Okay. So nearly everything counts, but keep in mind there are some limited exceptions. I state this not to give you a crutch to lean on, to say, well, we don't have to worry about that content. It's really so you can help prioritize what's important. And there are some exclusions. So the exceptions are, if you have our catalog of content such as old council minutes on your website in PDF form, as long as you move those preexisting documents into a dedicated archive area of your website is and they're not used, let's say, to apply for a government service, then technically, there there's an exception an exemption rule for those. I went over this in detail in previous converse or previous sessions. So if you're really curious on what those exclusion rules are, please go back to that, presentation or content because, there are things that you should probably prioritize that aren't exclusions or excluded, ahead of some of these exclusions. So just be mindful of that. So what's on your website, whether it be forms, content posted from vendors that you're paying for this utility billing is included. Documents that you publish, including PDFs, if they don't meet these exemption rules, have to be addressed. So just be mindful, there are exemption rules that we've discussed in previous sessions. Okay. So we're gonna talk about how you can find issues. And this is where, we're gonna do some demos. We're gonna talk about some tools that are out there that will help you navigate. We're not gonna go into documents as the previous session was specifically for documents. We're gonna focus mostly on your web pages and your web your web content. So when we think about how do you test, we break it down into four layers. Right? There's automated checks you can do. There's free tools that will scan your website to surface compliance issues. They're a great place to start. That's where I would recommend everybody start. Because it's gonna catch those obvious things or maybe things that aren't obvious, and it's gonna give you a decent amount of feedback of some of the things that automation can check. We always would recommend a manual review. There's things that a automated checker can't assess. I'll give you an example. When you're describing an image on your web page, let's say you're describing it, because obviously if someone's blind, the screen readers need to describe the image to someone who's relying on the audio. Whether that description is sufficient is not something automation can check. Automation can check that, yeah, it's not there or it is there or maybe it's only a couple words or not. But to check the accuracy of the description takes a human. Okay? And so there are things that you need to check manually, such as maybe keyboard navigation. Right? So keep in mind layer two. Layer three, I think this is really important. There are assistive technology tools such as screen readers that you've probably never had to use. We would highly recommend, reading the like, using a screen reader just to read the page to you as if you were blind. It'll expose not only the experience people have to go through when they're relying on screen readers, but it'll also probably surface some issues that you probably wouldn't have been able to tell unless you had these screen readers. And lastly, and we understand that every, local government entity, does like may not have resources or access to to people that have actual disabilities to do testing. But it's something that we would recommend, even for ourselves, is, if you have someone in your community, maybe someone on your staff, that's willing to help you on this journey to achieve ADA compliance, they're a great person to lean on. And so, obviously, layer four, you know, may not be within reach, but it's it's really a good idea to get someone in the shoes, or really to ask someone who may be willing and able to do this, kind of help you on this journey. So just the four layers. We're gonna focus on, really mostly the first three today. You cannot test every web page. You could, but there's not enough time. Okay? We've seen web pages that have thousands of pages, hundreds of documents. So the question is, do I have to scan every single document? Companies do, like us, do compliance checks for clients, for prospects. We ask for a subset of your web pages because it's not feasible to check every page. I like this line. Think about the pattern of what you're saying, not just the page where you found an accessibility issue on. If you fix the pattern, you may be able to resolve a bunch of issues all at once. Okay? So think about the pattern, not the page. So when we're thinking about what should we test, if you're telling me, Kevin, we can't test every single web page, well, I would obviously say pick a couple of your most popular pages. Obviously, the homepage is where a lot of people start. That's a no brainer. You wanna obviously scan your homepage. Maybe the next most popular page on your website is the page people use to, view the council meeting videos in minutes. It's a really good candidate. Right? So think about what your unique pages are, and then those be your candidates. If you have web analytics, if you have, a a tool that tells you these are the most, popular pages on our website, I would definitely look at that. That. You know, sites have, tools like Google Analytics built in and it'll tell you this is the most popular item people are going to. Well, it should definitely be on your list of 10 because obviously a lot of traffic's going there. In the second lane here, when you're building a web page, you're probably not writing, like, HTML. Right? You're probably picking a template or you're saying, hey, add new page. Well, those templates have shared code. And so if you identify a common issue with a template that's, let's say, two columns and looks a certain way, well, you should be able to fix the template once and applies everything tied to the template. A lot of this depends on what your content management system is on your web page. If it's just a bunch of independent pages, then you're not gonna get the benefit of these templates. But I know as we design web pages for clients, we're generally creating templates and then you create a bunch of pages off the template. So, so there again, you're fixing a bunch of issues at once. And And then obviously, anytime you change, especially if you're redesigning your website, if you're introducing something significant, you wanna retest those. And it's a good idea to continuously check pages because obviously your most popular pages are gonna change over time. So general rule of thumb, maybe each month you wanna rescan your top 10 pages again. Right? Just to make sure it's not working off of accessible to not accessible. So, so these are just some tips. It's not a one time test. You should be able to identify some patterns that fix a bunch of issues at once, and so just keep those in your mind. Okay. So I talked a little bit about automation. Just statistics show between a third and a half of your web page issues are gonna be detectable by automated tools. So what this really means is if you want to achieve compliance, it's going to take a human involved. Right? The human needs to be in the loop. Okay? The human can actually, like I mentioned before, can verify whether the alternative text on an image that's describing the image makes sense. Whether the focus order makes sense. Whether the error message helps. Right? So a lot of the automated tools don't catch these things. So don't just say, well, I use the scanner tool and now we're good. Like, you're gonna it's gonna take a human probably to get you to full compliance. And so just keep that in mind. Okay. So we're gonna specifically talk about a tool called Wave. This is a free tool. It is amazing. It's easy to use. It sits right in your web browser, which means it's it's it's just an extension you can install in, Chrome, which is amazing. With this tool, it'll show you issues in context. What that means is, when I run this tool in a bit, you're gonna see the issue and then you're gonna be able to click on the issue and go right to the element on your web page that's not compliant. So it's right there. It creates a little side panel for you to see what's going on. And on the right, you have your web page. On the left, you have this little panel that gives you instructions and results. Since it is an extension in Chrome, if you have certain parts of your web page that the Internet can't see, let's say there's some password protected part of your web page, you can run this extension against those. Keep in mind, You can run this extension against those. Keep in mind, intranets aren't within really within scope of the DOJ ruling. They're more focused on the public content that's not password protected. But if you're striving for accessibility even for other areas of your web page that may be behind the login wall, then you can also use this tool for that. And really it's built for content editors. It's very easy to use, very clear. Once you kinda get some reps on the tool, I think it'll make a lot of sense. Okay. So how does it work? There's two ways to use the tool. The first is you just go to the website, web. That's gonna be wave.webaim.org. And I'm gonna pull that up real time just to show you show it off. Here it is. So, first thing it asks is what what page do you wanna scan? Well, I'm gonna use our v c three kinda demo site for this. We have a demo site with some some content on it. So you just paste in the web page. Now what this does is it's actually running a real time scan and it's giving you some output over here. I'll go specifically into the output in a bit, but I wanted to show you how to use the tool right now. So that's one way to run the tool. Just go to that web site, input your URL that you're looking to scan, and then you get this nice report. Another way to run the tool is to install the Chrome extension. And that's what I have on my computer. So if you've ever installed an extension in Chrome, you can go off and manage extensions, and you can search for WAVE and you'll find it. But, this is the same tool but via a Chrome extension. So I can now just go to the page I want to scan, click on the tool or click on the extension, and it does the scan in the web page. So let's say there was a login in front of this web page, you would log in and then you would run the extension. So that, this tool extension works with that protected page. If you were to put the protected page in the the tool we started with here, it would not be able to, like, connect to that page. So, definitely, the extension is a little bit more a little bit easier to use. So that's how you run the tool. We're gonna talk about how you use the tool now to test for issues, and and go from there. Okay. So let's jump into we're back to the PowerPoint. Okay. So the tool breaks down kinda six different area areas. The errors are the thing to focus on. Obviously those are the failures. Color contrast is detected in the tool. It gives you alerts. It it kind of says, hey. I'm not sure about this content. Maybe this alternative text for the image appears to be a little too concise. And so it'll kind of alert you that you may wanna embellish how you describe this image a bit. It shows some features. It gives you some structural things. And so we're gonna really just talk about these, in the context of the actual issues we're trying to solve and then kinda jump back and forth between the PowerPoint and demo. Okay. So, these are things that I've talked about previously. So every slide that we've talked about, we put it back on the screen. But the next slide is gonna tell you how to tech test for these things. So when we're talking about images on your website, if you've been in previous series, you under hopefully you understand that if the image is on your web page and it has some meaning to it, meaning it's not just a decorative image to make a web page look good, then you need to describe it. And the example I would give you here is something that I experienced when I experienced when I was, driving listening to a book on tape through Audible. Every time that the book was, the physical book had images in the book. So the audio version of the book was always referring to these images. And so it would say, see figure one. That's all it would say. So here I am driving, you know, trying to be safe. Can't have can't have my phone. And I felt really frustrated because I know there's an image, but I actually don't know what's on the image. It didn't describe to me what the image was about. And I'm just like, this is useful. I actually stopped the audio because I'm like, I'm not really understanding what's going on in this book. Well, your web page is the same way. Right? You're gonna have images on your web page. Someone may not be able to see your web page, so they have to rely on the screen reader to read the page. And the screen reader comes to this image, and if there's not a description, it has to describe it to the person just like I was expecting that figure one to be described to me listening to a book on tape. And so if the figure one description was just images of a chart, that's not helpful to me. I need it to be really clear so I can understand what it means. So these are some tests. Right? You need to describe your images. You try to avoid embedding text in images because that text can't be read because it's a part of the image. Don't rely on images alone. Always pair an image with text so that someone can who has a vision impairment can understand that. Don't repeat things in the captions. So these are just some tips. Let's talk about how to test for images. This is the key part here. You can run automated scans. It is really easy for an automated tool to see there's an image in a web page and to see that it does not have a description. That is a no brainer. Obvious thing. Takes two seconds. Okay? You can also and this is a great, like, way to experience it, is you can use the brow browser to read the page to you. So this is a really good thing. If you were to close your eyes and there's a tool within Edge that will read this page aloud, it will surface things that you've probably never thought about. And just like I was listening to that book on tape, I was like, Oh my goodness, the author didn't describe this image or whoever created this. And I'm like, I probably would have never thought about that unless I actually had to listen to it. So there's a really easy way to read a web page aloud. I'll show that in Edge. And then, another thing to check is, if you don't know if text is embedded in the image or not, if you simply zoom in and the text isn't, like, it's not selectable, if the text size isn't changing, that typically means the text is actually in the image. It's a part of the image, which makes it inaccessible because a screen reader can't read text that's just baked into an image. You have to somehow either remove the text from the image or put the text somewhere in alternative text. So let me show you how to test for these. So I'm gonna go to a test web page that has images on it that's intentionally made not to be accessible. So let me refresh this. And let me give me one second here. Images and alternative text. So to the naked eye, you can't really see the alternative text. Right? And if you think, oh, if I hover over an image and something pops up, then it has alternative text. That hover text you see is not intended for accessibility. That's not the alternative text we're thinking about. That is simply, text that's really not for assistive technology. So it's it's something that you're like, I don't know. Does this image have alt text or not? I can't see it. Well, that's why we rely on these tools. There's two tools two tools you can use. The first is there is a alt text viewer extension in Chrome. I'll mention that because all it does is just show you that what the alternative text is. So it just puts it above the image. So this says and this is a free Chrome extension as well, Gaz. And it's it's just called the image alt text viewer. So here, now I'm able to see that this image doesn't have alternative text. That this does have alternative text, and alternative text is full of a sunflower. This just says sunflower. So an assistive technology will say, oh, this is fine. This has alternative text. But this is not descriptive enough. And this one is actually pretty good. Close-up of a sunflower in a sunflower field. So this shows you, obviously, where your neck and eye may not be able to see this really really quickly that this has alternative text. I'm now gonna use the web, the Chrome extension for wave, and it'll show similar things, but it's actually broader than just alt text. So I'm gonna run this now. Okay. Well, lots going on here. This could look intimidating if you're not familiar with the tool. But let me focus on the things. So it said, hey, Kevin. There's one error. I said, okay. What's that error? I click on it. It takes me right to the element that has the error, and it says, this image is missing alternative text. Perfect. Easy fix, describe the image. So you would go back into your content edit edit editor. You would give a good description of this image. Issue resolved. Okay? There's some other things in here that are worth noting. Let me let me pull up, let me pull up this one. So this one wasn't flagged as an error. It does say photo of a sunflower, but a human, and being, you know, in the field of compliance, I'm thinking that's probably not descriptive enough. If you have a photo on your web page of the mayor cutting a ribbon at the new opening of town hall, then you should describe it as a mayor cutting a ribbon at the opening of new town hall. Like, be as descriptive as you can, but not so verbose that it's a paragraph. Right? If the photo just says town hall, that is not descriptive enough. And these tools aren't gonna catch the fact that town hall is not descriptive enough. It takes a human to realize, oh, we probably should describe this image a little bit better. Okay? So just think about that. Automated tools get you so far. But when it comes to like this meaning that we understand as humans, it's probably it's not gonna catch those things. So there's a human in the loop here. Right? This one says, there's limited alternative text. Obviously, that's what we put there because we're we're simulating this, but Sunflower's not enough. So these automated tools are great. They're not gonna catch everything. Okay? When I was mentioning before, how do you know if text is embedded in an image or not? Well, this is clear to me that this text is in the image because it it the font the way it fits to the image makes sense. But if you zoom in, like I'm zooming in now, you can I can clearly tell that this text well first off, I can't select it with my mouse which means it's a part of the image? The text isn't changing size as everything else on the page is. So obviously, that is another tell. It's not part of the image. Please please avoid posting things on your website that look like this. Okay. This is not meant for web pages. This is meant to be put on a bulletin board somewhere in print form. Okay. So those are just some quick ways to test it. Anytime I see something like this, I immediately say that's not accessible. I would rather take the PDF off the website, take the image off the website, and just put the words on the website. Right? This looks great. It's fashionable, but it's not functional. So those are just some quick tips on how to how to catch some image related issues, using the web tools. Alright. We'll jump back over to the PowerPoint here. Color contrast. So, I don't assume anybody on here with the naked eye can tell me that, oh, this is a 4.5 to one contrast ratio. That's why we have tools and automation. Okay. And so I'll show you through the wave tool, how you can detect that pretty quickly. Usually with the naked eye, I can generally tell there's a contrast issue, but I'm not exactly sure. Is it 4.25 to one or is it 4.72 to one? Right? As a human, we're not expected to know that. But these tools will tell you pretty directly. And a lot of times when we're seeing like contrast issues, it's when you have an image and the text is over the image. You see this a lot where the image has a lot of trend, like a lot of colors and a lot of contrast. And at parts of the image, it's hard it's hard to read the text because the text is white, but now the background the image background behind it is light gray. So it's really hard to see, you know, and I'll tell you what I do. I'll typically just take my mouse and try to highlight it and just figure out what it's saying. But that's obviously not something we want people to have to rely on. And then lastly, when you think about color contrast, if color alone is what you're using to to like say, hey, this field is required, that is not enough. I'll show you how you can simulate color blindness and what people would see who may not be able to tell red from green here as well. So we'll jump out. I'll show you a quick demo and then, and then we'll go from there. So we're gonna show three areas here. How to just check for your color contrast issues. I'm gonna show you how you can gray scale the page a bit to experience what it would look like if you had a color blind condition. And, and then we'll go from there. So I'm a jump out. I'm a jump back over to our little demo site here and refresh the page. Sorry. Got zoomed in quite a bit there. Alright. So color contrast. So, this is a demo page. So we've we're kinda telling you what's wrong, but and then I'll use the scanner. So these three top these four top areas have insufficient color contrast as you can expect. They're kinda hard to read. You know, as someone without a vision impairment, I'll try to highlight it, make the text white so I can see. But I don't know off the top of my head that this is a 1.21. But keep in mind the rule, the the specification is 4.5 to one is the goal. The the minimum should be 4.5 to one. So these are good. There's sufficient color contrast. So let's let's show you how you can test for this. So I'm gonna once again use the wave tool, which is here. And it has told me that there's four color contrast issues, which makes sense because we put four issues on the page. So it says, this is an issue. Very low contrast. This is an issue. This is an issue. And this is an issue. Easy. Easy peasy. So, it's part of that tool. So, very very easy to see that there's there's an issue here. If you want to, address conditions like color blindness, then there are extensions you can test for that or basically kinda simulate what the page would look like if you had a color blind condition. I have another extension here called color blindly. And what this does is there's various forms of color blindness. This one here is the one I like to demo because it kinda shows you what some people experience when they go to your web page. You know, I said this in a previous session, but people assume people can see red, yellow, and green because that's how traffic lights. You know, how can color blind people drive? Well, to them, it's not the color that matters, it's the position. Right? The top light means stop. The yellow the yellow the middle light means slow down, and the bottom light means go. Right? Or drive. And so, keep that in your mind as you navigate these color contrast issues. This is what your web page looks like to some people. Okay? And so, if you have a form and all it says is require fields are in red, well, I may not be able to tell red because I'm color blind. So you it's not just the contrast. It's actually if you're using color to drive some kind of action or meaning, you could have an issue. There should be more than color. So instead of saying required fields are in red, you should put an asterisk. Maybe the asterisk denotes the required fields. And still it's still okay to make red, but red shouldn't be the only thing to telling you what the, required fields are. So this is a really cool tool to do it. I usually start with wave. Honestly, wave gives you a really good, color contrast output. And then I also like to just experience the web page for color blindness as well. So those are some those are some easy tools you can use just to detect color contrast. I'll refresh that page too. Alright. So let's talk about headings. So when we're thinking about headings, structure is so important for web pages. And let me let me explain it in the context of a book. So how about these books here. Right? And if I've read half the book, I may want to start with the table of contents to figure out where I left off. Right? I may start in the table of contents and realize, okay, the accessibility part is on page 55. Right? So if you are As as a human, we use the table of contents all the time. Right? To skip content, to kinda get to the right area. In a web page with screen readers, screen readers do the same thing. They'll present somewhat of a structure, table of contents to the person who's relying on it. So that the person can tell the screen reader, okay, I'm interested now in the, you know, whatever part of the web page, you know, that that they wanna jump to. If that makes sense. So headings are the way we do this in in in the HTML world. And I'm gonna show you how to test the structure right now. So I'm gonna go out of this, back to the page, and I'm going I'll I'll just use the same page. I can see there's a structure to this page visually. It it appears that this is like a header. Right? And these are sub headers. Right? So this would be level one. This would be level two. So if you're building a table of contents, you might wanna just jump to level two. Yeah. You might wanna jump to this. Right? So we need to give the people that rely on the assistive technologies more than just scrolling. Alright? They can't see it. So you need to give them a table of contents, which is where the structure's important. How do you test that? Well, Well, you gotta use WAVE again. So I'm gonna use the WAVE tool right here. There is a structure category. This shows you what the table of contents looks like for this web page. It tells you that, color contrast is header one. Insufficient color contrast is header two. And then we chose to have some sub headers down here for these. This is so important. Okay? And I can't stress that enough. If you have a condition where you are not able to see the web page, you need to have a structure to navigate. The the screen readers will read to you the structure, so you can choose to jump down to the bottom section. The screen readers will read to you the structure, including the navigation, so you can skip the navigation if you've already heard it before. And so if you don't have a good structure, your web page is really hard to navigate, for somebody who is visually impaired. So you really need to check that you have the right structure. This is a really easy way to do it. This doesn't have any structural issues. But I'll tell you what some structural issues could be. Let's say you skipped header two and so you went straight from header one to header three. Well, that confuses the heck out of the screen reader because it's confused. It's like where's level two now? It doesn't really understand. You should never skip the order. Okay? Because then you end up with a table of contents that doesn't really make sense. So as I'm looking at the structure, I'm thinking about, does this make sense for somebody who's trying to navigate this web page via screen reader? Is this clear? Have we done the navigation in a way that people can skip it so they don't hear it every single web page? Because if you declare your navigation and your structure, the screen reader will allow the person to skip the navigation that they've already heard before. And so, it's really, really important. This is a very easy way to just make sure your web page has structure. If this is empty or it doesn't make sense to be the table of contents for your web page, then you should probably go in your web editor and actually define a structure. And when I say structure, I don't mean, well, to make it header one, I'm gonna bold it and make it orange. That is not a structure. That is a color and a bolding. Right? To make it header one so that it shows up in your structure, you actually have to declare it as header one. And And typically within your content editor on your website, you can just choose header one. Just like in Word, you can say this is level one. So it's not you coding it, it's just you instructing the the like through the editor that you're probably not, like I say, writing code on your web page to to do that. If there are developers on this call, you can obviously inspect the element and see what the header is. This is a little too technical probably for this audience, but if you're a developer and wanted to mention this, you can always look at the source code and say, okay, that's an h one. That's what we're talking about. That little h one right there tells it that it needs to be able to table of contents at level one. And you typically don't have to code that. You just have to select it when you're adding this to the web page. So pretty easy to detect. Pretty easy to fix. But having the ability to test it, this is a great tool to do that. Okay. So moving on here. And I know we have a limited time, so just wanna make sure I hit all the content. There's a lot to this slide deck too that, I put here for your reference purpose. So, you know, you'll you'll have the PDF available to you for some fireside read. So couple couple tips here. Use the WAV structure view to kinda see what the table of contents looks like. Strip away the content and I think about the headers. Does it make sense? Right? Like if you're writing the table of contents for a book, is it clear what's on chapter four? Right? Is it clear enough what it's about? Right? So just think about it. If you take away the text and just rely on the structure, does the table of contents make sense or not? Right? And then, I love using the screen readers. There's a really easy way to have the web page read to you using Microsoft Edge, Microsoft's web browser. So, if you're using a Windows device or not, I think Edge is still available. You can go into Microsoft Edge, and this is hard to demo unless I'm doing a live demo because, it's hard to get the audio to play through a Zoom meeting. But ultimately, in Microsoft Edge, there is a tool that will read the web page aloud to you. It's kinda tucked away a bit. So under more tools, re allow. That will read you the web page and I would encourage you if you've never done that, go to your home page, close your eyes or look away, and have this tool read it to you, and see if it makes sense. See if and just experience it. Like, just figure like, if you're somebody who has like, put yourself in their shoes. Right? And see if it makes sense the way it's describing the web page. Is there structure? Is it reading links correctly? And so that's an easy way to do it. You don't need to go download. There's a bunch of tools out there. Official screen readers. This is just a simple, easy, free way to do it built right in the Microsoft Edge. I would encourage you to do that. It will it will probably enlighten you to see what it feels like to actually rely on these screen readers. Okay. So we'll keep we'll keep moving along here. So the next thing we'll talk about is tables. And we see a lot of web pages that have tables in it. The key concepts here are tables are fine. I mean, there's nothing wrong with a table on a web page just like, you know, what you would expect in an Excel. You have a table header and you have roles. Rows. The only issue with tables that we see a lot is the header row isn't really a header. And as what I mean is, it may not have a header at all, which is an issue, or the header isn't declared as a header row. Let me show you what that means. So you can go into, let me go back to that web page and show you a table that's not a proper table. So when I go into, let's see. I think it's under content layout here. Nope. Sorry. This is actually a good one. So this appears to be a two column, two row table. You could argue that, yeah, I don't see any problem with this. This isn't really a table. This is content that just happens to be in table cells. So it has no table header. It's really just used to lay out the page. So this is a problem. And it's a problem because it doesn't need to be a table if you're trying to build something like this. And the only reason you use a table is to get these blocks these boxes to line up. Right? So a more appropriate use of a table let me pull up one here. Duh duh duh duh. I think I have it under here. So this is a table that doesn't have a header, which is a problem. This is a table with a header. How do you know it's a header? Well, it looks different. So you say, well, that's gotta be a header. It doesn't necessarily have to be a header. This could just be a table row that's has a blue background and white text. Right? So how do you determine that this is an issue? Now the question would be, is Wave gonna check and identify that table header as an issue? Let's take a look. Let's see here. So it tells you that a a layout table is present. It didn't specifically say, I'm suspicious that this there's something wrong with this table. But it kind of references that, hey, this appears to be a layout table, which means it's only used to structure, like, how it looks. It's not really, really a table. These down here are good to go because it's not reporting this as a layout table. So there are some tools that you can use out of the box to kind of assess, is this a real table or not? But keep in mind, there's a human in the loop for this. And so don't rely solely on the automated tools. Use your judgment. Mind just say, hey, I don't think I need a table for this. It's gonna confuse the heck out of a screen reader. Let me tell you why the screen readers and table desks are important. When the screen readers read this table, it's going to say it with a proper table, knowing that this is the header, it's going to read the header first and then the value to someone relying on it. So it says department, city administration. Description, oversees daily operations. Contact, contact email. Next row, department, public works. Description, manage a street. It connects the row, the cell, to the header, and that's so important for screen readers and people who need that technology to connect the dots. Else, it's just gonna read left to right, and you're not gonna know when the first one starts and the second one ends. Right? And so that's why headers are so so important, for the developers on the call if you care. You know, t h means table header. That's how it's coded on the back end. T r is table row. So if I see a t h, you're good to go. Screen readers understand that. I know most of y'all aren't probably writing t h, but that's how it's done on the back end. And so you'll probably just need to declare your headers correctly, make sure it's just not a layout table, you're good to go. Nothing wrong with tables as long as they're intentionally used, not just used for layout purposes. Okay. So use Edge to identify the tables or layout tables. Can we excuse me, wave. Use Microsoft Edge. If I were to read that bad table aloud, I would probably be able to hear the fact that it's not reading the headers, so there's no header at all. Right? So each cell should announce its row and column header before the value. And then there's other things that you should do, like styling of the table is important. You know, if you can zoom in, zoom out. So I'll give you some checks on how how to test that here in a bit. But layout tables are kinda dangerous. I would recommend not using tables just for structure purposes. Use them for things that actually are tables. That's kinda the rule of thumb there. Oh, I love links. Let's talk about links. So, click your links are bad, because they don't really have meaning to someone relying on it. When I say click your links are bad. If I go to a web page and the link says click here, and that's the link, and the rest of the link says to view the latest building permit, but the to view the latest building permit isn't clickable. The only clickable part of the link is click here. That's an issue. And let me describe it in a way that hopefully makes sense. Links on your website are like doors in a room. Okay? So if you're standing in a room and there's five doors, and those doors take you places. Right? Well, the question is, if I open door one, where am I going? So hopefully there's something on the door that says, this is the bathroom. This is how you exit the building. This is the edge of the cliff. So you know when you open that door where you're going. If each one of those doors didn't have a description and it just said, click here, Door one. Click here. Door two. Click here. Door three. Then the person opens the door, have no idea that they're about to fall off a cliff. So whenever you have a click here link on your website, there's an issue. It's a door without a indication of where you're headed. Because the screen readers basically say, here's the links on the page. Click here, click here, click here, or click here. Which one would you like to click? That's the issue with click here links. Okay? Really easy to identify with your naked eye. Right? Let's go to a page that has some really bad links and show you how to test this. So I'm gonna go to, this page that has an some intentionally bad links. This is a bad link. It just says click here. This is actually a good link. It tells you actually where you're going. Right? So So the question is, is the wave tool gonna detect this, or is this just something that, you have to catch with your own eye? Look at that. It has determined there's some suspicious link text here. That's perfect. So it's smart enough. There's some meaning to it. And that's why these tools are built. It says, I'm suspect that this link isn't described properly. You might wanna add some extra text so people know where you're headed. Really easy to do. And and that's all you do. Now, obviously, you can look at the page and see it, but it's good to have this tool help you out. Let's look at some other things on this page that might be useful here. Let's see if we have any other issues. Okay. It's caught a few issues here. Redundant links. This is a good one. So what this is saying is now you have a label on the door, but they all say the same thing. Download form, download form, download form. Just like those click here labels. Right? So you think you're being intentional by saying download form, but the question is what form am I downloading? I'm not sure where this is going. Right? And so just be explicit. Now there's one exception to this rule. Let's say you have a table. Right? And you have a table that says the header row says, variance form. And the row says, download form. So I mentioned how I was talking about structure of tables. It's gonna read the header row and then read the value. So it's gonna say, download various form, and then it's gonna say there's a link. Next, it's gonna say there's a link to download the form. So you kinda know that what the link's going. It's going to download the variance form. I would still try to be somewhat explicit, you know, at the point of the current specification, as long as the header row is descriptive, the link can be somewhat generic. But I would just on the side of caution. Just just call it what it is. Download variance form. Download site plan. That way you're compliant. If these rules change, you know, I'm sure the DOJ is gonna keep updating the rules and they're gonna get more specific. You know, just just assume that you should just describe the link and just be clear. Right? So there's there's some common tips. Links are really easy to catch, you know, with the naked eye, but you just wanna kinda think through that. Okay. Jumping back over to the PowerPoint here. Let me go here. Sorry. So look for duplicates. Some Some of those tools will catch some things like that. But obviously, you use your intuition and use your own brain to make sure that those links are that make sense. Okay. So, when we talk about list, you know, you have links on your web page, you have a table. Just be really explicit that when you're building a bulleted list on your website, you know, you have bullets, don't fake it out by tabbing over, putting some spaces, and putting a little dash. Like, it should be an actual list. So the same way in, Microsoft Word where you can say that, you know, you just choose the bullet and it moves over and it gets a dot. You could fake that out by space space space space space and putting a dash and then putting it. That is not a list. That's some spaces and a dash. And so when you think about that, just be really mindful that you should just be using the native elements. The way that the second part is really interesting. When the screen readers realize that there's a bulleted list, it's going to announce that there's a list with five items. Item one, a, item two, b, item three, c. So it's instructing the user that there's a list in the page. If you didn't construct it as a list, it's basically just gonna read each item. There's no count. It doesn't tell you how many items are on the list. So that's why it's so important. Right? And if you faked it out with spaces, the screen readers just get really silent. Right? They just pause for a bit. And they'll actually read a dash and say it's a dash. That's unnecessary. Right? One rule of thumb that we would use is try to avoid nesting things too much. We can visually see that there's a bullet and a sub bullet and a sub bullet and a sub bullet. That gets really confusing to the screen readers Because now you've introduced this whole like complex structure and depth to your levels. So just keep it simple. Okay? We would recommend no more than two levels of depth. Right? I mean that's that's generally, a good thing. So how do you test this? I love the read aloud feature. Just have it read that page to you. When you get to that list, if it doesn't read it as a list, you probably need to go back and make it a list. If there's some weird things in how it's describing it, then you just fix it. Right? So just keep that in mind. Okay. Forms. This is one of the areas we see a lot of issues on web pages. Right? You have a form that has a field on it that doesn't have a proper label. There's issues where the indication that it's required is only colors. Right? And the probably the most common things that we see is forms that don't actually have labels. And let me explain how that looks. Let me see if I have a form I can show you here. So let me go to this. One second. I've got a couple demo examples here. Alright. I'm gonna pull up one here. Alright. So the oh, there's a video plan. That's another ADA issue there. So I'm gonna go there. Okay. So this is a pretty bad web, page. The first thing I noticed is that there's only a color indication here. That's that's the biggest issue with this page. Is this telling you fields are in red, but guess what? When you use color blindly and you say, alright. I'm gonna simulate this, and there's no red to be mindful of. Right? So that's the biggest issue. The second issue we see a lot is, you see how this says full legal name? And as soon as you start typing into it, that kind of placeholder text goes away. This has a proper field, around it that says this field is for applicant name. That is so important that you connect the label to the field. Because if you're relying on assistive technology or screen reader, it needs to describe every element on the page, and it needs to tell you that this is, a field that doesn't have a label. Let's let's run this through Wade and see if it, see what we get back. This has a lot of errors on it. But as expected. So there's all kinda issues. It'll tell you when you have fields that are missing a form label. There is a very specific way that you have to connect the field to the element. So just to FYI, it will catch it in the tool. Use your own I mean, it's great to run the tool. But when I'm looking at a form, just make sure the label is not just in the field itself because that stuff goes away and it's connected to the field. So keep in mind, forms are a common area where we see a lot of issues because the labels are just not connected to the actual field. Video and automation. So, captions, transcripts. So we're talking kinda about, you know, that that area here. So here's a here's here's some cool ways to test it. Right? So turn off the audio on your computer and slowly watch the video with captions. And you need to make sure that that forces you to make sure the captions are accurate because a lot of times these auto captions after the fact aren't accurate. Does it make sense to just rely on the captions? So simple test. Just turn off your volume. Watch the captions. Make sure they make sense. If you're doing like live council meeting, if you're posting a live video, a live stream of a council meeting, the auto captions are really all you have. Right? And so those auto captions are great. It gives people who are watching it live, who have a condition, the ability to understand what's going on in the moment. If that video is still on your website two weeks later, you should have had an opportunity to review the auto captions and make sure they're accurate. A lot of time, if the audio is not clear in the room, those audio captions start to hallucinate and start saying things that aren't really the words. Right? So you really need to make sure after the fact when you post that video that the captions are accurate. So probably the best way to test that is to watch the video and ensure the auto captions. There's no magical tool that's going to, like, determine that, hey, this person didn't say this and said that. Right? It takes kind of a human in the loop. So just watch the captions and make sure it makes sense. And obviously, just spot check the auto captions after the fact. Okay. We'll talk about embedded midi video. So, you should never autoplay anything on a web page, because if you think about when people who rely on the screen, you just go to your web page, the first thing that happens is the screen reader starts reading the page to you. Right? And so if there's some video that just happens to start, it's now the screen reader competing with the video audio. Okay? So you really just don't want auto autoplay anything on your web page. Don't ever introduce sound. If you can avoid it, let the screen readers do their job. And let the person tell the screen reader to play the video. Then the screen reader stops talking and the video starts. Okay? And so just keep that in mind. How do you test that? Easy way is turn your sound up, go to your web page. If the screen reader is talking over something, you've probably have you have an issue. Right? There is a rule of thumb that says nothing should start more than three seconds without a pause control. Like, nothing should start on its own. I would just say don't start anything automatically. Just respect the screen readers. Give the person the time to actually start the video on their own. You don't necessarily need to autoplay it. And just just it's kinda taboo now. You probably don't go to a lot of web pages that just start playing content. I remember in the early days in Internet, you'd always have that. But either way, here's some tips on how to how to test for that. And these are just some some things I mentioned in previous sessions. So I don't know if anybody's using emojis, but, or any kind of custom icons. You just want to accompany that with text. A lot of these emoji descriptions just don't make sense. And so, screen readers allow you to understand whether these icons make sense, if that's all you have to understand. So once again, screen use screen readers are a great tool. Have the page read aloud to you. Make sure it makes sense. And avoid color, instructions based on any kind of color, shape, or position. Right? Overdue items in red only. That's not compliant. And a lot of the auto checkers aren't gonna catch that because it's you know, you're kind of just just describing some behavior or some rule. And so you really take a human to say, okay. Well, we shouldn't just use red. We should throw an aspect on it. Right? And buttons should be very clear. You know, click the submit button, not the round button. What is round? If you're blind, you don't know. And so, keep that in mind. So how do you test for this? Once again, we're back to screen readers. So screen readers are a great way to hear kinda what those how those icons are described. You know, visual cues. So, use that color blindly extension if you like. That'll show you what the pace looks like in a gray scale if if you need it. And there's some different editors out there as well. Files and documents. You know, just thinking about files and documents. You know, there's a whole session where we talked about files and documents. But I just wanna reiterate a few things as far as, like, when you're have documents in your web page, just make sure the name of the document is representative of what it is. So bad example, final phase two revised of what? I don't really understand what that is. This is the council meeting agenda for March 2026. That's much clearer. So a lot of those same rules around links apply to how you name your documents as well. And then if you can, put the content in the web page. You're gonna have way more tools to run scans on the content in the web page as opposed to having the PDF and trying to use some of the other tools out there that are built into the Adobe to run a scan. So always prefer content on web pages if you can avoid it. Some key tips around documents and PDFs though. If you can't select the text in the PDF, then a computer can't read it. Okay? So quick check is grab your mouse, open up that image and just try to select the words. Just like we were doing with the images that had embedded text and you couldn't select the text in the image, do the same thing with the PDF. If you can't select it, it means it was probably scanned in a way that a computer can't read it. So that's a problem. Right? There's checkers built in to a lot of the accessibility tools like, Microsoft Word and Adobe. You can run checks there as well. I would recommend, if you can get the content in your web page, go ahead and do that. For keyboard and focus, this one's easy. Remove your mouse and just try to tab your way through your web page. So a lot of the screen readers aren't gonna do that level. But when you're tabbing your way through your web page, it's gonna expose some things. Are you going in the correct order as you tab? Field to field to field to field to field. Right? Sometimes the order is so weird. You start halfway down the form and then you wind back up at the menu and then you're lost and you're jumping all around. Right? Is it clear to you as you tab where you're at at all times? So there needs to be focus. There needs to be a blinking cursor, something to tell you you're in the first name field. Right? If you're lost and you're like, where am I right now? Then you have an accessibility problem. It's not clear and you're kinda stuck. You're really not sure where to go. Okay? So these are some of the more manual checks you can do, but it's easy to do. Just tab your way through it and make sure you can submit the form. When I was presenting this with, an individual who was actually blind, they said there's nothing more frustrating than spending fifteen minutes to fill out a form only not to be able to click the submit button. Because something is up with the accessibility where it's not allowing you to do that. So keep that in mind. People get frustrated. It is not where we need to be in 2026. They should be able to submit the form. Especially if it's an important form, like register to vote. Like all these, government services that are provided through forms. If you're a developer, you can expect things yourself. I don't expect a lot of people on this call probably want to get into the code. But, you know, as developers, we're able to kind of see under the covers and make sure that that table header is declared as a table header. A lot of these easy to use tools prevent like, you don't necessarily need to do do that. These are some tips on what to test. Forms, tables, things that pop up like dialogs are are kind of traps. A lot of times, meaning the dialog opens, like a little when pop up window opens, and you can't close it cause there's no close button. Well, I know you typically just mouse out of the dialogue, like the little pop up into somewhere in the background and the thing just closes. But if you're blind, you obviously need a way to close the dialogue. So that's another thing that if you take your mouse away and you have that dialogue pop up and you realize you can't really close it, then you have an accessibility condition. So just think about that. And then like I mentioned, screen readers are great. I would highly recommend if you have an experienced one, use the Edge screen reader. It'll give you some really, really good insights into how your web page sounds to someone. These are just some tips. We talked about color contrast. Here's a good tip. If you zoom in 200%, meaning I'm just gonna refresh this page here. And I'm gonna zoom, zoom, zoom, zoom, zoom, zoom to 200%. This this kinda this this worked out well. Right? It kinda compressed. I don't see any horizontal scrolling. That's really the idea. Right? A lot of times when you zoom in on a in a in a pace that's not accessible, you get scroll bars, things start to get cut off. And those are things you really wanna address. Right? You wanna make sure your web page, will fit not only a 200% zoom, but actually maybe fit on a five inch cell phone. Right? And so, we call that responsive design. You want the web page to respond to the device that is showing it. So, obviously, you should have been like, go to your web page on your phone, see how it feels because that's a really small screen. Right? And zoom in on your browser. See how it looks. Do you have scrolling going on? Does the menu collapse to the hamburger menu, as we call it the hamburger menu. As opposed to the vertical menu here. So just kinda think about stuff like that. Okay. I know we're right at time here. I'm gonna just kinda close out with a few tips. And keep in mind, all of this will be available, to you in the slide deck. So if you have residents or even staff members that are willing to help you on this journey, that's a great thing to do. I realize that's probably not within the reach of a lot of folks or, but, you know, something that we ourselves really strive for is to really hear from the community impacted by these things. And, you know, we're here for the right reasons. And if they're willing to help, we would welcome it. So these are some steps that I talked about in previous meetings. I'll plan to close with this. Accessibility is not a one time project. An accessible website on Monday may not be accessible by Friday because on Wednesday, a PDF was uploaded that, had text embedded in it. Right? So to keep your website compliant, you need to understand the rules, you need to understand how to test it, and you need to keep it at the top of your mind. Like, you always should be thinking about compliance, you should check the pages before you publish them on your website. And if you have new people in in your organization that has the access to edit your website, they need to be trained day one. Or else they're gonna be following probably some some practices that aren't that aren't appropriate for your web page. So training training is so important. An accessibility audit is great. You know, if you're curious now, install the wave wave tool and run it on your web page. You'll see what comes of it. And then you probably wanna do that periodically. Maybe once a month, rerun the tool again. If you've been to just a new page, why don't you just run the tool right then before you publish it? Like, catch it before you publish it. And put an accessibility statement in your footer of your website that shows intentional, a a focus that shows you're aware of that this is a thing, you're trying your hardest. I think, residents who do have issues may be more receptive to the fact that you're trying, may be more constructive conversation with them. Say, hey, just wanted to let you know there's there's one area in your website that's not accessible. I wasn't able to submit this form. Like, that's a different conversation than I'm really upset because you're not even trying. So accessibility statements are a no brainer. And then monitor, train, make sure if you do have compliance that you address those in a timely manner or people tend to want to escalate when you don't. Okay. Some key takeaways. It's not a one time project. It's an ongoing practice. Most of the issues are fixing the content. You probably don't need a developer to fix a lot of your issues. And, when in doubt, just stick to the basics. You know, don't fake out those bullets to to make it look good. Like, actually use normal bullets. So And some takeaways here. Litigation around this area is at an all time high, which means people are filing lawsuits against entities who aren't making their websites compliant. And so, those dates are important that I talked about earlier because there are probably some people just waiting in those states to hit to, compliant. And, these are just some things worth mentioning. I'll put that in the dot slide deck but ultimately I have to kind of cover these, previously. Okay. We are at time. I know that was a lot of content. I apologize we didn't have a dedicated Q and A session. But, ultimately, we will look at any feedback we get if we haven't answered it in the Q and A chat. Hopefully this was helpful. I know this is a journey for a lot of you guys. If you need help, we put our email here. You know, we have a great relationship and partnership with NCLM, so we are here to help. And so feel free to reach out and hopefully this was beneficial for everyone. So thank you everyone.

Thank you for taking the time with us on this episode. And I hope we've answered some of your questions about web accessibility and generated interest in the next webinar on the subject. Again, that's 09/03/2026, and you can find the registration on the events calendar at nclm.org. On the same website, nclm.org, you can send me a direct message. There's a people directory in the navigation area up top, nclm.org. Navigate to the people directory. You can type in my name, Ben Brown, and send me a message. Let me know what questions you have, what's on your mind. You can also recommend episode topics. We love that. This podcast is all about the universe of municipalities, sharing cool ideas, interesting stories, things people not might not know about, that come out of your city hall. Anything fascinating or worth appreciating, I'd love to hear about. We'll see you on the next episode of Municipal Equation. Thanks. I'm Ben Brown.