Accessibility Strategy and Goal-Setting Workshop: Amber Hinds

>> PAOLA GONZALEZ: Welcome, everyone, to WordPress Accessibility Meetup, Accessibility Strategy and Goal-Setting Workshop, with Amber Hinds. We have a few announcements today. You can always join our Facebook group to connect between meetups. Over there, we talk about anything and everything accessibility. Most likely, if you ever have a question when it comes to web accessibility, it can be answered over there. You can find the group at facebook.com/groups/wordpress.accessibility. You can also find upcoming events and past recordings in one place. Yes, this meetup is being recorded, as all our past meetups have been recorded. They’re all live at equalizedigital.com/meetup. You can find this recording for this event in about two weeks time, because it does take us a while to get our transcript ready. You can also join our email list to get news and event announcements, at equalizedigital.com/focus-state. You can also tune into our podcast, where we release the audio version of the meetup, and also some other conversations related to WordPress Accessibility. You can find the podcast at accessibilitycraft.com.

We are seeking additional sponsors for the meetup. The WordPress Foundation does not provide us with monetary– I’m spacing on the word. They don’t help us when it comes to ASL or captioning, so we have to go out and find our own sponsors. If you’re interested in sponsoring meetup, you can email us at meetup@equalizedigital.com, or you can message me during the event, and I can give you some information about sponsoring. Also, if you have any suggestions for the meetup, or need any additional accommodations to make the meetup work for you, you can also contact us at that email, or you can contact me during the meetup.

We are the organizers of the WordPress Accessibility Meetup. We’re Equalize Digital, and we are a mission-driven organization focused on WordPress Accessibility. You can find us at equalizedigital.com, and you can always find us on X, where we are very active @equalizedigital. We would kindly like to thank our live captioning sponsor today, GoDaddy. GoDaddy’s mission is to empower a worldwide community of entrepreneurs by giving them all the help and tools they need to grow online, including a simpler, safer WordPress experience.

GoDaddy provides a managed WordPress experience that is as easy as it is effective. The latest version of WordPress comes pre-installed with exclusive themes, plugins, and tools to get you up and running quickly, with automated backups, updates, and malware removal so our pros can spend less time on monotonous maintenance, and more time building their business. You can find them at godaddy.com, and we always encourage our attendees to tweet them or X them, I’m not sure what the language is there, to post an X message at them, at godaddy.com and thank them for sponsoring the event. Just a quick rundown of our upcoming events for Q1 of 2025.

We’re actually very excited that we are almost booked through the full Q1, and the first meetups that we’re going to have are, Navigating the Future: Using WordPress Menu Blocks That Work for Everyone, with Michaela Lederman and Eli Frigoli, from Aten Design. That is on Thursday, January 9th, at 10:00 AM Central. Then we also have, How D&D Can Improve Accessibility: Using Roleplay During All Phases of Product Development to Better Consider User Experience, with Nick Croft. That is on Monday, January 20th, at 7:00 PM Central. So that is this same time slot in January.

We also have, Digital Accessibility: Thinking Beyond WCAG and Compliance, with Chris Scholtens. That is on Thursday, February 6th, at 10:00 AM Central. We have today’s speaker, Amber Hinds, who you all should know. She’s usually doing this part of the intro. She is the founder and CEO at Equalize Digital, and she is working to build a more equitable web for people of all abilities. So, yes, Amber, take it away.

>> AMBER HINDS: Thank you, Paola. I appreciate you doing all the intro for me. Let me see. I’m going to share my screen here. We’re going to pop that over. Okay. There are two things that you’re going to need today. The first is we have a slide link. Paola can pop that in in a minute. I will give you a link to the other item. This is going to run a little bit different from a normal meetup, where we just have a presentation and then Q&A at the end. I’m really hoping that this can be more interactive, that we can have conversations throughout the meetup, and that it’s a bit of a working session for everyone here.

The agenda for this meetup is we’re going to talk a little bit about understanding where you are now, defining your available resources, identifying your conformance targets, and then drafting goals, and then we’ll end with some sharing and discussion. I’m hoping everyone will leave this meetup having drafted at least one goal for accessibility for 2025. I have a screenshot up here on this slide of my accessibility roadmap planning worksheet, which is sort of a combination of some of the things that we do for our customers, and it’s a Google Doc, and you can get that if you go to EqualizeDigital.com/a11y-planning, P-L-A-N-N-I-N-G.

EqualizeDigital.com/a11y-planning, and I think Paola should be able to pop that link into the chat as well. That will get you over to a templated version of this worksheet that we are going to work through. A couple of notes on how to edit this. When you go there, you’re going to have the view-only version of it, just because we don’t want everyone editing the same copy. If you’re not familiar with Google Drives, what I would most recommend is you can go to file, make a copy, and this will copy it into your personal Google Drive. If you don’t use Google Docs, you can also download it, if you go to file, export, and you can download it as a Microsoft Doc file if you want.

Just a note on there. I do have some dropdown/form components, depending upon how you edit those. Like I downloaded the Microsoft Doc, and then I opened it in Pages, on my Mac. Those were now just plain text, but you’ll still be able to do everything else. It’s just some of those interactive components won’t be that, they’ll just be regular text, because Pages doesn’t support forms. There are some tables in the sheet, and I can show you this as well. If you need to add a row to tables in a Google Doc and you’re not sure how, there are two options.

If you are a mouse user, you can right click on a table in any row and select insert row below. If you are a keyboard only user, when you are in the table, in the last cell in the bottom right of the table, if you hit tab again, it will create a new row and put you in that row. That is the keyboard only way, which I’m a mouse user, but I use the keyboard only way because it’s faster when I’m typing, to just do that as well. If you want to make changes to a dropdown, you would click on the dropdown and select an option. If you want to modify things for your own use cases, when you click on a dropdown to edit the dropdowns options, you can then click add/edit options.

You can modify this, take it, make it however will work best for you and your organization, and that’s sort of the goal there. Where I want to start is with understanding where you are. Because writing goals, the way we think about goals, and we do a lot of different goal setting internally here, with ourselves and with our customers, but we’re very big on creating actionable goals. One of the ways to do that, or one of the key things before you can do that, is you have to first start by knowing what your current status is. If you don’t know what your current status is, then perhaps your first goal is to figure out your current status.

Basically, if you’re trying to plan an accessibility roadmap for your organization, you cannot do that without knowing where your starting point is. What do I mean by your starting point? You need to know what kind of content exists on the website and how much of it there is. You need to know which pages get the most traffic. Then from that, you can start to define a representative URL sample. Then I always recommend running some automated tests and documenting just some initial quick findings, which then you would go back and manually test, and spend more time on them. That might give you an initial picture of where you are.

