Digital Accessibility: Thinking Beyond WCAG and Compliance: Chris Scholtens

>> AMBER HINDS: Welcome to WordPress Accessibility Meetup, Digital Accessibility,:Thinking Beyond WCAG and Compliance with Chris Scholtens. Chris is a Product Manager at Enghouse Video. A few announcements before we get started. If you have not been before, we have a Facebook group that you can use to connect between meetups. You can find that if you search WordPress Accessibility on Facebook, or go to facebook.com/groups/wordpress.accessibility. This is a good place to share things that you are working on, ask questions, help other people and answer questions, just a nice community in between meetups. Everyone always asks, is this being recorded? Yes, the meetup is being recorded. It takes us about two weeks to get corrected captions and a full transcript, and have the video edited, and then we will post that up on our website. You can find upcoming events and all of the past recordings if you go to equalizedigital.com/meetup. The other way to get notified when the recording is available is to join our e-mail list. If you join our e-mail list, you’ll get a weekly news roundup from around the web related to digital accessibility. Then we also send out links to the meetup recordings and our podcast.

Meetups will also be posted in audio format on podcast, so you can find them on your podcast player of choice, or you can find them if you go to accessibilitycraft.com. We are seeking additional sponsors for the meetup. This meetup is part of the WordPress meetups program, but the community team did tell us that unfortunately, they cannot help cover the cost of live captioning, or transcription, or any other accessibility services that we want to provide. They said, “Go out and find sponsors.” If anyone is interested in helping to support this meetup and make it accessible for our attendees, we would greatly appreciate it.

You can find information about that on the meetup page on our website, or you can reach us at meetupatequalizeddigital.com. That’s also the best e-mail address to use. If you have any suggestions for the meetup, if you need accommodations to make it work better for you, if you’re interested in speaking, we are looking for some more speakers for 2025 still. Or if there’s a topic that you want to learn about, maybe you’re not the speaker, but you’d like us to find a speaker for that topic, please e-mail meetupatequalizeddigital.com. I’ve been talking for a while, but I haven’t introduced myself.

My name is Amber Hinds. I’m the CEO of Equalize Digital, and my company is the lead organizers of the WordPress Accessibility Meetup. We are a mission-driven organization. We are a corporate member of the International Association of Accessibility Professionals, and we are focused on WordPress accessibility. We make a WordPress plugin, Accessibility Checker. There’s free version of it that you can get right off WordPress.org, and it scans for accessibility problems, provides reports in the post-edit screen to help make building accessible websites easier, and speed up all of your manual accessibility testing.

You can learn more about us at equalizedigital.com, and we’re @EqualizeDigital on many of the different socials. We do have a sponsor for today who I would like to thank, Kinsta is sponsoring our live captions. Kinsta provides managed hosting services for WordPress. It is powering 120,000 business websites worldwide, and based on the user reviews, Kinsta is the highest managed WordPress host on G2, the rating platform G2. It has everything you need, including an unbeatable combination of speed, security and expert support. Powered by Google Cloud and the fastest C3D and C2 servers combined with CDN and edge caching.

Your sites are secured with CloudFlare Enterprise, protecting you from DDoS attacks. All plans include free migrations, and the first month of starter plans is completely free, so you can try the service risk-free. If you want to learn more about Kinsta, please go to Kinsta.com, which is K-I-N-S-T-A.com. Another thing that I ask, kindly, if you are willing, on whatever social media platform you are on, if you can find Kinsta and just send them a quick, “Thank you for sponsoring WordPress Accessibility Meetup,” let them know that having live captions matters, and that we appreciate that.

That helps them to know that I did my job by shouting them out, and also encourages them to want to continue sponsoring in the future. So that is a request that we have for our attendees, if you are willing. Some upcoming events that I want to make sure everyone is aware of. Our next meetup will be on Monday, February 17th at 7:00 PM US Central Time. We will be having an attorney, Richard Hunt, who will be speaking about the law of accessible websites and applications in the United States. So if you’re interested in legal context in the US, then this will be a great meetup to attend. On Thursday, March 6th at 10:00 AM Central, the same time slot, we will be having Picha Neary speaking about captions. Her talk is called We Need to Talk About Captions.

Then on Monday, February 17th, From Concept to Code, Communicating Accessibility in the Design Handoff with Danielle Zaccaro. The other thing that I want to shout out, these are not meetups, they don’t require Zoom registration or attendance, but I have started on any Thursday that there’s not a meetup, so not this week, but all of the other Thursdays, I am doing live accessibility remediation on YouTube and into the Facebook group, since I finally figured out how to make that work. Thursdays at 11:00 AM Central Time, if you go to equalizedigital.com/events, there’s a form you can submit if you want to get an email reminder before those live streams start. Otherwise, you can just watch our YouTube channel.

It’s a good way if you’re trying to figure out, “How do I actually take a website from not being accessible to make it accessible, and I just do an hour every week on a website?” You can track progress over time, and it’s the same website. So I am going to add a spotlight, and I think bring him up here for today’s speaker, Chris Scholtens. Welcome, Chris.

>> CHRIS SCHOLTENS: Thank you.

>> AMBER: Chris is a product manager who is deeply passionate about delivering valuable products to customers. He’s a lover of gadgets, tea, Apple products, board games, old jazz, and blues albums, comic books, accessible products, and delightful UX. We are very excited to have you here to speak.

>> CHRIS: Well, good morning, everyone. I am very excited to be here. Thank you for joining. As an unplanned thing, I wanted to give a special shout out I saw in chat. Brenda who was joining from Madison, Wisconsin. I don’t know Brenda, but I am in Madison, Wisconsin, so a special hello. I’m excited to be here talking about WCAG, and thinking beyond just compliance and digital accessibility. As we said, my name is Chris Scholtens. I’m a director of product management at Enghouse Video. My background is in user experience, design and research before moving over to product management. But I’ve always had a strong passion for accessibility.

