Interview and Discussion with Joe Dolson on State of Accessibility in WordPress

Rachel Cherry:
Hi, Joe!

Joe Dolson:
Hello!

Rachel Cherry:
Good morning, you're on the other side of the coast, right? In California?

Joe Dolson:
Yeah, yeah, I'm in San Diego right now, so, uh, yeah, this whole starting at 10 a.m. thing, doesn't feel the same right now.

Rachel Cherry:
I bet.

Well, we're grateful that you gave this time to us today, and we don't have a lot of your time, so I want to go ahead and dive in and start talking about accessibility in WordPress.

So, first up, how would you describe the current state of accessibility in WordPress Core today?

Joe Dolson:
Um, obviously it's complicated.

uh, you know, WordPress Core is kind of divided into two parts, because there's the whole Gutenberg.

Block editor, site editor, which is maintained in one codebase.

And then there's WordPress Core, which was maintained as a completely separate codebase, and they get periodically merged.

Um, but when I'm talking about WordPress Core, what I basically mean is this is the stuff that is in.

the WordPress Core package. So anything from Gutenberg that's been merged is now WordPress Core.

And overall.

But the accessibility in that.

Combined package has been steadily improving for several years.

It's always difficult.

In part because that merge process, getting things.

into core from the Gutenberg package.

Uh, tends to happen really, really late in the release cycle.

And, uh, sometimes you just get surprised. We're like, oh, I didn't know that was happening.

Uh, because there's just so much going on.

Uh, like, this particular release, which is coming up very soon.

Amber mentioned to me, Amber Hines, that she'd looked at the math block and saw a problem with it, and I was like.

There's a math block? Oh, okay.

I guess I'll need to look at that.

Um, so it's always challenging, like, there's just so many different things, and, you know, I'm sure.

They all need to be looked at. But overall, I feel like it's a steady progression of improvement.

There are always problems that are popping up.

But we're polishing things, and I think the processes are very slowly getting better.

Rachel Cherry:
So basically what you're saying is that WordPress has all these distributed teams that have challenges, uh, communicating sometimes and working together.

And I think our audience can appreciate that.

Joe Dolson:
Yes, I think they can.

Rachel Cherry:
Well, that's good to hear that there's positive, constructive progress happening, and or a general positive vibe.

I feel like we skipped over possibly introducing you and your role in the WordPress Core Accessibility Team, um, so why don't you, uh, kind of describe your role?

Joe Dolson:
So, okay, I'm Joe Dolson. I am a WordPress Core Committer, and I've been a member of the accessibility team.

for many years.

In WordPress, roles are also very distributed.

So, like, there are no formal leads outside of.

Matt Mullenweg and the people designated as the WordPress development leads.

Uh, not all of whom are even involved in CORE anymore.

So, I'm kind of the de facto accessibility lead for the project, simply by the nature of being a core committer, which means I have that power to actually push things forward and get them into core.

And by being an accessibility specialist who's putting a lot of time and attention into trying to make things improve.

Rachel Cherry:
What progress or milestones in the accessibility spectrum of WordPress have you been most proud of or encouraged by?

Joe Dolson:
I'm very encouraged by the fact that, right now, in WordPress development, in those processes.

Uh, what I don't see happening very often anymore is developers assuming that the knowledge they have of accessibility is sufficient.

And so there's a lot more requests for review, and, like, actual active desires to be like, okay, can we get somebody from accessibility to look at this before we put it forward?

Um, you know, the interactions with a lot of the new blocks that are coming in have been really positive, of being able to be like, yes.

You understand a lot of the basics, but you also understand that you don't know enough.

To make that final decision.

And I feel like, you know, if you go back, say, 5 years.

There was an awful lot of people just being like.

Well, I know the basics of accessibility. This is fine, I'm gonna commit it.

It's done. And then, that's when you find things showing up in core, and you're like, uh, what is this?

Rachel Cherry:
Yeah, excuse me?

Joe Dolson:
And so I think that this is something that in the whole process, is really improving.

Um, you know, there's just so much that it's not a perfect process, but I do feel like it's better than it used to be.

And that is actually one of the most encouraging things, is that gives us a path forward in that, like, if there were more people available to actually review these things and help contribute the process,

I think we could really do a lot.

Rachel Cherry:
Something that will be extremely relevant to our group.

