Six Levels of A11Y Maturity: Know Where You Are to Know Where You Are Going: Nick Croft

>> AMBER HINDS: Welcome to WordPress Accessibility Meetup. We’re going to talk about six levels of accessibility maturity, knowing where you are to know where you are going, with Nick Croft. A few announcements just to get us started. If you have not been to Meetup before, we do have a Facebook group that you can use to connect in between the meetups. It’s a great place to share what you’re working on, ask questions, help other people with things related to accessibility or WordPress and accessibility. You can find that if you go to Facebook and just search WordPress accessibility, or the actual URL is facebook.com/groups/wordpress.accessibility. Everyone always asks, is this being recorded? Yes, it is being recorded. It takes us about one and a half to two weeks to get corrected captions, edited video, and a full transcript, and then we will publish this up on our website. You can find upcoming events and all of the past recordings in one place if you go to equalizedigital.com/meetup. If you want to get notified when the recording is available, we recommend that you please join our email newsletter. You’ll get invitations to all of the upcoming events. You’ll get notified when this recording is available and links to other important accessibility news and resources from around the web. You can join that if you go to equalizedigital.com/focus-state.

Then the other place where we release this is in audio format because we had a few people asking just for audio, and you can tune in to the audio version. That sometimes takes an extra week or so, but if you go to our podcast website, accessibilitycraft.com. We are always seeking additional sponsors for the meetup. This is part of the official meetup program, but they told me they have no funds to cover the cost of captioning or transcription or any sort of accessibility support services, so they said go out and find sponsors. So if anyone would be interested in sponsoring for your company, please feel free to reach out to us. There’s also information on that meetup page on our website as well about what sponsorship entails and the benefits and costs and all of that.

You can get a hold of us at meetup@equalizedigital.com if you want to learn more about sponsorship or if you have suggestions for the meetup, if you have any ways that we can make it better for you, or if you’re interested in speaking, we’re always looking for speakers. I think we have a few slots towards the end of this year that we are working on trying to get filled. Feel free to email Paola and myself at meetup@equalizedigital.com. Who am I? I am Amber Hinds. I’m the CEO of a company called Equalize Digital, and we are the organizer of the meetup. We are a mission-driven organization and a corporate member of the IAAP that focuses solely on WordPress accessibility.

It’s sort of our baby and what we love to do. We have a plugin called Accessibility Checker that scans WordPress websites for accessibility problems and puts reports right in your admin dashboard, and there’s a totally free version that doesn’t limit the number of pages and posts you can scan. I’ve said our website a lot, so I’m not going to say it again, but if you want to find us on the socials, we are most commonly on Twitter/X, and we’re at Equalize Digital, and we do have a sponsor that I want to thank today, and that is IvyCat. IvyCat is generously covering the cost of our live captions for today.

IvyCat helps clients and agencies create, market, and maintain high-performing WordPress websites and web apps that are fast, easy to use, accessible, and get results. Their website care plans, search engine optimization, and accessibility services help clients grow and succeed without the stress and headaches of doing it alone. If you want to learn more about IvyCat, you can go to Ivy, I-V-Y-C-A-T.com, IvyCat.com. We always encourage people to give a shout-out on social media to our sponsors and thank them for covering the cost of captions. It helps to encourage them to want to continue doing it and to know that I’m doing my job to shout them out.

If you want to thank IvyCat for covering the cost of captions for WordPress Accessibility Meetup, you can do that. They’re on Twitter @ivycatweb. I have three upcoming events that I want to share with you. Our next meetup in June is Monday, June 17th at 7:00 PM US Central Time. It is a accessibility audit. Typically, I do these with Alex, but Alex wasn’t available, and so Raghavendra Satish Peri has offered very kindly to step in. We’re going to be taking a look at the Lifter LMS plugin, doing some live screen reader testing for it. If you’ve never heard a screen reader user interact with a website, I definitely recommend tuning in for that, or if you’re trying to get more experience with testing or just want to see how this plugin stacks up, it’s a great webinar to join.

Then in July, we are making a change. I have this highlighted on the slide. We are going to be on the second Thursday in July, not the first Thursday, because the first Thursday is the 4th of July here in the United States, so we’re taking a holiday, and then we will be back. We don’t typically change for anything, but I decided that was probably a good reason to change in July. We are going to have Gavin Colborne speaking about enhancing university accessibility with real-time web registry services. Specifically, he’s going to talk a lot about how you handle accessibility when you work at a university that might have hundreds or thousands of websites.

This is really going to cover accessibility at scale, which would be applicable for anyone else who is working for entities, whether or not they’re higher ed with large numbers of websites. Then on Monday, July 17th, I am going to be doing a presentation on which page builder is the best or worst at accessibility. I spent a bunch of time testing various components in multiple different page builders, and I am going to give you the results in this talk, so that should be fun. You can find all of those and register on our website. I am really excited to announce today’s speaker. I’m going to add a spotlight for him.

Nick Croft. He goes by Nick the Geek online. He’s been developing for WordPress for over a decade. I first got to know him via the Genesis community and admired the many plugins that he put out that I then used on websites I built for my clients in the very early days, and even now we use plugins that he built on websites we built. He is a senior developer at Reaktiv Studios, a WordPress VIP partner, and as it mentions here, he’s done many plugins. He’s also an organizer for WordPress Accessibility Day Conference and has been a speaker here for us before. Welcome back, Nick.

>> NICK CROFT: Thanks for having me.

>> AMBER: I am going to stop sharing and let you take over. While we’re getting that set up, I’ll just note for everyone that we do have the Q&A feature available in Zoom. If you have questions, it is helpful if you can try and put those there instead of in the chat, because sometimes they get buried in the chat, and I will come back on and ask those questions to Nick when appropriate.