Today, well, why are we here? I think the biggest thing is I love to point out over 96% of the world’s top one million webpages are not accessible. That means we have a lot of work to do to help users access the products and services and content that they need to help navigate their lives. Today, we’ll start by looking at the foundations. We can’t go beyond standards and compliance if we don’t understand them and meet them first. Then we will look beyond compliance at some practical examples of going beyond WCAG criteria. We’ll also talk about performative accessibility and what that means.

Next, we’ll talk about accessibility’s broader impact on organizations and companies, and finally, we’ll talk about how to begin. So, what are the foundations of making accessible products and services? Why do we do it, and why do we care? Well, as Steve Krug says, the one argument for accessibility that doesn’t get made nearly often enough is how extraordinarily better it makes some people’s lives. How many opportunities do we have to dramatically improve people’s lives just by doing our job a little bit better? Disability impacts all of us. The World Health Organization estimates that 1.3 billion people experience significant disability. That’s about one in six people.

Now, the categories on the screen right now of disabilities, including cognitive, mobility, auditory, visual, speech and psychological disabilities, these are not an exhaustive list by any means. It’s just representative of the breadth of disability that could impact a user. Because disability impacts all of us, many countries and regions around the world have created legal standards for making various products and services accessible to all users. Now, we can run around trying to make sure that we’re focused on compliance with one legal standard or another, but luckily for all of us, almost all of these legal requirements point back to a version of the WCAG standards, meaning we can focus our efforts there.

Just as a side note, I will be saying WCAG for the acronym W-C-A-G. I know there are different ways that different people might pronounce that, just so you know. Why WCAG? For many of you, this may be a review of information you already know, but the World Wide Web Consortium created a single shared standard for individuals, organizations and governments with testable success criteria that divide into 13 guidelines and 4 organizing principles, perceivable, operable, understandable, and robust. The standards have also been updated over time, allowing us to know that our digital content is accessible to all users. We are currently on version 2.2 of WCAG that was introduced a little over a year ago.

Why isn’t WCAG our end goal? The guidelines are an important baseline, but just meeting them doesn’t ensure the most accessible experience for our users. In fact, being solely focused on that compliance can limit how much we can help our users access our products. So, how do we look beyond compliance? As Ron Kaufman says, “Exceeding expectations is where satisfaction ends and loyalty begins.” In the many conversations I’ve had about accessibility over the years, we often fall short when talking about accessibility, accessible design, accessible development. All too often, accessibility is a checkbox. “Did we hit the standards?” Fly the mission accomplished banner.

Or maybe we only care about accessibility so that we can meet a requirement for sales on an RFP or a tender. Our product is accessible, whatever that means to that customer. Or maybe you hear the common refrain that I’ve heard time and time again. Well, accessibility takes more time and more money, and we will absolutely be talking about that a little bit later. Or maybe you have people building your product that are very well-intentioned, and they’re thinking about accessibility. They’re taking kind of the first steps. Okay, I know my images have alt tags, my color contrast ratios are good. Maybe we’re even using some ARIA elements, but that’s not the end of the story.

Or maybe you’re at an organization that actually cares about the WCAG standards, but all too often they may be focused on making their product or service perceivable and operable, and not giving as much attention to understandable or robust. Of course, users with different disabilities don’t get the same attention. Somebody that has ADHD may have a harder time understanding long form content. Someone with dyslexia may have a harder time perceiving text-based content. The single best thing that you can do is do real world testing with users with disabilities. I’m going to be saying that a lot today.

WCAG is not our end goal, what do we do? Invest in novel ways to improve accessibility. Focus on the difficulties that your users with various disabilities may face, and these can be unearthed through your real world testing. Think about how you can make your content more perceivable, more operable, understandable, and more robust, not just some subset of that. At this point, I’d love to dive into practical examples. I would love to hear or see in chat, what are some ways that you have made your product more accessible in novel ways, or maybe, what are some ways that you’ve seen another product be more accessible to users?

I’ll give people just a minute to type in chat here. [silence] Just adding headings makes a big difference? Absolutely. More white space? Yes, just be joining those two together. Just the way that things are presented visually is extremely important. Drag and drop, bigger font, descriptions to images, increasing target size. All of these are fantastic. I’m going to dive into some practical examples that I have seen, that I have worked on implementing myself, and talk about the good and the bad of them. One common way that I see of making a product more accessible is by introducing themes.

Light mode, dark mode are becoming very, very common, with high contrast, somewhat less common. This allows users to select their preference, which really does improve accessibility and usability. I will note, I keep hearing this myth that dark mode is inherently good for accessibility, because it improves the text readability. That’s not always true. I recommend a true high contrast theme for that specific reason. It has the highest contrast ratios, and is really designed to be the most legible, the most readable for users with visual disabilities. Dyslexia-friendly font options.

There are fonts like Dyslexia or Open Dyslexic that are designed to be more readable for individuals with dyslexia. The letters are given more visual weight at the bottom to help users quickly figure out which letter a given letter is. It helps in recognition. I will say, the research about the effectiveness of these fonts is a bit mixed, and certainly, color can play an important factor as well, but offering users choice can improve accessibility for that individual. The Color ADD language. This is a language of symbols to help identify colors. It allows individuals with visual disabilities to identify and engage in items where color carries informational significance.