is the shift. We're continuously talking about.

Or I'll say we're still talking about the shift from blocks, or shift to blocks from the old classic editor.

How do you feel that that shift has changed the accessibility landscape?

within and even, like, I guess within WordPress and within WordPress Core.

Joe Dolson:
So I think when we're talking about the content editor.

I'm not totally convinced it's had a really strong impact on accessibility overall.

I think it had the potential that hasn't really been followed through on, because there's a lot of stuff built into it.

That can do some things like contrast testing and looking at headings hierarchy.

But it's not very well exposed.

And it's not very thoroughly developed.

So it doesn't do a lot of the great things it could do.

I think we're at a point right now where we're moving in a direction where it can start to have more of an impact.

And that's because of this push that is currently ongoing to add more core blocks to fulfill a lot of these desired user interfaces.

There's a lot of resistance against adding things like an accordion block, or a tabs block, and things like that.

For a long time, but that is being shifted, and we're being like, no.

We should be able to provide these basic interfaces, and I'm very much in support of that, because.

Frankly, I have looked at an awful lot of accordion blocks.

And the vast majority of them are running that gamut from, oh my god, that's terrible, to, eh, I guess I can use it if I have to.

And being able to do something in core where we can actually be like, alright, we're going to put a lot of work and attention in trying to make this as accessible as possible.

And, you know, people can always still choose some other more opinionated thing,

but as long as there's an option available by default when you install, where you can do this and it's going to be accessible, I feel that's a vast improvement.

Because one of the problems we've had is, like, a lot of the older blocks, like, some of the more complex blocks that were added early on, you know, you look at something like the table block.

And it's terrible.

Like, it has horrible accessibility, and it doesn't support tons of features that you need in a table.

It's just not a very good block.

But these are being developed with a lot more attention to detail.

So I think there's a lot of potential there.

I'd like to see a lot of those, you know, authoring tool.

uh, assistance really improved. I'd love to have more feedback and have it better exposed.

Um, we'll see where that goes.

Rachel Cherry:
That's good to hear.

I think a lot of us, especially in these enterprise environments and accessibility professionals like myself and you, like.

We understand the importance of.

creating accessible shared patterns from, like, the foundation, and we, especially those of us who have been involved in, like, WordPress for a long time, understand the influence.

WordPress has in establishing these patterns.

So, for example, like, if the table block.

Is terrible, and everyone's using it, then that means, you know, this.

WordPress CMS that is so widely used across the internet.

Is repeating that inaccessible pattern.

people are using that as a starting point, copying and pasting and using it. Like, that influence is so high.

Joe Dolson:
Yep.

Rachel Cherry:
That what makes it so important to have these accessible patterns from the get-go.

Joe Dolson:
Right, exactly.

Rachel Cherry:
What is your sense of how accessibility is prioritized across release cycles in WordPress?

Joe Dolson:
I mean, you know, prioritization iss interesting. I mean, there is essentially no structural

Wow, the sun has just come out.

One moment, I'm gonna close the blinds.

Rachel Cherry:
Go for it.

Joe Dolson:
That was a lot.

It's now very dark, but I hope you'll live.

Rachel Cherry:
Our eyeballs appreciate it as well.

Joe Dolson:
Um, also, I don't want to sunburn out of this talk. I don't feel like that would be appropriate.

Rachel Cherry:
No, please.

Joe Dolson:
Um, so yeah, prioritization. Uh, so there aren't enough people doing accessibility, like, actively specializing in accessibility within core development to be able to, like, actively set priorities.

So, the priorities for WordPress are basically.

Uh, and I don't mean this in any arrogant way, this is simply practical.

That's whatever I say.

And that's because I am literally the only person right now.

Who's an active core committer, who's focusing on accessibility and is a specialist in the area.

That's not to say that there aren't lots of people who are contributing to accessibility, including core committers who are really paying attention to it and trying to make it as good as it can be.

But ultimately.

I have a limited amount of bandwidth. You know, I'm not a full-time contributor to WordPress. I have about, you know, I'm funded for 10 hours a week.

And so I look for as much as I can do, and try and just.

I do what I can do. Uh, but that's a real serious barrier

You know, my priorities are things that I have time to look at.

uh, things that I understand, which tends to mean that things like the site editor get left a little bit behind, because I look at that and I'm like.