I’m going to flip over to my example of the accessibility roadmap planning worksheet, which I have filled out for wpproducttalk.com. If you’re not familiar with that, that is a website for a podcast that I co-host. Let me see if I’ve got a good– This is the back end. I can get the front end somewhere. That I co-host with Matt Cromwell, Katie Keith, and Zach Katz. I wasn’t involved in building the website. I think Matt Cromwell did all of it, all by himself, which is amazing. We were talking about how we wanted to make it more accessible. So, I have a goal next year of spending some time on this, because I haven’t really spent any time looking at the website.

I did recently, and I was like, “Hey, I really want to fix some of the things around here.” My co-hosts were all like, “Yes, that would be awesome.” So, I’m filling this out with my goals for this website. The first H2 in the document is current status. I first went through, and I look at the scope of the site. The easiest way for me to figure out is, what kind of content is available, is I just go in the dashboard of WordPress admin and I look for post types, and I look for taxonomies. I have pages on this website, I have posts, so the normal things you’d expect.

I will go into them, because sometimes you’ll go in and you’ll be like, “Oh, there are blog posts,” but you realize this customer doesn’t actually have any blogs. It’s empty, right? Then this website also has podcasts as a post type, and it has a number of different taxonomies below it, it has guests, co-hosts, topics. You’ll notice under posts, the default tags doesn’t exist. It’s been removed. What I did was I went through the website, and I filled in this table under the scope of site, H3 in the doc. I added, in the content type, each row, and don’t mind my red underlines. These are Grammarly shouting at me. I’ve got pages as a content type, I’ve set in my visibility that it’s public.

The options I currently use on these are public, private, not in use. If you’re not familiar with WordPress, when something is set to private, it means that it doesn’t have a front end page. It is usually used to store data so that perhaps it could be output in a block instead. We do this a lot on custom websites we build, like for example, with Teams. We might have a place for somebody to input all of their team members in a certain format and then store it in a team post type, but there’s no front end for that, we just have a block that can be inserted into a page, or a short code maybe that outputs all the team members in a very specific format.

That would be a private post. Then, just for myself, I go through and I put a count of how many posts or terms exist, and I’ll write any notes about them. For example, if I had one of those private post types that then output content in a block in the notes, I would probably say like content output by this block. So I would know, okay, well, why does this exist and it doesn’t have a front end? Is there some other way that that content is being output that I need to look for later on? On this website, I have found nine pages, nine blog posts. There’s only one category. There’s no tags. The taxonomy has been removed from site.

It’s not just that the customer is not using it. I’m going to say customer, right? The website’s not using it, it literally doesn’t exist. There’s no way for someone to even add tags. I don’t have to worry about that would be a gap in my testing. There are 83 podcast episodes, and then there’s different taxonomies for the podcast, custom post type, which is co-host, guests, and topic, which all pretty much use the exact same page template, which tells me I don’t necessarily need to test all of them in my representative sample. I did that first. I went through and filled that in. Then I looked at my analytics.

You might get this from Google Analytics. This website uses Plausible Analytics. So I just looked at Plausible Analytics and I got the top 10 pages by view count for the past 12 months. Now, you have to decide what a good sample is for yourself. We generally look at 12 months, because it gives us a feel on if something is seasonal, like Black Friday, you might have a very specific kind of traffic on Black Friday, or in this last, if you were to look at just the last 90 days, it might look very different from what the website actually looks like. We’ll do that.

This is helpful for me too, because it told me some things like, homepage was number one, then the blog, then the contact form, then the be a guest form, which if I was looking at the front end of the website, I don’t even see that page, be a guest, in the navigation. I just see episodes, subscribe, blog, reviews. Even I think it’s down here in the footer, but that’s a page that I might have potentially missed without realizing, no, this is actually, it doesn’t look like a top level page, but it’s the number four page for traffic on the site. So that definitely makes me think, “Oh, this is high priority. I should probably take a look at this page.” Then the episodes archive, of course.

The marketing was the topic that got the most. So if I’m going to look at an example of a topic page, then I would probably choose the marketing one, because that’s the one I know gets the most traffic. So that would be the first one I look at before I look at all the others. An episode with Matt Mullenweg, a blog post, how we’re self-hosting our podcast, product development archive, and another podcast episode, is the WordPress market share declining? I just list those out for myself, knowing that I’m going to come back to them. I come back to them when I am defining my representative sample.

What this is is this is my list of the components that I know need to be tested in order to have a thorough picture of the website. I am not going to start out by manually testing every page. I am going to start out by running an automated scan with Accessibility Checker on every page, and then manually testing one of each type for each key page, if it’s an actual page, that has unique components such as accordions, tabs, carousels, forms, maps, pop-ups, or modals. Other interactive things need to be on this list. You really want to cover at least one example of all of those things. Then you can sort of work on remedying those before you start manually testing more pages.

What I do is I put in the page name. In my status column, I have a dropdown that tells me whether it– for me, I use needs and audit, means it needs both a manual and an automated. Then I have needs manual testing. That means I know that it’s been tested with an automated checker, but not by a human. Needs remediation means it got tested, problems were identified. Accessible means it got tested, there were no problems. During an actual remediation, we might have other stages here, where it’s not just needs remediation, it might be like open dev issues, open content issues. Different things like that.

For the purpose of planning, this is just broad enough for me to figure out, where is this in the stage of accessibility? I’ll put in the actual URL, so that it’s easy to click and go over to that, and then any other notes. For example, on the homepage, I said, “Hey, there’s a chatbot on this page.” It’s on every page, but I’m typically going to lump that in with my homepage test. I’m going to test it on the homepage. Contact, I noted that it has a form by Kadence. The blog archive, I didn’t have any specific notes for. The blog single, I picked our high traffic post, and then I also noted, when I was looking at that blog post, that it had a bunch of code embeds in it.

I’m like, “Oh, this is an interesting component.” What I can show you, I’ll just show you those real quick, looking at it on the front end. It has, without me even inspecting it at all, I’m like, “It could be an on-frame, it could just be a code block.” It has fancy styles, but it has like black box with PHP and then color code, like you’d see if you were actually writing code locally with some different sample PHP functions and filters. I’m thinking, “Oh, this is a unique content that definitely is going to have to be tested for accessibility.” This is why I chose this post over another one, because it has something that is unique that I didn’t see anywhere else on the site.

The blog news category, then I’ve got that be a guest. I noted there, actually, that it’s not using a Kadence form, it’s using an iframe with a form that comes from Fillout, which is interesting because until I saw that today, I’d never even heard of Fillout, but I guess it’s a form building software, or WordPress plugin? Don’t know. I’m going to have to investigate that, right? Then my episodes finder, I noted when I went there, that there were filters on the left here that are built with Kadence that can be used to filter the posts in the post grid.