That means the specific color of something is important to what it is trying to do. The example on screen here is a Rubik’s Cube. Obviously, if I am a person with color blindness, Rubik’s Cube is going to be very difficult for me. That being said, this Color ADD language is a universal set of symbols that allows me to identify the colors, and be able to engage with a particular piece of information. This is, it comes out of Portugal, but it has been adopted in a number of places around the world. There are Rubik’s Cubes, there are UNO sets. I have seen subway maps even adopting this language to offer an alternative means of conveying the information.

It is certainly a unique tool that is available for offering an alternative means of getting the necessary information across. A while ago someone mentioned to me that QR codes improve accessibility. I had honestly never thought about them in the context of accessibility, but when I did actually think about it, it really can be something to help improve accessibility. If a user has a hard time entering in a long web address, scanning a QR code can save time, or even make a task possible that wasn’t before. But QR codes can also present challenges for users with visual or motor disabilities.

Offering QR codes as an option, not the only way, again, provides a more flexible, accessible solution. For anyone that’s following along, the QR code that is on screen right now does lead directly to the WCAG 2.2 standards. I don’t often hear translation brought up in the context of accessibility, but offering content in a user’s preferred language or their native language does improve usability and accessibility as well. So, we should all rush out and implement all of the things that I’ve just presented today, all of the things from chat, right?

Well, let’s talk about performative accessibility. Kevin DeYoung says,” I try to keep in mind the simple question, am I trying to do good, or am I trying to make myself look good?” What is performative accessibility? It boils down to doing something for how it looks. Did you add a feature to improve accessibility because it helps your users or because it makes you look good and you can pat yourself on the back with a nice article on LinkedIn? It gets back to making sure your foundation is secure first, and then building from there. I will be the first to admit, it can be a difficult tightrope walk.

There’s a reason I mentioned the downsides of some of the previous practical examples, but ultimately, for both the user and the organization, it’s better when things are more accessible. What does doing it right look like? Well, listen to your users, test with real users with disabilities. There is no substitute for that. Make sure your foundation is secure. When you can make it happen, which it can be hard to find time, budget, resources to get buy-in from leadership, et cetera, have your product audited for accessibility compliance by an independent third party.

That gives legitimacy to your claims for your strong foundation, and lets you know you’re ready to invest in novel solutions. At this point, I would hope that this audience is bought into going beyond WCAG. If you’re here at a WordPress meetup on accessibility, you probably didn’t need a whole lot of convincing. This is better for users. But what about the broader picture? What does this mean for your organization? As the Dalai Lama says, “Everything you do has some effect, some impact.” Everyone knows building and developing more accessible products only costs more time and money, right? Well, that’s not always true.

In my earliest days fighting for accessibility, I often got buy-in when I could get it solely to avoid negative consequences. We don’t want to get sued, or we just need it to win a customer deal. When I would try to request time or budget or staff or other resources to improve accessibility beyond that, it was really an uphill battle. In reality, building and developing accessible products and services has positive benefit for organizations. It can drive innovation, it increases market reach, it can foster brand loyalty, and it can create a culture of empathy.

These are the arguments that are going to help make your case when you are requesting resources to do more. But I will say, if you can only get buy-in to improve accessibility to avoid a negative consequence, still take it. It is better than not being given anything to improve accessibility. As an example of accessibility driving innovation, look at closed captions. Closed captions started as a capability for TV viewers with auditory disabilities to watch TV, but they have been widely adopted across many different industries and all uses of video. Even our meetup today is being live-captioned.

I can’t remember the last time I watched a TV show without the captions turned on. Or take a look at late-night TV. Many of the products that you see in infomercials came to life as an accessible alternative. Here in the United States, a really popular example is the Snuggie. It’s a blanket with sleeves. It seems kind of gimmicky and silly until you realize it was designed for wheelchair users, but they’ve become popular with the market in general. So, accessibility design and development is not a time and money sink. It truly improves products and the organizations who make them.

So, now we’re all bought in, and we’ve convinced our leadership to buy-in to improving accessibility beyond just meeting the standards. So, where do we begin? The great Muhammad Ali said, “Even the greatest was once a beginner. Don’t be afraid to take that first step.” Like the old joke says, how do you eat an elephant? One bite at a time. You just have to start. The same is true for accessibility. Hopefully, I can help you avoid some common mistakes along the way. I want to be very clear. No product is ever perfectly accessible. So, make small improvements over time. Don’t wait for your product to be perfect.

There is no magic solution because accessibility is a program of improvement, not a project with a finish line. Last but not least, you can’t do this all on your own. Whether you have a team, or coworkers, or a cohort, or people in meetups like this, someone can help you. Going alone will lead to burnout. Make improvements where you can. Put in the work of designing and developing and testing every step of the way. So, where do we start? Start with others. Can you take advantage of a plug-in or a library? Obviously, our hosts today have a wonderful plug-in for WordPress.

There are plug-ins for WordPress. There are plug-ins and libraries outside of WordPress as well that can help improve your accessibility. I will add the caveat, not all plug-ins are created equal, so please do your research. Make sure your foundation is rock solid. Use automated testing to identify potential issues. Get an audit done. I will say existing digital footprints, if you have a product or service that is already out in the world, can have hundreds, maybe thousands of websites, millions of web pages. That’s why audits use a representative sample.

It’s impossible to manually test every single page, and honestly, it’s not always necessary. That’s why it’s important to build websites on a stable foundation. So, make sure your templates or your design systems, make sure those are accessible. They make creating and auditing your content significantly easier. Lastly, listen to your users. They know when they find something frustrating or unusable. Test with real users with disabilities. I will say it again and again. I know I sound like a broken record, but it is the most important thing you can do.