I don't have time to figure that out.

Um, so yeah, it's a problem. We really need more accessibility specialists who are

Able to take that time to engage on these, and help.

shape priorities. You know, I hold a bug scrub every week in the accessibility Slack, in the accessibility channel, in the WordPress Slack.

If you have opinions, you're welcome to come. Uh, right now, once we are into this alpha stage, I mean, the release candidate stage, which will be starting.

Next week. Uh, that's when I start to do bug scripts that are focused on setting the priorities for the next release.

So, that is really when I start going through open tickets and trying to say, okay, this is something we're going to try and get done.

for 7.0.

So, I'd encourage people to stop by and voice an opinion.

Rachel Cherry:
I'm sure people here have opinions.

Contributing is complex.

Uh, it's, you know, it involves so many parameters between bandwidth and privilege.

Fiving your time for free is a privilege, or having the opportunity to give your time for free, and thankfully, you're funded.

Um, which allows your time to be paid, and that's wonderful.

And you're basically touching on one of the other questions, really, is, like, for our higher ed teams who do want to get back to WordPress, especially for accessibility.

you know, where is the best place?

And it feels like maybe joining the bug scrubs?

Um, getting involved in the Slack channel.

Joe Dolson:
Yeah, I mean, I think one of the things that

And this is something I do, and maybe this is not a great approach. I try and be on top of everything.

you don't have to know everything. Like, it is totally valuable for somebody to come in and be a one-issue person.

They're going to take this one ticket that they care about, and they're going to try and follow it through.

Uh, it requires patience, uh, because sometimes those problems can be pretty intractable.

Core committers are a lot like faculty in that they're going to nitpick and debate.

forever over certain types of changes.

There are some things that I feel take way too long to resolve.

For one example, uh, there's a a separator in the events dashboard widget.

between the different links and the footer of that widget, which is below color contrast. This doesn't really matter because it's decorative, but it raises a flag in Lighthouse tests, which means it causes a bunch of.

reports that show up in TRAC for people saying that this is an accessibility issue.

Uh, it's a false positive, really. It doesn't matter. But we've been debating how to solve that.

for weeks. And I'm just like I don't really care.

I only wanted to do this because it's extra labor to deal with false positives, but now it's become more labor to decide how to fix the problem.

Rachel Cherry:
I often have this, complaint in my role, it's like, we spent more time talking about it than it would have taken to just fix it, you know?

And I feel like everyone can relate to that.

Joe Dolson:
Yep. Yep, 100%.

Rachel Cherry:
I am smiling a lot because I, the other day, got an email about an issue that I created 11 years ago.

Joe Dolson:
Oh, that's probably my fault.

Rachel Cherry:
I don't think it was an accessibility issue. I honestly don't remember what it was, but I was like, what is this? And I was like, oh, okay, well

they came in and they basically closed it, but it was just the reality of, like, that's how it can be sometimes.

For anyone who's created issues in, like, WordPress track, like, it can take a long time. It really depends.

Joe Dolson:
Yeah. Well, WordPress.

Rachel Cherry:
It's like an intersection of, like, your issue and priorities, and who had the motivation to care.

Joe Dolson:
Mm-hmm. Well, and the fact is, WordPress track, I mean, so that's, first of all, there's only, like, half the collection of reports, because.

The Gutenberg GitHub issues also have a lot, but there are something like 5,000 open tickets.

on track. Uh, so, yeah, you know, there's so many that just get lost, because.

there's just so many. It's just a volume problem.

You know, I spend a fair amount of time, trying to look at older things and trying to

polish them off, and I'm sure one of the reasons yours was.

looked at was somebody decided, alright, I need to do an old bug scrub of this niche area.

And they're like, okay, I think this has already been taken care of, this is no longer an issue,

this is irrelevant, this is obsolete, whatever.

But yeah, it happens all the time.

And it should happen more, because frankly, it'd be a lot easier if we got.

More of those old issues closed out.

Rachel Cherry:
so in my role, I do a lot of project management.

Just yesterday, I spent an hour creating a document about task status, operational pipelines, and all these things, and so I'm curious

Do you feel like there's a shared understanding of how work is done in the WordPress project.

Joe Dolson:
I mean, I guess I would say yes, there's a shared understanding.

