This episode is a recording of a November 2024 WordPress Accessibility Meetup where Joe Dolson, well-known accessibility consultant and WordPress plugin developer, shows how accessibility can be improved and maintained throughout the lifecycle of a software product. WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend. If you want to watch a video recording from the meetup, you may do so on the Equalize Digital website: Managing Plugin Accessibility for the Long Term: Joe Dolson.
Listen
Summarized Session Information
In this session, Joe Dolson covered the challenges and strategies for maintaining accessibility in WordPress plugins and other software. Using detailed case studies, including Notepad++ and Sonos smart speaker apps, Joe showcased the consequences of accessibility regressions and the importance of continuous testing, user engagement, and proactive planning.
Joe provided practical advice for plugin developers to future-proof their applications and stressed that accessibility is an ongoing commitment to inclusivity and user trust.
Session Outline
- Introduction
- The importance of maintaining accessibility
- Challenges in WordPress plugin development
- Strategies for sustaining accessibility
- Addressing front-end complications
- Ensuring accessibility during refactors
- Practical advice for plugin developers
- Closing thoughts
Introduction
Joe Dolson is a WordPress plugin developer, a web accessibility consultant, and an educator on LinkedIn Learning. He is also part of the Make WordPress Accessibility Team, a WordPress Core Committer, and a co-founder of WordPress Accessibility Day. Joe is a leading voice in accessibility, dedicating substantial time weekly to improving WordPress accessibility.
The importance of maintaining accessibility
Accessibility regressions are situations where previously accessible software becomes inaccessible due to changes or updates. These regressions often result from insufficient testing and poor planning, leaving users with disabilities unable to use software they previously relied on.
Accessibility as an ongoing process, not a one-time effort.
Case study: Notepad++
In February 2022, Notepad++ released version 8.3.0, rendering the application entirely unreadable by screen readers on 64-bit systems. The issue arose from a technical update that changed a variable type, inadvertently breaking compatibility with screen readers accessing the application via the Scintilla API. The oversight stemmed from a complete lack of accessibility testing prior to release. A simple screen reader test could have identified the issue, avoiding significant user disruptions.
Case Study: Sonos Smart Speaker App
Sonos launched a completely rebuilt app in May 2024, which significantly degraded accessibility compared to the older version. The new app’s functionality was initially so limited that users could only navigate elements but not interact with them effectively. Sonos’ decision to release the app prematurely, while acknowledging known accessibility gaps, left users unable to control their devices for months. Joe criticized this decision, emphasizing that accessibility is a trust-based relationship with users, particularly when they have invested in a product for its accessibility features.
Challenges in WordPress plugin development
Shifting the discussion to WordPress, there are unique challenges that plugin developers face. Unlike standalone software, WordPress plugins operate within an interconnected ecosystem of themes and other plugins, creating complex dependencies that can lead to unforeseen accessibility issues.
Long-term degradation
The concept of long-term degradation is where features that were once accessible become outdated as standards and user expectations evolve. Joe shared a personal example from his WP Accessibility plugin, where a feature designed in 2012 no longer met modern accessibility expectations by 2022. This highlighted the need for periodic reviews and updates to keep plugins aligned with current best practices.
Component and dependency updates
Updates to dependencies, such as jQuery libraries, can introduce regressions if not carefully tested. Developers should maintain detailed change logs, monitor updates to third-party components, and test integrations thoroughly to identify potential issues early.
Major refactors
There are also risks associated with major refactors, particularly when rebuilding large sections of code. It’s important to engage with users with disabilities in the process to identify features they rely on and ensure these are preserved or improved. The Sonos case study is an example of the consequences of neglecting user input during significant redesigns.
Strategies for sustaining accessibility
Joe proposed several strategies to help developers maintain accessibility over time:
- Date features: developers should document when features were last reviewed for accessibility to help identify outdated elements.
- Build ahead: implement emerging standards and forward-thinking features to future-proof applications, even if they are not yet widely supported.
- Continuous user testing: regular user testing is essential to understanding changing expectations and catching regressions early. Testing should go beyond new features to include legacy components.
Addressing front-end complications
There are some challenges of maintaining accessible front-end components in WordPress plugins. The most common approaches are:
- Gradually staging updates to avoid overwhelming users.
- Allowing users to enable new features selectively, as seen in Gravity Forms.
- Increasing CSS specificity to minimize conflicts, though he cautioned against overly rigid CSS that could hinder user customization.
Ensuring accessibility during refactors
It’s important to plan and include user involvement when refactoring accessible applications. Key steps include:
- Identifying strengths and weaknesses: developers should assess what users appreciate and find challenging about their application.
- User involvement: engaging users with disabilities during the planning and testing phases helps identify critical areas for improvement.
- Avoiding broken updates: developers must avoid introducing regressions in previously accessible features during updates.
Practical advice for plugin developers
Joe concluded with actionable advice:
- Regularly review your plugin for accessibility issues.
- Involve users with disabilities to gain valuable insights.
- Prioritize addressing issues in critical features first, balancing improvements with ongoing updates.
Closing thoughts
Accessibility is a continuous journey. Developers must prioritize accessibility at every stage of development to create inclusive and reliable products. You should view accessibility as an investment in your users’ trust and satisfaction.
Transcript
>> CHRIS HINDS: Welcome to the Accessibility Craft Podcast, where we explore the art of creating accessible websites while trying out interesting craft beverages. This podcast is brought to you by the team at Equalize Digital, a WordPress accessibility company and the proud creators of the Accessibility Checker plugin.
And now, on to the show.
>> AMBER HINDS: Now, I am very excited to introduce Joe Dolson. I added a spotlight, so you should all be able to see him. If you’re not familiar with Joe, he is a WordPress plugin developer, he’s a web accessibility consultant. He owns a company, as I mentioned before, called Accessible Web Design. He’s part of the Make WordPress Accessibility Team, which works on WordPress Core, and he’s a WordPress Core Committer and contributes, I think, is that six hours? Might not be accurate anymore. It’s much more than that.
>> JOE DOLSON: That is not accurate. No, no.
>> AMBER HINDS: I’m looking at this bio and I’m like, I’m pretty sure Joe contributes at least 20-plus hours to building WordPress each week.
>> JOE DOLSON: Officially, I contribute 12 hours a week.
>> AMBER HINDS: Oh, okay. 12 hours. Seems like it’s more than that.
>> JOE DOLSON: That’s the official amount of time.
>> AMBER HINDS: Twelve hours per week. He is also on the board of the WordPress Accessibility Day non-profit with me, and was the founder of WordPress Accessibility Day Conference. He teaches WordPress accessibility on LinkedIn Learning. He is pretty much the de facto WordPress accessibility expert, is what I’m trying to tell you. I’m so excited to have you here and thank you so much for coming and speaking with us, Joe.
>> JOE DOLSON: Thanks so much for having me. I’m really glad to be here.
>> AMBER HINDS: I’m going to let you take over sharing. I am going to turn my camera off, but just so everyone knows, we have the Q&A module available in Zoom. If you have any questions as Joe is talking, if you can put them in there, I will come back at the end of the presentation and pass those along to Joe, and we’ll do Q&A at the end. Thanks, Joe.
>> JOE DOLSON: All righty. Well, thank you very much. I am really glad to be doing this talk. This is a little bit unusual for me as a talk goes, because it’s really a lot less technical and it’s much more about planning and strategy. It’s really about the long-term. This whole talk is basically about what happens next. Because what we have really is a scenario where you build a plugin or any kind of application. Really, this talk is applicable to almost any kind of software. You improve it, you end up with this great accessible tool, and then regressions happen. This is really about regressions.
This is about what happens after you’ve made your application accessible, because really it’s not enough to make your application accessible. It needs to stay accessible. Most people with disabilities have almost certainly encountered accessibility regressions at some point, sometimes frequently. Everybody is frustrated by the miscellaneous design changes where settings move around and defaults change, and these impact people, but they’re not necessarily huge problems in and of themselves. Accessibility regressions can be catastrophic, and they can be more frequent than other issues. Why does that happen, and what can we do about it?
First of all, are they really common? I’m going to say just flat out yes. I’m going to raise a few examples of some major catastrophic cases, but the reality is they are an ongoing constant issue. Regressions happen all the time. This happens because there’s really not a lot of implementation of automated accessibility testing in the ecosystem. The automated testing that does exist, and all automated testing, is fundamentally limited.
It doesn’t do an enormous amount to actually resolve all of the potential problems, because user testing focuses almost entirely on new development and doesn’t tend to look nearly as much as it should at everything you’ve already done, and because development just tends not to prioritize accessibility. How real is this? What are some real-world examples? Well, I’m going to first start with a case study on Notepad++. Notepad++ is a fairly popular application. It’s a simple text editor for writing code. It’s not a full-on IDE. It just has some basic tools to help make writing code easier. That’s where I got my start writing HTML from scratch in 2000. We’ll leave the numbers out. That was a long time ago.
Version 8.3.0, that released on February 4th, 2022, was completely 100% unreadable with any screen reader. Obviously, this is a catastrophic change. Anybody who is attempting to use it completely lost that ability. What happened? Well, it was based on a technical change where they changed from a long variable type to an INTP variable type to manage character position representations. That’s highly technical, and you don’t need to know the details. Screen readers were accessing this via something called the Scintilla API, and it expected a long variable type.
Because that failed, all screen readers were unable to access it in any way whatsoever if it was on a 64-bit system, which, honestly, the vast majority of systems were 64-bit at that point. This is obviously a devastating problem. A lot of people are developers who are screen reader users, and they require these tools. Suddenly losing all access to the content, and in fact, on NVDA, it actually caused Notepad to completely crash, so you could really get no information at all. Disastrous.
It was fixed because screen readers released updates that branched how they treated that API based on the system architecture so that they could read the content in either environment. What went wrong in the Notepad++ development? This technical change actually made sense. It was necessary. They needed to do it in order to support a certain type of file, essentially large files. They did no accessibility testing of the release, and therefore had no upstream communication to screen reader makers.
A very simple test could have caught this problem, and they might have just needed to delay the release to communicate upstream and say, “Hey, we have this problem, we need to do this. What’s going on?” The difference would have been significant. If they had done even a single test with any screen reader, they would have quickly discovered they couldn’t do anything.
That’s a catastrophic example of a lack of testing. Now I’m going to look at another type of study. This is the Sonos smart speaker app. Sonos speakers are a tool for basically sound management in your audio system. They released a brand-new app that they rebuilt from the ground up in May 2024. This new app almost completely broke every aspect of accessibility for users. The new app was released along with discontinuing their existing web interfaces and their previous app had been highly accessible. The fact for both of these applications that before these problems, they were already very accessible is a lot of what caused this to be a big deal.
I have to be a little hypothetical to talk about what happened internally at Sonos because they don’t have a public development environment where you can look and check in on this, but you can make some fairly straightforward guesses about what was happening. Clearly, they didn’t have a lot of good testing. Mostly, I feel they had a premature release and they failed in that process to take accessibility into consideration. They failed to recognize that losing accessibility of an existing application creates a significant degradation of their service.
How was it fixed? Well, it was gradual improvements in the app, which they had predicted. They had actually informed people that was going to be what happened. As of July 15th, there were public presentations reporting that it was possible to use, but definitely not as good as before. This is a solid two and a half months after release. It’s just, eh, it’s okay.
What went wrong? This is Sonos’ announcement on accessibility prior to releasing the app. They stated explicitly, “On May 7th, the app will have basic support for screen readers, allowing you to swipe through and read through all items on the screen. Following launch, ongoing improvements to the accessibility of the updated mobile app will remain a top priority. A software release available May 21st will improve screen readers so you can select items on the screen in any order. Further improvement will be added to the experience regularly until we reach parity with the S2 app by late June.” You may already be realizing there are some big problems with this statement.
This announcement is basically ethically indefensible. I’m going to break it down a little bit. First of all, they say basic support for screen readers. What is that? What does basic support for screen readers mean? To me, it means everything can be read, everything can be interacted with, and screen readers’ work. Because anything short of that is not support for screen readers.
The next thing I have to call out is that you can swipe through and read through all items. Oh, I’m sorry, this is an interactive app. If all you can do is read items, then I don’t understand how you’re supposed to be able to use it. Are you in a situation where now you’re expecting somebody else to actually control this, but at least you can find out what’s going on. May 21st will improve screen readers so you can select items on screen in any order. You already know that two weeks later it will have better accessibility. Why are you releasing today? Why not delay for two weeks?
Finally, you will reach parity with the S2 app by late June. You have a plan. You have a schedule for accessibility, and you know exactly when you’re going to achieve the level of accessibility you want. Why did you release it on May 7th? What was the reason that you couldn’t wait two months to release a version that wasn’t going to leave a large percentage of your customers in the dust? Because really, here’s one of the things about an app that is accessible, and that’s that people invest in that product.
Screen reader users bought Sonos environments. They spent thousands of dollars on speakers and systems so that they could use this because it was accessible. By making this kind of a release plan, you are effectively telling them, “Oh, well, we don’t really care about your business. We’ll get there. It’s fine.” Two months without listening to anything isn’t a problem. Clearly, this is a problem. Though, obviously, you’re probably thinking to yourself at this point, how exactly does this apply to WordPress products?
Of course, there are some significant differences going on when we talk about WordPress. WordPress is very different from these apps. Very few WordPress plugins or themes actually are highly accessible. If you’ve spent a lot of time looking at WordPress plugins and themes, as I know some of you have, you know that there are a lot of accessibility gaps.
Most of those that have become accessible, for example, you’ve got Gravity Forms, which is really only accessible on the front end, are in their first phase of accessibility. When I say first phase, what I mean is this is the first time that they have brought their application into the realm of being accessible. Right now, they’re in that improve phase. They are gaining clients because those clients care about accessibility. They are at the point where now, if they want to make future changes, they have to be prepared for what might happen.
Of course, in the WordPress environment, most changes are, in fact, highly gradual. Relatively few plugins do a just gigantic rewrite of everything so that now it’s a completely different fundamental code base. That is one of the reasons that that Sonos app had so many problems, is rather than revising something, they scrapped it and started over. Sometimes there’s a good reason for doing that, and that’s okay. It is a risk.
There are certain types of changes that always have to be watched out for. This is going to be true in all products, but particularly when we’re talking about WordPress products, what exactly is going on? One of them is what I like to call long-term degradation. I’ll go into that into some depth. There’s component and dependency updates. This is what happens if you’re dependent on a particular system. Say you’re using jQuery UI, and jQuery UI releases an update. You are dependent on how that changed. The way it changes is what defines for you how your interface actually works. Then, of course, as I discussed earlier, there are major refactors.
Long-term degradation. What exactly does that mean to me? Because, of course, this is my talk, and I made this up. This is all what I think. Let’s hypothesize. Launch day is today, November 18, 2024. You’re really excited. You’ve got your new product out. Woohoo. There’s a graphic on the screen. It is a very colorful woohoo. It’s rather comical. This application is fully tested with users with disabilities, and it meets all known and active accessibility standards. It meets all the best practices. This is really great. This is fabulous.
10 years later, we now have a graphic which is the same word, woohoo, but it’s in graffiti on a concrete wall. Everything’s looking a little rough. Is this still accessible? Does it meet today’s standards, and does it use today’s best practices? That’s actually a fairly complicated question. First, how do we actually define accessible? I tend to break this up into three subsections. The first one is, is it possible to use? The second one is that it meets standards, and the third one is that it’s pleasurable to use. It’s actually a good experience. What’s possible to use? 10 years later, it should still be possible to use.
The reality is, if you’ve worked on something up to conforming with standards, the fundamental fact about conforming with standards is that they are comprehensible by software. The software knows what to do with something that meets some past standard, and so it’s undoubtedly possible to use, barring some kind of major technological breakdown.
What about meeting standards? Well, this one is a little bit more complicated. If it met a standard previously, it will still meet that standard. That’s just how standards work. Meeting standards is not about being accessible. Meeting standards is about being consistent with a recognized set of guidelines. You could still today create an application that met WCAG 1.0. You can still write code that conforms with HTML3 if you want. That would meet standards, but it doesn’t make them good. It just means they meet a standard.
10 years from now, WCAG 2.0 will be 26 years old. It really shouldn’t be the foundation of any accessibility standard 10 years from now. Whether you will meet a standard that’s recognized in law 10 years from now, with WCAG 2.2, for example, well, you might.
Laws move painfully slow sometimes, and that might be the case. What I can say is you will meet a standard. Whether you’ll meet the best standard, the recommended standard, or the legal standard is not something anybody can predict. Will it be pleasurable to use? This is where things start to get really into the rough. Whether it’s pleasurable to use or not can ultimately only be answered by a user. This is where user expectations really start to come into play. Who knows? Maybe it’ll be pleasurable to use, maybe it won’t. Let’s talk a little bit about what some of the types of user expectations that can change whether something is pleasurable to use or not might be.
>> STEVE JONES: This episode of Accessibility Craft is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish. 1000s of businesses, non-profits, universities, and government agencies around the world trust Accessibility Checker to help their teams find, fix, and prevent accessibility problems on an ongoing basis.
New to accessibility? Equalize Digital Accessibility Checker is here to teach you every step of the way. Whether you are a content creator or a developer, our detailed documentation guide you through fixing accessibility issues.
Never lose track of accessibility again with real-time scans each time you save, powerful reports inside the WordPress dashboard, and a front-end view to help you track down hard-to-find issues.
Scan unlimited posts and pages with Accessibility Checker free. Upgrade to Accessibility Checker Pro to scan your website in bulk, whether it has 10 pages or 10,000.
Download Accessibility Checker today at equalizedigital.com/accessibility-checker. Use coupon code accessibilitycraft to save 10% on any plan.
>> JOE DOLSON: Here’s an example from one of my own plugins, the WP Accessibility plugin. When I built it in 2012, I added a feature that allows you to display long descriptions, basically takes the description field from the media library and presents it as an overlay on top of that image triggered by a button so that you can read it. It was a fun, cool feature. At one point when we were building the WP Accessibility Day build, Raghavendra Satish Peri, who was performing some accessibility testing on the site, flagged it as an error. This was in 2022.
That was a little bit of a catch to me. I had to think about that. I was like, “Oh, wait, I built that myself.” I hadn’t actually looked at it in 10 years. It hadn’t needed change, and it hadn’t had reports of problems, so I hadn’t really looked at it. It was, in fact, possible to use. It didn’t meet the normal expectations a screen reader user had for interacting with something in 2022. What changed? Bluntly, it was the existence of ARIA. The Why ARIA specifications were transformed into a recommendation in 2014.
In 2012, I wasn’t using them. Today, it is a broadly supported and strongly expected feature in any website. This can happen at any point. Anything you do is something that is potentially going to be changed later on. You just have to be prepared for that. A general takeaway here is very simple. Whatever the best practices were in 2014 aren’t the recommendations today. Whatever the recommendation is today will not be the recommendation in 2034. You need to start planning ahead.
Now we start talking about defensive accessibility. Another term I’m just coining because that’s apparently what I did with this talk. How do you protect yourself against this kind of gradual degradation down the line? One of the first things to do is really just to date things. Keep track of when your component was last reviewed. When was this feature last remediated? What is the oldest piece of UI you actually have? Look at change logs when you upgrade a dependency. Just having a date gives you at least a reference.
You can jump back and say to yourself, this particular search feature we haven’t reviewed in like eight years. Maybe we should really just check it over and make sure we’re doing the best we can. This is always something that changes. Not being broken isn’t the same as being right. You can also build ahead. Use features that aren’t supported yet. This is actually one of the things that affected me with WP Accessibility. I could have used the ARIA expanded attribute. It was somewhat supported even though it wasn’t actually a recommendation yet. At that time I was choosing not to use things that had not yet become standards or were not yet supported by browsers.
The reality is it’s frequently a lot easier to just remove a polyfill than it is to rebuild your component. If it’s already using the tools that it should be using, you just stop faking them using your polyfill. The reality is this is a bit of a risk. Not all unsupported features will necessarily always be kept, but a lot of them will. A lot of them will actually be improvements.
One example now might be something like the ARIA controls attribute. It is minimally applied by any browser or AT combination, and it may never be, but there’s no reason not to use it now because at some point it might actually have a distinctive function. Right now it’s mostly used as a way to figure out in your code how this event actually should trigger, but it can be anything.
Next, you just test with users, and you test continuously. It’s not all about just limiting your user testing to whatever you’re now working on, whatever is new. You just have to monitor for new user expectations. You have to recognize that if the user’s expectations have changed, that doesn’t mean that you made a mistake. It just might mean that now you have something that depends on prior expectations. This is also something that’s going to really help you catch unexpected consequences earlier.
This is the kind of thing where with that Notepad++ problem, if they just were doing testing as a routine behavior, that would never have happened. They would never have released something that had that much of a huge break. It seemed innocuous, but in fact broke the entire application. It’s easy to hear the comment that you don’t hear feedback from people with disabilities, so you’re not worried about things. You assume things are fine. That’s essentially based on false assumptions. It’s based on the idea that people are using your product when it’s maybe not accessible. That changes if your product becomes accessible.
Fundamentally, losing accessibility from an application is radically different from lacking accessibility. Lacking accessibility will prevent people from using your application. What they will not do is they will not invest in using your application. Losing accessibility is where you have something that people have invested time and effort in. They have built their products. They’ve built their website using this tool. Now it suddenly becomes inaccessible and they can no longer use their website. That’s a disaster because people should be able to expect to continue to be able to use the applications that they purchased.
In the WordPress environment, there are always complications. This is one of the things about the fact that the WordPress stack is very deep. I’m going to talk a little bit about some of the front-end complications that we get when we’re trying to push updates to any plugin that has a front-end. Essentially, this is something that applies to me in a lot of ways. I have a calendar plugin, which is events management. I have a ticketing plugin that allows people to purchase tickets. Both of those have a lot of front-end. They are very heavily dependent on what’s going on up with the user.
Of course, that means that I have to manage changes to those front-ends. When the code changes, I have to somehow make that work. How do we manage front-end change in a WordPress plugin? We can stage changes and introduce them gradually. We could introduce a new model. We can selectively enable it, let users selectively enable it. That’s basically what Gravity Forms did. They now changed to a completely different version, and all new installs get that. You can turn it on if you want to. You can increase specificity in your CSS.
Mostly that’s what your options are. They all have, unfortunately, some downsides. When you’re staging your changes, basically, you’re just embracing that you’re going to have an ongoing cycle of minor breaking changes. You are in lots of releases, release after release. You’re going to, I’m going to break whatever custom CSS you might have had for this feature. Then next release, I’m going to break this for that feature. That can be really difficult. That certainly isn’t something that will win you friends with your users. Since nobody really enjoys having to constantly reconfigure their custom CSS to make things work. It is a strategy.
Introducing a new model comes with the downside that really only a small percentage of sites will even get those changes. With the Gravity Forms example, an enormous percentage of sites were just still using the legacy HTML. That had all sorts of problems. That also has flaws. If what you’re trying to get is to have people overall have a much more accessible experience, that only gets your future users. Increasing the specificity in your CSS can be quite painful. I am personally heavily biased towards weak CSS in my plugins. I prefer it to be easy to override.
That also means that that can be really– It’s very easy for them to accidentally override, which is to say, all sorts of themes override my CSS and other plugins override it, and that can be a real hassle. If you make it too specific, then it becomes really difficult to override and user design choices sometimes just get lost. These are all things that sometimes just have to be worked through with a WordPress plugin.
When refactoring, you have a whole different set of issues. I’m going to be totally upfront here. Refactoring is something where I have actually the least experience. Or I should say, refactoring something that’s already accessible is where I have the least experience. I have done a fair amount of refactoring, but usually it’s going from something that is not accessible to try and turn it into something that is accessible. That is a completely different problem. Refactoring something that’s already accessible has a different challenge.
This is essentially what Sonos was needing to do. In my hypothetical, in how I imagine this would be best done, you start by interviewing your users. You have just a few questions that you really need to try and get from them. The first one is, what are, in fact, the accessibility strengths of your application? What is it that people like about it? Because there’s a broad sense of if it’s really accessible and all of the technical aspects are correct, that’s great. That doesn’t necessarily mean that the application is delightful to use. It can just mean that it has a lot of strong characteristics. What do they actually like? This is something that Sonos really could have done.
On the screen here, I’m showing you a screenshot of the Sonos app before their redesign against a screenshot following after their redesign. In the one before the redesign, down at the bottom of the screen, there’s a series of five tabbed controls. They allow you to flip between My Sonos, Browse, Rooms, Search, and then there’s a More that gives you access to additional features. That is gone in the new version of that screenshot.
One of the big complaints, one of the things that really was hard on people with this architectural change, was the fact that the new design put all of the features and all of the controls into a single long screen. Whereas previously, they’d had a lot of grouping. There’d been four different sections. It was easy to find the specific type of thing you were trying to do. That’s not really relevant to the accessibility problems that they actually released with. Those were about the screen reader just couldn’t get any information about any of the features on the page. That was lacking accessible names for controls.
In fact, they made a fundamental architecture change that was less desirable to their users who are using screen readers. That’s one of the reasons why when I was talking about some of that, that July post that was talking about the fact that it was more accessible now, but still not as good as it was before. It wasn’t as good as before because of the choice they made and how it was architected. Interviewing your users, of course, there are a lot of stakeholders in a project. There’s no guarantee that that interview is going to make it all the way through to the final product.
At least if you’re aware of what your users actually want from your application, what makes it easier to use for them, then you can try and avoid making those sorts of changes that will actually make it just fundamentally more difficult. Of course, you also want to ask them, what are the accessibility weaknesses of your application? Again, just because your current interface might be technically perfect, doesn’t mean that it’s easy or pleasant to use. It might be just difficult to navigate. It might be difficult to figure out where things are.
Maybe the labels are just not as clear as they could be. There are all sorts of ways in which an interface can be technically accurate without actually being easy to use. You can use this refactor as an opportunity to improve these things, to try and make them all just better. You’d want to just try and differentiate between just meeting standards and providing that great experience. A refactor can be a great opportunity. It’s just that it’s also an enormous amount of change. Involving users with disabilities in the process of working out what a refactor should look like can be incredibly important.
Ultimately, this is all about needing to prioritize accessibility. One of the hugest things that Sonos did wrong was releasing their app before they implemented the accessibility into it. It might seem like this isn’t necessary to say, but if you’re releasing an update that isn’t accessible, you’re releasing broken software. It’s just that simple. If you’ve been working on improving accessibility gradually, you’ve been working on it across many versions, you might be accustomed to thinking that it’s okay to ship with some broken accessibility.
Because in the process of improving, you’re continuously making things better. Yes, some things are still broken and that’s okay. Once you have an accessible application, you actually have to think very differently. It is no longer okay for something to ship while it’s broken. Before your application was accessible, you might not have had any users who needed it. Because it’s not because they didn’t want your application.
It’s not even because they maybe didn’t need your application, but they couldn’t use it, so they didn’t. Once it becomes accessible, that period is over. They will be using it. That’s good. What I don’t want is for anybody to walk away from this talk with the idea that you shouldn’t make applications accessible, which is an easy takeaway. Because it’s so much easier if you’re just gradually fixing broken things. Once you have an accessible application, now you’re like, “Oh my God, I can’t change anything,” but you can.
You need your application to be accessible. People can acquire disabilities. Even if they purchased your application in a place where they could use it, they might have acquired a disability and now they should still be able to use that application. They might be forced to use it because of employment. You don’t want to have an inaccessible application that can cause you to lose customers who can no longer use it. You don’t want it to cause anybody to lose a job. It’s important to make sure you’re prioritizing, you’re testing early, you’re testing often, you’re distinguishing between having a lack of accessibility and actually having broken something that was previously accessible.
I think what I want as my biggest takeaway here is that accessibility doesn’t end once you’ve made your product accessible. That’s just the first stage. Because you still have to continue to improve your process. You still have to continue to improve your product. You have to do that in a way that doesn’t lose some of the great features you’ve fought to have in that first place. That’s my whole talk. If there are any questions, I’m here for them. I will stop my share.
>> AMBER HINDS: Do you want to, before you do that, just read out your website and–
>> JOE DOLSON: Oh, you mean in case somebody actually wants to find me or something? I don’t know if they want to.
>> AMBER HINDS: Yes. Where’s the best place for people to find you, Joe?
>> JOE DOLSON: Well, you can find me on my website, which is joedolson.com or you can email me, joe@joedolson.com. You can find me on Bluesky @JoeDolson. You can theoretically find me on Facebook, but I probably won’t respond. Anywhere I am, I’m Joe Dolson.
>> AMBER HINDS: Yes, I know. I think I might have tagged you in the WordPress Accessibility Facebook group recently.
>> JOE DOLSON: You did, yes.
>> AMBER HINDS: I was like, “Joe might know the answer to this,” but I don’t know that you did answer it.
>> JOE DOLSON: I have not, no. I think your answer was fine, just for the record.
>> AMBER HINDS: Oh, thank you.
>> JOE DOLSON: All right, so with that, I will now stop my share.
>> AMBER HINDS: If anyone has any questions for Joe and you want to put them in the Q&A, we’ll be passing those along. I did see one come in via the chat, so I’m going to start there. This is not specifically related to what you were saying, but I’m curious to hear your thoughts on this. Maurice had said, Maurice supports a number of clients and is moving them to WPMU DEV Hub to give centralized control for updates, et cetera. Do you know of an accessibility testing module that works in that environment or reports over? Have you ever seen that?
>> JOE DOLSON: I actually, I’ve never used the WPMU DEV Hub. I don’t know anything about it. I would be well out of my knowledge base to actually respond to that. I assume that you’re basically looking for something that would take the global reports and feed them back into your hub. Seems like it should be possible, but I honestly don’t know anything about it. I couldn’t guess.
>> AMBER HINDS: We actually have some of our sites set up there because we use our uptime monitoring, which is handy, and Smush Pro. I haven’t seen any accessibility that coordinates with that. Maybe it’s a good note for us on Accessibility Checker.
>> JOE DOLSON: I think there’s a lot of benefit to being able to pull those types of reports into a centralized hub, because if you’re managing a lot of sites, that would certainly be valuable in the education world. They tend to be very heavy on huge, complicated installations that have many, many things going on, but I don’t know anything about it.
>> AMBER HINDS: Maurice had followed up with a question in the Q&A that you were talking about accessibility for developers of plugins. How do you feel like your talk and the principles that you were discussing apply just in general to websites that are being developed and developers of websites?
>> JOE DOLSON: It definitely applies. Websites tend to have the complication that there are also non-developers working on them. They tend to be more fundamentally chaotic, just because it’s so much harder to get a clear picture on everything that’s happening.
Obviously, there’s a lot of different types of websites. There’s everything from the hobbyist who does everything themselves, to the heavily managed professional experiences where everything goes through a review process before it gets published. In that latter case, it’s much easier to make sure things stay on track. It’s definitely relevant. There’s no question. Fundamentally, a website is software. It’s a software application.
It happens to be one that’s assembled from a whole bunch of dependencies, which are plugins and themes and WordPress. Those all have the same fundamental consequences. Whenever a plugin updates, you really do need to look and see what has actually changed here and has it gotten better or not? I have absolutely had experiences where a plugin got worse from the accessibility standpoint. That almost always happens because they have decided to implement some form or another of a third-party UI tool. Now, suddenly, they’re using UI kit or something.
>> AMBER HINDS: A library for carousels or something.
>> JOE DOLSON: Suddenly, like, oh, great, this has now gotten bad. Frequently, it’s simple becomes complex. It’s the same fundamental tool.
>> AMBER HINDS: How do you handle that when you encounter that on websites?
>> JOE DOLSON: On websites that I actually manage?
>> AMBER HINDS: Yes, like your client sites.
>> JOE DOLSON: Well, I don’t give my clients a lot of freedom to install things. I might be a somewhat domineering manager. I will just remove it. I have a very particular set of clients. My clients are not necessarily– They’re not always the most knowledgeable about digital accessibility. Because so many of my clients are disability-focused nonprofit organizations, they do care about whether or not something is accessible. I have a large degree of freedom to simply make changes and tell them that I have made these changes if they’ve done something that isn’t accessible.
It is a fabulous privilege to be able to just change a client’s site without asking them. I try not to abuse it. If they’ve put something up that’s extremely important in an inaccessible manner, we will have a conversation first. I have definitely just taken things out.
>> AMBER HINDS: Then I’m assuming you– There’s a line of, do you try to go to the plugin developer? Do you fork the plugin? Do you just remove it and say, “Nah, we’re not going to have this functionality at all.” They’re trying to figure out based upon the different scenarios how to address it.
>> JOE DOLSON: It really depends on how important the functionality is and how replaceable it is. I also build an awful lot of custom software. That has a lot to do with habit. That has to do with the fact that I have been doing this for a very long time. When I was building accessible websites with WordPress in 2009, there were zero accessible options.
>> AMBER HINDS: Not very many plugins.
>> JOE DOLSON: All I ever did was fork things or write custom stuff. To a large degree, I still do that. It is weird. I have a very low level of trust for plugins.
>> AMBER HINDS: I don’t know that I think that is weird given the plugins that I’ve tested all the time. Same thing. It is an unfortunate reality maybe right now.
>> JOE DOLSON: It is. It is very much.
>> AMBER HINDS: Hopefully that will change.
>> JOE DOLSON: Fingers crossed.
>> AMBER HINDS: I want to follow up on Maurice’s question and then we’ll go back to Nick’s because Nick’s is– Or Maurice’s is related. He asks, would it be correct to assume that you recommend testing sites for accessibility when making updates to plugins? What would you say the cadence is of updating things and testing them that you would recommend?
>> JOE DOLSON: It really depends on the plugin. Because it has so much to do with how are you actually using this plugin and how– There’s a certain fundamental trust level. It’s actually very– I would say it’s almost identical to my policies when it comes to security and plugins. If I really only install plugins that I have a pretty high level of trust for, and that includes trusting that they’re not going to make big changes unexpectedly. It’s hard to tell sometimes whether any given plugin is using semantic versioning or not. In general, if it’s a third-degree update, I am very unlikely to do any additional testing. They’re going from–
>> AMBER HINDS: For people who are less familiar, there’s 1.1.1. For versioning controls, you’re talking about those third decimal point changes?
>> JOE DOLSON: If it goes to 1.1.2, I probably won’t check it. If it goes to 1.2.0, might check that. It depends on what the change log says. If it’s a first digit change, then it’s probably going to get staging and a detailed examination before I do anything. Because that’s probably a really big deal. Different developers use different systems, but I don’t think very many would release 1.1.2 and just feel it’s okay to completely revamp their UX. That would be weird.
>> AMBER HINDS: Hopefully not. Do you have a list of trusted plugins?
>> JOE DOLSON: I don’t really have a list, but I do tend to install almost the same things everywhere. I will be blunt, it’s very short.
>> AMBER HINDS: Can you name any?
>> JOE DOLSON: The majority of the plugins I use–
>> AMBER HINDS: I’ll put you on the spot.
>> JOE DOLSON: I trust Gravity Forms these days. It also depends on context, because with the clients I have, I frequently do have a need for the admin to be accessible. In those cases, I do not use Gravity Forms because it’s not there. There, I actually mostly use Contact Form 7, which is rough. You have to really know what you’re doing, but it is possible.
>> AMBER HINDS: With your accessible defaults plugin added, too?
>> JOE DOLSON: Yes. It just makes it a little easier.
>> AMBER HINDS: I might throw a link in the chat to– I don’t know if this is a total overlap with yours, but last year people had asked this question for WordPress Accessibility Day, and we had put together a list of plugins that we use on our website, the WordPress Accessibility Day websites, which is not to say that they’re all perfect, especially in all combinations, but they are ones that we use on the website, and the website is accessible. I don’t know how else to word that.
>> JOE DOLSON: Well, a lot of the plugins I use are almost exclusively admin side. Those just don’t have a lot of direct impact on the accessibility of the site.
>> AMBER HINDS: Susan had a follow-up question on the Contact Form 7. Can you clarify what you mean by it is rough?
>> JOE DOLSON: What I mean is that editing a form in Contact Form 7 requires you to really understand HTML, short codes, and really just have a pretty decent handle on how to operate in code. It’s not a visual layout tool. It requires a higher bar for people to be educated to be able to use it. It doesn’t pose a whole bunch of barriers outside of knowledge, and knowledge is something that I can provide people with.
>> AMBER HINDS: I want to follow up on Nick’s question, and then I have a few others about developing plugins, maintaining accessibility in plugins. Nick had said that he worked on a new feature for WP Scripts package, and was wondering if you know any got-yous for developing command line tools.
>> JOE DOLSON: There’s not a lot of got-yous for command line tools. The biggest thing is, if you’re doing an interactive command line tool with an exchange of prompts, to make sure that those are sufficiently clear. The reality is, the command line, it’s just text, and anybody who’s interacting with the command line, they need to be operating at a pretty high level to even work with it.
You have to be able to understand that minus R has a meaning, and it’s very specific. I don’t know of a lot of really major got-yous to working with command line tooling. The biggest one is just, I think if it’s an interactive thing, making sure that you aren’t creating any kind of confusion. I would say, there are people who would probably have a much better answer to that than I do, who actually interact with it.
>> AMBER HINDS: That sounds like a better answer than I would have given. I’m curious, I want to dive a little bit more into talking to your users that you talked about. I’m curious if you do this with your own plugins, and if so, how? Is it just via an email list, or if you have good recommendations for people who maybe aren’t sure if assistive technology users use their plugins, and how to even get feedback from them?
>> JOE DOLSON: For me, really it’s specific individuals. People who I know have disabilities, or are using specific assistive technology, and are using my plugin. It’s very much, it’s not email lists. It’s literally, I reach out to my contact at NFB, and they’re like, “Oh yes, we’ll respond to that.” That’s the National Federation for the Blind. Yes, it’s very much, it’s because I’m reasonably well-connected. I know a lot of people, and can get individual feedback reasonably well. That said, I also don’t do a whole lot of big refactors. I tend to bias towards pretty small changes there. I have done a lot more of what I listed as bullet point one, where it’s constant stream of minor breaking changes. I’ve been doing that for five years. I think I’m, fingers crossed, don’t need to do that again for a little while, but yes.
>> AMBER HINDS: For someone who doesn’t, then maybe it’s reaching out, trying to look in the WordPress community, or going to office hours, and make, well, I know office hours might be changing [chuckles].
>> JOE DOLSON: Yes, I mean, trying to [crosstalk] [unintelligible 01:00:07]. Right. Trying to get– You do have to reach out and ask somebody, and you should be prepared to pay them if they’re not already doing it as part of their job, because the reality is, there’s a lot of people who are willing to participate for free in helping to build open source software, but there’s a very finite limit to how much time and effort most people are willing to give to that. When they are, they want to choose what they’re giving it to. You shouldn’t expect somebody to just happily contribute back to your random open source plugin.
You should be prepared to invest in improving it and making that happen. At the very least, you should make sure that you give them props in your next changelog or release notes or whatever, because that’s just fair. It’s important feedback.
>> AMBER HINDS: Yes. I think there’s a few community members you mentioned who might be worth reaching out to. Like Raghavendra Satish Peri is one you mentioned who is blind.
>> JOE DOLSON: He tends to be very generous with his time, yes.
>> AMBER HINDS: He also does paid auditing if people have budgeted for that and need something. I think his feedback is always very understandable. We’ve hired him to do some testing for us and our plugin. He’s someone I’d recommend and there’s some other people in the WordPress community. Alex, I think does a little bit. Alex Stein, not as much volunteer, but I think you can hire him as a consultant. Kevin Andrews is another one.
>> JOE DOLSON: Yes. I mean, there’s quite a few people, but yes, finding them and making an arrangement. I think one of the things that people need to always embrace is feedback doesn’t have to be delivered in 20-hour contracts. You can get an enormous amount of data out of one 45-minute working session. If you have developers who are able to watch that recording back and absorb that feedback and do some research and ask questions, then you can really make a huge impact just from that small amount of data.
It’s just extrapolating from original source and just going, “Okay, he commented on that. Well, we also are doing that over here and over here and over here, so maybe we should just get all of this fixed.” I always tell people that it’s in your best interest to make your application as accessible as you can before I look at it, because it’s going to take a lot less time and you’re going to pay me less if it’s already in better shape.
>> AMBER HINDS: Yes, I mean, for us, I feel like when we do audits, finding the problem is not really what takes that long. It’s writing up what the problem is, how it maps to Web Content Accessibility Guidelines and then what are recommended fixes. That’s what takes a really long time. Even just having someone get on Zoom with you and share their screen and giving them prompts and having them move around like, “Hey, can you create a post in this post type that your plugin manages or whatever this thing is?” Don’t tell them where to go. Just be like, “Can you do this?,” and watch them try to use your thing or figure out where to go and how to do it. I think that can give you a ton of usability feedback.
>> JOE DOLSON: Yes, absolutely.
>> AMBER HINDS: Maurice had a question about your experience in the testing that is done by Automatic for changes in core. I don’t know if this is just an Automatic question or if it’s really just like core contributors. Can you explain more about how testing works in WordPress core?
>> JOE DOLSON: I mean, that is a big question. First of all, I don’t think– there’s not much or any of the testing in WordPress core that is strictly automatic that I’m aware of. There’s a pretty complex test suite for both Gutenberg and for WordPress core. Gutenberg has some accessibility-related testing, though not a lot. It does have visual regression testing so that we can actually track when something changes, which can be really helpful for kind of figuring out various changes there. Most of the tests are more functional.
It’s making sure this does that and this happens then. Gutenberg testing, they actually have, there is a lot of keyboard-related testing, making sure the keyboard events actually occur. It’s not done with the intent of it being accessibility testing. It’s being consistency testing. I don’t know if that answers your questions, but–
>> AMBER HINDS: There’s always a need for people to come in and test for core, right,-
>> JOE DOLSON: Oh, yes, absolutely.
>> AMBER HINDS: -and Gutenberg?
>> JOE DOLSON: The thing is, it’s such a huge, complex system. There’s always things that can be tested. The scope of problems and even just finding things can sometimes be exhausting. The number of times I’ve gone into a bug and I just, especially in Gutenberg, and I can’t even figure out which screen it’s on, let alone actually help resolve it. That can be complicated, which is why there’s so much automated testing.
>> AMBER HINDS: I’ll ask you a kind of edgy question. Do you feel like the testing of features is sufficient before they’re rolled out and released?
>> JOE DOLSON: No, that’s not even edgy. I don’t think, I mean, I’m sure there are people who believe there is enough, but no, God, no.
>> AMBER HINDS: Yes. I remember being frustrated, I think this might be resolved now, by the bug where any– if there was like a meta box at the bottom of the screen in the block editor, it would cover up the controls for the block that was right above it. You’d have to insert like a spacer block or something just to be able to edit your paragraph or your heading levels or whatever. Or like add links to things. I was so frustrated by that. Then I found out that it’s because the people who test core releases do it with like no plugins activated and by default, there’s only really plugins add meta boxes down there.
>> JOE DOLSON: Yes. It’s actually, it’s an interesting thing. Part of the testing process, and this is part of the process to verify whether or not it’s a core bug, is to test with all plugins disabled. However, some core bugs are only triggered by the presence of a plugin. There do have to be some exceptions to that. There’s a fundamental, we do still need to interact with plugins. There are some complicated lines for trying to decide, “Whose fault is this? Like, do we need to adjust for this or not?”
>> AMBER HINDS: I think there’s kind of a similar line though, too, as you’re developing your own plugins, right? How do you decide what other plugins or themes to test your plugins with?
>> JOE DOLSON: Oh, you mean–?
>> AMBER HINDS: You personally.
>> JOE DOLSON: Comparative compatibility.
>> AMBER HINDS: Yes, I’m curious.
>> JOE DOLSON: Yes, that is complicated. I’ve actually, I haven’t worried about it so much with plugins. I do some. Like with anything that I have that has a payment gateway, I make sure that it still works if you’re running EDD or WooCommerce, because I can’t test every possible payment-related plugin, but at least I can make sure that I’m not conflicting with those. I did have a, I had a conflict with Give at one point that I hadn’t found. I was like, oh, okay, well, I guess I’ll need to deal with that. It is hard because there’s so many plugins and it’s just, there’s so much time you have to spend in testing with them.
Then themes are– the thing– when I was talking about front-end complexities, that is actually the hardest thing, is like so many themes do such weird things. Suddenly, like–
>> AMBER HINDS: You have to battle.
>> JOE DOLSON: Every single button has to have padding, which is 30 pixels on both the top and bottom and 80 pixels on the side. Like, oh my God, this is impossible, and it’s important.
>> AMBER HINDS: This is the battle that we have with Accessibility Checker’s front-end highlighter. We have tried so many times to, on our buttons, unset theme styles, like for all the, like, padding, margin, like all the things, like the outlines, like everything. Yet still, sometimes I’ll get in with someone and I’ll see the, what are like button to trigger it or like, and it’s like the one that’s like view code or whatever, and it’s massive. I’m just like, oh, it’s so hard to be compatible.
>> JOE DOLSON: There’ve been a few movements in the CSS working group to try and develop kind of an isolation layer in CSS, but it’s so complicated, so difficult and so frustrating.
>> AMBER HINDS: Yes. I think that’s probably one of the hardest things for plugin developers is figuring out how to make your plugin work in any theme, not knowing what you’re going to get.
>> JOE DOLSON: The ones I’ve seen that have been like consistent, like they are internally consistent and everything is the same, are inevitably things that are incredibly difficult to ever make any changes to. It’s just like, yes, there’s, I don’t like that compromise either. It was easier back in 2010.
>> AMBER HINDS: When you just put important on everything? [laughs]
>> JOE DOLSON: No, when people building websites knew what they were doing.
>> AMBER HINDS: Yes, as opposed to all the drag and drop–
>> JOE DOLSON: The fact is so many modern drag and drop tools, people no longer have to know CSS or have to know HTML. It used to be the case that you really did if you wanted to make any changes and–
>> AMBER HINDS: Now you don’t. Yes.
>> JOE DOLSON: It’s interesting.
>> AMBER HINDS: Rishi said– Rishi has been working with the USWDS, which is the US Web Design System for anyone who’s not familiar. It’s the component library for US federal websites that is accessibility-focused. I’m working with USWDS recently with Gutenberg. Website is mostly accessible, but the back end is not. Do you know any component library which has good accessibility features for the back end?
>> JOE DOLSON: I’m struggling a little bit to understand exactly what this– Do you mean that the–
>> AMBER HINDS: Rishi, if you want to put any extra context in the chat, that might help us and we can do it. I’m curious, broadly, and I might have asked you this the last time you spoke, which was more than a year ago. How do you feel about the accessibility of the back end of WordPress core?
>> JOE DOLSON: I mean, it’s improving as long as you– The full site editor is a pretty messy and the integration between the block editor and the full site editor is complicated. If we’re talking about the actual, the WordPress core, the classic environments and settings and all of that, they really are making progress. That has been my primary focus for the last couple of years, is just getting those things adjusted. It’s been a lot because essentially we had opened, I’m just going to say, a lot of tickets about in the five to eight year ago range. Then they all kind of got derailed by the Gutenberg development process, so I’m kind of doing catch up.
>> AMBER HINDS: Yes, circling back.
>> JOE DOLSON: It’s got all of the problems that you would expect from anything that is legacy software because it has everything I talked about today because it has things that were built 15 years ago and have hardly been touched since then. It has things that are built in all sorts of different styles and languages and different kits. It can be complicated to work with. It’s mostly there. I mean, it’s certainly not perfect. There’s a lot of existing issues, but it’s improving. We have real accordions now.
>> AMBER HINDS: [chuckles] Very exciting. I know one thing you were telling me about. We were talking about some issues with like the settings. With the way they’re being output, if you do it the WordPress way in a table with like weirdness with the labels and things like that. I don’t know if maybe what Rishi was getting to. Specifically, there’s some extra context there. Rishi says, “I created custom blocks but core controls are not accessible. If there is any Gutenberg control library–” I’m wondering if that means like in the editor? Do you know if there’s a library available for people to use? Like we were talking about the settings, you’re like it’s probably better to just make your own.
>> JOE DOLSON: Yes, I mean, so are these blocks that you built, Rishi? I’m trying to figure out where the controls are actually coming from, because in general, if you’re building a Gutenberg block and using the current version of the Gutenberg API to do that, you really should have generally accessible controls as long as they’re fully defined and everything.
>> AMBER HINDS: By Gutenberg.
>> JOE DOLSON: Yes, because you shouldn’t really [crosstalk] be getting totally custom controls. I mean, you can build some weird stuff, but then if that’s the case, it’s not a Gutenberg thing. It’s you’ve done custom code and it doesn’t match.
>> AMBER HINDS: Well, I’ve experienced this too. I audited a website where they had custom blocks, but they were using like Metabox, I want to say, or something to create the fields in the block controls that show up on the right hand panel.
>> JOE DOLSON: I mean, there’s some really complicated stuff you can do in blocks. I mean, you can create a block that is basically a container for your own custom library. In that case, you could end up with just about anything. I mean, you know, I was just reading the other day about the bridge that’s importing the media library into Gutenberg, which is kind of interesting. It’s complicated because, of course, the media library has to be kept isolated because it’s completely an independent code base. That’s kind of funky. I don’t know. I’m not totally sure-
>> AMBER HINDS: [crosstalk] good answer.
>> JOE DOLSON: -what it is that you’re trying to do, Rishi. We can talk later. I know I have your contact information.
>> AMBER HINDS: Yes, so those were all the questions that we had so far. I don’t know if anyone else has any final questions. Otherwise, what I’d be sort of curious, Joe, like a final wrap-up thought for plugin developers who are trying to really keep things accessible, do you have maybe like a high-level how they can best–? I’m trying to think about what I want to say, like map that out maybe? Obviously, we saw the bad, right, with Sonos where it’s like we’re going to do a reversion and then come back to maybe better, which is obviously [crosstalk] not good.
I feel like it’s a planning issue, right? Why would you release something that’s half-baked? I’m wondering if you have any recommendations on how somebody can say, “Okay, I want to do this big overhaul or I want to do this thing. How would I map out accessibility along the way?”
>> JOE DOLSON: I mean, I think the first thing is to really honestly assess where you are now. Knowing what you have is the key thing to figuring out what your risk is, what you might lose. There’s so many different cases here, depending on exactly where that plugin sits at the time they’re doing this refactor. If where you are is we’ve really never paid any attention to accessibility and we don’t know anything about it, most likely your refactor will be an improvement, but not necessarily, because a lot of the time if what you’ve done in the past was just very simple, then you might be fine, at least functionally, if not actually according to standards.
You could be something that people can interact with and then you upgrade it all to make it all react-based and now suddenly people can’t even interact with it. Knowing where you are is the thing that you have to figure out first. Once you know where you are, then you can start to break down your components and be like, “Okay, well, this one is actually really accessible, so we need to make sure we don’t lose anything. This one is mediocre, so let’s figure out what we want it to be. This one is awful, so anything we do is going to be an improvement.”
Then that you have a different level of investment concern about each different component. Obviously, the long-term goal should be to make them all this great experience, but from a practical standpoint of wanting to keep your releases moving, you don’t want to just hold everything steady for a year while you revamp everything. That’s one of the reasons I think the WordPress plugins almost never do big refactors, is that there’s a lot of pressure to continually release-
>> AMBER HINDS: Update.
>> JOE DOLSON: -so that people don’t start telling you that you’ve abandoned your plugin, which has happened to me. I had somebody ask whether I’d abandoned a plugin when I’d had literally been two months since my last update, and I was kind of like, “Really?”
>> AMBER HINDS: Because they’re expecting like little micro releases every week or something, because that’s what the really big plugins do.
>> JOE DOLSON: It’s funny because it used to be different. You know, 10 years ago, people would complain if you released more than once every couple of weeks.
>> AMBER HINDS: Because they didn’t want to have to run updates, but now everything’s on auto-update.
>> JOE DOLSON: Yes, I know. It’s weird. Things change. Anyhow, I do think there’s really nothing better than just knowing where you are. Then your strategy at least can coordinate in relation to a basic level of information. That doesn’t mean you have to do like a detailed audit. You can have an overview of have a user walk through it and just give you some insight and be like, “Okay, this was good. This was bad. This was mediocre.” It can even be– Yes, I think there’s a lot of different ways that information can come through. It all depends a little bit on what is your actual budget for the work you’re doing?
Let’s be realistic. Some plugins are a solo developer working part time and they’re going to have a different set of concerns than somebody who is a team of 35 full-time developers.
>> AMBER HINDS: Yes.
>> JOE DOLSON: You know, different process. It’s inevitable. I say that as the solo developer who’s doing this part time.
>> AMBER HINDS: [laughs] Yes, and a lot of other amazing things for WordPress. Well, I mean, I think on that note, if you’re not sure about the budgeting or the road mapping, come next month to WordPress Accessibility Meetups. There will be different talks on those.
>> JOE DOLSON: See, I managed to give you a lead in.
>> AMBER HINDS: I know, that worked out very well. I really appreciate you coming and sharing your thoughts and your expertise with us. I don’t know if you saw the chats, but there were a few people that said thanks for the great discussion. They really appreciated it. Remind everyone, you’re at Joe Dolson on just about all the channels and in WordPress Slack.
>> JOE DOLSON: Yes, pretty much.
>> AMBER HINDS: Yes, okay.
>> JOE DOLSON: Find me online. I live there.
>> AMBER HINDS: Thank you [laughs]. Hopefully, we’re all going to sleep now. Not doing too much more work.
>> JOE DOLSON: All right. Thank you so much for having me. Glad to be here.
>> AMBER HINDS: Thank you, Joe. Bye.
>> JOE DOLSON: Ciao.
>> CHRIS: Thanks for listening to Accessibility Craft. If you enjoyed this episode, please subscribe in your podcast app to get notified when future episodes release. You can find Accessibility Craft on Apple podcasts, Spotify, and more. And if building accessibility awareness is important to you, please consider rating Accessibility Craft five stars on Apple podcasts. Accessibility Craft is produced by Equalize Digital and hosted by Amber Hinds, Chris Hinds, and Steve Jones. Steve Jones composed our theme music. Learn how we helped make 1000s of WordPress websites more accessible at equalizedigital.com.