As a side note, I’m just thinking of this right now. What’s a good aphorism that modernizes the phrase broken record? Because I don’t know that that is universal anymore. [laughs] If and when you do come up with novel solutions, verify and test them with your users, and then come and tell me so I can learn too. I think that that’s self-serving, but I absolutely want to know, what are you doing out there? I want to leave you with this thought. Accessibility is a journey. We have to embrace a spirit of continual improvement, challenging ourselves to do more to serve our users’ needs.

We have to start with empathy and grow through innovation so that we can shape products that genuinely enhance the lives of those we serve. At this point, I’m ready to open it up for our questions.

>> AMBER: Great. Sorry, it always takes me a minute to find myself again. So, I am going to go through questions. If anyone has any questions for Chris, please post them in the Q&A, and I will pass them along. I did want to touch a little bit because there was some conversation in the chat about the tools, recommendations, and plugins, and all of that kind of stuff versus overlays. I think it’s always worth mentioning here if you’re not familiar with an accessibility overlay, those are the things that add the toolbars on the front end that allow users to modify your website.

I always recommend looking at the overlayfactsheet.com to get a lot of information about that. I loved, Chris, how you were saying what’s really important is anytime you put a tool on your website, you have to have users test it. I’m wondering if you want to expand on that a little bit, and why that’s important.

>> CHRIS: I have learned, take my successes where I can get them, and automated testing was how I started with making sure we were compliant and accessible. But you realize pretty quickly into that, not everything can be caught by an automated test, especially if you are not a user with disabilities, you don’t perceive things in the same way. I am not a native screen reader software user, but I have, at this point, many, many, many hours of using screen reader software. I still don’t experience using screen reader software the same way that somebody that uses it natively does.

They experience different pain points than I can identify in automated testing. So, just because of the complete difference in how something is perceived and experienced is between a, I hate this word, but normal user.

>> AMBER: Typical is what I like to use.

>> CHRIS: Typical. Yes, that’s a much better word. Thank you. A typical user and someone with disabilities, you can’t account for that in every automated test. That being said, automated testing is getting better and better, but it’s not a replacement, especially if you’re testing with users of your product or service. They already know it and can identify where they have pain points. That is better than a generic test.

>> AMBER: Yes, and that’s a big thing for us because we went back and forth on this. We’re going to build a testing tool, and how do we have all of our language and all of our reports? We ended up putting this thing that’s like 100% passed test does not mean 100% accessible, because I was like, sometimes people see those scores and they think, “Oh, it’s perfect.” But you’re right, you really do need to include real users of assistive technology. I love that Andy posted a comment in the chat that said, “Accessibility is a journey. If you want to go fast, go alone. If you want to go far, go together,” which is an African proverb.

>> CHRIS: Absolutely.

>> AMBER: I’m going to work through some of the questions that we have here. Jude said, “I’d really love to hear your perspective regarding the European Accessibility Act in 2025, and what should US-based companies be aware of from either a compliance or non-compliance perspective? We’re going to start this off with, you are not an attorney, correct?

>> CHRIS: Absolutely not.

>> AMBER: We’re going to give advice, neither am I, we’re going to give some advice and opinions as web professionals. This is not legal advice, but go ahead.

>> CHRIS: As a non-lawyer, my interpretation of the law is, as far as standards and compliance, it is still referring back to WCAG standards. That’s where our focus should be. The one additional piece is requiring a statement from products that wish to be compliant. That is, in my understanding, a little bit of a minefield right now because each country in the EU can establish their own interpretation of what that needs to be.

I think it’s honestly still a bit of a moving target. But from what we can do, make sure we have our foundations rock solid, that we are fully compliant, and honestly, I recommend when I’m doing consultation, make sure you’re compliant with the WCAG 2.2 standards. I know a lot of things point back to 2.0 or 2.1, but do yourself a favor and do a little bit of future-proofing. That’s where the most effort and the most current research into what actually makes things accessible and usable has been put.

>> AMBER: My understanding is, in many ways, this is going to be like GDPR was for privacy. Even if your business is not located in Europe, if you sell products to customers in Europe or you advertise in Europe, then the law might start applying to you. Even if you are a US-based company, if you have a European market, then you need to pay attention to the European Accessibility Act. The threshold for that is 10 employees or more, or €2 million in turnover, revenue. Adrian said, “You mentioned translation to a person’s preferred language.

Is letting the browser auto-translate to the user’s preferred language acceptable, especially if you have a wide range of international visitors from diverse language backgrounds?” Adrian says, “I think many translation plugins are no better and possibly worse.” Do you have more thoughts on this, translating to different languages?

>> CHRIS: Yes. I will give the classic answer, it depends. [chuckles] Realistically, when I am viewing products or websites from countries or languages that are not my primary language, and they offer an auto-translate, more often than not, it can lead me to being frustrated because it’s close but not quite, and it doesn’t make my experience better. It can actually make it a little bit worse. But if it’s done well, I really appreciate that, and really value it.

From a business perspective, I am much more likely to spend my time and my money on something that I have a good experience with. So, it really depends on the quality of translation that you’re getting out. I agree that many automated translation tools are probably not good enough. The products that I work on, we do defend the need to have a dedicated budget for doing professional translation because we see the most value out of that.

>> AMBER: I’ve had a few customers even here in the United States where they know that they might have large Spanish-speaking or Chinese-speaking populations, particularly in health in certain parts of the country, and they’re typically bringing in a vendor to translate the spoken audio of the video, and then also provide captions and transcripts for the videos in those alternative languages. But with WordPress Accessibility Day videos, we aren’t translating the spoken audio, but we’ve decided to get humans to translate the captions so you could at least read it in your own language if you wanted to, to help support listening, or you could mute maybe. I don’t know if you have thoughts on that, especially from a video perspective.