But it's also so incredibly complicated that.

Even the people who are really in the middle of it frequently have to ask questions and say, oh, wait, so how do we do this?

Um, there's a ton of documentation, it's not always up-to-date, because there's just a lot of it.

you know, I know that every time.

There's, like, a big package merge.

Uh, you know, that's a complicated process where some things need to be updated in CORE, and some things need to be updated in Gutenberg, and

you know, it can be difficult to remember all of the steps, even though they are pretty well documented, but then, you know, GitHub will change something in there.

Processes, and so now one of those docs is no longer quite the same as it used to be.

I think the processes are pretty well understood. It's just that they're also pretty flexible.

I mean, as a core committer, I am permitted to commit anything I want.

As long as the core code is open to commit at that time.

Uh, you know, there are rules during release candidate periods, where to commit to that branch, you need to get a second commit to sign off.

Um, but, like, during the whole alpha-beta phase.

If I want to make a change, I can do it.

That doesn't necessarily mean that's a good idea. And every committer is only given that privilege because they are trusted to not do.

Rachel Cherry:
Interesting.

Joe Dolson:
Terrible things.

Uh, and sometimes terrible things just means making rash decisions.

Rachel Cherry:
Yeah, the second that trust is gone, your privilege is gone.

Joe Dolson:
The thing about the alpha phase, though, is we, and this is always a balance for committers, is that you have to be willing to commit things that you're not totally sure of.

Because that's what the alpha phase is for.

That's where you find out, okay, this does cause problems in these areas.

we need to go back to the drawing board and figure that out. Like, there needs to be a really strong willingness to make mistakes, because sometimes you just can't imagine all of the test scenarios that are going to trigger these issues. Your mind isn't going to be that.

broad. Uh, so yeah, you just commit it and hope that people do enough testing so you can find these problems and revert it, and then.

Figure out how to solve it better.

Rachel Cherry:
Let's switch to WordPress Accessibility Day, because that was recent. That was, at this point, I think a few weeks ago.

And I'm curious, um, what were your key takeaways from this year's event.

I'm interested to hear your take on, like, common and recurring themes that you noticed across the sessions.

Joe Dolson:
Yeah, um, I think one of the biggest takeaways I had from the event.

And this is something that I think is just kind of

It's been increasing in the last couple of years is a lot of talks about the accessibility needs in areas of the world that have a lot of infrastructure challenges.

You know, we're talking about Africa, South America, places where, you know, the networks may be unreliable, where people are much more dependent on a cell phone, you know, have a desktop computer.

And how much of an impact those performance and bandwidth and mobile support issues have on accessibility.

And that is definitely a really important concern. It's definitely one of those things that, like.

Some of the things, like the site editor, it can be really heavy.

Uh, you know, if you're adding all sorts of these huge images, hero images, and whatnot that it really encourages, although those can be problematic.

But, I mean, like, the WordPress performance team has been doing a really good job of trying to keep that under control and.

And do things in the best possible practices way.

But it's just been interesting seeing how much.

People with accessibility needs.

are talking about that as a priority.

The other common thread, uh, and this has been true for years, and it just keeps increasing and keeps shifting.

is about automation and AI.

You know, last year and the year before that, I would have said it was all about overlays, uh, and then overlays kind of have shifted.

the concerns about overlays have sort of shifted to be a big concern about AI and what impact that has.

Now that you can do things like just tell some automation to build this site for me.

Uh, what does that actually mean?

And what is the outcome going to be like?

And do people know what they're doing well enough to be able to use it and create a good product? And that was definitely a big thread throughout a lot of different talks.

Because it's concerning. I certainly have personally reviewed at least one website that was built entirely using AI.

Where the person building it was explicitly telling the AI to build it excessively.

And it was interesting.

Was it accessible? Nope.

But it made a very interesting set of accessibility errors, which are exactly what I would expect, honestly, because they're the same errors.

Rachel Cherry:
I'm shocked.

Joe Dolson:
That you see developers make when they don't really understand accessibility.

And that's my concern. It's like, when the AI is trained on our existing.

ecosystem of code.

Then it's going to make the mistakes all of the ecosystem of code makes.

And, uh, you know, the accessibility of websites globally is.

basically terrible.

So, to expect that AI is going to be able to look at that data and be like, oh, I can do this, no problem.