I’m like, “Oh, yes, that’s definitely going to require some sort of manual testing.” Because a lot of times with filters, you can’t get everything with just an automated test. I really need to make sure that it’s announcing things to screen readers appropriately. Then I’ve got an example podcast episode, which of course, this is the point of the website. When I just glanced at them, I pretty much went with– I looked at the two top, the Matt Mullenweg one and the, is WordPress market share declining, by traffic and ended up deciding that I was going to test the, is market share declining, by– even though it had less traffic than the Matt Mullenweg one, because it has more content, and it has more different types of content.

So I wanted to have a more thorough example, and not just like a shorter one. Then I also noted, when I saw there that there was a download transcript link that actually goes to a dot HTML file. It looks like a webpage, but this is something that I noted down for myself, because Accessibility Checker, for example, wouldn’t follow those links and wouldn’t scan those. I’m going to need to use a different automated tool, or just straight up manually test it without any automated tools, to make sure there’s no problems there as well, because it is on the website, and any documents on the website also need to be accessible.

The reviews page, it basically has one row of three testimonials right now. It’s the only example of the testimonials block, so I know I want to test it, but because the content is so thin, it also doesn’t show up in my top 10 list, as far as getting a bunch of traffic, which makes sense, because there’s not really much content on there, and it’s not really linked anywhere. I put a note, this is probably my lowest priority for testing. This will be the last thing that I test. Then that marketing, the topic archive. Noted here that this has the same template for co-host, guests, and series taxonomies.

So I don’t actually need to plan, at least in my initial round of testing, to test those taxonomy term archives, because they use the identical template to this marketing topic archive. Then, I just have a section below where I wrote out some notes to myself as I was going through and looking at it, like how is the website built? What plugins and third-party tools are in use? I noted it uses the WordPress Kadence theme. It does not have a child theme, which is important for me to note, because I’m going to circle back to this when I’m thinking about remediation.

I’m probably going to go have a conversation, be like, “Do we need a child theme? Would that be better?” If not, where do we put custom code, right? Some of those sorts of things. I’m just sort of noting things that seem relevant to remediation. It’s built with Kadence Pro, the Kadence Pro plugin, the Kadence Block plugin. All of the podcasting stuff comes from the Seriously Simple Podcasting plugin and add-ons, and then it has this Add to Calendar button plugin, which sort of jumped out at me when I was looking at the plugin list as, “Oh, okay, that might be functionality. That definitely needs testing because it’s probably interactive.”

I didn’t see it on any of these pages, so I’m going to have to go ask Matt, who built the website, “Hey, where is this? How do I find this component?” Again, making some notes for myself. That’s like an initial scope building and trying to figure out what exists that might need to be tested. Then what I usually do is I’ll just real quick, and all of this that I did here, I did in like 40 minutes. It really doesn’t take a huge amount of time to go in and just do this initial audit, and try to figure out, what is the most important content, and what needs to be looked at?

In that same 40 minutes, I looked at, what were the Accessibility Checker findings for the homepage? I filled this in. So, the homepage had 79% passed tests. I do have a note on this document, that automated tests cannot cover all accessibility problems. Manual testing is still necessary to confirm accessibility even if automated tests find no problems. Even if it says 100% passed tests, you can’t just say, “Okay, this page is done. Good.” Right? You still need to do manual testing.

That said, if you find a large number of automated tests, that can give you some ideas on how much time it might take to actually remediate, which is useful information to know as you’re trying to think about how to create realistic goals in a timeline that actually makes sense for that particular website. The homepage on this site had 25 errors, 12 contrast errors, 19 warnings, and I just popped in. I went over to– do I still have the homepage open? Yes, there we go.

I went to Accessibility Checker at the bottom of the homepage, which this part you could just see in the free plugin, and I went to the details tab, and I just found empty link, seven, linked image empty alternative text, six, two, iframe missing title, 12 insufficient color contrast, 10 incorrect heading order, seven ARIA hidden, six links opens new window or tab, five image empty alternative text, and one image animate GIF. I just put that, what the issue name was, and the count in this table, which is found under the issues found on homepage heading. Just, again, I didn’t go in and look at them.

I could tell you right now, I could guarantee you that the six linked image empty alternative text is the exact same as the empty link. I suspect that. That means fixing one thing will fix these two problems, but again, right now, I’m just trying to get a feel, like what’s here, what might there be, what seems sort of empty, or what seems sort of easy to fix, and what might require more work? Then I went to the full site, scan for Accessibility Checker Pro. I looked at the open issues, and one thing I will note, the way this is set up with issue type and count in this table, I actually straight up copy and paste this, and it goes into the Google Doc, and it inserts the rows that it needs and everything.

I’ll just go to open issues, and I’ll go to the table on that page, and I’ll highlight the first row, starting with the check, all the way across type and count, and then I’ll just go down until I get– I don’t include past items. I’m only putting in the items that flagged as problems. I’ll copy it, and if you just go into the first cell, in that table, you can paste it in, and you might need to use, in the toolbar, there’s a clear formatting button, and that will adjust the formatting back to match the font and everything. This makes them all linked, and includes the count, and saves a bunch of time on typing data.

So I’ll do that, and again, this is sort of giving me just some initial, like, okay, what problems exist on this website? What am I high level maybe starting with? So, that is the first thing that I am due. To try and understand where I am. I’d like to take a minute or two, and I’m going to open the chat, and also open the Q&A, but I want to give everyone maybe like three or four minutes to fill a little bit in on that doc, some information about your website. Obviously, I mentioned it took me about 40 minutes to do that for the whole thing, so we’re not going to do the whole thing right now, but just starting to play around with it, see how some of the different fields work.

I am also happy to answer any questions that you might have about how you can understand where you are. Just to get started. Feel free to pop them in. The next section that I do before I can plan out what a timeline looks like, is I need to define my available resources. What do I mean by that? I need to get clarity on what resources I have in-house, or through existing vendor relationships. If you are a developer, then maybe that is you. If you work at a business or a nonprofit that has an agency who build your website, then they are your vendor that helps you with that.

It could be that neither of you have accessibility experience, and so then you might start to realize, “Okay, we actually might need additional assistance.” What you want to do is map out your team capacity and identify an owner for accessibility. Who is the person or the group of people, if you’re at a very large organization, you might have an accessibility team or an accessibility committee, depending upon your organization, but who is ultimately responsible for accessibility on the website? It’s really important that you define that. Because if it’s no one’s responsibility, and no one has ownership of it, then it’s very easy for everyone to say, “Well, that’s not my job.” Right?