>> CHRIS: Yes. Working for a video company, I have lots of thoughts on captions, and there are really two different subsets of that real-time transcription, and then on-demand after the fact. What I have found through research is that in real-time, users seem to be a little more willing to accept slightly lower accuracy. That being said, it can’t just be wildly inaccurate. It’s still in the ballpark of accurate. You can understand what is going on. For on-demand or non-real-time captioning, there does seem to be an expectation that this is 95%, 97% accurate.

There are still some tolerance for not being 100% accurate because we understand that, you know, in the day we live in, a lot of things are AI or machine captions. But even humans, when they’re captioning something, still make occasional mistakes. I think, especially when you get into offering caption in multiple languages so that the user can choose, again, what language they would like to engage with, you get more flexibility for what inaccuracy will be accepted during live. But for that kind of after-the-fact, on-demand, you need to be equally accurate in all of the languages that you present.

>> AMBER: Yes. The translation, going back to Adrian’s question, maybe allowing auto-translation via a browser, which means putting nothing on a website, might potentially be sufficient if it’s not your key audience. But, for sure, if it’s a language that is primary or on videos, you definitely want to have accurate transcripts, it sounds like what you’re saying in captions.

>> CHRIS: Yes, and I just saw in chat, someone said– this gets back to my point of needing human testing, I can’t tell you for your specific product without any more information that, yes, an automated translation is or isn’t acceptable to you users. You can try it out, and if it meets their needs in testing, that’s great. It’s probably a significantly lower time and expense to do translation that way, and to improve your usability and your accessibility. But that being said, it might not as well.

>> AMBER: Meryl Evans is here. She’s an accessibility specialist who is also deaf. She had put a couple of comments in the chat as well. This one I thought was interesting. Talking about what you were saying about real-time versus pre-recorded or live versus pre-recorded. She said, “Just one word wrong in a sentence in captions can really throw off a viewer, but it’s also speed versus accuracy for live.” She said that when she is speaking as a deaf speaker, I prefer automatic captions when she’s on a panel or speaking because the speed can sometimes be faster than a live captioner.

>> CHRIS: Yes, absolutely.

>> AMBER: I thought that was interesting to add. I’m going on these by upvote order, just so people know. We had someone ask, “If you were starting to build your website today and wanted it to be accessible as a small business, what would you recommend?” This person said they want to try and get buy-in from smaller clients. Maybe they’re a web developer. Do you have any thoughts on that?

>> CHRIS: Yes. I would say you’re likely not building a website from scratch. You’re probably starting with some sort of template. If you’re a small business, make sure a template that you’re choosing is accessible to start with. That’s going to be the biggest amount of payoff for the smallest amount of investments, basically. Outside of that, just the same thing that I will keep reiterating is, as soon as you have even designs, start putting it in front of users for testing. But, yes, between starting with something that’s known to be accessible and doing testing with users, I think that will get you a long ways towards your goal.

>> AMBER: For the person who asked this, if you look in the Meetup recordings, there’s a talk that Jen Harris gave where she talked about doing it on a budget. One of the things that she said, because she works with a lot of very lower budget micro businesses, and she had shared that she just limits their options. For example, she just tells them, “We don’t put carousels on websites,” because she knows there’s not a good accessible, out-of-the-box accessibility carousel, and it becomes more expensive if she has to go fix whichever one they want to use.

Really like figuring out what, like you were saying, your template and what components you’re willing to use can really reduce costs on building out accessibly, I think. I’d recommend looking for that. I think maybe Paola might be able to find a link. Evan said, “Great talk. You mentioned that no product is ever perfectly accessible. What would you say to prospective clients who come to you asking for guaranteed accessibility or perfect WCAG compliance?” I think that Lelani’s question is a good follow-up on this, which says, “Since it is a process and nothing is fail-proof, how can you defend yourself?” What do you say if someone says they want perfect accessibility or 100% compliance?

>> CHRIS: I’m not a lawyer, so I would not be defending myself in court necessarily, but what I would help equip a lawyer with is showing documentation. My partner works in human resources and she always says, “Did you document it?” That’s a common saying that I hear. “Have you documented it?” “Hey, we had this audit performed.” “Hey, this is how we brought in testers. This is every step that we took to show in good faith that we are trying to be accessible, and if there is a miss or something that is out of compliance, here is how we remediated it, or here is our plan for remediating it.”

That’s the best that we can do, is show good intention, and show a history of behavior of trying to be accessible and meeting up with standards. As I said earlier, you need to make sure that you are in compliance with your standards before you try looking at anything beyond that because of this exact reason.

>> AMBER: I think the other thing that we commonly have conversations with our customers about, I guess when they’re prospective customers, when they ask for this, is we’ll talk a lot about budget and reality of quantities of content, and that perhaps they can’t just rely on us. They might also have to do fixing. Then also there might be times where you make decisions to take content offline. I know that was a big thing that Harvard and MIT, because of the lawsuits related to lack of captions on their open videos, and they ended up deciding, “We’re just gonna take them down because we don’t have the resources, either human or budgetary to caption all of these videos.”

That’s a conversation that we’ll have with customers. It’s very easy for us to ensure that the header, and the footer, and the sidebars, and the main page template components are accessible. But if we’re now talking about eight or nine years of once a week blog posting, right where probably they weren’t doing anything right, that’s a whole different story. I think that’s a big thing that we talk about with them, is setting the right bar on what is realistic and what makes sense. There are exceptions with some of these laws for what they call “archived content”. But a lot of times people think content’s important, and then you look at your Google Analytics, and you’re like, “You know what? Literally, no one has looked at this blog post from five years ago.” No one has looked at it in the last two years. It has had zero hits.