>> NICK: Great. Again, Amber, thank you for having me. I just want to apologize to everybody. I am not feeling well today. If you’ve heard me speak before, you would know this is not my normal voice. I am sucking on a lozenge right now hoping to keep my voice working for the duration. Because of that, I have modified the talk that I was going to give, and what I’d like to do is make it more of a discussion. Hopefully, after I go through the initial overview of everything, people will be comfortable sharing about their experiences as you transition through the different levels of accessibility maturity, and what that looks like for you personally.

Hopping right in, we have six levels of accessibility maturity, know where you are to know where you’re going. This is based on six levels of UX maturity. Great studies showing how UX maturity can evolve within an organization. As we talk about this, I’ll talk about organizations, but I want to really highlight that a team can be a team of many, a team of a few, and even a team of one. I’ll try and highlight some ideas about what that looks like for large teams and small teams and teams of one.

The six levels of accessibility maturity, starting with number one, is absent, then limited, then emergent, then structured, then integrated, and then accessibility driven. Now, the subline to this is know where you are to know where you’re going. I’d like to take a moment and talk about an experience I’ve had many years ago. My wife and I at the time lived in Springfield, Missouri. My parents were in Northern Virginia where we live now. We would travel to Northern Virginia to see them and they would travel to see us. This was back before we had GPS. Some folks had GPS at the time, but we were young and we were poor and we did not invest that kind of money.

We had maps. We were driving through Southern Missouri. There’s a few different routes that we could take, and this was one that went through Southern Missouri, crossed over near the Bootheel, and then got us onto major interstates from there on in. I had researched my route. I had marked up my route, and then we were driving down the road and I saw something about a detour, just as a large vehicle was right there next to me, and so I didn’t quite see what the detour was about, and then I didn’t see any other signs until next thing I know, I’m heading towards Arkansas, and I should not be heading towards Arkansas.

So I had to figure out where I was, and once I figured out where I was, I knew generally where I wanted to go, and so I started making that route. I would turn north until the road kind of turned into not such a major road again, and I would find a semi-major looking road, and I would turn right, which would move me to the east, and that was generally the direction I knew I needed to go. Eventually, as I worked my way back and forth through these routes, I got to the highway I was supposed to be on. I figured out where I was. I knew where I was going, and I was able to plot a course through that route.

As we look through this, you, your team, your organization is somewhere on this chart, absent, limited, emergent, structured, integrated, and accessibility driven. Most likely, you are not at your final destination. Your goal will be to move to another point along this chart. It doesn’t mean necessarily that you are sitting here with no accessibility whatsoever. You is completely absent from the organization, and now your goal is to get to accessibility driven. Your first goal is to get to limited accessibility and then emergent accessibility and move along these waypoints that I’m laying out for you today.

If you’re sitting here going, “Yes, we have–” after we’ve reached this discussion and gone through these things, we have emergent accessibility, I know what that looks like, I know what the next step of structured accessibility looks like, I know what the transition points can look like between the two. It makes it a lot easier to move along this journey and become more integrated with your accessibility overall. I want to dive in and talk about absent.

This is the first one. It is absent. I don’t know a better way to say this. What does it look like? Accessibility is not thought of at all. Disabled people are not considered, and accessibility costs too much. A lot of times when you’re in an organization and you talk about things, it’s really a cost driven experience. When the concept of accessibility comes up, it’s like, “Well, we can’t afford to do that right now.” That means that there’s a huge group of people that are not going to be addressed because the concern of the organization is the cost, not the benefit.

One of the things I remove from this is what are the costs and benefits of being absent in accessibility? The benefit, there’s not really any benefit to not considering accessibility. People think that there’s a benefit, that they’re saving time and saving money because they’re not investing in that, but the costs of it show that the benefits really aren’t there. We talk a lot about the number of people who have disabilities. It’s 20%, 25% of Americans have disabilities of some kind. Those disabilities are, of course, a very large range, but when you don’t consider accessibility, you’re potentially losing 20%, 25% of your audience.

That is a huge cost to the organization. Before you even get into considerations like what does the legal expenses cost as we start having more and more laws that are addressing this and all these other things like that. What does this look like in a project? Accessibility is something that we’ll get to someday. The MVP, the minimum viable product, doesn’t need to be accessible. There’s no accessibility tests that are run. It’s like this is an organization that is sticking their head in the sand, saying there’s no accessibility problem because nobody is reporting to us that there’s an accessibility problem. There’s no accessibility problem because we don’t have tests that are showing that there’s an accessibility problem.

There’s no accessibility problem, so why would we invest in fixing something that doesn’t exist? That’s what absent looks like. Absent also can look like, “I think that I know what I’m doing. I’m not testing anything, but I think that I’m doing this right.” In my personal experience, my personal accessibility journey, if we go back to some of my first projects that I worked on, some plugins that I built, I didn’t really think that I was doing anything wrong accessibly. I created a plugin with a great designer [inaudible] that I worked with at Studio Press and CopyBlogger, and I thought that I knew what I was doing. I used ARIA.

If you use ARIA, then obviously you’re accessible, right? I didn’t test anything with it, though. I didn’t look into anything with it. You can see what I’m talking about. There’s no tests being run, and so you think that you’re being accessible, but you don’t know what’s actually happening with your accessibility. As a result, I didn’t realize that I had created a very inaccessible plugin, which we’ll talk about here in just a little bit as I continue through this journey. Our next step along the way is limited. What does limited look like? Limited is, I want to be accessible. My team wants to be accessible. My company wants to be accessible, but I don’t know how to be accessible.

It’s aspirational. It’s saying, we’ll be accessible someday. It’s going to happen. We definitely have that on our roadmap of things that we want for our organization, for our plugins, for our clients, for whatever your team and organization looks like. It’s something that’s going to happen. We definitely know that there’s problems. What does this look like in a project? There’s limited automated tests done, usually at the end of the project. You get through and you are like, “Okay, let’s see what we did for accessibility,” and you open up AXE DevTools or Lighthouse, and you see that you have a bunch of stuff.