You need someone who can be the ultimate bottom line, “I am responsible for this person.” Then you need to identify any potential speed bumps that might slow down your progress, determine what training might be needed, in order to get everyone up to speed, and identify your available budget. Going back to my example, where I filled this out for the WP Product Talk website, we’re going to look at the H2 available resources, there is an H3 team capacity under that, and I have a table here where I list the team member, the role that that person plays, I have some default things in here, the options currently are accessibility specialist, content editor, designer, developer, project manager.

Again, you can add or edit options as makes sense for your organization, but saying, “Okay, who is this person? What are they going to do as related to the website? How many hours per month do they have to contribute to accessibility?” Not to the whole website, to accessibility. Owning that part. The auditing or the remediation of the content or the development. Whatever that might be. Are they a decision-maker? This is also a dropdown with options of yes, no, and unsure. What do I mean here?

There are going to be people who work on your team, who can see a problem, think of a solution, and implement that solution without having to ask anyone else. With the exception of, okay, these are really major choices, right? They are empowered to make decisions to make something accessible right away. There are other people on the team who are incredibly valuable contributors, but they are not a person– they’re more of a doer than a decision-maker.

Meaning that if they see a problem, so for example, they might know that there’s a color contrast failure on your buttons, but they’re just a developer, not a designer, and you have a guideline in your organization that developers don’t make design choices, and so therefore, they’re going to have to go and say, “Hey, this got flagged in a checker, can you tell me what color I need to use?” I think it’s good to be aware of who on the role might be able to ultimately say, “Yes, this is the direction we’re taking,” versus, “Hey, I know there are problems,” and be able to make recommendations, but then someone else needs to be the ultimate decision-maker.

There might be multiple decision-makers, there might be multiple not. I threw a bunch of people in here for our website, just as examples. I don’t actually know that this decision-maker thing is fully accurate, but what I have on this table right now, I put myself in– I gave myself the accessibility specialist role. I’m going to wear a lot of hats on this. I’m going to do some content. I might even do little code fixes. You can put multiple roles on people, so I put Matt Cromwell, and I just copied and pasted that dropdown and put it in there twice, so he has both developer and project manager.

I’ll be totally honest, this is a project that makes zero dollars, and we all just volunteer our time for it. We don’t have any sponsors for the podcast, we don’t have any of that, right? So I’m sitting here trying to think, “Okay, how many hours per month am I going to contribute to this?” Right? I kind of put, “Okay, maybe four to eight hours fits around all of my actual job duties, and what I do for the WordPress Accessibility Day conference.” Starting to think that, how many hours per month? What I have in this chart is probably not realistic for what you have in an organization.

Hopefully, you’re going to have larger numbers of hours. That said, if you are an organization, like in my example, that has a vendor who is a developer, and you know that your contract with them includes, let’s call it 10 hours a month of development support, then you’re going to list the developer, or maybe that vendor company name, and you’re going to put 10 hours. You’re going to know, “We have 10 hours of dev.” Which either means that if we need to move faster, we have to increase capacity with that vendor, or we have to accept that we are going to move a little bit slower because that is a current limitation that we have, because of budgetary reasons.

Starting to put that in. Then just any sort of notes that are helpful for you as you’re thinking about people and what their roles are. Just for purposes of example, I’ve got myself, and Matt, who I mentioned, I just listed us both as decision-makers. It’s Matt’s website. He’s the founder. He goes, he built the whole thing. If he wants to change something, he just goes and changes it. He doesn’t talk to anyone. He said, “Yes, Amber, you can own accessibility.” So I said, “Okay, great.” That means I get to go make changes [chuckles] without asking anyone.

Except for certain things maybe, which we’ll talk about in just a minute. Then I put in Katie and Zach, who are also on our team. I don’t know, I have to go ask them, would they be willing to help with remediation? If so, how much time would they have, right? Again, because that’s going to help me be able to plan and scope this out. Then Maria, on our team at Equalize Digital. Equalize Digital, I said, “Okay. Well, maybe we’re willing to commit two hours of her time if we need her for extra testing to back me up,” or if I’m like, “Hey, I want a second opinion on this thing.” Then I could pull her in.

Just sort of thinking, who are all of the people that work on the website, their role and their capacity, and any other notes that you might need to have. Who is ultimately responsible for accessibility on the website? It should, if you filled in up at the top, the variable for the website organization name, it should have filled that in for you there. This says on WP Product Talk’s website. I wrote myself, Amber. I am the team of one who’s going to own the accessibility on this website.

The next section is all about, what do I need to think about that might slow me down? What are potential limitations or threats to achieving accessibility goals? Items that should be overcome, or that I need to account for when I’m creating an accessibility plan and timeline. The first one is that subheading of in-house skills. I’ve got dropdowns next to it, just to make it easy. Yes, no, unsure. I also like them because I have the yes with green background and white text, and the no with red background. So it’s real quick for me, what’s good, what’s bad.

The questions I have listed out there is, is there an in-house accessibility expert for testing? That’s me, so yes. Is there an in-house person who can remediate PDFs? No. That means that if I discover PDFs on this website, we’re going to have to find a vendor to help us with fixing those PDFs, or we’re going to have to choose to eliminate the PDFs. Is there an in-house person who can caption videos? Yes. That is something that Matt is currently doing already. Do developers have strong JavaScript skills for coding patches? I don’t know. I don’t actually know very much about Matt and Zach’s dev skills as my co-hosts.

So I just left that as unsure, and that’s something that I’m going to have to figure out. If it’s not just a matter of changing settings, and if certain plugins aren’t responsive to feedback, would they be able to write JavaScript to patch it? I’m going to have to figure that out, right? Then the last question there is, is there already an established workflow for making changes to the website that includes staging and review when necessary? That’s a no. If you work at a big organization, I’m hoping this is a yes for you.

If it’s not, that is the number one foundational, and that might be your first goal, is figuring out a really good workflow to make sure that you can test changes somewhere other than on your live website, and that you can version control code. If you have an important website, you definitely want to be version controlling your code, and moving things through an approval process and getting them launched smoothly and as quickly as possible. If you answer no to this, then that right there might be your number one goal. Before you can even start on accessibility is figuring out what a good workflow for managing your website is.

The next section is capacity changes. Again, thinking of our– it’s almost like a SWOT analysis, where you think about your weaknesses and your threats. What could threaten our accessibility progress? I first asked, what changes to the website are planned for the next 6 to 12 months? I go through this with our customers, too. That’s just something I always want to know, because if they’re suddenly saying, “Oh, we’re going to add a whole new product line, there’s going to be a whole new section.” That could really take up a lot of people’s attention. That slows down remediation, right?