So, would deleting it really be that bad? Probably not. [chuckles] Let’s see, someone said, “How can accessibility SME,” so subject matter expert, “make sure that the accessibility is incorporated as part of in a sprint when there’s lack of recourse?” I’m guessing on a product sprint, if maybe people are pushing back, how can they make sure that it doesn’t just get pushed off and pushed off? Do you have tips?

>> CHRIS: Absolutely. This is my bread and butter because this is what I do. It’s figure out how to fit what is potentially a massive remedial fixing of accessibility issues in already existing products and services into two-week sprints, three-week sprints, whatever your cadence may be. It really is dividing it into bite-sized chunks. “You know what? For these two weeks, we are just going to be making sure all of our images have alt tags, or we are using the appropriate ARIA elements, maybe even smaller than that. Maybe we’re just doing a ARIA role, something very manageable within a two-week period.”

That’s why I stressed, this is little improvements over time. You can’t fix an entire 100,000 webpage site in two weeks. But you can say, “Hey, in two weeks, I can get through the images, or I can get through color contrast ratios,” things like that.

>> AMBER: I like that. We’ve been doing a lot, and Basecamp has a free eBook where they talk about their Shape Up method. We’ve been doing that where we set sprints, and then in between the longer sprints we have what we’re calling cool off periods where we do a lot of bug squashing, which isn’t necessarily accessibility bugs, but just random things, right? I feel like figuring out how to map out your products in that way is very helpful. Like you were saying like, “What are our sprints? What can we fit in?” Just really working on that buy-in like you talked about in the presentation, and making sure everybody understands why it’s important to not ignore those.

I always say too, from a development standpoint, one of the first things I’ll advise if we’re consulting on like a plugin, because we do a lot of audits and consulting on WordPress plugins, is if your GitHub repo or wherever you’re storing your code doesn’t have a label for accessibility, that is the first step. You got to go create that so that you can start labeling your accessibility issues.

>> CHRIS: I do want to give a shout out. Nathan said in chat, “For new features or pages, we include accessibility in the definition of done.” Absolutely. I 100% agree. If you do not do this, you will just end up 6, 12 months down the road repeating this cycle of, “Oh, we’ve got to go fix up our accessibility because we let it slide.” Include it in your definition of done, and don’t let it pass until it’s actually there.

>> AMBER: I love that. Someone said, “Do you have any suggestions for where to source testers with disabilities? Any business or consultants that you can recommend?”

>> CHRIS: There are a number of services out there that will help source testers for you. I would say, honestly, it has been in my experience more beneficial to do testing with users of my product already, and just putting out a call to my community of users to say, “Hey, we’re looking to do some testing with someone who is–” since we do a lot of work with video, “Someone who is blind, someone who is deaf, other visual and audio-disabled people.”

>> AMBER: You’ll just send an email to your email list to see if there’s anyone who is already in your customer base that matches that description?

>> CHRIS: Yes, I try to go inside before going out to somebody, because then in addition to working with the accessibility, I have to orient them to working with our product, and that’s doing general usability testing rather than accessibility testing. I’m trying to keep things focused on accessibility when I can, certainly.

>> AMBER: That’s really smart. If people don’t have them, I will give a quick shout out. We do user testing for a lot of different companies, and we have people who are blind on our team that can do user testing, and access to some other people with disabilities. The other one that I would recommend is Knowbility, which is spelled with a K, K-N-O-W-B-I-L-I-T-Y. They are a nonprofit organization in Austin, and I think Paola just posted the Knowbility.org link in the chat. They also have a program called AccessWorks that can connect you with people with disabilities, and have a pretty big network, so that is also a good resource.

Let’s see. JC said, “Which accessibility practices are good foundations for people getting into HTML? When I teach about web accessibility, students often obsess about perfection. They obsess about using the perfect HTML tag, or adding role attributes to everything, and this makes learning basic HTML overwhelming. I’ve compromised with stressing general semantic HTML and headings, and I’ve hand-waved learning more specific HTML and ARIA roles saying that they can learn more in practice.” Do you have opinions about this?

>> CHRIS: Yes. I absolutely understand why you’ve stressed just general semantic and following appropriate heading levels. It’s going to follow the 80-20 rule. You’re going to get the most bang for your buck by just following semantics. If you are a developer or learning developer who is trying to make sure that you are accessible, and hopefully everyone is, then you should be learning about ARIA, but I agree that it can be after you’ve learned the semantics and fundamental basics. I think you need to be able to put it into real-world practice, or it’s not necessarily real-world practice, practical practice where your ARIA role is shown to have a direct impact on something.

So, run your site through a screen reader just so they hear what that sounds like, and they understand why an ARIA role is important. Not saying you have to know all of the ARIA roles right now, but understand what they are and why they’re important at a basic level, I guess, would be a good starting place.

>> AMBER: I would point students to Mozilla developer documentation. I feel like they have some of the best documentation on ARIA and how to do things from an accessibility perspective. This might be sort of a quick, there’s two questions related to testing. I’m going to answer what I think is the first one first. Godwin asked, “What are some of the tools that are out there that we can use for automated testing? Do you have a few that you like or want to shout out?”

>> CHRIS: Yes. I always recommend the standard panel of NVDA, JAWS, VoiceOver on Apple as your quick sanity checks for automated testing–

>> AMBER: Screen reader.

>> CHRIS: For screen reader, sorry. For automated testing, I currently use a tool called Total Validator. Mostly because it also offers command line interface. I can incorporate that into our CI pipeline. But there are many, many, many different tools out there that will perform the automated testing. That is a good first step.