Lighthouse is a really great one, because it will even give you a percentage. Like, “Oh, I’m at 80%. My accessibility isn’t that bad. I’m doing great.” Then you just make a list of all the things that it flagged for you. So you have lists of tasks, but you don’t always have plans on how you’re going to solve the task. You don’t know exactly what is going to happen, but you definitely know you want to get it all fixed, and it’s going to be solved. In my journey of accessibility, this is kind of where I really got kicked off and running with it. I sat in a seminar, WordCamp DC. There was a young lady that was presenting on accessibility, and she talked about screen readers.

I thought it was really interesting, the things that she talked about. She talked about other testing tools and different things like that, but what I really remember is she had challenged folks to just go home and test your stuff using a screen reader. That’s what I did. I’m like, “Okay, yes, my stuff is totally accessible. I just want to hear how good it sounds.” I really thought that I was doing great with this particular plugin that I had just finished developing. I did. I went home that night. It was in DC. I live about 90 minutes or so away. I had to come all the way back home and I got on my computer at the house, and I pulled it up, and I tested it, and it was not accessible at all.

I realized that there were some big problems that I needed to fix. I made a list of all the things, but I didn’t really know how to do it correctly. That’s where this limited idea comes in. It highlighted for me how important it is to start considering accessibility. When we’ve reached this point, your organization probably recognizes the importance of it. There was someone that commented in the chat with a university, maintains a couple of websites. The university is saying, “Yes, we need to be accessible, so I’m going to learn about these things.”

This is of where I am guessing and imagining that conversation comes from, is, we know this is important. Now it’s time to figure out what we can do to improve our accessibility. The next step of this is emergent. In my personal experience, I kind of went from this limited to emergent almost overnight. The experience of, “Oh, wow, I really messed up when I made this plug-in,” was shocking to me and I wanted to get it fixed. I started trying to figure out what to do to get that turned around and fixed. In this case, what does it look like? It’s considered on most projects. At the organizational level, they want you to think about accessibility to make sure things are accessible.

They may even say, “Let’s talk about the accessibility before we get started.” It’s not all the time, but occasionally something that’s considered early in the life cycle of a project, but most of the time it’s really something you run into later in the life cycle of the project, whenever you get to the QA testing and you find out that there’s a bunch of stuff you’ve got to fix now. What does this look like in a project? Automated testing becomes part of the QA process. I think it’s really important to think through that the QA process is happening towards the end of the project after a feature is built, that’s when the automated testing is being done and it’s highlighting things that automated tests can pick up.

It’s not as common to look at these things during the development process at this point. It’s not as common to look at things during the planning process at this point. Now, lists of issues are made and people figure out how to solve them. They work on them and they get these things nailed down and fixed. Again, back to my accessibility journey is this is where I realized that there was a problem, in that Step 2. Then by the end of WordCamp, that next Monday after the WordCamp, I was going through and figuring out how to fix this. I fixed it all.

Then I found out that it turns out not all screen readers are the same. So I did some additional testing in another screen reader and found out that my fixes were not universal. So I had to understand this and work my way backwards through things to figure out how I can fix things in a more universal way. I spent a lot of time trying to figure out, how can you identify what screen reader a person is using? It turns out you can’t and you shouldn’t, but I didn’t know those things at the time. I spent way too much time trying to figure that out instead of trying to figure out how to make my code itself actually accessible.

One of the other things that you’ll notice is at this point, as I’m working through these things, I’m the only person in the organization that’s really pushing this idea. It’s not a huge team that we have, but I began to think that accessibility was very important, so I began to push on these ideas and try and get other people involved in the ideas. Then there was also pushback of people saying, “Well, that’s great, and we think it’s a wonderful idea, but we don’t have the time. That’s great, it’s a wonderful idea, but it costs too much to fix everything all the time.” Try and figure out how to do this in the smallest possible way.

You can see that that’s where things begin to break down and it causes difficulties and problems for people that are getting excited about accessibility. Sometimes this is where things stall out, because people have begun to get excited about it, usually at the individual level. Then the organization is not able to make the transition to more of an organizational level. Because of those conflicts, individuals get burned out and they say, “Okay, it’s not really worth my time,” or they leave the organization and that impetus to move towards accessibility leaves the organization.

This is a very tricky step at this point for organizations because it’s got to get over that hill and then begin moving forward into a more cohesive form of accessibility, which is where we start getting to with the next one. When we get to structure, what does this look like is it’s partly systemic and variably effective. What that means is the organization begins taking on accessibility, not just individuals within the organization. What it might look like is a specific team within the organization begins caring about accessibility because there was a particular teammate that was excited about it and they got other people on that team excited about it.

Because it is not the entire organization, you only have partial effectiveness. What does this look like in a project is automated tests are being run on all the projects. Manual testing is being done on most projects, especially things that are involved with a team that’s getting excited about it. Accessibility is still often thought of at the end of a project, though. Because at the organizational level, it’s not quite completely systemic. It’s not fully integrated into the organization itself. The people that are driving decisions are not coming up with accessible design and scope with what they’re passing down and saying we need to have this.

Then you have to convince them that changes need to happen to be accessible. What this may look like is a design team creates a beautiful design and it’s exciting and people love this design. Then it gets handed off to a dev team that looks at it and says, “Oh, we need to make these changes because there’s contrast issues and we need to make these changes because of various other things like that.” Then it creates a tension between design and dev, or maybe it’s the other way around.

Maybe the design team creates this incredibly accessible design and hands it off to dev and dev says, “Well, it’s kind of difficult to do these things that you want to do. So can we cut back on this, this, and this? Then we’ll work towards your goals of everything, but we can’t quite make this happen. We don’t know how to do this accessibly.” There’s a ongoing tension that exists there, but we’re definitely moving in the right direction. I’ve had this experience quite a bit in organizations where as we go, you have smaller teams within the organization.