Thinking about like, are there any major changes or anything that we need to be aware of in the next 6 to 12 months? All I put for that on this website is we’re going to be adding podcast episodes. I don’t believe major redesigns or other changes are planned, so that’s good. Next question. What other plans could cause distraction or take away the team’s attention? This is where this gets weird on WP Product Talk, but I put this as a volunteer project. If business workloads changes could reduce capacity. We’re all just volunteering. We don’t make money off it.

If our individual companies that we work for suddenly require more of our attention, then that could impact our ability to improve accessibility on the website. It has in the past. This year impacted the gaps in between when we are releasing podcast episodes. Some weeks we just don’t do them, because we were all like, “Hey, we all had to go to a conference for WordCamp.” Then we all had a bunch of stuff happening with our business. That’s the reality of a volunteer project. These things could happen on a business, or a for-profit website, or a organizational university website.

So really thinking critically about what other plans might take away from the team’s attention, so that you can be proactive about them in advance. Then I have a section about approvals, and the two questions under that is, what type of fixes require additional review or approval, and who needs to approve them, and what is the approval process? I listed myself as a decision-maker up there, but the first question I asked Matt when I said, “Hey, can I work on accessibility on this website?” Was, “What things am I not allowed to change without talking to you first?” Because there’s always going to be something. This is a conversation that we have with our clients.

When do they care about seeing it on staging first, or approving a color switch, or a structural change, whatever that might be, and when do they just want us to make it more accessible, and they allow us to use our best judgment as to how it looks and how it functions, in order to make it more accessible? This is what he said to me. He said, “Changes to the podcast player.” He wants to know about that. He doesn’t really want me to make any changes to how guests and hosts are connected to episodes, and then any major structural or design changes.

If I’m going to totally redesign a whole page, [chuckles] when he just did a rebrand, right? Then we should probably talk about that first. Really having a solid understanding on what you, or the team members that you’re managing, are allowed to just go fix, and what things are going to require committee approval, or approval of a single client, whatever that might be, is really important. Then I listed out that Matt needs to be included in these items. Our plan, again, we’re volunteer, we don’t have a whole project management system or anything like that.

So just going to, if something needs to change in one of those things, I’m going to draft a written plan, post in Slack, or stage changes and ask for review via our Slack, that we talk to each other in. You might have a much bigger process for that. Then vendors. This is another area where you can definitely hit road bumps. If the website uses third-party tools that are not negotiable, they cannot be removed or replaced, and those tools have major accessibility problems, it can really slow down your progress or result in a much higher cost, because perhaps you need to have a developer come code a custom patch for those items.

It’s important to identify, what are core things to the website that cannot just be, “Eh, I’ll just swap this plugin for another one.” On this website, the number one is the Seriously Simple Podcasting plugin. That is how all the podcast episodes are managed, and that needs to stay on the website. We’re not going to just swap it for a different custom post type website plugin. Then also, it’s using Kadence theme or blocks. We’re not going to replace the theme host cell.

This isn’t a rebuild, this is a remediation, so we’re not going to be changing those items. Then, just a note there, if you have third-party vendors that are known to be challenging to work with, because you have experience with them, whether it’s a plugin that you have experience with, or a SaaS, the customer maybe already can tell you, “Hey, we’ve requested things of them before and they never respond,” or they say, “Oh, we’ll put it on a roadmap,” and they don’t actually do it, listing that and being aware. If certain vendors are more challenging than others, it can be helpful going in.

I just put none, because I don’t know. I didn’t notice anything when I was looking at the plugin list, but that might change. Then what training is needed? After doing just an initial thing, and that quick glance at what some of the issues were that were showing up, I know right away that we’re going to want to have training for everyone who edits content on the site about best practices for content entry to maintain accessibility on an ongoing basis. This is really common.

Pretty much all of our accessibility remediation plans include this, because once we have a checker on there, we don’t ever want to see things like linked images missing alt text. [chuckles] Because it’s very easy for a checker to tell you, and it’s just a matter of making sure everyone knows how to add alt text onto images, and to always do it, and to not ignore the checker, or things like headings out of order, stuff like that kind of stuff.

The other thing that occurred to me was, it might be helpful to document for the team how to accessibility test when adding a new feature or page, because it’s kind of an experimental website, and sometimes we do things, like Matt spent a bunch of time building that chat functionality, like the chatbot functionality, and I was thinking, “Oh, it’d be important maybe for him, when he’s playing around and trying out things, to also know how to accessibility test them.” That’s what I put under what training is needed. Then budget. Available resources would not be complete without a budget.

I, of course, on this website that makes no money, and that no one gets paid for, it has a budget of zero dollars for testing, zero dollars for remediation, and zero dollars for training. The handy thing here is that we know how to do all of the things, so we don’t actually have to pay anyone, it’s our own time. If you work for an organization that is making money off its website, of any sort, whether those are donations as a non-profit, or actual revenue as a business, then you should have some sort of budget for these things. You just have to figure out what it is and document it so you are aware.

Identifying conformance targets. The next thing that I do, when I start planning out accessibility remediation, is I have to set what my end goal is, and ideal timeline, knowing that the timeline can change based on a lot of things, like what you find when you manual test, and what you find when you start diving into the code, because on some themes, particularly older websites, maybe that are built in a kind of old-school WordPress way, where a lot of things are more hard-coded into page templates, it might require more time to remediate, but we want to set an end goal and timeline.

The first question to ask yourself is, what level of Web Content Accessibility Guideline conformance do you want to meet? By what date do you want to achieve conformance? Then you need to determine how conformance will be measured. This is the next section, in my goal-setting section, where I have that. I have defined that my goal for conformance, again, there is a dropdown here. The options are 2.2 AAA, 2.2 AA, 2.1 AAA, 2.1 AA, 2.0 AAA, and 2.0 AA. I selected 2.2 AA. I would generally recommend everybody strive for Web Content Accessibility Guidelines, 2.2 AA. 2.2 is the most current version.

There are many laws around the world that only reference 2.1, and in the US, Section 508 only references 2.0. However, to be the most forward-looking, you should always strive for 2.2. You might potentially prioritize problems by doing the 2.0 problems first, and then the 2.1 second, and then the 2.2 third, if you want to do it that way, but I would strive doing that. Looking at this website, and again, if we go back and we look at it, it’s actually a rather small website. I’ll scroll back up here for just a second, and we can look at some of the counts, which is sort of helpful.

It had nine published pages, nine posts, only one category archive, no tags. The biggest piece of content is podcast episodes, and there’s 83 of them. Then we have 73 guest taxonomy terms, but those all use the exact same template, so really remediating one should, in theory, remediate them all. It’s a very small website. It’s not without problems, as we saw, when we looked at some of the issues that were listed here, but I don’t know that they’re insurmountable or significant. So, for me, what I decided to set as a goal is that I want this website to be 100% 2.2 AA conformance by June 30th of 2025.