Uh, yeah, that's what it's going to think, because it's sycophantic, but it's not going to actually succeed at solving that problem.

Rachel Cherry:
Agreed, it seemed the concern, see, is that it's just amplifying the existing problem that we have with our ecosystem.

One of the reasons why a large percentage of the internet.

Or the web is inaccessible is, you know, because of our systems, including.

A lack of, uh, good training and education.

Lack of enforcement of standards.

Um, lack of certification processes?

Joe Dolson:
Yeah, and this comes right back to what we were talking about, WordPress needing to provide.

base-level templates and blocks that are accessible. It's because that's what's going to get reduplicated.

You know, that's what people are copying from.

Rachel Cherry: Yep.

Joe Dolson:
You know, I hope nobody has ever made copies of 2019.

Because that theme, the accessibility of the menu in that theme is absolutely atrocious.

Rachel Cherry:
Noticed anyone here using a copy of that theme.

Uh, but yeah, one of the reasons why people create inaccessible digital experiences is because they don't really know what they're doing.

They haven't had proper training.

They've kind of taught themselves to various degrees by copying things and learning things off the internet, and then if they don't.

Joe Dolson:
Yeah.

Rachel Cherry:
They don't truly understand how the web operates and how these systems work together.

If they don't understand how browsers and user agents work, if they don't understand how people use browsers and user agents.

Whether they inadvertently create inaccessible experiences, and they don't understand why.

And so, yeah, and so AI is basically just participating in that in a different way.

Joe Dolson:
Yeah, it is. It's just another aspect of ways that you can do things without actually having to learn how they work.

And if you don't learn how it works, then you're not going to achieve a good outcome.

Rachel Cherry:
And I want to circle back to the first theme you talked about.

About the topic of, basically, of how performance can affect accessibility.

And I think that that's so important to highlight how when we talk about creating accessible experiences,

we really talk about creating high-quality experiences, and that are, um, that use semantic data, that have accessible user interfaces, but are also performant.

And how, when you are focused on creating the most.

Rachel Cherry:
The highest quality experience.

You are creating more accessible experiences.

And that can turn into things like.

Like, screen readers and using assistive devices, but also.

Uh, speed testing and performance loading and wrapping that into how people use the web.

And how our work and what we do.

Can have an impact on how people access information.

Rachel Cherry:
And it all comes together.

Joe Dolson:
Yeah, it absolutely does.

Rachel Cherry:
How do you feel events like Accessibility Day shape the broader WordPress roadmap or its priorities?

Joe Dolson:
So I feel it's more gone the other direction so far. It's more that what we do at Accessibility Day, the speakers are kind of reacting to what's going on in the ecosystem.

I'd like to see it actually be a little bit more of a driver.

But so far, my general sense is that the talks are reactive. They're saying, alright, we have this block editor, what can it do?

What are the problems? Okay, we have the site editor, we can build block themes, what does that mean?

They're less about saying what needs to change, what direction can we go? I have not seen a lot of talks that are really saying things like.

can we do more, say, to improve how WordPress interacts with the authoring tool accessibility guidelines?

That's a personal concern, like, that's the thing I care about passionately, but I haven't seen talks trying to really drive that forward.

I would love to see that. I'd love to see more talks come in that are actually probing WordPress and saying.

Here are things that WordPress does not do well and needs to do better at.

Because I do think that there is room to really push that forward by exposing some of the limitations, some things that just need to be better. And without.

Without just being naysaying. You know, it's easy to just say, oh my god, the site editor, it's crap, it's horrible, everything's terrible.

But that's not something anybody can really work with.

And I will tell you, from doing an awful lot of bug scrubbing and issue scrubbing

on the WordPress stuff, there are actually a lot of tickets that are literally raised saying.

Feature X is not accessible.

And that is the entirety of the information they've provided.

And, you know, that's not a good bug.

Because it's it's just too broad. You're like, okay.

It's not accessible to whom? It's not accessible in what way? What is the context?

give me any information at all, because otherwise what you're doing is you're creating work for me, because I have to be like, okay.

Now, am I going to go through this particular feature, fully audit every part of it to try and figure out what you're talking about?

And then create the, say, perhaps 30 separate tickets that that really should be.

And so, I tend to look at those ones, and like

I can't do that. I don't have time.