Some of them get more into doing the accessibility, maybe some of them get more into doing security and some of them get more into doing optimization or other things like that. Everybody thinks that their thing is the most important thing. In a very real way, their thing is the most important thing, because all of them are incredibly important. It’s about trying to find the momentum to make all of those things important and move forward on projects and adopt better security and adopt better accessibility and adopt better optimization and adopt the newest and coolest features and all these different things that we all want to do all the time.

To do that, we need to make things more integrated, which is our next step. What does integrated look like? Well, it’s comprehensive, pervasive, and universal. This is when the entire organization begins to accept accessibility not as a thing we have to do, but a thing that we want to do. It is a thing that is good for our organization as a whole. It makes it much easier to pass it up the chain and say, “We need to have more budget to be able to make this accessible.” It makes it a lot easier to say, “Well, this is a great feature, but how does this affect users with this particular disability?”

These conversations happen early and often through the course of a project. What does this look like in a project? Every project gets automated and manual tests across everything throughout the company. They’re all involved with this. Tools are used during the development process to catch accessibility issues early. It’s part of code review. It’s part of whenever I’m developing something right now and I create something, I begin thinking like, “How is this going to be affected by a keyboard user?” I created a slider. We tried using a bunch of different sliders. They’re just really problematic. It’s more of a carousel than a slider. It’s not automated. There’s a bunch of stuff that is really frustrating to do with things, but it’s just a really beautiful way to build this out.

Very early on, I was like, “Well, how does this work if somebody is a keyboard user? Do they need to interact with their arrows or different things like that?” What we did was we just made sure that every card in the slider is focusable so that they can just move through the process, and as you tab along, you just move that card right into view. It works really, really well. Then we had to ask, “Well, what does this work like for a screen reader user? How are they going to interact with this?” What we found was because of the way that we solved it for keyboard users, it solved it perfectly for screen reader users because they honestly didn’t even–

Somebody that isn’t seeing what’s going on the screen doesn’t even know that you’re interacting with the slider. You’re just getting the information that’s in the slider as it goes across in the carousel as it goes across. It allows it to be fully interactive without having to use additional controls to be able to find things and roll back and solve things and things like that. This was stuff that we talked about early in the project through– is to figure out how we can make this accessible. Then teams consider the accessibility impact of a feature, which, again, we were talking about there, but another project that I worked on was creating a load more button.

The thing with the load more button is usually you’ve gone through all of your content and you get to the button and then it fills in the button, but your focus stays on the button, which is really problematic. I’m like, “Well, if somebody is not a keyboard user, then they have to go backwards and then they’ll see that everything changed,” but they’ll have to go backwards, but if somebody is a screen reader user, then they won’t know anything happened. We can give them an ARIA live experience and say, “17 new posts loaded,” or whatever. 17 is a weird number, but then they still have to figure out what to do.

Why don’t we just move their focus up to this first card and then we can announce to them however many posts loaded and now your focus is on the first card and they can continue navigating and doing this. It’s a great way to experience this and talk through, like, “How does accessibility impact the feature and how can we make this an integrated part of what we’re doing?” The last step is accessibility driven. What this looks like is it’s reproducible and habitual. It’s the point where the organization is excited about accessibility. It’s not just that they accept that it has to happen and they are looking forward to making it part of their life, but they are excited about it.

Teams are excited to solve problems with accessibility first. During the planning phase, user stories will consider disabled users, and then teams are excited to share with other teams. It’s like what I’m doing right now. I’m excited to share about accessibility with all of you because I am impacted by this personally, but I was excited about accessibility even before I was impacted by it personally. It is about helping everybody have access. In my opinion, there’s no reason why anybody should be prevented from having access online. We have the tools. We have the technology. We really need to make this a part of our life.

I love sharing with others about accessibility. You can see that at the organizational level, it becomes pervasive through the organization not just that this is something we do, but this is something that we love and are excited about. Down to the individual level and the team level, teams are excited to show these are the coolest new things that we’ve created for accessibility. Individuals down to a team of one is excited to write about these cool things that we solved so that we can have these great features. There’s not that tension and fighting between teams of saying, “Well, I want to have a beautiful design and I want to have accessible design, and I want to have–“

We recognize that we can have beautiful, accessible designs and we recognize that we can have beautiful, accessible websites, and we can have beautiful, accessible content, and all these different things are available to users. We begin looking for ways to do things. It drives our design. It drives our development. It drives our business practices. It drives really everything about what we’re doing all the time. It may not be that your team will get to this point. It may be that your team is going to move into this and then move back from this and shift and roll through these steps a little bit along the way.

I wanted to highlight again that there are some key obstacles along the way. As I talked about with Step 3, this emergent area where you have maybe one person that begins getting excited about it, and they’re shut down, and they begin to get burned out, and they begin to feel like they’re the only person making things accessible for the entire team. They begin to feel like, “I don’t know what I’m doing and I’m trying, but it feels like everything that I do isn’t really working–” This is a really frustrating place to be. I get too structured. I should be on emergent. I don’t know how I switched. I thought I saw emergent.

They feel like they are just overwhelmed with everything. It’s really difficult to move to this next point until you begin to get more people “on your side” in accessibility, more people that are pulling in the same direction. Once you start to get more and more people pulling in the same direction, you get to that structured look and it begins to become more systemic, not fully, but more systemic through the organization. This is probably the biggest hurdle and obstacle moving forward.

This is the one where I feel like community, this group here, this meetup here, is really going to help people who are starting to feel that burnout, and say, “Well, what can we do to make this more structured inside the organization? What can we do to solve some of these problems of, I don’t–” accessibility is easy but it’s also extremely hard. You try and go and read WCAG and they’ve got great stuff, but until you begin to really understand the layout and structure, it’s like I don’t understand any of this. When you start trying to make accessible components, it’s like, “I know what I want to make, but I don’t know how to get to that next step.”