>> AMBER: I think if someone’s just getting started, a common one that a lot of people use is the WAVE browser extension. Or axe is another browser extension. Of course, we make our accessibility checker if you have a WordPress website for automated testing. There’s a lot of little browser extensions that can do different things that are helpful. Like I have one that helps me find landmark regions on a page. There’s maybe a longer question of, Lily asked a question about what manual testing focuses on? Could you briefly outline things that you look for when you do manual testing?

>> CHRIS: Yes. This very much ties into my background in user research. I always come in very task or workflow-focused. Maybe it’s been a little while or maybe we have changed something or we’re adding a net new capability. We need to test that workflow with our users. For example, one thing that I’m working on right now is adding better support for multiple audio tracks during video playback to allow users to select that. I’m running testing right now with users and basically giving them a script and saying, “Hey, here’s what I would like you to do. Please talk through out loud what you’re thinking and feeling as you’re doing that.”

That’s very much UX research-focused, but I am still able to observe and hear their thoughts about how they feel when they’re doing that specific task. I keep it task or workflow-focused.

>> AMBER: For user testing. You’d say something like find the video on this page and turn on the audio description and then you’d watch them try to accomplish that task and listen to what they see and observe where they get hung up.

>> CHRIS: Yes. I would do that. I would go a step further and say, “Tell me about what you think about this particular piece of content and the audio description,” because I’m also evaluating did our audio description track actually deliver what we needed to deliver when I’m evaluating accessibility? I may ask, “Would you expect this to be available in another language? Or would it have helped you if this was available in another language because I know you are a native Spanish speaker,” or something along those lines.

Trying to approach from multiple angles. Really, the question is, what’s going to make this easiest for you and help you understand the content the best?

>> AMBER: I appreciate that. I think user testing is it’s interesting because you get a lot of different feedback from it, but it probably really is the most authentic. I think as a web professional, I don’t know if you want to provide any other thoughts on just what we could do for manual testing, or I could give a short summary. I think we also have documentation on this in Accessibility Checker. Maybe we could grab the link. Do you want to talk about some things you might look for if you were testing?

>> CHRIS: Yes, I always do a quick sanity check on screen readers, do a quick sanity check on– There are like 14 different specific elements that I check and I’m not going to be able to remember all of them off the top of my head. I am checking some of the basic WCAG criteria. Are my color contrast ratios okay? Are my images alt– Do I have an alt text for my images? Do my videos all have captions? Can I control the playback speed of my videos?

A number of enhancements to make sure that just the basic expectations are being met. I can’t tell you the number of times we roll out a new page. Not roll it out, but we’re working on it and I run it through screen reader. Even at 1x speed rather than some of the speeds that I’ve seen my testers do, I’m like, “Oh, that’s not right. We missed something. Let’s go look at what we missed.” It’s a quick sanity check more than anything.

>> AMBER: You mentioned playback and I think the literal on that is if you didn’t have a mouse, could you still do everything on the website with a keyboard?

>> CHRIS: Keyboard navigation is one of my 14 points that I check.

>> AMBER: It’s almost, I think, surprising sometimes with people that are getting into accessibility or just learning about it in the first hand that you don’t actually have to be an expert to test that. As long as you’ve got a tab key and you know how to push it, [laughs] you can start to figure out, “Can I move around? Can I see where I am on the page?” All of this stuff, which an automated tool can’t really check. Some of them can highlight tab stops, but a person still has to look at it to see if something was missed.

David had an interesting scenario. David said, “Let’s say you have three vendors that supply an online banking platform and two of the three vendors have some understanding of digital accessibility. However, the company is leaning towards the third vendor that does not have an accessibility program but offers all the ‘Cool bells and whistles’ that customers would want. How do you influence the company to select one of the two vendors that have an accessibility program?”

>> CHRIS: Again, it’s going to depend. I have risen in my career to being a director so now I have a little bit more ability to put my thumb on the scale and influence things. If you are earlier in your career or you have a role where you’re not in leadership necessarily, it can be hard to influence that. I think you absolutely should be trying to influence this. That’s one of the reasons why I love to see VPAT documentation from vendors.

If they have even that, it shows that they are thinking about accessibility and it’s going to show the good, the bad and the ugly of where they’re at with all of the criteria. You can use that as your evidence. Again, you don’t always want to use accessibility as avoiding a negative consequence but, “Hey, this banking software that we’re looking at, it’s not very accessible or they’re not showing us that it’s accessible. We’re opening ourselves up to lawsuits. I really think it would be better to go here.”

At the end of the day, the best you can do is let your complaint be lodged. You may not be able to change that decision, but you’ve done everything that you can.

>> AMBER: I think that there are some scenarios where fear works really well and I think the banking industry is an industry where you could convince people with fear because there is a lot of legislation around people with disabilities have to have equal access to their money, full stop, right? I think probably if the decision makers at a bank were not aware of all the laws around banking and accessibility or the court cases that have– Going back even what, 20 years maybe to some of the work Lainey Feingold did with getting headphone jacks added to ATMs.

I think that probably would be where I would start to be honest, which I would just be like what you said. Vendors one and two have clear programs and have put effort in, vendor three is not and look at the laws that apply to our– I think it’s a cost thing too because if you went with vendor three, because you like the quote bells and whistles, that might be possible, but then you might need to add costs to remediate things before you can launch.

Maybe it would be less expensive to go with the other vendors that have already put some effort in. Let’s see, we have about 15 minutes left. Maybe we’ll see what we can do. I think we should be able to wrap through these. Emmy said when accessibility issues– Sorry, hold on one second. I need to read this a little bit. I think this is a little bit related maybe to what we already talked on. How do I get executive buy-in? Do you have anything else to add beyond what we’ve already said about maybe using fear?