Rachel Cherry:
No. Everyone here on this call that does customer service and their role is feeling that so much.

Joe Dolson:
Feeling heard, yeah.

Rachel Cherry:
Yeah, feeling heard. Um, yes, I'm gonna need more information.

It was really fun earlier this year to run into you at an accessibility conference.

Joe Dolson:
Yeah, that was fun.

Rachel Cherry:
We attended CSUN in Anaheim, and I'm relating to what you're talking about, about kind of wanting different kinds of talks, and

What I'm about to say is not about Accessibility Day, but more about accessibility events in general, where I feel like it's

Kind of repetitive, and it's a lot of the same types of talks over and over again.

And there's good and bad with that, because a lot of the repetitive talks are very, like, what is accessibility and why it's important?

And as someone who's an accessibility professional specialist who's been doing this for a long time, it's like, I, you know, I need something else.

You know, like, I want to talk about why it's a problem, and how we can fix it.

Like, I want to get in the weeds. Like, how can we fix the systems that are causing these problems?

Joe Dolson:
Right.

That's actually been a really interesting challenge with WordPress Accessibility Day.

We've been workshopping and workshopping the information we give to prospective speakers and how we ask for talks, because what we keep trying to.

Make clear to people is, we do not want you to give an introduction to accessibility.

Like, please don't do that, because this is 24 consecutive accessibility talks, and if everybody does that.

Then, you know, the first 20 minutes of every talk is the same.

It's a challenge, because as you say, like, there is a purpose to giving those. There are always new people coming to accessibility, and they do need those basics.

Um, so we haven't quite managed to figure that out.

Um, it's hard. You want people to really talk about a focused topic, and when they start by just.

Kind of giving a summary of all accessibility, then they only have 15 minutes left for their actual topic, and that's frustrating.

Rachel Cherry:
Yeah.

Joe Dolson:
But I think accessibility speakers are accustomed.

To having to give a baseline before they get into the meat of their talk.

Because, I mean, I certainly have to, speaking for myself.

the vast majority of talks I have ever given.

Have been in front of audiences.

Who didn't already know accessibility.

I mean, that's just the reality.

Rachel Cherry:
And I think that what we would love.

In our roles is to have the baseline shift up.

So we don't have to continuously tell people what is accessibility and why it's important.

We can move on to how we're going to make it better.

Joe Dolson:
Right.

Rachel Cherry:
And, yeah, it's hard.

Joe Dolson:
Yeah, 100%.

Rachel Cherry:
So we have about 10 minutes left.

Let's kind of dive into more of a higher ed focus.

What do you see as the most common barriers to maintaining accessibility at scale, especially in, like, WordPress? I'm sorry, WordPress in higher ed sites?

Joe Dolson:
The biggest barrier I've seen, like, in the things that I've actually looked at, is more structural.

In how the organizations operate than it is the actual websites.

It's essentially the organizational units, whether it's a department or a school or whatever.

Who've gone outside of the institution rules and, you know, standards to fet somebody to build them a custom website.

And inevitably, whenever I've done stuff for higher ed.

Uh, you know, do you see those? And you're like, okay, you've got a baseline of accessibility across most of your campus.

And then this school is completely crap.

And it's because they went outside of the box.

And I think, you know, lots of people here are in higher ed, and they know that, like, this is because that school has a separate budget from some endowed fund, and so they're able to go and break the rules, and this organization does this.

And those things create these problems.

And they actually detract from the ability of the centralized standards to actually

Really be impactful, because it's that much harder to get that thing across the board.

I mean, when you talk about the actual technical problems, honestly.

A lot of organizations, if you're able to impose standardized templates and requirements, and you have your common headers.

You can control for a huge percentage of the actual issues. It's just when people are allowed to go outside the box that

problems happened. And I don't have a solution to that, and I'm sure there are tons of people here in higher ed who also don't have a solution to that other than.

Follow the rules.

Rachel Cherry:
Well, interestingly enough.

When we're done, I'm going to talk about that, and to talk about how to solve for this problem, especially in a higher ed environment.

So you hit everything on the nose. In enterprise environments, accessibility governance usually isn't about technical.

It's usually about people and processes, that they need improvement.

Alright, so let's look ahead, with our time left.

What is your hope for accessibility in WordPress over the next few years?