Again, that’s a very difficult place as you move from this one to this one, from emergent to structured. All of those things are obstacles along the way, but I truly believe that as a community, WordPress Accessibility Meetup, WordPress Accessibility Day that’s coming up, I’m going to be speaking at Higher Ed Web and accessibility and stuff like that. Those are all areas where it doesn’t have to be on us. Whenever we’re at this point, it feels like it’s all on us, but when we take a step back and realize that it’s not just our organization, it’s not just our team, it’s not just me as a person, but it’s us as a whole, I think that there’s a lot of room to help us out and move us along this journey.

What I’d like to do, and as I’ve said, I do not feel super great today, but I’m hopeful that we can have some conversations around what your process was as you moved along. I shared some of my story, my journey, because I think it’s important to hear those things that we’ve been through, but again, this idea of this journey process and community coming together, I think if you can start sharing your stories of, “Oh, yes, this is what it was like when I first really started looking at accessibility.

This is what it was like whenever I was at this kind of point here when I knew that accessibility was a problem, I was really trying to make it something that our organization cared about, and it was difficult,” or it was easy or it was whatever your experience was, and things that you found as you moved through that journey. I would just encourage you to start sharing those things in the chat. We can start reading things out. Amber, I think, is going to be helping me with that. My voice has held on so far, but I make no promises. The cough drop is gone.

>> AMBER: You want me to pop back in?

>> NICK: Yes, please.

>> AMBER: All right. While some people– we would definitely love to hear what you have to say in the chat as far as your experiences. I did see some questions come in, so I’ll loop through those in just a minute, but I thought I might share a little bit about what our journey was. Does that seem helpful? Okay. While we hear from some other people about theirs. My personal journey is that I started with WordPress in 2010 and I was just like– friends were like, “Oh, I like your blog. Will you help me?” Then I helped them and then I started to realize I could charge people money.

Very typical WordPress story, which is that I did it for free. I started charging people money. I never said no to anything. I was just like, “I’ll just Google it.” Someone’s like, “I need an event calendar.” I’m like, “Okay. Yes, I can do that.” I had no idea how I was going to do that. A lot of self-taught. I think that’s what’s wonderful about WordPress. I learned PHP and JavaScript and HTML and CSS and all that stuff off of blogs. Almost none of which ever talked about accessibility. I built a lot of websites, as we all did a long time ago, that from a lot of perspectives, we’d be embarrassed about beyond even accessibility.

Then I started working with Colorado State University in 2016. We’d grown the company. It was not just me. I had a team. They’re like, “It has to be accessible.” The same thing, we were like, “We can do that.” It’s what I consider trial by fire. Learned a lot. Then on the next project, we said, “We really need to start bringing in users to test this, to actually validate, because we know that the university tests some stuff.” They have an accessibility committee that would review before websites could go live, which I still highly recommend. If you have an organization that has the ability to have people test things first, definitely do that.

Then we were like, “We need to actually have blind people come in who use screen readers every day and go through and audit something.” We had a project where we did that. That for me was just– I learned so much. Then that was when we were like, “I have to change the whole way I’m thinking about this.” I don’t know if that’s been your experience, Nick, the first time you saw someone use a screen reader, that it just totally made you think differently about the code behind it and even just the journey. I learned a lot more about the importance of headings, because they don’t just listen to the whole page, which I think in my head is what I thought. It just reads the whole page. No, they use the search feature.

Not necessarily the website search feature, but the search feature in their screen reader or in the browser. Then they jump around for headings or they listen to lists of links all by themselves without any context to try and find what they’re looking for. That, I think, for me, really changed me just thinking fundamentally about what the user journey is and what the goals of the people are. That’s kind of what our path was and shifting in. Then as an agency perspective there was a lot of–

Initially it was an add-on that we were trying to sell to clients as a line item on their proposal. Some people would go for it and some people wouldn’t. Then eventually we were just like, “No, we don’t feel okay with this.” We just included accessibility in every phase. It wasn’t a separate thing that they could just delete. It just said design and we included whatever budget for accessibility we thought in that design budget. Then it said development, and we included whatever we thought for accessibility. Testing and QA. That was a big shift for us, which is where I think we started to get into that more structured, this is just the way it is kind of planning accessibility.

That was our journey. Let’s see. I’m trying to see if anybody posted in the chat some– Maybe it’s more integrated, I guess, with your things. Yes, go ahead.

>> NICK: When you make that change from a agency level where you stop separating out accessibility as a line item, because companies are going to be like, “Oh, well, that’s like $10,000. I can save money,” or whatever. I’m just pulling a number out. I’m not saying that’s what it is, but pulling a number out. Companies really do that, but then you make that change and it’s just part of your budget. It’s part of design, part of development. I feel like that’s really when it’s integrated. It’s just part of what we do. You can’t get it without it. It just isn’t available. It’s not something we do. I think it’s a great point.

>> AMBER: That was a big change for us too on the dev side. Teaching our developers that there are certain expectations that we expect them to test for before it even goes to QA, quality assurance. I don’t get a website that has accessibility checker empty button [inaudible] on it. I’m like, “The tool’s there. Look at it. Do the stuff.” You don’t need a blind person to tell you your buttons are empty. There are lots of tools, accessibility checker, WAVE, AXE, that will tell you that. I think that was a big shift in how we had to think about training, was very different when we were onboarding new people to our team, because not everybody knows about accessibility, whether they’re a content specialist or a developer or a designer. I think when you become more integrated, you have to think about that.

>> NICK: I will highlight, at no point along this way do you reach a point where everything is just perfect. Just last week, I think it was, I had a button navigation that used an SVG element, and I marked everything up to make it accessible correctly, the way that it is according to spec. It tested and worked correctly in the browser I was using at the time, but then my QA specialist tested it in a different browser, and was like, “This doesn’t have a label on it.” I’m like, “Yes, it does. I’m looking right at the label. What are you talking about?” We went back and forth.

>> AMBER: It wasn’t reading it in that specific browser.