>> CHRIS: I would say get any foothold you can, and if you have to do that through fear and saying we don’t want to be sued, take it and run. Hopefully, you can show the benefits in a positive way that, “Hey, this is actually driving innovation. This is creating more customer loyalty. This is showing us as a company or an organization that has empathy,” and that has market value. It can be very hard to translate that into real dollars and cents, and sometimes that’s what you have to do.

Anything that you can do to try to improve, even if you say, “Hey, can you give me $100, $500,” something, you could get an automated testing tool and that will hopefully help make things better. If you can say, “Can you give me some token amount of support to try to do this?” Because it’s not that they don’t want to be accessible. I’ve yet to encounter someone who’s like, “No, I’m opposed to the concept of accessibility.” It’s that they think it’s going to take too much time or too much money that they don’t have. Trying to get some minimum amount from them and then turning that into a success and building from there.

>> AMBER: I like that. I think connecting it to key performance indicators, so KPIs, if the company has that, if you can say this is in support of this KPI, that might be motivational for executives. I think on that same note, there’s a question here about creatives and people often see creative and accessibility as opposites. Do you have any thoughts or responses for that objection? It’s not about budget. It’s not about time. It’s that accessibility limits our creativity.

>> CHRIS: This is kind of striking right to my core as a former UX designer. I will answer honestly. Sometimes creativity should be limited when it comes to product design, website design. Your users are not there because you have a pretty design. Your users are there to accomplish a specific task, to do a certain thing. If they can’t do that because of your pretty design, then you failed. You need to have a functional thing. Something that I reiterate over and over to my teams is content is king.

Why are they there? For the content, not for the design. You should absolutely have design because design can help improve your accessibility. It can help draw attention but having pretty design for pretty design’s sake, when it sacrifices usability and accessibility, no, I don’t think that’s the right answer.

>> AMBER: I could not give a better answer to that than what you just gave. That was great. Nathan has sort of a technical question. I don’t know if you know the answer to this. I don’t. Nathan says, “We’re looking to automate screen reader testing like we would with a unit test. We’ve defined a piece of HTML content that is somewhat complex and we want to ensure that in the future, we don’t accidentally break the way the screen reader reads. Are you aware of any tools to accomplish something like that?”

>> CHRIS: I am not aware. I guess the closest thing I would say is I have seen some work with AI to try to be a more robust automated tester and gets into more things like being able to automate screen reading testing. That being said, I don’t think the capabilities are truly there yet with enough accuracy. I think absolutely have your automated tests, have them run as part of your pipeline because it’s always good to know if you forgot something unintentionally in your development.

There’s always going to be a need for just a quick sanity test. It should be, as we mentioned, part of your definition of done to have your developer run one screen reader test before they’re signing off on their work being complete. It doesn’t have to be, “Hey, we’re going to test with JAWS and NVDA and voiceover on Apple and, and, and.” Just do one as a sanity check.

>> AMBER: I know we’ve done some experimentation with Puppeteer to automate clicks and testing user interaction that way, but I’ve never heard of anyone doing it with a screen reader.

>> CHRIS: I’ve seen some efforts into automating the testing of the keyboard navigability because that is much more objective rather than subjective. Screen readers is very hard because hearing content out loud and comprehending the content and knowing the context of it is not something I’ve seen an automated test do well.

>> AMBER: I’m making something up here, but this is how I’m envisioning that this might work, which is that if you have a component and you know how it’s supposed to sound already with NVDA, you would know this is the exact script that I expect NVDA to read out. If you could code something that renders the component or interacts with the component or whatever that is with, let’s say Puppeteer with NVDA, if you’re able to support that, you could then get the speech viewer the text script of what NVDA read and compare it to the approved script and then flag if it doesn’t match exactly.

I don’t know if there’s a tool that exists for this. Maybe this is a product someone needs to build, [laughs] but that’s how I think you could maybe automate this, but you’d still have to feed it in. This is the exact thing I expect.

>> CHRIS: With large language models, you could build some fuzziness into that. That’s are you close to it? Then it’s probably okay. For an automated test, I still wouldn’t be entirely reliant on it, honestly. Until I’m shown 100% accuracy.

>> AMBER: Many times.

>> CHRIS: I’m a bit skeptical. [chuckles] That being said, absolutely. I think we should be looking into it if there are ways that we can do more automated testing. It’s going to improve accessibility for everyone. I’m fully in support of it. I just am a bit skeptical that we’re there right now. As I said during my slides, if you do come up with it, let me know because I would gladly incorporate that into my own procedures.

>> AMBER: Software product idea for all of our viewers. [laughs] This has been phenomenal. I really appreciate you sticking around and giving so many wonderful answers to all of the questions. Thank you to everyone who submitted great questions and the great conversation in the chat. Chris, where can people follow up with you if they want to get in touch?

>> CHRIS: They can reach out to me. We were talking about this before we really got started. Twitter, I am not on anymore. I am on Threads. You can visit my website, which is just chrisscholtens.com and reach out through there. I am on LinkedIn. A lot of the usual suspects you can find me, certainly.

>> AMBER: Great. Well, thank you so much. Everybody, please come back in two weeks, as long as it’s not the middle of the night for all of our European friends, [laughs] to hear more about Digital Accessibility Law from Richard Hunt. In the meantime, we’ll see you all online. Bye.

>> [01:17:10] [END OF AUDIO]

Download PDF Slides for “Digital Accessibility: Thinking Beyond WCAG and Compliance.”