Now, that’s my target conformance date. Once I get in and I start working on it, then that might change. I did see that Nick asked, how do you decide about the As? It seems like different companies have different levels, but I never asked about it. Most laws reference AA, and require AA. Single A is bare minimum, but not actually sufficient for accessibility. From a legal standpoint, and an actual being user-friendly standpoint, is not going to be sufficient. At a minimum, you want to hit AA. That’s why you noticed, in my dropdown for desired conformance level, I don’t offer single A as an option.

AA versus AAA. There are some guidelines that have both a AA and a AAA version. For example, there is a higher level of color contrast needed in order to meet AAA than there is for AA. If you meet AAA, then you also meet AA. If you meet AA, you might not necessarily meet AAA. Tap target size is another one. Like the size of your buttons. They have to be larger for AAA than they have to be for AA. As much as possible, I would try to hit AAA, because that is obviously the best, most accessible website, but there are going to be some instances where that just doesn’t happen and isn’t realistic.

I haven’t really dived a bunch into, for example, the purple that is used in the WP Product Talk logo, with the white to figure out, is that a AA passing or a AAA? If it passes AA, but not AAA, and it does not– then changing that to be AAA conformant would require probably a bigger discussion, because it would be a brand change. As I’ve learned, is a lot of people in organizations are against [chuckles] color brand changes. It can be challenging. That’s sometimes one where you just say, “Okay, fine. I’ll take the AA, in some spots.” You sort of have to weigh it on the organization.

Another difference is, I think Gary mentioned this, ASL interpreters in videos, in addition to captioning and audio description. Yes, AAA would require audio description. It would require ASL interpretation for every video, and there is a cost to that. It also, a difference there, which WP Product Talk is a podcast that live streams, and when we live stream the podcast, it’s going to have automated captions. Because we don’t have a budget and we don’t have sponsors, we don’t have live captions for that like we have for meetup. They are automated captions, not human-generated captions.

Now, they get human-corrected captions and a human-corrected transcript after the fact. That is considered AA conformant. If we wanted to hit the AAA, we would have to have live captions for the live streaming podcast. If we determined, as a group of co-hosts, that that’s what we wanted to do, then we would probably have to have a conversation about who is paying for that, and are we now going to start seeking sponsors for this fun side project that we have, so that we can make it more accessible? Those are things that you have to weigh a little bit when you’re deciding on what conformance level to target.

I would generally start with AA, and then assess at an individual level the different AAA success criteria, and determine which ones realistically you can meet based upon budget and time. The next thing I have under there is, how will conformance be measured? This is important, just trying to literally write out, are you going to actually test to confirm that you are meeting that? What I wrote is that it’s going to be a combination of manual and automated tests performed by Amber. Maria, from the Equalize Digital team, is available for backup testing when needed.

Then what I determined was that when the website is determined accessible, I’m going to cover the cost of bringing in a user for a user testing session, and we are going to record and publish that to the web. The thing I actually haven’t said about this is that next year I’m going to live stream all of this to the Equalize Digital channel, because I think it will be interesting to show, but I want to actually have proof with someone other than me that, yes, this is accessible. So, where possible, I like to have an actual user who might represent someone who would listen to the podcast, or be a guest on the podcast, come and use the website and give us feedback.

Under the additional conformance notes, you might leave this blank. Some thoughts that I had that I added in here specific to this project was, I decided that I am going to report via a VPAT. You don’t frequently make VPATs for websites. They tend to be more for software, but we are going to do one for the website. If any third-party tools fail, we’re going to report this publicly on the tools GitHub or WordPress support forum, because we want to be really transparent. Oh, this is where I said it. This is going to be a test and remediate in public project. So, everything’s going to be transparent to the public, and live streamed on Equalize Digital’s YouTube. That was just a note that I had with a goal.

That’s covering conformance. How we’re going to measure it, how we’re going to report on it. I’m guessing a lot of you, maybe give me like a reaction, like a thumbs up if you know about SMART goals. [chuckles] I think most of us know about SMART goals, but I will go through that with this image that I borrowed from Indeed, the job website. It is, the image source is linked if you want to go check it out. SMART is an acronym that stands for Specific, Measurable, Achievable, Relevant, Time-based.

When you are writing goals, it’s really important to not write kind of loosey-goosey, like, “I’m going to make the website accessible.” Because it’s hard to track it, and it’s hard to stick to it when you don’t have a timeline. This is what those things stand for. Specific means make your goals specific and narrow, for more effective planning. Measurable, make sure that your goal and progress are measurable. Achievable, make sure that you can reasonably accomplish your goal within a certain timeframe. Relevant, your goal should align with your values and long-term objectives.

Then they should be time-based or time-bound depending on which infographic you look at, [chuckles] and that basically means set a realistic but ambitious end date to clarify task prioritization. An example that I came up with for my first goal for this website is during the first two weeks of January, I’m going to perform a review of the Accessibility Checker reports and a manual audit of the homepage and then create a priorities list for remediating the header, footer, and homepage content by February 20th, 2025.

I give myself more time on that than I probably am going to need on any other page because, one, the homepage is long, but also the homepage encompasses fixing the header, fixing the footer, and then you remember I had that note about the chat, which, to me, is a total wildcard. It could be really good. [chuckles] It could also maybe be quite difficult to remediate depending upon how it’s been built out. I have a section here where I list out, in a table required people, required budget, and required time.

In order to achieve this goal, which is doing the audit and then creating a plan, it’s going to be me and Matt largely. Remember, we’re not spending any money, we’re doing it all ourself, and I’m thinking it’s going to take about six hours. Then I always like to put subtasks required to achieve each goal because my goals are more like high-level, big, but there’s tiny milestones that have to be hit along the way in order to actually achieve that goal, so I will list these out and also make them as smart as I can by saying who’s going to do it and giving a deadline on them.

On January 2nd, I’m going to manually test the homepage, ignore any false positives in Accessibility Checker and create a comprehensive list of issues. By January 9th, I’m going to prep an agenda for a meeting with Matt to discuss the status and our plan of attack. Then on January 16th, Matt’s going to join me on a livestream and he and I are going to meet in public to discuss issues, priorities, and delegate tasks. That’s the initial thing. Then my next section under the goal after Subtasks is possible blockers to overcome or questions to answer.

Some questions that I had just initially was– I mentioned this earlier, I noticed when I was looking at it that it doesn’t have a child theme, so this was a question I had, do we need to switch the website to have a child theme? If not, where does custom code go? I don’t know. Do we want to create a staging site and a Git repository for the theme and define some sort of workflow? We’d only do the Git repository if we had a child theme, but do we want to do that or do we want to cowboy it because it’s our personal side project? [chuckles]