>> NICK: Some browser just was not picking up the title tag in the SVG, and it’s like, “Why is this not working?” I pulled up spec and I’m looking at the spec and I’m looking at what I did, and I’m like, “I did everything correctly, why is it not working?” Then I had to do it differently. I had to use an ARIA label on it instead of the title tag like it was supposed to be, but it fixed it, and it was like, “Why is spec not working the way it’s supposed to be working?” There are times where you’re going to trip over things, even though you know everything, just because sometimes things don’t always work the way you expect. I do want to encourage folks, if you run into stuff and it’s like, “I don’t know what I’m doing,” I run into this myself.

>> AMBER: We still have– even last night, okay, I entered the dark side, I’m going to admit it right now. As of last night, there is a pop-up on our blog post, but I was like, “Okay, we’re going to experiment with this and see what it does for us.” I was like, “I have to have someone test this.” I tested it a bunch, but then I went and I messaged Ragha and I asked him, I was like, “Will you do a test on this for me? Because I want to make sure that I know.” Even when I think you feel like– I don’t know if you can ever know everything, and I think it’s good to get multiple people to look at stuff. That kind of thing is really helpful.

>> NICK: I want to read a couple of things. I took off my glasses, I can’t read. Nicky Wolf said, I had to leave an organization that thought they were at level six, but were actually at two and three. They refused to acknowledge very needed changes. I’m now in an organization at one and two, but they acknowledge this and want to get further along. In my experience, the outlook and attitude is so important. Mistakes will get made, but it’s acknowledging this and trying hard and not pretending everything is fine when it’s not fine. I really love that. It’s like I said before, you get to a point where it’s like the organization just has their head stuck in the sand. They think everything is okay.

I’ve been there. I’ve definitely been there. Even you shared it. I remember a couple of months ago you talked about you had a old website that you pulled up where you used all that pink.

>> AMBER: Oh, yes. My own personal website.

>> NICK: You found a lot of issues, but it’s like we’ve all been there where we thought we knew what we were doing. Even now, like I said, that button navigation, I did it correctly and it didn’t work in Firefox, I think it was. It’s like, “Why is it not working in this? They’re part of writing the spec. They should have this working correctly,” but it didn’t work.

>> AMBER: I think it is really important to have that perspective of where you are and to be honest with yourself, which is probably one of the hardest things for organizations.

Especially people– if you’re at a large organization, whether that’s a company that’s a very large company or a university where you’ve got the president of the university who has a lot of opinions about the website or the admissions team who has a lot of opinions about the website but maybe has very little design or technical expertise at all. Again, this happens at companies all the time too where the CEO is like, “I need X, Y, Z to happen on the website.” I do think if you are working either within an organization like that because you work at one or they are your client, I think the biggest thing is trying to come up with some questions to help them figure out where they fit along this journey.

Because a lot of times, I like what you’ve done here where you’ve given both an example of what does this mean and what does this actually look like in a project? Because that’s really helpful because I think a lot of times you might just say, “Oh, no, we’re really close. We actually have it integrated, right? Like we’re doing accessibility,” but then when you start to look at it and you’re like, “Are we actually considering accessibility impacts when we start talking about a feature before we even build it?” You’re like, “Oh, no, we’re not doing it.

Okay, maybe we’re not here. Maybe we’re a step before. That’s what I would say is looking at these, and I know you posted the link in the chat and we’ll make sure that gets up with the recording, the slides, and coming up with some questions that you can ask almost in a discovery process with your organization or with your client to help them figure out where they fit on this journey is really important because then you can figure out, “Okay, what questions do we need to ask ourselves to figure out how to get to the next step?”

>> NICK: Absolutely. I do like what you just said there as well about maybe we’re at the structured level instead of integrated level. It’s not to beat anybody up and be like, “Oh, you’re not integrated. Ooh, you’re just not integrated.” It’s a journey, and sometimes a journey moves back and forth between these different things as well. I think it was Nikki who said, as long as you’re recognizing that you can work on things and do better and keep improving and keep moving forward, that’s really a great place to be. Greg, I want to apologize in advance if I mess up your name, Yingling. I kept encountering all sorts of well-intentioned but absolutely wrong or even worse than nothing accessibility guidance when I started.

That is definitely a true thing. There’s no weight about how true something is whenever you use Google.

>> AMBER: Even worse now with AI, right?

>> NICK: Yes, exactly.

>> AMBER: People are using CoPilot to write their code for them or asking ChatGPT. I think for me, I tend to look at who the author is and the source a lot when I’m reading accessibility blog posts. Because I still sometimes Google. I’m like, “Wait a minute. I think I know this, but I want to figure it out.” Or someone will ask me a question, and I was like, “No, there’s got to be more to this,” but I’ll look at who the author is or, like, the website source. I think that’s good to point out. Even the W3C, a lot of their examples say this is not production-ready code. You still need to test it.

Let’s see. Angelica said, Angelica was a social worker for almost a decade and helped disabled people navigate these overly complex systems and experience them with the reality of the impact of inaccessible designs. Angelica transitioned to the field a little bit over a year ago, starting with the UX boot camp, and has been honestly shocked at how little accessibility is discussed or focused on. In her short experience, accessibility is the absent stage for new designers. From the courses to entry positions, accessibility overall feels limited, in the limited stage at best. I think that’s probably true. I don’t know if you’ve had different experiences with some of these boot camps and things.

That’s what I’ve heard, having not gone through one, that most of them don’t talk about accessibility much. I think a lot of them don’t even talk about HTML. Maybe that’s why it’s getting missed. They just go into JavaScript. I don’t know.

>> NICK: I’m trying to remember her name. I know you know her, Amber. She posted a lot on Twitter for a long time there about accessible design. Ann Cook, maybe? No.

>> AMBER: Ann Cook from Microsoft?

>> NICK: Maybe. Anyways-

>> AMBER: Anna.

>> NICK: -she was going through a design program and was talking a lot about how little they talked about accessibility through their program. I think that’s the problem, is it’s just not talked about a lot at that level. It’s something that people have to end up learning after they’ve gone through education and training.

