Thinking Beyond WCAG and Compliance With Chris Scholtens  ## Metadata - Author: [[Accessibility Craft]] - Full Title: Thinking Beyond WCAG and Compliance With Chris Scholtens - Category: #podcasts - URL: https://share.snipd.com/episode/0b58d05f-7f81-4e67-8420-9ff2866709c5 ## Document Notes ## Highlights - **Website Accessibility State** - Over 96% of the top 1 million web pages are not accessible. - There's much work to be done to improve accessibility for users. Transcript: Chris Scholtens I think the biggest thing is I love to point out over 96% of the world's top 1 million web pages are not accessible. ([Time 0:01:44](https://share.snipd.com/snip/94074354-2455-4a34-b71d-a7191961567d)) - **Focus on WCAG** - Disability impacts one in six people globally, encompassing diverse categories. - Countries have legal standards, but most refer to WCAG, offering a unified focus. Transcript: Chris Scholtens 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. ([Time 0:03:09](https://share.snipd.com/snip/42895d89-8aa0-4301-8829-d8e3f0d69441)) - **WCAG as a Baseline** - Meeting WCAG guidelines is a starting point, not the ultimate goal. - Focusing solely on compliance can limit the user experience. Transcript: Chris Scholtens So why isn't WCAG our end goal? Well, the guidelines are an important baseline, but just meeting them doesn't ensure the most accessible experience for our users. ([Time 0:05:12](https://share.snipd.com/snip/0b6a535c-981d-476b-9052-8608ee332e75)) - **Performative Accessibility** - Accessibility is often treated as a checkbox, hindering true user benefit. - Performative accessibility prioritizes appearances over genuine user needs. Transcript: Chris Scholtens 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, you know, people building your product that are very well intentioned, and they're thinking about accessibility. And, you know, 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. And 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. Single best thing that you can do is do real-world testing with users with disabilities. ([Time 0:05:39](https://share.snipd.com/snip/378a9e29-341c-42e9-bbde-ebaaa5c4618b)) - **Invest in Novel Accessibility** - Invest in novel accessibility improvements based on user needs. - Conduct real-world testing with users with disabilities to identify difficulties. Transcript: Chris Scholtens I'm going to be saying that a lot today. So 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. So at this point, I'd love to dive into practical examples. ([Time 0:07:44](https://share.snipd.com/snip/91b04ae4-2404-419f-8eb4-70b7b24ef434)) - **Color ADD Language** - The Color ADD Language uses symbols for color identification. - This helps colorblind individuals engage with color-dependent information, like Rubik's Cubes. Transcript: Chris Scholtens 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. And this 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. ([Time 0:11:17](https://share.snipd.com/snip/b715e631-6d3e-4779-92b2-692da48f77bc)) - **Avoid Performative Accessibility** - Performative accessibility focuses on looking good, not doing good. - Prioritize a secure foundation and genuine user benefit over superficial actions. Transcript: Chris Scholtens 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? Well, 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? Making sure your foundation is secure first and then building from there. And 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. ([Time 0:13:42](https://share.snipd.com/snip/eb2432a4-3e76-487f-8252-e4ea18b9a4b0)) - **Start Small and Iterate** - Start small, make continuous improvements, and don't aim for perfection. - Accessibility is an ongoing journey, not a project with a finish line. Transcript: Chris Scholtens 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. And last but not least, you can't do this all on your own. Whether you have a team or co-workers or a cohort or people in meetups like this, someone can help you. Going alone will lead to burnout. ([Time 0:19:53](https://share.snipd.com/snip/b79bb889-25dc-49e6-9282-9e40e68bc23b)) - **User Testing Over Automated Tools** - Test accessibility tools with real users, as automated tests have limitations. - Chris Scholtens and Amber Hines discuss the importance of user testing for effective accessibility. Transcript: Amber Hines 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 kind of 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. And 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. And I'm wondering if you want to expand on that a little bit and why that's important. Yeah, ([Time 0:23:36](https://share.snipd.com/snip/4040bf14-1204-44ce-a0a5-d64d6799c816)) - **European Accessibility Act** - US companies selling to or advertising in Europe must heed the European Accessibility Act. - Focus on WCAG compliance and prepare an accessibility statement. Transcript: Chris Scholtens Yeah. Amber Hines 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 U.S.-based companies be aware of from either a compliance or noncompliance perspective? We're going to start this off with you are not an attorney, correct? Chris Scholtens Absolutely not. Amber Hines So 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. Yeah. Chris Scholtens So 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 kind of establish their own interpretation of what that needs to be. So 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. ([Time 0:27:12](https://share.snipd.com/snip/a75736e7-bf1d-4013-ba49-dda661f9a417)) - **Document Everything** - Document all accessibility efforts to demonstrate good faith and compliance. - Track audits, user testing, and remediation plans to defend against legal challenges. Transcript: Amber Hines I think. So I'd recommend looking for that. I think maybe Paula 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. And 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? So what do you say if someone says they want perfect accessibility or 100% compliance? Chris Scholtens Well, 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. So my partner works in human resources and she always says, did you document it? You know, that's a common saying that I hear. Have you documented, hey, we had this audit performed? Hey, this is how we brought in testers. This is, you know, every step that we took to show in good faith that we are trying to be accessible. Or something that is out of compliance, here is how we remediated it, or here is our plan for remediating it. You know, and that's, you know, the best that we can do is kind of 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. ([Time 0:38:42](https://share.snipd.com/snip/e40f3d35-d589-4eca-a0d0-dfc628075497)) - **Accessibility in Sprints** - Incorporate accessibility into each sprint, focusing on manageable chunks. - Prioritize small, iterative improvements over attempting to fix everything at once. Transcript: Amber Hines There's lack of recourse? So 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 Scholtens Yeah, 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 kind of fixing of accessibility issues in already existing products and services into two weekweek 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 an ARIA role, you know, something very manageable within a two-week period. And that's why I stressed this is little improvements over time. You can't fix an entire, you know, 100,000 web page 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. You know, things like that. ([Time 0:42:50](https://share.snipd.com/snip/42148efc-f32b-4c20-ac00-10f0b011dbca)) - **Internal User Testing** - Source testers from your existing user base for more relevant feedback. - Internal users offer product familiarity and quicker identification of pain points. Transcript: Amber Hines Yeah, 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 Scholtens 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. Just putting out a call to my community of users to say, hey, we're looking to do some testing with someone who is, you know, since we do a lot of work with video, someone who is blind, someone Who is deaf, you know, other visual and audio disabled people. Amber Hines So 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 Scholtens Yes, I try to go inside before going out to somebody because then in addition to working with the accessibility, I have to kind of orient them to working with our product. And that's doing general usability testing rather than accessibility testing. And I'm trying to focus on accessibility when I can, certainly. ([Time 0:46:04](https://share.snipd.com/snip/ef2791e8-847b-4c5e-abeb-5f370a62e6a7)) - **HTML Accessibility Basics** - Prioritize semantic HTML and heading structure for foundational accessibility. - Introduce ARIA roles after mastering basic HTML to avoid overwhelming learners. Transcript: Amber Hines 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 stressful general semantic HTML, oh, with stressing, sorry, 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? Yes. Chris Scholtens I absolutely understand why you've stressed just general semantic and following kind of 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, you know, a developer or learning developer who is trying to make sure that you are accessible, hopefully everyone is, then you should be learning about ARIA. But I agree that it can be after you've learned kind of the semantics and fundamental basics. I think you need to be able to put it into real world practice, or if not necessarily real world practice, practical practice, where your ARIA role is shown to have a direct impact on, You know, 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. And ([Time 0:48:22](https://share.snipd.com/snip/98a8eb7c-e729-4440-a9c2-b20200a6baa1)) - **Task-Focused Testing** - Focus manual testing on specific user tasks and workflows. - Observe user behavior and gather feedback on their thoughts and feelings. Transcript: Amber Hines You, a question sort of about what manual testing focused on? Could you briefly sort of outline things that you look for when you do manual testing? Yeah. Chris Scholtens So this very much ties into my background in user research. I always come in very task or workflow focused. I say, you know, we really, you know, 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. So 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. So I keep it task or workflow focused. ([Time 0:52:49](https://share.snipd.com/snip/3b75a43e-7831-4cf8-9ad6-d7a2bb81f6c0)) - **Influencing Vendor Selection** - Advocate for accessible vendors by highlighting potential legal risks and long-term costs. - Use VPAT documentation and emphasize the benefits of proactive accessibility measures. Transcript: Amber Hines 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 quote, 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 Scholtens 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. But 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. And I think you absolutely should be trying to influence this. And 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 like, hey, 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. And at the end of the day, the best you can do is let your complaint be lodged. And you may not be able to change that decision. But you've done everything that you can. ([Time 0:58:14](https://share.snipd.com/snip/d9ed6e35-f7c3-456d-abec-91e823785607)) - **Balancing Creativity and Accessibility** - Limit creativity when it hinders usability and accessibility. - Content and functionality should take precedence over purely aesthetic design choices. Transcript: Amber Hines Accessibility as opposites. Do you have any thoughts or responses for that sort of objection? So it's not about budget. It's not about time. It's that accessibility limits our creativity. Chris Scholtens And 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. And if they can't do that because of your pretty design, then you failed. You need to have a functional thing. You know, 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 But having pretty design for pretty design sake, when it sacrifices usability and accessibility? No, I don't think that's the right answer. I ([Time 1:04:03](https://share.snipd.com/snip/3f8166f4-4b10-400f-8e87-ce74e6eb28e7))