Not a real website, right? We got to figure that out. How flexible is the chatbot? How necessary is it? This’ll be a conversation that Matt and I will probably end up having. If there’s a lot of problems with the chatbot and we determine that accessibility is more important, is it okay to just say, “Remove,” right? These are the kind of things you have to start thinking about, how do you weigh keeping something that is totally inaccessible versus fixing it, versus replacing it with something else, right?

There’s a lot to unpack there. Then some possible blockers. If there are issues related to Cadence, then they would need to be reported to Cadence and that may delay the remediation timeline. That’s not saying anything bad about Cadence team. It’s just the reality of when you report something to a vendor or a third-party developer, you have no control over their priorities. They might turn around, and I suspect they will turn around and fix things very quickly because anytime I’ve reported something to Ben and Cadence team, they’re super-fast.

That said, I don’t know. Maybe he’s sick. Maybe that will add a week to our timeline, whatever that might be. Then the other possible blocker that I just noted, once I get in and audit that, there could be more work than fits in the available time. If the goal is to have header, footer, homepage, fully WCAG conformant by February 20th, maybe once I get in an audit, then I’m going to have to adjust that. That’s my example goal and some of my thinking behind it.

This is the part where I want to talk just briefly about how I would prioritize some fixes and then give you all some time if you want to work on it or Q&A, or people can leave a little early, whatever makes the most sense to you all. How to prioritize fixes, the way I would think about it when you’re looking at your website and you do that initial scan or do a manual test by tabbing through or using a screen reader, you’re going to get a lot, right? What we saw was big numbers in certain things and so sometimes it’s hard to know where to start.

Number one, global elements. Then within these, I actually have them listed in order of importance. Number one in number one is “visible focus outline.” I put this first because, one, it makes your own testing way easier. If there’s no focus outline around things when you hit “tab” and you can’t tell where you are, it makes it really hard to accessibility test. Also, it is and should probably be a two-minute fix, maybe a little bit more if you have to do whack-a-mole on some specific classes that are removing focus outlines, but it’s a very easy CSS fix.

It’s one of the first things that I would just straight up fix on a website, and it can have a big benefit for a lot of sighted keyboard-only users. Number two is navigation. Navigation requires a lot of manual testing and also very frequently, depending on how the website is built, can require developer intervention, but if the navigation on a website does not work, people will not be able to do what you want them to do on the website. After the visible focus, that is what I would do.

Then I would fix any problems related to site search because what I have observed in all of our user testing sessions is that if someone is looking for something on the website, a screen reader user, they almost always try to use search, especially if the navigation doesn’t work super well, but sometimes even when the navigation is great, if there’s a search available, they’re going to do that first, so fix any problems related to search, then anything else that you have in your header.

Making sure your logo has the correct name, don’t just say, “Equalize Digital Logo.” It should be like, “Go to Equalize Digital homepage,” if it’s linked to your homepage. Those sorts of things. Anything else that’s there and then go to your footer after you do your header. Then, from a priority standpoint, you want to look at critical blockers. What am I going to do after the homepage on the WP product type website? I’m going to go look at the two pages that have forms, the “contact” page and the “be-a-guest” page.

I want to make sure that all of the forms function, that they are labeled appropriately, they can be submitted, and all of the notifications and confirmation messages can be heard with a screen reader. Forms, critical blockers. Empty links, empty buttons are the next two. Empty links and empty buttons can typically almost always be found with an automated checker, so you could find those lists of those to fix in Accessibility Checker. The next item, non-semantic buttons. That is things like a “next” or a “previous” arrow on a carousel, but it’s actually coded as a div, or span, or just an image, without a button tag or even a link tag.

They shouldn’t be link tags, but that would be better than nothing. Those require manual testing but really thinking about, what’s going to stop someone from being able to actually use something? I would look at tabs and accordions here for this non-semantic buttons because if you have, for example, an FAQ page, where every question about your organization is an accordion that’s collapsed, and the answer is collapsed and cannot be read, and then the question is not wrapped in a button, so there’s no way to open it, then a lot of users are not going to be able to get important information. Any non-semantic buttons need to be fixed.

Number five, videos without captions. You might prioritize this a little higher, depending upon how important the video is. For example, on our podcast website, if we had videos and that was the only way to get that content– there wasn’t transcripts, the whole purpose is to go experience the podcast and learn about it, then that becomes a major priority because now we’re blocking a whole bunch of people from actually consuming the point of the website, right? You have to fit that in.

A video on a product page that sells a product without caption is probably more important than a random video embedded on a blog post that hardly anyone goes to, so you have to figure out priorities. Then the same thing, important PDFs. If you have PDFs that are really, really key to understanding the product or maybe, for example, knowing what size, [chuckles] like how size is mapped to a human body so that someone can choose size and that’s a PDF– One, maybe don’t make it a PDF, but if it is a PDF, then that would definitely be what I would consider an important PDF that would have to be fixed and make sure that it’s accessible.

Then after critical blockers, we go to any pages where conversions happen, and I do a reverse funnel. I’ll look at a checkout page first, then the cart page, then the product single or any place where somebody can add something to the cart, going from the bottom up on a funnel, looking at any contact pages, email signup forms, so where do people subscribe to your email newsletter? And, of course, live chat widgets. Then after I’ve done all of those pages, this is when I look at other high traffic pages and fix those.

Number one on that would be if you are paying for ads and you have landing pages where you are actively driving a lot of traffic to them, those come first and then the next would be any pages that bring high organic traffic. This is the same thing in Accessibility Checker. If you get the open issues, which I have a screenshot of the open issues table here just from a fake website, I would look for critical blockers again. Color contrast can be sometimes an easy-ish fix. If you have a theme that’s using global colors, you might only have to change a color code, and it will roll out across the whole website. That’s pretty high priority because, again, depending upon how low the contrast is, that could benefit a lot of users to improve that.

Again, empty links, linked images that are missing alternative text, any issues with forms. Duplicate form labels or if you have fields that are missing labels and flagged that way in Accessibility Checker, those would be considered critical blockers. Broken skip or anchor links, also a critical blocker. Then sometimes I look at things that are quick global fixes. For example, our warning about “link that opens new window or tab,” we have a plugin that you can install that adds warnings for those instantly. On this particular sample website, there’s 7,270 of those. Well, I’ll just install and activate that plugin, and those warnings all go away. [chuckles]