>> AMBER: No, I think it would be great if there could be more on accessibility up front, but the thing that’s hard about that, I used to guest lecture one class a semester at Colorado State University in their undergrad web development class. They would be like, “Come here and do one class on WordPress development.” I was just like, “Well, one 90-minute lecture on WordPress development, I’ll see what I can do. We’re going to start with how WordPress websites are structured,” but I think that’s the thing that’s hard, is probably it needs to be an entire course, if we’re really going to be honest about it.

I don’t know if that means all of us that are advocates or people that need to go to colleges and university boot camps would be like, “I need to be an adjunct and this is what I’m going to teach,” just accessibility and design or accessibility and content or whatever that might be. There are some questions in the Q&A. Do you mind if I go through those?

>> NICK: Yes, absolutely. I may end up dropping here very shortly. I’m starting to drop.

>> AMBER: Okay. I’ll see what I can get through. Someone said, accessibility testing is quite time-consuming. Who would be best to make sure what we have is accessible? How do you test for accessibility efficiently? They said, we’re a big company but are early in the accessibility journey. No one owns accessibility and there’s no internal expertise. This person has conducted initial needs assessment and they need to secure some accessibility tools and experts to support us. Do you have any guidance on that or where to start?

>> NICK: Yes. I feel like a lot of times it starts with an individual. An individual can affect a team and a team can affect the organization. Like you said, nobody owns it, so nothing’s ever going to get done. Someone needs to just take ownership and say, “This is important and this matters.” Now the problem is, like I said, this is going to put you somewhere around two, limited, and three, emergent, where you’re just starting to really do things with this and move forward in this space. If you can’t get from an individual to a team to the organization, what’s going to end up happening is you will be burned out. You will get overwhelmed. You will get sick of it and you will say it’s not worth it.

It’s not about saying, “I’m going to take ownership of it and I’m the only person that’s going to ever do anything and I’m going to make it happen and I am some superhero that’s going to be accessibility person and push through the whole thing.” It’s really about saying, “This is important and I want to start getting everybody involved with this. What can I do to get the team involved in this? I can do testing. I can do these things. There’s another question here about you’ve heard automated tests. What do they look like? When we talk about automated tests, we’re talking about using Axe DevTools, Wave, Lighthouse, et cetera, these different things that scan a webpage and say this is accessible, this is not accessible.

It can get, I think Axe claims they’re up to 70% or something like that of WCAG issues. There’s still manual stuff that you need to do. It’s not the end-all solutions, but it’s a good starting point because that’s going to get a lot of stuff. If you can learn to use Axe, if you can learn to use a keyboard, which is fairly low, you just use the tab key to navigate through things and make sure you can use stuff.

>> AMBER: Everything that you could with a mouse, you want to be able to do without a mouse.

>> NICK: Exactly.

>> AMBER: That’s the short way of explaining keyboard testing.

>> NICK: If you do these things, you can say to the team like, “This can’t be done. This needs to be fixed.” You start getting some momentum with that. You start getting other people interested in saying, “Well, how can we–” Anytime you deal with a developer, if you give them a problem seriously, like, “I don’t know how to fix this.” You don’t go to a developer and confront them and say, “You need to fix this.” You say, “I don’t know how to fix this.” You just give them a problem to solve, almost every developer out there will be like, “Ooh, well, let’s figure this out.” Suddenly they start getting excited about stuff, and suddenly the team starts feeling excited about stuff.

Then as you continue to bring that out and get other people involved, that’s how you get past this particularly difficult hump. It is moving from emergent to structured. It is getting more than a handful of people– in a large organization, it might be dozens of people, but they’re all on different teams and pulling in different directions, but as soon as you start getting entire teams pulling in the same direction, it makes it a lot easier to keep the momentum going.

>> AMBER: I’ll add too on that. If you don’t have anyone in your organization then it’s definitely worth finding someone outside your organization to at least consult. Even if it’s on a small bit. I know we do that. I think Nick maybe do that. His company, certainly, if you have a larger enterprise website and you want to work with them. Then there’s the International Association of Accessibility Professionals. They have a whole directory of people who are certified, whether they work with our company or they’re an independent freelancer that does testing or consulting.

I would say bring in someone because they can help you. You don’t know what you don’t know. We do a lot of operational planning around it and road mapping and figuring out what do you need to change. Like I mentioned, we had to change what our training process for onboarding new hires was. Which you don’t think about. You’re like, I need to fix my website accessibility. You don’t even think about, I have to change an HR process but there’s a lot of organizational things that need to happen in order to move further up that accessibility road map. I recommend that.

I will give a shout out, of course, for our accessibility checker pull-in. There’s a free version. Like I mentioned, no limits on number of pages and posts. WAVE is free. ACT has a free version. One of the weird things that is incredibly helpful is there’s a browser extension called Headings Map, which is free. It’s simple. It just does one thing. An outline of all the headings on this page. Like I mentioned, I’ve learned from watching people that headings are super important. There’s a lot of little free tools, which we can link when we post up the recording.

I’m going to skip down a little bit. Michael has said, “I contact a lot of owners of public institution websites, unemployed services, localities, foreign affairs, etc. I have the impression they’re at a level one or two. In Europe, there is not such strong incentive like lawsuits as you have in the United States. How can we move them from level one to two, three quickly? Even national, federal websites are so bad regarding web accessibility. Even an automated test seems too much for them. Telling them that those tests are far enough is not heard. They have laws, but no fines.” I think this is going to change is my assumption. I don’t know if you have any thoughts on this, Nick?

>> NICK: Sorry, I’m probably going to drop after this answer. I don’t love trying to sell accessibility from the perspective of lawsuits. Even in the US, where that’s becoming more possible, it’s very expensive. It’s not really happening a lot in even the US at this point, although there’s some laws California tried proposing that was going to open the door to that a little bit more. I really like selling accessibility from the perspective of potential market. When you’re talking about 20% or so of all users have some disability, when you talk about the fact that accessibility is good for everybody.

