Special guests Joe Dolson, WordPress core committer and accessibility consultant, and Anne McCarthy, Architecture and Open Source Director at Automattic, join Amber and Steve to talk through the vision behind Accessibility Lab, a new canonical accessibility plugin concept for WordPress core.
We learn what Accessibility Lab is, what it is not, and try to understand what the practical use case is in the dizzying context of one of the world’s largest open source projects.
The conversation gets into some genuinely difficult technical territory, including why some accessibility optimizations in WordPress core are particularly difficult to solve, challenges related to getting enough real-world testing, and the organizational hurdles around collecting bulk data that’s detailed enough to shape decisions. There is also healthy disagreement about whether a single canonical plugin can successfully juggle both persistent, stable features and early-stage experiments that in some cases may jeopardize the stability of production WordPress websites.
And because this is Accessibility Craft, the group tackles all of that over Cerveza, a Mexican-style lager from Save The World Brewing Company in Marble Falls, Texas.
Episode Outline
- What the WordPress Accessibility Lab canonical plugin is intended to do
- The case for better accessibility experimentation pathways in WordPress
- Specific examples of challenging accessibility problems in WordPress Core
- Challenges related to feature testing and useful data collection
- Persistent accessibility features that Accessibility Lab could introduce
- What Accessibility Lab should explicitly NOT become
- Deciding what belongs in Core, Gutenberg, or Accessibility Lab
- Whether persistent, stable features and early-stage experiments can, or should, coexist in the same canonical plugin
- Where the Accessibility Lab project is now, and what work has been done
- How contributors can help shape the project, if they’re interested
Tune in to Accessibility Craft conversation episodes like this one every other Monday.
Accessibility Craft is hosted by Amber Hinds, Chris Hinds, and Steve Jones. They are experts in digital accessibility and creators of software, courses, and specialized services that have made millions of websites more accessible through their work.
Links & Resources
- Save the World Brewing TX Cerveza
- Help shape the Accessibility Lab plugin
- [idea] Add a way to implement custom ARIA attributes at block level
Download Accessibility Checker and use coupon code AccessibilityCraft to save 10% on any plan.
Subscribe for more practical conversations about digital accessibility, WordPress, emerging legal developments, and beverages that inspire unusually serious debate.
Accessibility Craft is hosted by Amber Hinds, Chris Hinds, and Steve Jones. They are experts in digital accessibility and creators of software, courses, and specialized services that have made millions of websites more accessible through their work.
To learn more about us, you can visit our website.
Listen
Watch
Transcript
Chris Hinds: Welcome to Accessibility Craft, where we explore the complex challenges and emerging trends that are shaping digital accessibility, while sipping on unique craft beverages. This show is proudly produced by Equalize Digital, The most trusted name in WordPress accessibility. Join us every week as we break down accessibility news and share the expert strategies we’ve used to help make millions of websites more accessible.
Grab a drink, the show starts now!
Amber: Hey, everybody. It’s Amber, and I am here today with Steve.
Steve Jones: Hello everyone.
[00:00:41] Introducing Special Guests Joe Dolson and Anne McCarthy
Amber: And we have two special guests here with us today, Anne and Joe. Hey, do y’all wanna introduce yourselves?
Joe Dolson: Sure. I’ll kick it off. I’m Joe Dolson. I’m a WordPress core committer. I’m one of the board members and team leads for WordPress Accessibility Day. I’m a plugin developer and an accessibility consultant.
Anne McCarthy: Sweet! Joe, you were on the 7.1 team with me, and so it’s fun to be on a podcast with you after all that is over. I am Anne McCarthy. I’m a sponsored contributor to the WordPress Project, and my title is technically Architecture and Open Source Director at Automattic. So I live between our engineering leadership and then a lot of our efforts within the WordPress Project. And so I end up being involved in a wide range of things, including this wonderful Accessibility Labs plugin, so I’m excited to talk about it today.
Amber: Yeah, we are excited to have both of you here. For folks who are tuning in, if you want to get show notes and a full transcript, you can find that at accessibilitycraft.com/180 because this is episode 180, which is very exciting. We also are asking you pretty, pretty please, hit the like or the subscribe button wherever you are listening. Leave us a comment or write us a review. We very much appreciate it. It helps us show up in other people’s podcast players so maybe some people who were not aware of accessibility before will become aware of it.
[00:02:11] Today’s Beverage
Steve Jones: Cool, so today I get the pleasure of announcing the drink since Chris is not with us today. And I will do my best, chris has much better taste notes than I do. But today we are doing a a beer from Save The World Brewing Company in Marble Falls, Texas. And it has felt like Texas up here in the northern Midwest lately so this will be a nice refreshing beverage.
So this is called Cerveza. It’s our Mexican style lager. Is crisp and refreshshing perfect for days in the Texas sun and nights in the dance hall.
Amber: I actually came from, it’s like so perfect for me having the Texas beer because earlier today I went to the very first Texas High School football pep rally and my daughter is on the dance drill team. Depending on where you are in the country you call it different things. And they danced to like a whole mashup of country songs including like Shania Twain, Feel Like a Woman.
Anne McCarthy: Incredible.
Amber: And I was like this is like the beer that goes with Texas high school football, I think.
Steve Jones: Wha- wait, hold on. The beer that goes with high school football, for the parents.
Amber: Yes.
Steve Jones: So this is to all you parents getting loaded before the high school football game. All right, should we crack it open?
Anne McCarthy: Let’s do it.
Amber: Yeah, I will, while everyone is doing that, I will say it…
Anne McCarthy: Smells good.
Amber: Has a very like, red, white, and blue, like, Texas label design, which I kind of appreciate. And this is not too far from me where Marble Falls is, maybe like an hour and a half, but I’ve never had this brewery so I’m excited to try it.
Anne McCarthy: It’s really good.
Amber: Joe has a glass.
Anne McCarthy: I’m not that fancy.
Amber: Want to describe the pour, Joe?
Joe Dolson: So it poured pretty easily. It’s got a decent kind of large foamy head, but not overkill. It was a really easy pour. It’s an interesting color. It’s just a little bit hazy maybe, but I won’t describe the color.
Amber: It, is it lighter than you thought it would be? Like, did you expect it to be darker.
Joe Dolson: No, actually I’d say it’s darker than I was expecting, but it’s yellower than I expected, to be honest.
Steve Jones: It kind of goes in like, it goes in and comes out and looks the same color.
Joe Dolson: Yeah, we’re all trying to avoid saying that, but it’s basically what you’re thinking.
Anne McCarthy: Yeah.
Joe Dolson: It is good though!
Amber: Anne, what do you think? You tried it already?
Anne McCarthy: Oh yeah, I think it’s great. I think it’s a very easy drink. I’m like, this is definitely… I grew up in Florida, so to me this is like a perfect, I would think of it as like a beach day. But yeah, I resonate with this being a Texas, like in the sun, refreshing.
Joe Dolson: Yeah.
Anne McCarthy: Yeah.
Joe Dolson: Really good hot weather beverage.
Anne McCarthy: Mm-hmm.
Joe Dolson: And today here in Minnesota it’s 92, so…
Anne McCarthy: No way!
Joe Dolson: It is. I think Steve and I have had similar weather lately.
Amber: Yeah, that is crazy. You know the other thing besides football that I think of was, this is very hill country. I don’t know if you guys have heard of this, but people go and you take like big tubes, some of which have bottoms on them, you can float the rivers. And it’s not like in Colorado where you’re like rafting.
Steve Jones: No.
Amber: Like, a lazy river that you’d have at a water park, only you go through the Texas Hill Country, and then you can get the tubes with the bottom so you can put a cooler in it.
Steve Jones: Mm-hmm
Amber: And yeah. That’s… This would be perfect for that
Joe Dolson: And there’s a river that runs right through downtown Missoula, and that was absolutely just one of those routine activities when I was growing up. ‘Cause, you know, you just get an inner tube, you go upstream some distance, and then just float down through the city, get out somewhere, you know, in the middle of downtown, possibly you go to a bar afterwards.
Amber: That’s not just American though, because I will admit when I went to WordCamp Europe two years ago, I was so sad about how cold it was because didn’t they do that?
Joe Dolson: They did, yeah.
Amber: Wherever that was. Switzerland, yeah, but what was the town? I’ve already forgotten, but…
Joe Dolson: Basel.
Anne McCarthy: It was Basel.
Steve Jones: Basel, yeah.
Amber: Yeah, there we go.
Joe Dolson: Yeah, I mean actually one of my, you know very early trips in Europe this was in 2006. I was in the Czech Republic; I was in a town called Cesky Krumlov and the Moldau right through Cesky Krumlov. And I remember just it was a hot summer day in July walking through the city and then he hit the river and it is just packed with inner tubers and every imaginable thing and you did discover that they did not separate between their nude and non-nude beaches.
Anne McCarthy: Fun.
Steve Jones: All right.
Amber: Were there kids there? You know, they’re a lot less prude than we are, I think. We have that Puritan ancestry in…
Anne McCarthy: Yeah, we do.
Amber: Oh, that’s funny. I also think they probably don’t have air conditioning.
Steve Jones: Yeah.
Amber: Hearing that in the news this summer when it was so hot in Europe, and people didn’t have air conditioning, so they were trying to get into the water.
Steve Jones: Well, we had that whole discussion internally when we went to Italy. Like, I think Amber was trying to get us to book a hotel that didn’t have air conditioning. I was like, “You know this doesn’t have air conditioning. We should stay at the Hilton.”
Amber: We always have a very non-technical rating system. Would you buy it again? So where do you land? Is this up, in the middle, down? Everybody can give their own rating. You’re one thumbs up, Anne.
Anne McCarthy: I’m full. Oh, no, I’m full. I’m like, I would do… I’m 100%. It’s also, I was just looking at the alcohol content, ’cause that also is a…
Steve Jones: 4.6.
Anne McCarthy: Yeah, that’s great. Like, as long as it’s, like, drinkable. I’ve gotten in trouble with some, like, 8 percenters that have not been as fun when you- it’s a hot day.
Amber: When they sneak up on you.
Anne McCarthy: Oh, yeah.
Steve Jones: Yeah, we had one of those last week and the rest of the Friday was unproductive.
Anne McCarthy: Exactly, yeah.
Steve Jones: I’ll give it two thumbs up because this is definitely… I mean, if you’ve listened to the podcast, you know my style. This is definitely my style: light, you know, easy to drink. So I’ll give this one two thumbs up. But I know, I kinda know what Amber’s review’s gonna be.
Amber: No, I actually am gonna give it two thumbs up too.
Steve Jones: Really?
Amber: I know normally I am way more of a dark beer person. I like this one and it makes me think of college and the kind of beers that we drank in college. Like It’s a scenario specific beer I feel like but it’s easy to drink And it doesn’t have some of the bitterness that we’ve had with some other ones. So I think… And we can get this in the grocery store. So I probably will tell Chris we should actually buy this again just for us to drink not just for podcasting.
Joe Dolson: I mean, this is just a nice, chill, relaxing, easy drink. I mean, it’s not like it’s fancy or complex, but it is– I may be influenced by the weather right now and the fact that in my office it is currently roasting. And this is exactly what I want to be drinking right this minute so…
Amber: Do you not have air conditioning, Joe?
Joe Dolson: We have window air conditioning units, so I can’t really run them when I’m on something like this.
Amber: Oh. All right, so you want to switch topics right now.
Joe Dolson: And it’s not easy to install air conditioning in a house with radiators.
Anne McCarthy: I’m in the same setup in Seattle. We have like an a window unit, but then otherwise… But my partner grew up in Missoula, so she never wants to turn it on. She’s always like…
Joe Dolson: Yeah.
Anne McCarthy: Yeah, she’s always like, “We just open the windows. We just open the windows all summer.” And I grew up in Florida, and I’m like, “No, you have air conditioning. Like, turn the AC on.”
Joe Dolson: Always open the windows, and when I moved to Minnesota, one of the things I definitely learned is you do not do that here.
Anne McCarthy: Really?
Joe Dolson: There are way too many bugs. It is not a good idea.
Anne McCarthy: Oh, that makes more sense. Yeah.
Amber: Yeah. I also grew up north of the Mason-Dixon Line. I think that is like a separator, ’cause even here it’ll be like 79 out and I’ll be like, “We should just open the windows.” And Chris will be like, “What are you talking about!?”
Anne McCarthy: No.
Amber: I’d be willing to open them even in the low 80s sometimes. I’m like, “I want fresh air.”
Anne McCarthy: Yeah.
Amber: If you grew up south of that, you’re like, “No way.”
Steve Jones: Yeah.
Anne McCarthy: Shut all the windows, turn the AC on.
[00:10:26] What is the Accessibility Lab plugin?
Amber: Yeah. Well, we invited you here to drink a very tasty beverage and also to talk about the Accessibility Lab plugin. And, Anne, you wrote a blog post that was released on was it the meta blog for Make WordPress?
Anne McCarthy: Yeah, or the Make Accessibility.
Amber: We’ll make sure we find a link and put that in the show notes, but could you give us a quick summary of why this plugin was introduced and what it does? Let’s start with what it does.
Anne McCarthy: Yeah, so it’s a combination we can get to the why after. But it’s a combination of two things. Sometimes we run into features when working in core where it needs more testing or it needs a different pathway for experimentation where we can get people using it to figure out like the right approach. You’ll see this with things like real time collaboration or with AI, performance.
And working for awhile in the project I noticed we were coming up on those situations and then it would stall or dead end because we didn’t have a very clean or clear pathway to do that. And that’s a bummer. Combined with that I hear from a lot of different people especially when I was running the sighting outreach program around shared accessibility needs whether it’s an agency, higher ed, a business owner who is trying to basically be like what do you recommend I use? And how can I use something that’s well supported and that we can adopt?
And I saw a lot of duplicate solutions being used. And Matt over the years I think he has post from 2022 that I can dig up where he talks about canonical plugins and I think at Word Camp US this year he also talked about. My brain was kind of fried that day so I apologize if I probably gonna misremember some of it.
But he talked about having really high quality plug ins to solve shared problems in the project. The plugin also seeks to do that. So providing really good features that people will use that solves a shared need that all of us can contribute to this one area. This won’t work for everything; I mean there’s a million different performance plugins, AI plugins, accessibility plugins.
Like this is… That just is what happens in the project.But especially in this age of AI I’ve been thinking about that a lot where it’s like how can we have a community run maintained option for people that can provide valuable features when it comes to accessibility that may not happen in core.
And so it’s a split. It’s a pathway for experimentationin core with a core track, a very explicit core track. If we want to land this in core we need a place to put it and to have experiments and testing done that people can opt into and then also providing valuable features that impact multiple different user groups. Um,and so do you want me to jump into like how this came about ’cause it’s kinda relevant to this as well.
Amber: Let’s do that, but let’s first take a quick pause for a commercial break, and then we’ll come back and let you do that.
[00:13:09] Brought to you by Accessibility Checker
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. Thousands of businesses, nonprofits, 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’re a content creator or a developer, our detailed documentation guides 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.
[00:14:23] Why create this? How did we get here?
Amber: Okay, so we’re back, and why don’t you tell us a little bit more about what you were thinking before I so rudely interrupted you?
Anne McCarthy: I love it. Yeah, I wanted to talk about kind of how this came about. And some of it came from being involved in different release squads and planning their roadmaps for the releases. So I pay a lot of attention to how work is done, how things get added into core, why they do, what works, what doesn’t work.
And one of the things I noticed in the last couple cycles particularly around AI features and performance features, having the plugins aside as areas where they could work on things, get things into place, get testing, try different approaches in a smaller subset without trying to land something big in core. I notice that model was working pretty well and I was on the release squad for 7.1. And as part of that I noticed that when I had a call with Matt about some of the features for 7.1 and this all in public record he was basically like,” I don’t want to add an AI feature unless it has double digit growth.”
And in that conversation about 7.1 we talked a lot about how much to be careful with what we do include and how important canonical plug ins can be the project to further development. This kinda runs on theme; I think the post is in 2022. He’s been talking about this years, and when the media library change happened it kinda was like breaking point for me. I was like interesting, I wonder what we can do to further brings accessibility into the same feature development pathways that we have in other areas of the project, and I wasn’t really sure whether this was a good idea. It’s something I actually pinged Joe about and talked to different people about. At the same time, there was a guy named Troy Chaplin who had shared with me some of the stuff he was doing with a plugin that he was working on, and how much he wanted it to benefit the project, and how could he do that?
And so it was kinda this weird merging of things. Like, I’m watching 7.1 happen, I’m watching us punt features, but then the feature development can continue in this AI plugin. And then I’m also seeing, like, these canonical plugin discussions. What would it mean for the community if we had these really good plugins that people can use and that could solve real problems? And it just kinda, like, felt, like one of those moments where all this stuff was coming together, where it felt like this could make sense if we positioned it correctly, had a narrowly defined scope, had people use it when it made sense. And the last piece which I didn’t quite… Which is related to this, is also some of our education work, the WordPress education programs with WordPress credits and getting new contributors into the project.
People are really intimidated working on core. It’s just intimidating. It’s a high bar. You have all these scary names. Or you get no traction. It’s just one of those things where it’s hard. And one, a group has been working on pathways basically to make tangible tasks easier for people to jump in and contribute. And accessibility is an area I think we’re all trying to get more contributions on, and so this felt like another pathway where it’s like I’ve seen the AI plugin get some really good contributors, same with the performance plugin, same with Gutenberg even. Like, people find it to be a lower barrier of entry.
And so that was another piece of this, is I was like, “Okay, if we can have this Accessibility Labs plugin, potentially this means that we could get new contributors working there in a more contained space.” Smaller scope in some ways for certain things, but people could see their work have an impact, and it could be a part of the contribution base.
So it’s kind of from all these things, like shared problems I’ve been hearing from lots of different people, Matt’s desire to see more feature development happening, not necessarily in core, but alongside core with some supported community options. The ways in which we’ve been able to land features coming up from plugins over the last few releases and how valuable that is as, like, a data pool and, like, instance of users, and then the contribution experience.
So it’s a lot of things. I probably did a poor job of communicating that in the post. You should have seen earlier drafts. But that’s the full context of it.
Steve Jones: No, I think that… I mean, I think you did a fantastic job of just describing why this was created and kind of the framework in which it helps facilitate the contributions to accessibility.
[00:18:19] Anne and Joe Share Their Visions for Accessibility Lab
Steve Jones: I’d like to go a little further into what the plugin is and to some of the features that are already there, some examples of features that you kinda envision for this and that might be able to be accepted in.
Can you kinda walk us through some of those?
Anne McCarthy: Yeah. Joe, I don’t know if you want to touch on any of this either, ’cause, like, you were very critical in helping understand, like, what would be good to test, and you’ve had some good examples that immediately came to mind as well.
Joe Dolson: I mean, I think it’s difficult to talk about the plugin in terms of what features are actually there because it’s really early.
Anne McCarthy: Really early.
Joe Dolson: Still in the…
Anne McCarthy: Like, yeah.
Joe Dolson: Scale of scoping out exactly what are we going to focus on building, and there’s a lot of different aspects to that like what makes sense? What is useful? What are the targets? One of the areas of focus is trying to solve problems that are fundamentally difficult to solve in core because there are certain types of things where shipping them directly in core is actually incredibly risky. Although ironically some of those things in a plug-in are considerably less risky. Oh, I can talk about that if you want to get into some nitty gritty about it but…
Steve Jones: Yeah solid examples are definitely kind of what I’m looking for here. Yeah, like, I mean…
Joe Dolson: One of the things that I’m really pushing for is to try and refactor how we handle the storage of alt text in Core. Currently, it’s stored a meta field. It’s just a simple text field which is itself fine, but meta fields are fundamentally very difficult for indexing and searching. And that is the reason that you actually can’t search on alt text in the media library by default.
Steve Jones: Performance, right?
Joe Dolson: Yeah, it’s a massive performance problem once a library starts to get really large.
Amber: Can I pause for a second?
Joe Dolson: Sure.
Amber: I kinda want to tangent on that a tiny bit only in that I feel like WordPress core search, like, sucks, and that’s why people install Relevanssi and, like, these other plugins. And I’m like, is this really an accessibility or, like, a moving the meta, or should just, like, WordPress search be fixed? Because it would also solve things on the front end.
Joe Dolson: So yes, WordPress search should be improved. However, that wouldn’t solve this problem ’cause this is actually a data storage problem, not a data searching problem. The reason it becomes a problem for search is because you have to pull in that meta index into the search results, which massively complicates the search queries and makes them really slow. Speed is not one of the problems WordPress core search has, because the core search searches just a single well indexed table. It’s searching, you know, post content, it’s fine. But because the alt text is not in that table, it now requires a join. joining a table that doesn’t index so it’s really messy.
But making a gigantic migration to essentially move the alt text into the post content table with the additional complication that whatever is already in that post content field has to go somewhere else, ’cause currently the description field is stored there. And while that is a rarely used field, it’s not an unused field.
And of course we have very little way of knowing what kinds of weird complications people may have added in their own plugins. So swapping those is incredibly difficult. And then I would like to add to that, but actually I’d like to change the structure of the alt text as it’s stored. Currently, it’s just a simple text field. I’d actually prefer to store it either in a, like in a structured JSON or in something with perhaps block demarcations.
Steve Jones: Mm-hmm.
Joe Dolson: To separate different blocks of alt text. Because the reality is the… Alt text isn’t singular. An image shouldn’t be represented by just one single alt text. And this would make some of the things that we’re doing a lot easier. Like we pull in alt text from the image metadata. Great.
Steve Jones: Yeah.
Joe Dolson: That shouldn’t be the only option. You just can’t, you can’t have multiple choices. You have to custom do anything that’s other than that one media item that’s stored there.
Steve Jones: Right. And this is because of context, right? Because of where the image lives?
Joe Dolson: Exactly.
Steve Jones: Yeah.
Joe Dolson: Because an image that is– I mean obviously if of the decisions that the block editor has made is if you edit an image in the block editor, you know, in the content and add an alt text there, that is not saved back to the media library. Which is okay except that it means that if you actually want that content to be stored in your media library and you want that image, like when you’re say doing an analysis of your media library to come up as having an alt text, you have to actually go edit it twice. You have to do it once in the content and then again in the media library. That’s a real hassle
Steve Jones: Mm-hmm.
Joe Dolson: But the decision was made because this is supposed to be use specific. It is something where the usage of this alt text should not be what you have stored in the database; it’s a usage. And it should… it can start from that but that’s not actually what the image should be. And we can do a lot to fix that problem by enriching that data. But doing that directly in core?
Like that means we have to do this massive database migration process. And doing that in a core release is terrifying to me. That’s like we have to really write some scripts that are going to be able to potentially handle like millions of rows with a vast number of unknown exceptions. And if we can just work on that in a plugin it’s so much more relaxed. It gives us time. We can develop different options. Learn about the bugs because we can encourage people to install this plug-in on a, you know dev environment, a staging environment. I- that to me is the kind of thing that we should really be working on, because it is so difficult to tackle in core.
[00:24:29] Can persistent, helpful features coexist with experimental features that could break some WordPress configurations?
Amber: Yeah, so that almost suggests that in order for this plugin to be really useful, there’s probably some minimum threshold of like types of sites or numbers of sites that need to actually just be running and testing against it and reporting issues, because otherwise you’ll never get over the threshold of being afraid to move something into core.
Anne McCarthy: That’s…
Amber: It has to stay in the plugin forever, right?
Joe Dolson: That is also a problem with any core change ’cause the reality…
Anne McCarthy: Yes.
Joe Dolson: Is getting people to actually test betas and release candidates is incredibly difficult. Those are so incredibly under tested. There will only be like 3,000 active installs of a release candidate.
Anne McCarthy: We do test them on WordPress.com, for what it’s worth. We will do, like, 20,000, 40,000. I know. That’s, I just always have to say that ’cause I’m like, we do a lot. I force our systems people.
Steve Jones: Yes. Yeah.
Joe Dolson: I say installs and not, sites because actually number of sites is m- considerably less relevant. It’s number of unique installs that actually matters.
Anne McCarthy: We do test on individual instances. It’s just hard to we have WordPress WP Cloud is one of the things that our systems teams run, and those are individual instances, and those are tested on there intentionally.
Joe Dolson: And I do…
Anne McCarthy: Yeah, but it…
Joe Dolson: …cloud of testing is extremely valuable on certain types of stress tests.
Anne McCarthy: But not this, it’s different.
Joe Dolson: But what that doesn’t give us is the vast array of potential plugin strangeness, oddities, unusual server configurations. You know there’s so much. Like…
Anne McCarthy: Yeah.
Joe Dolson: I would love 10 times that much testing.
Amber: Like there is a weird threshold over figuring out… Like maybe what we need to do is figure out how to make it easier for people to test. Because I have tested and I have found issues, but I’m like, “I don’t have time to go write a really detailed Trac ticket or Gutenberg issue that explains how to replicate it,” and all this stuff. And then there have been a few times when I just DM Joe, and I’m like, “You should go look at this block because it has accessibility problems.”
Which is horrible ’cause that pushes all the work on Joe and makes me kind of a jerk, but I’m like, I know it has problems, but me trying to figure out how to document it in a way that like, like. When I find an issue for Steve, I can be like, “Steve, this doesn’t do X,” and he’ll be like, “Okay, whatever,” and he’ll go figure it out and he’ll fix it. But if I have to open that for WordPress, I have to like explain to someone who doesn’t understand screen readers, doesn’t understand all these things, and it’s like this huge… I don’t know, like there’s a big like hill you have to get over. It like adds so much more time to creating a ticket, and I feel like that’s part of the challenge with this not being able to test. There might be people that are running it and are testing it and they’re figuring out their own things, they’re not reporting it upstream because it’s too much work for them to report it upstream.
Joe Dolson: I think there’s no denying that is a huge challenge and a huge problem we have in core development. And I mean, we– you can’t ignore looking at the fact that between our Gutenberg and core bug trackers, we’ve got somewhere in the vicinity of 13,000 open tickets, and that is overwhelming for absolutely everybody. Know, I spend a lot of time on old tickets, those are
Amber: When the first question is, “Did you search to make sure you’re not creating a duplicate issue?” That might make people be…
Joe Dolson: But even that is not trivial. I mean, sometimes like issues are extremely hard to find because… if you do even a casual search, make an attempt to find it, just open the ticket, it’s fine. If somebody knows it’s a duplicate, they’ll close it and link it to the duplicate. You’ll still get credit for having reported it’s fine. It can help raise the presence of an issue.
Steve Jones: Yeah totally.
Joe Dolson: Like I will know for a fact that there’s a ticket on a particular issue ’cause I have seen it before, I’ll be like, “But I can’t remember like the right words to actually find this ticket,” ’cause they didn’t use the words I’m thinking of to describe it.
Anne McCarthy: AI has helpful. A group of us have closed about like 600, 700 issues in Gutenberg that are all just like stale. Like it’s just like, or it’s no longer relevant. So there is a big effort because we do need to get, and my ideal would be we gotta get that down. There should probably be like 1500 to 2000 issues open in the Gutenberg repo.
We just got under 5,000 for the first time in like I think a year and a half or something like that. I remember when it went over 5,000 and I was like, “Oh, no.” And we were creeping up almost to 6,000, and now I think it’s around 4700.
Joe Dolson: Part of the problem is stale issues that are–
Anne McCarthy: So many stale.
Joe Dolson: But one of the things about the plugin is it can be more focused. It’s it doesn’t require somebody to think through all of the vast numbers of things in core and all of those track tickets. Yeah, we’re trying to focus on a subset of problems. There was a recent conversation in the repository for the Accessibility Labs which was about the question of adding support for ARIA attributes to blocks.
So basically you can declare variety of aria attributes. It’s one of those things that I think it seems like a no-brainer. Seems like, “Yeah, of course we should allow this.” But it’s actually got a lot of complexity to how and when we should allow it. While it seems great, like of course you should be able to declare an Aria label on this ’cause it’s…
Steve Jones: Mm-hmm.
Joe Dolson: An icon, and you should be able to declare that. The problem is once you’ve allowed an Aria label, like first of all people are having to maintain two different types of content. You’ve got something that’s visible and something that’s invisible. We’re not good about that.
I mean, an Aria label is a really absolute piece of naming ’cause it basically overrides anything else contained within that element. So like it’s dangerous. It is not just an absolute like, oh yeah, we should totally support this. So I think the plug-in is a good place to explore that because we can really start to study it and try implementations and see what… maybe try and see what people actually do before just deciding to add that.
Because I think there are some checks we can add, and I think some of the stuff that Troy has worked on with block validation can be some ways of kind of adding some safeguards.
Steve Jones: Mm-hmm.
Joe Dolson: Like, Yeah, no, you just did this, and I think you better double check that.
Steve Jones: Yeah, we’ve done some proof of concepts in regards to this ourself and definitely, you know, not opening up attributes wholesale was definitely like one security problem, right? You need to be able to sanitize these things out correctly. And two, it’s like you said, it’s extremely dangerous. And s-some of the work some of the work has been to like facilitate the application of those attributes.
So when you…
Joe Dolson: Yeah.
Steve Jones: Choose a certain attribute, you try to validate or you try to expose a notice that kinda guides them in the right direction.
Amber: I think on our end it’s maybe a little easier for us to put that in our plugin ’cause we have a scanner, so we could do something like if there’s text and it doesn’t match…
Steve Jones: Yeah.
Amber: The accessible name, we could alert them and give them, “You have entered an aria-label that fails label and name,” for example, right?
Joe Dolson: Right.
Amber: But without having a scanner, that makes it more difficult ’cause they’re not gonna necessarily get any feedback.
Joe Dolson: Well, and I think like the extremely strong bias that the block editor has towards rendering things as they would appear, can really get in its way from being actually supporting accessible content construction. Like it’s not going to show you things like the alt text in the content. That wouldn’t be visible on the front end so you can’t see it on the back end. It’s hard to see. That’s gonna also be true for any kind of ARIA attributes you ever add.
Those are now invisible. They can only be seen when you’re actually looking at the block and checking the inspector and that makes that content more fragile. And what I was actually about to say was when you look at something like how the WordPress added recently the tabs block, so you can…
Steve Jones: Mm-hmm.
Joe Dolson: Create a tab panel interface. Technically, that whole thing could have been omitted and we just added the attributes to declare it and support for, you know, declaring things through the interactivity API so you could just create it yourself with code in the block editor just by declaring things.
However, that would be incredibly fragile and it would mean that we would have dozens of different implementations, most of which were broken. So no, instead we create the tabs block, which we’ve checked and tested and then like, okay, everything’s being done right. And I think that’s an important thing is that if this is why in something as powerful as the block editor, it’s really important to make these decisions for people. Like yeah, we’re gonna decide how these attributes are applied because it’s too fragile and too dangerous to just let them be done willy nilly.
Amber: Well, and I mean, I don’t think that WordPress as a CMS is built only for developers, right? And perhaps maybe developers are a small minority of the human beings who use the block editor to create content. And so really, I think it’s that weird thing, like, do you want a small number of blocks, or do you want blocks that are just easy for people to use right without having to think about it?
Anne McCarthy: The other piece of this that I am thinking about too and part of why it’s not… This plugin isn’t just pure core track experiments we need testing, and why there are features is incentives. If we get people to be like, “I want to use this plugin because it adds these cool features. Oh, here’s a option where I can actually give back to the project, and, like, test this new thing because I care about accessibility and I’m using this plugin,” there’s kind of a flywheel effect there, where people will want to use it.
They’ll have the opportunity to opt in. Obviously there’ll be consent. We won’t just, like, rogue turn this on. That’s the whole point of it, is you kind of turn these things on and customize it as you want. But the idea is to bring people in to solve real world problems that are happening across people using it. And then they have the option of, like, kinda going into, like, beta mode of, like, test this thing.
And my ideal– I came from… I got my start in WordPress as a student at UNC Chapel Hill, and talking to folks in higher ed, there is, like, a really big need for a lot of this stuff, especially for some of the stuff with the accessibility checks for students when they’re writing content or for a marketing team at the university or whatever. There’s a lot of need for that. And so my hope is that we can potentially get large amount of people using it depending upon what ends up being put in the feature set, and if people are game to have their plugin be absorbed, like Troy was game for that. I think there could be a real possibility to kinda gain steam on it, but we’ll see.
Part of this is also everything I do is an experiment. Like, I’m like, let’s see if we create this space, what happens? Who comes? Who shows up? What ideas show up? What can we do? What works? What doesn’t? Like, all of it is information, all of it is, like, a current approach. And so if I will be the first person to raise my hand if six months from now I’m like, “This isn’t working.” I had to kill another pet project of mine months ago, and it sucked, but it’s like, yeah, if this isn’t working, I don’t want this to be a dead end either. And so I’m really excited if we can kind of have this combination of features to pull people in and then, yeah, really hard, gnarly problems that then we can potentially get more insights from because we have invested time in building features and have an interested audience who’s in line with what we’re trying to do.
[00:35:53] The Technical and Organizational Challenges Behind Data Collection
Amber: Do you know, has there ever been any conversations around these canonical community supported plugins adding data sharing opt ins so that… you know like me talking about the problem of feedback is a weird barrier for people right? If people could use the canonical plug ins whether it’s Accessibility Lab or any of the other ones and then opt in to send data back to be like “Here’s what is turned on,” here’s if there’s other errors that happened right?”
That kind of thing I feel would maybe help with that barrier.
Joe Dolson: Those conversations are… They don’t generally get anywhere mostly because there are very few people who can authorize that actually happening. And ultimately, that all has to go through Matt. ‘Cause anything that’s gonna ultimately be data collection, that’s gonna get push, pushed back to .org.
We’re gonna need an endpoint that handles it. We’re gonna need some kind of authorization for who can view this data and how do we get it shared, and sure it’s secure, making sure it’s private, anonymous. There’s a lot to it.
But it has absolutely been talked about because in the — going back to that conversation about how difficult it is get, to get people to test betas and test RCs. Part of that conversation was how difficult it is to get feedback from those people and how to know what they’re actually testing. One example of this is in the Gutenberg plugin, there’s the experiments panel. There’s a ton of stuff in there that can be turned on. We have data about how many people have the Gutenberg plugin installed. We don’t really have data about which experiments are actually being used.
So we don’t– we can’t say, “Well, there’s this many people installing Gutenberg, X number of those people have tested the experimental media library mode.”
Steve Jones: Yeah, so you don’t have, you don’t have precedence to implement something like that. Yeah.
Joe Dolson: That’s the kind of data that we really need to be able to get good information about that. One thing that has been talked about is actually adding that into the beta tester plugin so that the beta tester plugin can act as the feedback mechanism and can also… Can provide things like bug reports like a, an actual interface for people to do that. So at some level, even if somebody was using the , the lab plugin would not be responsible for managing that feedback loop. They could get that by installing the beta tester plugin, and that could be used in any context that involved any kind of beta testing. And I like that because that would be kind of a centralized tool.
Only one group of people has to actually maintain that tool set, and then all the other experiments and lab projects can actually take advantage of it. But yeah, it’s definitely been talked about. I have never seen any actual headway.
[00:38:40] What is the Accessibility Lab not going to do? Where is the line?
Amber: Yeah. That’s interesting. So I think it would be worth us talking for a minute about what this plugin will not do or is not intended to do, and Steve, I know you had some concerns when you first saw it, and you were talking about, like, some of the things you’ve contributed back to Gutenberg, and I don’t know if you wanna talk a little bit about that and those concerns, and I’d love to hear Joe and Anne’s thoughts about this.
Steve Jones: Well, I think I can bridge the previous conversation with this one, right? Like, you know, where Joe was talking about updating how meta is stored and things like that. While yes, it is easier to do inside of a plugin, but from an engineering level, the shape of achieving that in the plugin and the shape of achieving it inside of Gutenberg take a vastly different shape.
So where one may be great for testing and fact-finding and figuring out bugs and the different systems in which a, you know, migration script has to run, there’s ultimately gonna be, you know, a time in which a feature graduates into something more mature that needs to go inside of Gutenberg. So being that resources are short, it’s hard to get people to contribute that feels like a very large friction, like going from plugin to core.
What is the actual case that actually happens? Or would it just be better to like, you know, do it in a PR, right? Things like that. So but that’s just kind of touching on the point before, but I think that the article actually kinda went into a little bit more what the plugin’s not intended to be as well, and I think it’d be good to touch on that too.
Joe Dolson: So I’m gonna start, I think by answering the first part of that.
Steve Jones: Yeah.
Joe Dolson: You know like, the difference between approaching something in a plugin and approaching it in a PR is like there– Like I referred earlier to the idea that this migration was going to be much easier in the plugin than it is in core, and that is because of the database migration process which in a plugin you can run that database migration while WordPress is running.
Steve Jones: Mm-hmm.
Joe Dolson: And in a core update, that not quite the same way it works.
Steve Jones: Right.
Joe Dolson: And that makes that whole process a lot more complicated. You know one of the things that was a risk point in real time collaboration was like okay if we add these new database tables, what is our tolerance for failure in that actually running. ‘Cause the… It’s really hard to depend on those database migrations definitely running. So yeah, there is, there are some definite engineering problems in migrating th-those back and forth. However, there is– it’s easier to get buy-in from all of the people who need to be involved in that complex engineering for that process, if you’ve got a proof of concept that definitely works and people are using it and liking the way it works. And that’s the thing you can’t really get out of the PRs because the PRs have testing that’s likely to be limited to like ,a really well tested PR is like six people.
And that’s not enough to give you good data whereas the plug-in if it’s got thousand active installations and half of those have run that migration and been like,”Yeah this is cool. I love this is great.” You’ve got really good data and that can motivate people like,”Okay this is worth doing, this is worth putting in that engineering time and effort.”
So I think there is a really meaningful difference there. And of course, there’s that second part; what can we– What should we absolutely not be doing in this plugin? And I do think that is one of those… it’s a fundamentally subjective question because there’s going to always be some kind of boundary where we have to set between, “Is this just a bug that needs to be fixed or is this a complex problem we need to work out?”
And especially with some of the stuff like, like the block validation tools. Should that just be an API that’s available in the editor so that people can use it to write and run tests within that context? Or should it be in a, in this plugin permanently? And I think there’s a lot of room for trying to make, having to make those decisions. But I personally will set a very hard line against using it to fix, just fix the problem, especially permanently.
I mean, I feel strongly like if it’s fixing a problem, if it’s fixing an actual accessibility failure and that’s just th- It just permanently lives in this plugin, is just travesty. That shouldn’t happen. That damages the project on a wh- on a whole. I think that would be terrible.
Amber: I was just gonna say like when the conversations that I participated in before it was announced there was a lot of that and even conversations about whether this should be called the quote “accessibility plugin,” and I advocated very strongly for it should not be called that. Because one, I think that savvy users with disabilities and accessibility professionals will hear that as it’s an accessibility overlay for WordPress core. And like you know if your Aria labels are missing and then you activate this they’ll all be there. And I’m like well first of all that shouldn’t exist in this plug-in and like it just, it starts it out on the wrong foot. And I think it’s really important and I don’t know how we get around this and maybe you have thoughts beyond you know what we announced in the blog post that who knows what small percentage of contributors to WordPress saw.
Steve Jones: Mm-hmm.
Amber: But like I really don’t want people to think that this is the place where oh if something was coded as a div we can turn it into a button in this plug-in. Like no, I feel like it should actually be…
Steve Jones: Yeah, I think historically in WordPress that’s been like a, kind of a practice, right? You have your Gravity Forms plugin, and then there’s the Accessibility for Gravity Forms, right? And then there’s Elementor, and then there’s Accessibility for Elementor or Divi, right? So on and so forth. So I th- I think that kind of, you know, I think you did a really excellent job there, Joe, of kinda differentiating between you know, fixing accessibility and actually using this as an experimental labs plug-in to one, solve, do a proof of concept and two, collect and to garner the feedback and the buy-in for these features.
Anne McCarthy: Yeah, and I’ll add like, I think there’s also some interesting stuff with had this conversation with, I think it was Select Mode back in the day, and with preferences, and with all this sort of stuff. Like we’ve had these different conversations about how can we give actually more…. You know, there’s con- there’s needs conflict.
[00:45:14] What belongs in Core versus Accessibility Lab?
Anne McCarthy: Accessibility is not just one thing so it’s like one of the things I’ve been theme opening an issue on that I haven’t done yet ’cause time. Having more preferences specific to accessibility that are well supported in the plugin, that then we could see what to graduate into core as well. Like, I think there’s like really interesting you know, when you’re setting a phone up, when you’re doing whatever, there’s these accessibility options that are presented.
It’s like, can we do something with that? Could that… But it’s like should that be an Accessibility Lab plugin or should that be in Gutenberg? Like how could we approach this? And it’s, there’s a whole separate related conversation around distraction free mode in the editor, and separating basically that mode out into actual granular preferences. And I think the same could be done with different accessibility needs. Like there’s a lot of things that I think could be interesting to explore that probably my brain, I think part of the reason why I haven’t opened it is ’cause I’m like, “I actually think that might make more sense than Gutenberg.”
But there’s some stuff that core may not do, and that’s where the line goes into feature set. So it’s like if core is not gonna do this, we hear this need across the community. Instead of a bunch of plugins being started, it’s like, let’s give people, here you go. And then also you wanna test these things that are in progress, great. Like, I think there’s just that nice loop where we can get people in the door by solving real needs and providing cool features. But then yeah, we have to make sure Gutenberg and Core are accessible. Like it makes… I am nothing, if not practical, and that is like so inefficient to just like, I just like, that would like I don’t even want to think about either.
That drive, that would drive me crazy if it was like, oh, we made all these fixes just in this pla-… It makes no sense. So yeah, I don’t, that is not the intention of the plugin at all, and I think I started the conversation about re- naming it to Accessibility. I think it’s like a, want people to, getting the names right are hard. Like the AI plugin all of a sudden, by WordPress.org sounds really official, and so I think there’s a level of like that I was trying to strike, and it was really helpful to get feedback. I mean, this is partly why the community’s so awesome and like hearing from different perspectives of like, “No, it’ll be easier if we call it a lab.”
And I’m like, Yeah, that’s perfect. Performance Lab. That’s what the performance Like these were taken from, you know the whole concept is not new, which is great. We can watch and see what other people have done in the past they have walked to see how we can also create momentum with this effort, so. But yeah, rest assured the fixes need to go in Gutenberg. The fixes need to go in Core. This is definitely for like narrower edge cases, if that makes sense, or edge case isn’t the right word, but…
Joe Dolson: Yeah.
Anne McCarthy: Narrow scope.
Joe Dolson: Well, I think it’s things that need balance.
Anne McCarthy: Mm-hmm.
Joe Dolson: I think there’s two points that you raised that I want to come to. One of them is you mentioned earlier, not in the most recent section having features in the plugin that draw people in, which is an interesting thing.
[00:47:56] Does Accessibility Lab belong on live sites? Opinions are divided.
Joe Dolson: And that had not even occurred to me that’s what you were trying to do when you were talking about these the features like the block validation and offering practical help. Which is– It’s kind of an interesting thing that I hadn’t considered at all, that there is an element of wanting something stable in the plug-in that actually causes people to use it. ‘Cause as a pure experiments plug-in, there is a legitimate concern that if all this is experimental things, meh, why bother? You know, the same reason people don’t do beta testing.
Anne McCarthy: Carrot and stick, man.
Amber: I- mean…
Joe Dolson: And…
Amber: There is a weird line there though too…
Anne McCarthy: Mm-hmm.
Amber: If you’re also putting experiments in, should it be on a production website? You know, like, and so why do you want permanent production features and then experiments?
Steve Jones: Yeah.
Joe Dolson: Because some of them will have destructive potential. When we actually at some point ship anything that does any kind of database migration for alt text. That potentially is destructive.
Steve Jones: And I will underscore what you said, Amber. This should not be run on a production website. Like, these types of plugins should not be run on your production websites. And that’s where, like, you know, those features that, you know, the, the draw-in features where, you know, yeah, that sounds good on paper. It sounds good to get people over there, but what is the ultimate goal? And if the ultimate goal is these experiments, then it probably should…
Anne McCarthy: In my opinion, but I’m one person in this. So in my opinion, I think there are shared problems across the ecosystem that are replicated across everything. And if we think about every developer at a higher ed who’s working on this, who’s creating something for their students to create accessible content, if we could get them to work on this, would be a much better solution, and we can get a feedback for these real problems.
I, maybe I’m too optimistic. It could be the case.
Joe Dolson: I think that is a great argument for working on the features. I don’t think it’s a great argument for working on them in the plugin.
Steve Jones: Right. And we…
Joe Dolson: I don’t see that as a defense they should be plugin-focused, because, I mean…
Amber: I mean, I think…
Joe Dolson: Why should those things not be in core?
Amber: And the thing that I think about it too, like the question you were posing, Anne, when you were talking about distraction-free mode and stuff, and, like, should these be in core or should they be in a plugin? The difficulty of them not being in core is that there now has to be some sort of… the very first time someone installs WordPress, some way to surface, “Here are these other features that exist in a different plugin which you should install.”
And, so then the question is, do the hosts have to do that? Like, do the hosts have to say, “You’re using WordPress for the first time. Maybe you need accessibility,” lets it co-install Accessibility Lab every time a WordPress spins up, or does there need to be some sort of into WordPressCore…
Anne McCarthy: I see those features that you’re describing would be in core. They would not be in this plugin.
Steve Jones: Yeah.
Anne McCarthy: Do onboarding in core, so I see that as completely separate. Like, that could be a host specific discussion, but I do feel strongly about having people, things, shared solutions to shared problems across the ecosystem.
I get questions all the time and people end up building their own stuff, and it just feels like a waste of resources. I think this is where my brain goes to, like, inefficiencies, I would love for there to be, like, a really strong feature set that pulls people in. ‘Cause we don’t… Honestly, the AI and the Performance Lab plugins have done that. I don’t think Gutenberg has and so…
Amber: Even thinking about like some of the things Troy contributed, like for example suggesting the correct heading level to people and not allowing you if you already have an H1 you can’t insert another H1 somewhere else on the page, right? If we know that is a good feature that of websites should follow that logic when they are creating content then to me I’m like, “That shouldn’t be a permanent feature.”
Like we should get that gating stops people from making mistakes when they create their content. We should just have that in core.
Joe Dolson: There are plugins out there that force specific heading levels through the use of their specific patterns, through the use of you know, fundamental building blocks and their page builder that could violate that. And so like there’s a lot of subtlety to figuring out how to implement that so that it doesn’t literally just stop people from being able to edit their websites. But yeah, I do think it belongs in core. All of the Authoring Tool Accessibility Guidelines, that should be at least fundamentally possible in core. To me, I see It has– it really should be– There should be a block validation API core. It doesn’t…
That doesn’t necessarily mean that all of the rule sets need to be there. This is kind of the difference between the two different ways that automated testing is talked about. There’s two different way, two different types of automated testing. There’s essentially, there’s something like Axe core which is not run necessarily through automation but runs an automated set of predefined tests. And then there’s something like Playwright that doesn’t do anything itself but allows you to author all of your custom tests within it. And I think core is a good place for an API that allows you to write tests. I don’t necessarily think it should have all its own predefined rule sets.
Steve Jones: Mm-hmm. Yeah, because I mean, the, you know, block validation could span well beyond accessibility. Yeah…
Anne McCarthy: I’ve looked into this with, I sat in on some folks using real time collaboration recently and we were talking about workflows like when you can publish a post and the workflows for that. And a validation API could be similar to that. Like if someone at a large newspaper hasn’t set, it’s, where the post is gonna live on the home page. Like that could be related to validation right?
This plugin could pave the way for some of those early workflows and align actually really nicely with other parts of the project. And so that’s, that was another thing that’s on my mind with validation levels. And I think in the post I had something like, “It’s not currently on track for core but pieces of it might be extrapolated out,” or something like that.
And I think that, sorts of overarching shared areas are really interesting. And I’m like start now. We know that this is going to be a problem to validate before you publish. And so, and that can look like many different things. And I think it could be a really good use case for a shared API if we also have people already using it. And that’s something I’ve been talking about with…
Joe Dolson: Yeah, in that case, like the Accessibility Lab plugin could be a place where a broad set of example test cases could live.
Anne McCarthy: Mm-hmm.
Joe Dolson: They leverage that API. And that could be as much as anything that’s showing you how to use it’s giving you a kind of a default set of standard tests, but you can extend them, you can eliminate ones that are a problem for your particular case. You know I think that’s a viable way of approaching that.
Anne McCarthy: And it’s just hard to know with, like Matt has very… It was very interesting talking about 7.1 because there is a sense of just being very precious about what goes in the core, especially with security, the rise in security issues the surface area that can expose. So it’s like how do we balance?
Part of this is like a practical thing. It’s like I’m hearing from across different areas that it’s try a plugin, get momentum, see what happens. Like, there’s a lot of room for more community supported efforts and concentrating contribution around that, and so like I didn’t want accessibility to be left behind in that. And so I think this gives both in terms of WP credits thinking about getting things into roadmaps, it just gives another avenue. It’s another tool in the toolbox, and again it– We’ll see how it evolves ’cause I think it could either evolve really nicely or you might find that there’s a lot of philosophical disagreements and it doesn’t work.
I don’t know, and that, I think that’s part of what I’m excited to talk about it now and it’s super interesting. Like the feature thing, I’m like, “Oh, that’s so interesting.” Like clearly disagree, but I don’t think it’s completely at odds. I’m like, yeah, this needs to be shaped more. Like we need to figure that out more or the Performance Lab plugin for example, they break out their features into different plugins.
So there’s like a subset of bundled plugins that when you activate it installs other plugins. So it’s like there’s all these different models to potentially look at and follow and I’m just excited that we’re even talking about them. I don’t know. Yeah, I just am stoked that care this much. It’s really awesome.
Joe Dolson: The goal of this is to try and test hypotheses. So if we have philosophical differences that just means that now what we need to do is ship something that has each option as an available choice and we see what people actually prefer. It might be 50/50. I mean, the reality is like there are tons of things in accessibility that are highly subjective.
Anne McCarthy: Mm-hmm. Mm-hmm.
Joe Dolson: You really have to carefully balance. Things like the verbosity of how you label a control. Like how much information do you actually need here? People frequently tend to go way too much. But you know If we were trying to make a decision maybe we just ship that as an option. This is where we can try options. ‘Cause…
Anne McCarthy: Yeah.
Joe Dolson: In core, we’ve committed to something and…
Anne McCarthy: Yes
Joe Dolson: Shipping it to millions of people. Here we can be like “Hey, try this out Let us know what you like better.”
Amber: Yeah.
Anne McCarthy: And then it’s so much easier to advocate into a roadmap. It’s just so much e- I just can’t even begin to explain. Like, if I can come with data, with numbers that it becomes a lot a very different conversation.
[00:57:10] How to Help Shape Accessibility Lab
Amber: So it sounds like there are a couple of ways people can get involved, and tell me if I am missing anything. So number one is going to the GitHub repo which is on github.com/wordpress/accessibility-lab. And you can participate there either by contributing code or participating in discussions or testing things.
And then I’m thinking the other way is we want people to install this plugin. Is it up on WordPress.org in the plug-in repo?
Anne McCarthy: it’s so… This is so early right now. Intentionally I’m actually like embarrassed by the code for my piece of it. Troy has been cleaning a bunch of stuff up, but I think when there’ll come a moment when it’s less of a help shape the plugin, so share your ideas, share feedback. Yeah, you can install it and test it on a test site. But more like ideation phase, and then I think we’re in a point where it’s like, okay, we want people using this. I would like to do a more specific push for that’s just my own like perfectionism, I think.
Joe Dolson: I mean, I think one of the first things is just deciding, okay, what are we actually going to ship in the first version? We haven’t yet met to discuss that, and that will shape a lot of what is actually going to happen, because we need focus before we can do any kind of actual release. Like this is not meaningful yet.
Amber: Cool. Well, this has been a great conversation. Thank you both for joining us. Can you share how people can follow up with you, the best place to get in touch?
Joe Dolson: Sure. You can find me at my website, JoeDolson.com. You’re– I’m always available in the WordPress Slack instance with @joedolson. I’m occasionally to be found on Blue Sky or Mastodon.
Anne McCarthy: I am also always available on WordPress Slack and Sazzu which is an old nickname. Otherwise, nomad.blog, my contact form’s on there. I love whenever people reach out. I always always wish I heard from people more.
Amber: Great. Well, thank you both so much, and cheers. I hope it cools off for those…
Steve Jones: yeah.
Amber: (Cross Talk) … hot weather. I have no hope of that down here. So I will enjoy my cerveza in the 100-degree weather.
Steve Jones: Well, there we go.
Anne McCarthy: Thanks so much, and thanks so much for having us. Yeah, this was wonderful.
Steve Jones: All right. Cheers. Take care.
Thanks for listening to Accessibility Craft. If you found this episode valuable, please help us reach more people by subscribing, reviewing, or liking the show, and sharing this with your colleagues. Accessibility Craft is a production of Equalize Digital Inc. Steve Jones composed our theme music. To learn how Equalize Digital can support you on your accessibility journey, visit us at EqualizeDigital.com.