It’s a nice, quick fix. Any items in sidebars, header, or footer, things that show up on global pages. Then, as I mentioned already, always we’ll assess videos or PDFs because we have warnings that will tell you where PDFs are, or any sort of elements that might require outside support, I usually try and get– even if I’m not doing it, if I’m having my clients do that, I’ll give them an export of, “Here’s all the PDFs you’re linking to from Accessibility Checker.” I put it in a spreadsheet and I’m like, “Go through and decide, delete, archive-“– so we’re moving it to a separate archive section of the site, “-or remediate and keep,” because my assumption is, and it’s almost always right, that they’ve never made them accessible ever, so there’s not any that are already accessible.

There could be an option of, “It’s already accessible,” and tell us that. I’ll have them go through that because that is something that just a content owner can do and then we know, “Okay, well, this is going to take time.” We first have to assess them, figure out what needs to be remediated. Then we have to go to a vendor and talk to the vendor and get quotes and then sometimes they have to get it approved with budget, right? There’s a lot of pieces there so I don’t like to save that stuff to the end because it’s a bummer to be like, “Hey, the website’s almost all accessible, but you have all these documents now and this is going to add two or three months to your timeline.” [chuckles]

I try and do that early so that you have time for a vendor to be helping and working on those things or someone internally, if you have someone internally to do that while you’re fixing the website. I did my example goal out of order and that’s where I was going to leave things. Again, I am super open to answering any questions. If people want to hang out and talk, I would love to hear any goals. If anyone would be interested in sharing a goal that they have for accessibility for next year, if they’ve thought about any smart goals, anything that you want along that line.

Paola and I can chat as well if you just want to hang out and work on your worksheet.

>> PAOLA: I haven’t seen any questions. One that Nick asked is that do you prioritize based on desktop, mobile, or do they have the same priority?

>> AMBER: Yes, we don’t typically prioritize desktop or mobile different because a lot of the mobile elements need to be tested at the same time that you test desktop because one of the things that you need to do when you’re testing is you need to zoom in on the website both to 200% and 400% so that you are experiencing it as a low-vision user would. When you do that, you typically get the mobile experience of the website just on your desktop computer, so the mobile nav will come in and you’ll test it.

We don’t necessarily have to say, “Fix mobile separately.” I would fix the mobile menu at the same time as fixing the regular nav. Even if, in WordPress, they are sometimes totally different components, which is a little weird, but they are, I would fix them at the same time as part of that header navigation priority.

>> PAOLA: That makes sense, yes. Gary asks, “Is your template trademarked or are you good with people using it and modifying it?”

>> AMBER: I did put a little copyright at the end. It is, we are sharing it for people to use internally, share it within your organization. If you want to use it with your customers in your own process, if you’re an agency, that’s totally fine. What I ask you not to do, please, is do not distribute it. Do not sell it. When we put up the recording of this meetup, we are going to have a form that allows people to get access to it, which helps us because they enter their email address and then we get more people on our email list.

Yes, you can modify it, use it however makes sense for your organization and your personal use, but please don’t mass distribute it.

>> PAOLA: Yes, and I do not see any more questions. I do see a lot of people saying that they loved the talk and that this was a great example of how to go through the process for planning accessibility. I do want to add this talk is a follow-up to Chris’s budgeting talk that he had earlier this month. Over there, you can actually find all the prices and the math of most of the items that Amber talked about. Here you get the planning. Over there you get the numbers. They go hand in hand as well, and both of them will be linked in the recap as well.

>> AMBER: That one’s not up yet, though, right? I think we’re still waiting on the captions from the caption company, is that right?

>> PAOLA: We’re getting it up sometime this week, yes. It’s not up yet.

>> AMBER: We can grab that link– I know someone had asked for the link again to the template. This is just a short URL redirect. It’s equalizedigital.com/a11y-planning, and that will redirect over to that Google Doc template. I will put a little thing in here as well as a sidenote. We are planning our roadmap for Accessibility Checker, and if anyone is so inclined, we– Oh, wait, I’m only sending my things to hosts and panelists. Look at that, I didn’t follow my own instructions. We’ll have to pop that link in there because I didn’t put it in for everyone.

If anyone’s interested in filling out our– we created a survey for Accessibility Checker about features that people are interested in. You don’t have to be someone who– you can even say, “No, I don’t currently use it,” and then tell us what features that you want to see in it anyway. That’s fine. If anyone is willing to do that, we’re trying to plan out our internal goals because, as I mentioned, we’re super big into goals at Equalize Digital and we want to build things that people like.

It looks like Paola sent the template link the right way since I failed to do that before, so that should be in the chat as well. Oh, Karolina asks about the new window warnings plugin. That is on– You’re so much faster than me, Paola. [crosstalk] That is on wordpress.org. Paola put a link to it in the chat, but it’s just called– you can search it in the back end of your website, too, “Accessibility New Window Warnings.” It just adds an icon and an ARIA label that warns people, both sighted people and screen reader users, that it’s going to open in a new tab, and it does it dynamically for all links. I like fast fixes. We added some fast fixes in the plugin recently, which has been interesting to see what we can do and do well.

>> PAOLA: That is true, yes.

>> AMBER: Ricky shared a goal with us. He said his goal for 2025 is to make the TPGI, which is a huge digital accessibility agency website, accessible. Hey, look, we all have internal things where we have not done as well for ourselves as we’ve done for our customers. You might just want to try and make it a little more smart, Ricky, with a timeline and what it means. [laughs]

>> PAOLA: The shoemakers’ children go barefoot. [laughs] That’s a funny–

>> AMBER: Yes, exactly. Well, I’ll fuly admit that was the thing with WP Product Talk, and Matt worked really hard on it. I think it’s a beautiful website but then I was like, “Oh, man, I’m the accessibility person.” I went and looked on, and I was like, “Hmm, it could use a little improvement.” I was like, “Okay, this is my goal. I have to figure out how to fit it in around all of my other things that I do, but I really want to do it.”

I’m going to– I’m pretty sure what I’m going to do is I’m going to be livestreaming on YouTube on the Thursdays that we don’t have Meetup, so three Thursdays a month, starting on January 2nd. I said it here, and I listed it as a sub-item in my goal, I will audit the homepage live on YouTube, and people can tune in and watch if they want. We are at time.

>> PAOLA: We are exactly at time, yes, so let’s just wrap everything up. Amber, thank you again for this amazing talk and for taking the time to create the template so that everyone can go ahead and use that for their 2025 planning. Thank you, everyone, for attending our meetup. I’ll just let the captions sink in and we will see you next year on January 9th, and that’s going to be on a Thursday, 10:00 AM with Michaela Lederman and Eli Frigoli. They will be talking about more accessibility and mega menus. Thank you, everyone, and have a great rest of the year.

>> AMBER: Bye.

View “Accessibility Strategy and Goal-Setting Workshop” Google Slides.