Joe Dolson:
I mean, what I really hope for is more accessibility specialists actively contributing, because that is the biggest gap right now in terms of really being able to move things forward.

There's simply no way that I, by myself can even look at everything.

And I think that the direction is generally positive right now.

It's just a lot of work, and in order for things to move forward rapidly.

It's a big challenge.

And I know that Matt wants the 7.0 release to be a really big deal.

For whatever reason.

And that is going to mean that accessibility is going to get swamped.

Because I don't know what's going to happen. Is it going to be that they're finally going to actually launch this redesign of the admin?

In which case I'm terrified, and that's going to be a nightmare? Uh, I don't know.

But there need to be more people. In terms of the actual improvements and what can actually change.

Uh, I'd really like to see us lean in.

There's the direction that they're taking with adding more blocks and getting those to have a nice, accessible base of core blocks, I think is great.

I'd like to really move focus into more of the authoring tool accessibility guidance.

And be able to provide content authors with in-editor feedback about the things that are happening, and make that much more strong.

You know, I don't think that, at least at a basic level, that belongs in plugins.

Uh, you know, plugins are always going to be able to do more, they're going to be stronger, they can deal with things that are outside of core.

But, like, core should be able to analyze itself, the things that it is creating.

And I'd love to see better feedback on color contrast. I know there's a forms block that's in development.

That is an opportunity to do something that could be really accessible. It's also an opportunity to make horrible, horrible mistakes.

So, like, that's going to need a lot of work and a lot of attention.

So, I would love to see these things be able to progress.

efficiently and be really, truly accessible. But that's going to require people.

It needs people actively doing that. And I do want to say that a lot of the developers who are working on.

Building these core features are dedicated, they do care.

But if you're not a specialist, and you're building what are fundamentally extremely complicated applications, it's really easy to make mistakes.

I mean, I am a specialist. It's still easy to make mistakes. I mean, the fact is, these really complex things, you kind of, like.

Did I actually cover all cases? Did I test everything?

You know, one of the features that's coming in 6.9 is block notes.

It's a feature to be able to comment on what's happening in a given block, so basically it's just editorial comments on a block.

And that's been a very complicated feature to really get right, because it's that interaction between.

You've got a comment that it's related to this block, how do you know which block it's related to?

How do you get back and forth between the two areas? How do you sequence the replies to that comment, and how that thread of conversation has gone?

Um, that's been complicated.

I think it'll be pretty accessible. Will it be perfect? Probably not.

Rachel Cherry:
Wow.

Joe Dolson:
But at least it's going to be a pretty good starting base flap.

Uh, that feature sounds interesting. I dig it from a governance perspective.

So our final question. If you could rally the higher ed community around one accessibility goal.

What would it be?

Joe Dolson:
Well, I mean, I think I've actually already talked about it.

It's really, I think, the thing that most benefits higher ed, because higher ed has this kind of relatively unique scenario of

vast numbers of content creators, and huge challenges in providing training.

Is those authoring tool guidelines, that guidance, and having this accessibility testing and feedback in place during the editing process.

I think that because the biggest gap there is really the content creation process.

And making sure that when people are creating new content, that it's accessible.

When you're working with small numbers of people, like the developers who are actually, like, building out the sites.

They can create bigger problems, but it's such a smaller pool of people to train and correct.

That it's much less of a logistical problem.

But if you've got, you know, 2,000 content creators.

You need systems that can actually give them feedback immediately and much more directly.

Rachel Cherry:
Well, it's great that you say that, because at the end of our agenda today is a panel discussion with.

Folks that are creators of integrated accessibility testing plugins.

And these are the types of tools that teams can use to test content before it gets published, and provide that feedback, and kind of that education loop with content creators.

Joe Dolson:
Yep. It's a really important loop.

Rachel Cherry:
I agree.

Alright, well, thank you, Joe. It was really good to see you, and I hope you, uh, have a good rest of your conference and time in California.

Joe Dolson:
Thank you.

Yeah, well, I would love to be able to stay and hang out for some of the rest of this event, except what I have to do next is head to the airport.

Rachel Cherry:
Oh, yes. Well, safe travels, and we'll see you on the internet.

Joe Dolson:
Yes, thank you so much.

Rachel Cherry:
Bye.

Joe Dolson:
Bye-bye.