For example, most people are hitting a lot of websites from their phone nowadays. Their phone is not always in a nice, properly lit room to a dark room. It’s because they’re outside where the sun is pouring down on them. If you don’t have high enough contrast, they’re not going to see the things on your website. People have transitional disabilities where they are unable to do certain things for various reasons. A mother holding two children trying to order pizza for dinner, you can imagine that really limits your ability to just focus and interact.

There’s distractions and both your hands are full and you’re trying to wrestle these kids and do these things. If your website has these teeny tiny little icons you’ve got to touch, that mother is going to give up on that website and order from somebody else. It isn’t going to work. Just a whole host of things that you’re really opening up. You’re going to start saying, well 20%, well, really, we’re talking about once we add in transitional things, it’s more like 100% of all users are affected by our accessibility decisions.

When you start telling people things on the bottom line is we can get more customers. If none of our competition is accessible, that means all those customers will eventually come to us. This is a good thing, net good thing for our company. As you start getting people on board for positive reasons, net benefit reasons, it is less of a thing that they are fighting against and more of a thing that they’re excited about.

>> AMBER: I’ll follow up on this but I want to let you go because I know you’re not feeling well and I really appreciate you coming in here. I’m happy to go through the Q&A and I have more thoughts about this. Do you want to real quick just say how people can get a hold of you and then I hope you feel better.

>> NICK: Sorry. Let me drop it in here. I am not on Twitter as much anymore, but I’m on threads more lately. Let me grab my link for threads. Sorry, should have thought to do that. Where’s chat again? There’s chat. I have a contact form there. You can send me emails.

>> AMBER: At Nickgeek.com. I’m just going to say it for the audio.

>> NICK: I sent that to hosts and panels. Sorry.

>> AMBER: That’s okay. I think Paula grabbed them and sent them to everyone.

>> NICK: Thank you.

>> AMBER: Feel better.

>> NICK: All right. Thank you. Bye.

>> AMBER: Michael, I did see your comment about more public websites versus private companies. I do think that this is going to change pretty significantly with the European Accessibility Act. Maybe Paula can grab a link to that recording if you haven’t watched it. We had two people from Funka come and present about laws in Europe, both the public laws and the European Accessibility Act, which is a directive, which is telling countries they have to make laws, which are going to come into enforcement in June 2025. I have seen more countries adding fines.

Actually, one of the things they shared, which I was surprised about, but then I went and looked it up and it is true. Ireland is adding jail time if a website is inaccessible and not fixed when the government says it needs to be fixed. I do think there’s going to be more things that are going to apply both to for-profit but also public sector websites to enforce that. I think the biggest thing, though, is to discuss with them the implications of not being able to reach everyone in their constituent group. If it’s a water board and people have to go there to pay their water bill and it’s a government thing or their electric bill and they can’t do that, then obviously they’re failing to meet everyone in their constituents.

Ideally, that would be something that would motivate them to want to serve everyone that’s in their group. I don’t know if that’s helpful, but I would recommend looking at that presentation. It’s not just about the European Accessibility Act. It’s about all laws, so there might be something helpful in there as well. Ricardo, you had asked about six maturity levels, not five. I think the slide that he didn’t show which is number six, is you’ve achieved accessibility. You are right there and achieved it. Let’s see. I’m going to see what else.

Sorry, I’m looking through questions. There’s a question about which LMS we recommend with Moodle. To be honest, I have not tested all the LMS out there, so unfortunately, I cannot answer what the best LMS is. If anyone in the chat has opinions or experiences on that, feel free to post them. I think there’s going to be more coming on that for us in the future, because we’re planning to do a bunch of testing beyond even the LFTR test that’s happening. I might have an answer for that, or we could potentially put together a presentation for that in the future.

Let’s see. We’ve talked about accessibility testing tools already. Which page builders produce the most accessibility pages? Would it be horrible of me to tell you to come to the webinar on that where we talk about it. I think with many of them, you can build accessible things. You just have to be thoughtful and test different components. There are definitely others that give you a better starting point. That is going to be on the third Monday in July and I think Paula might have just shared a link to that in the chat.

I’m trying to see if there are any other questions. Maureen, you had asked about considerations for mobile devices. We also have a really good recording, which we can put a link to. Jan Wiles, who helped write. There are not specific mobile testing guidelines that are part of Web Content Accessibility Guidelines, although all of Web Content Accessibility Guidelines apply to mobile. There are also some things very specific for mobile apps or mobile user interfaces. She did a presentation about both building and testing accessible mobile sites and apps. She is from Australia.

She actually, as part of an international committee, helped to write mobile accessibility guidelines. She walked through what all of those are. That would be the best resource for that. I think probably a good way to wrap up, to what extent are the accessibility tests and dev tools sufficient? This sort of follows up on what Michael had said about automated tests. They can only detect 30 to 40% of the issues for the best tools. You can have false positives or they sometimes don’t detect a blocking point, which is almost an answer to this question.

I will say we’re a maker of a testing tool, but if you look at it, there’s a little note at the bottom of every report that’s like, “You have to also do manual testing. Here’s a link to how to do that.” I do think it is really important to do manual testing. As Nick said, if you’re coming from an organization that hasn’t done any testing at all, starting with automated testing can be very helpful. I would recommend starting there, but for sure, you need to go beyond automated testing. I know he said, DQ says that the asking check will find 70% of problems.

I still question that because most accessibility professionals say that 30 to 40% that Michael mentioned. I think that’s run through most of the questions. I appreciate everyone who has hung out here today. As a reminder, we’ll be back on the third Monday, which I’m spacing on the date right now. It’ll be right after I come back from WordCamp EU. We’ll see how much energy I have, but hopefully, it’ll be good. Thanks everyone, and we’ll see you soon.

View “Six Levels of A11Y Maturity: Know Where You Are to Know Where You Are Going” Google Slides.