About the Topic
Thanks to Our Sponsors
WP Engine, a WordPress technology company, sponsored the live captions for this event. They provide the most relied upon and trusted brands and developer-centric WordPress products for companies and agencies of all sizes, including managed WordPress hosting, enterprise WordPress, headless WordPress, Flywheel, Local, and Genesis. WP Engine’s tech innovation and award-winning WordPress experts help to power more than 1.5 million sites across 150 countries.
About the Meetup
Learn more about WordPress Accessibility Meetup
Watch the Recording
If you missed the meetup or would like a recap, watch the video below or read the transcript. If you have questions about what was covered in this meetup please tweet us @EqualizeDigital on Twitter or join our Facebook group for WordPress Accessibility.
Links Mentioned in This Video
The following resources were discussed or shared in the chat at this Meetup:
- WordPress Accessibility Facebook Group
- Equalize Digital Web Accessibility Resources
- Equalize Digital Focus State Newsletter
- Equalize Digital Website
- Equalize Digital on Twitter
- WP Engine Website
- Follow WP Engine on Twitter
- Empire Captions Solutions Website
- Follow Empire Captions on Twitter
- Joe Dolson’s Presentation Slides
- Make WordPress Core Trac
- Accessibility WordPress Trac
- Section 508 Trusted Tester Conformance Test Process Version 5
- PHP Coding Standards
- Joe Dolson’s Website
- Find Joe Dolson on Twitter
Article continued below.
Stay on top of web accessibility news and best practices.
Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.
Read the Transcript
>> AMBER HINDS: Yes. Well, it is 7:06. I am going to officially get started with a few announcements. I figured this out, last time I forgot to. I’m going to spotlight myself, just to make sure that I stay up for the recording. Then, we’ll add Joe back in just a little bit. Quick announcements, if this is the first time you’ve been here, we have a Facebook group. If you are on Facebook, and you want to connect between meetups, you can find that just if you go search WordPress Accessibility on Facebook. It’s a good way to ask questions or get help, get information, share information. If you have questions, if you’re an expert, please join us as well because there are definitely people who can benefit from your knowledge.
Then, if you want to find more information about upcoming events, or if you want to see recordings from past videos, you can find those. If you go to our website equalizedigital.com/meetup. This is being recorded, we do release recordings. It can take us a week or two because we edit the video, and then we get corrected captions and a transcript. They’re not always up immediately, but people always ask us, “Is this being recorded? Where can I get the recording?” That’s where, so watch that page.
You can also subscribe to our email list if you go to equalizedigital.com/focus-state. Also, if I manage to make the webinar work correctly, you might get bounced to a thank you page [chuckles] on our website at the end of this, which has a sign up there, too. That’s a good way to get notifications about upcoming events and information or links when the video recordings are available. We send about twice a month, sometimes less.
If another thing to be aware of is, we do have captions today, so you may need to turn them on. Those captions are covered by our sponsors, who we greatly appreciate. We are seeking more sponsors for the meetup to help with future events and captioning them. Please reach out to us if you or your company are interested in sponsoring. If you have any suggestions for the meetup, or you need any accommodations or any ways that we can improve it, or if you would be interested in speaking, we are looking for some speakers for late summer and early fall still. You can reach myself and Paula, the other organizer if you email meetup@equalizedigital.com.
I haven’t really introduced myself. If you’re new here, I’m Amber. I’m the CEO of Equalize Digital. We’re a Certified B Corp that specializes in WordPress accessibility. It’s passion for us. We have a plugin called Accessibility Checker, which scans for some accessibility problems, some of the ones that can be detected automatically. You can’t detect every problem automatically, but the goal of the plugin is really to help people find problems and make their content more accessible before they publish it to the web. There’s a free version of it on wordpress.org, or you can learn more about it on our website equalizedigital.com.
We have two sponsors tonight. The first one is WP Engine. WP Engine is paying for the cost of our live captioner, which we very much appreciate. WP Engine is a technology company. They have two hosting brands, WP Engine and Flywheel. They also own the Genesis Framework and Local by Flywheel, and more recently, purchased a lot of the delicious brains plugins, if you follow WordPress news. They have been a great supporter of our meetup. I believe they’re also going to sponsor the WordPress Accessibility Day Conference.
We really appreciate that they help to cover the cost of captioning. We always encourage people to thank our sponsors. If you have a minute, and you are on Twitter, and you’re willing to tweet them @wpengine and just thank them for sponsoring, that will help to encourage them to want to sponsor more in the future. If you want to learn more about WP Engine, you can do so at wpengine.com.
Our second sponsor tonight is Empire Caption Solutions. They very generously have offered to donate their services. They take our recordings of the meetups and correct the captions for us to ensure that we can post them with a full transcript and correct captions after the fact, which if you’ve ever tried to do this for an hour plus long meeting, is no easy feat, especially if you’re not super experienced at it like me or some of the people on our team who have tried to do it. It would take us a long time. It’s been really great that they have donated their services.
Then, occasionally, we’ve hired them also. They always do a great job. They work with us to make sure that they’re captioning in the style that we want. In addition to that and providing transcripts, they do audio description and ASL interpretation for recorded videos. You can learn more about them at empirecaptions.com. If you want to tweet them a thank you, They are @EmpireCaption.
We have two upcoming events and then a Save The Date that I want to remind you of. The first upcoming event is Dacey Nolan and Alex Zlatkus, will be doing a twofer presentation. Initially, Dacey will talk about her experience as a person with epilepsy and how that has experienced, how she uses the web and some problems that people with epilepsy can encounter on the web. It’s going to be a short in the beginning presentation. Then, the two of them, Dacey and Alex, will be presenting on building accessible design systems. If you’re interested in that or trying to figure out how to create that either for your own organization or for clients, it’ll be a great meetup to attend. That will be on Thursday, July 7th at 10:00 AM Central Time.
The next meetup in this same time slot is going to be Meg Miller. She’ll be talking about alt text and when and how to write alternative text. This is something that a lot of people have asked us about during meetups. We occasionally touch on it during certain speakers. People always ask, “Can we go deeper into this topic?” We’re really excited that Meg offered to do that. That will be on Monday, July 18th at 7:00 PM Central Times with this same time slot.
Then, the Save The Date that we’re mentioning again is WordPress Accessibility Day, which Joe, our speaker today, is the other lead organizer of WordPress Accessibility Day. It’s a 24-hour conference. It’ll be totally free, all about accessibility. You can learn more about it at wpaccessibility.day. Early in the organizing process, we’re taking sponsors right now and volunteers. We will be opening the speaker application process in about a month or so, I think in a few weeks. That will be coming soon. Please save the date for Wednesday, November 2nd at 10:00 AM Central Time is when it’s going to start. It’s going to run for a full 24-hour period. Even if you’re not here in the US, there will be talks that are in your time zone, either on that Wednesday or Thursday. However, that works depending on where people are located in the world. Please save the date there.
I am very excited to announce or introduce our speaker today, Joe Dolson. Joe is a WordPress core committer. He’s a plugin developer and web accessibility consultant. He has been covering topics on website accessibility since 2004. His company is called Accessible Web Design. He is a lead in core accessibility. He has previously spoken for us about his plug-in WP accessibility, which is really helpful in solving some of the problems that exist on WordPress websites. We’re really excited to have him here talking more about how we can all get involved with accessibility. I’m going to stop sharing my screen and pull him up here and let him take over. We’re excited to have you, Joe.
[pause ]
>> JOE DOLSON: Am I live yet?
>> AMBER: I think you’re live.
[laughter]
>> JOE: All right. Hard to tell. Well, I guess I’m to just go ahead and get started by sharing my screen. Okay.
[pause ]
What is sharing right now?
>> AMBER: We can see your slides and your face a little bit to the side.
>> JOE: All right. Great, but it’s not sharing my speaker notes?
>> AMBER: No speaker notes.
>> JOE: Great.
>> AMBER: We see your tabs in your browser. I don’t know if you care about that.
>> JOE: I don’t care.
>> AMBER: That’s a GitHub.
>> JOE: That’s a shocker. Anyway, here I am. I’m going to talk about the whole process of contributing to WordPress accessibility. As I was putting these slides together, I definitely came to realize that this was a somewhat enormous topic. I will happily take questions throughout the process as they come up, if there’s something that will help elucidate what I’m talking about for the rest of the talk. I’m also going to be focusing largely on the areas that I contribute to myself. Because going outside of that, just got to be a really incredibly complicated talk.
That doesn’t mean I’m not happy to answer questions about some of those other things. I know a lot about what goes on in contributing to some of the other areas, but in order to narrow this down, here we go. I was of course introduced. I am Joe Dolson. He/him, all of my various information. There is a link there for the slides, if you want to follow on somewhere else, or if you want to review them later, enjoy that. They are Google slides and they are very simple and very basic.
The first thing to talk about when it comes to contributing to WordPress, in general, is to understand the core release cycle. Wordpress basically releases about three times a year. In any given year, there will usually be three releases. Every once in a while, there’s four if something’s exceptionally complicated, for example, when they released WordPress 5.0, it was the first inclusion of Gutenberg that ran late and there may have only been two releases that year, but the overall shape of it is that you’re going to have about three releases. Those releases have three phases. During the Alpha phase, you’re always going to be focusing on new features, enhancing things that exist in WordPress, major changes and bug fixes from prior releases. That’s where all of the major change tends to happen. It’s an important period to have already planned for.
This is one of those things that if you haven’t already figured out what you might want to do during the Alpha phase, it may already be too late to get it done. If there’s something complicated, that’s a big deal. Then we move into the Beta phase. Once everything is stable, once all the features that we believe we can get done are actually in place, we’re going to go into Beta. Once you’re in Beta, bug fixes are restricted to only things that directly apply to changes that were made during this cycle. At this point, if you haven’t fixed a bug that has existed since WordPress 3.2, that’s too bad.
You’re going to have to wait. That’s one of those things that needs to happen during the Alpha phase. The reason for that is that a lot of those changes might be things that are going to have a significant consequence to plugin developers or theme developers who maybe have been depending on something working in a particular way, even if it was actually broken.
Once that’s all through, we’re into the Release Candidate. The Release Candidate phase is very tightly controlled. We really don’t want the code base to change very much during Release Candidate because that defeats the purpose of having a release candidate. If it’s radically different from one release to another, that’s going to really confuse matters and cause people to have some difficulties in properly testing what you’ve done. For accessibility, that frequently means we do a lot of planning during that Release Candidate phase.
That’s when we’re going to be really thinking about what we’ll actually do during the Alpha phase of the next release, because hopefully, by Release Candidate, there aren’t a lot of major accessibility bug fixes to be worked on. That doesn’t mean there aren’t any and it certainly doesn’t mean we’re not going to pay attention to them and look for them, because they do still need to be worked on and fixed. The major focus during Release Candidate is planning. During Alpha, we’ll implement those changes. Then there’s a lot of testing and bug fixing during the Beta release.
Gutenberg, of course, this may surprise. Absolutely, nobody follows a completely different release cycle. It’s integrated with the WordPress course cycle, but it is not the same cycle. Gutenberg releases a new version every two weeks. At some point along those lines, they’ll have a plan for what features they want to incorporate in the next WordPress release. They usually have a planning board in GitHub to track what features they’re trying to get done. The editor team will ultimately set a goal for a particular version of Gutenberg, that they are going to consider the version that goes into the next WordPress release.
That’ll generally be settled sometime during the Beta phase. It’ll have probably been decided which version it’s going to be well ahead of it, but that will actually be locked during the Beta phase. However, that doesn’t mean that that version of Gutenberg is absolutely a perfect match for what lands in WordPress, because if they affix bugs further on in a later Gutenberg release, those can get back exported into WordPress. As a result, no version of WordPress using the block editor, actually matches perfectly any version of the Gutenberg plugin, which is one of the reasons why, if you’re actually doing testing on Gutenberg, you need to be working in the plugin.
If you’re doing testing on WordPress core, you need to have the plugin disabled and be working directly with what’s actually in core, because they are not going to match. They are not the same software. I think that’s one of those facts that’s perhaps a little bit less known about the way the Gutenberg process works. An extremely critical thing about all of this when we’re getting into that Release Candidate cycle is that, accessibility issues are always considered bugs. That is not necessarily an absolute guarantee. They’re not necessarily always considered blocking issues. It’s going to depend on the scope of the issue and how much work it would be to fix it if it’s been introduced recently. They are absolutely something that is considered bugs. They can be fixed throughout the Release Candidate period.
In case missed it, accessibility issues are bugs. I just want to emphasize that with three additional bullet points elaborating the fact that accessibility issues are bugs, because it’s really, really crucial. Every software project should consider this as one of their basic tenets of development. WordPress tries very hard to do that. I think the biggest problem we run into with WordPress is actually the scope of the software and the lack of having enough people contributing to accessibility and testing for accessibility to necessarily catch things early enough for them to be fixed. But the intent is certainly there. I’m hoping from this talk, people might learn things that help them contribute and help spot those bugs while it’s still time. It really matters. Yes.
>> AMBER: I don’t think your slides that we’re seeing are changing. I just realized I looked at your slides.
>> JOE: Really?
>> AMBER: Yes. I’m still seeing what’s the WordPress release cycle as the slide.
>> JOE: Oh, that’s interesting. Have they changed now?
>> AMBER: Yes. Why does it matter? I see that-
>> AMBER: Now, that’s interesting. I had my speaker notes full screen and apparently, that was overriding the browser, the actual presentation version. That’s a bug in Google slides, I’m going to say, because that’s dumb. That definitely should not be what’s happening. All right, I will live without my speaker notes because it’s more important that you actually see the right slides. I don’t know that there was anything super crucial to see in the past slides. Anybody who wants to can look at these slides later. If you’re watching this talk sometime after the fact, I highly recommend you download the slides and take a look at them. I guess I’ll move on right now. The key thing about the fact that accessibility issues are considered to be bug is the fact that they can be fixed during Beta. They can still be fixed during Release Candidate and that extends our time available for doing all of the crucial testing of accessibility issues. Testing for accessibility issues can happen at any time during the cycle. What you focus on really is what has to change through each period of development. The key thing is knowing that during that release candidate cycle, during that Beta cycle, it’s really important to focus on testing things that are actually new. That will involve following the developer reports coming out of the make.wordpress.org/core and information they share.
What exactly does the accessibility team do? First of all, let’s talk about WordPress teams. WordPress is divided loosely into about 20 teams of developing bodies. I’m using the word develop, but this is not all developers. There are all sorts of teams dedicated to translations, dedicated to creating documentation, to educational resources. It’s all about just organizing the developers into interest areas and what they do. Those teams, each take responsibility for the oversight of the area that’s defined by their name. The accessibility team is choosing to take responsibility for oversight on the accessibility of WordPress.
From a practical standpoint, the majority of work done is going to cross between multiple teams. If, for example, there’s a major change being made to the media library model, well, it may be an accessibility issue, but it definitely is going to have to involve the media team because they are a key element of working through how that actually functions, what it needs to do, and they best know what kinds of compatibility issues we’re likely to come up with. It’s always going to be a matter of collaborating with multiple teams.
One of the things that means is that while the accessibility team is taking the responsibility for this huge amount of information, all of the WordPress admin interfaces being on top of whether the core themes are being released and developed in an accessible manner, wordpress.org itself, they’re sharing that with a lot of other people. Sometimes that means actually getting things done is not so much about doing them as it is about being aware of them and knowing more or less who to report them to. That’s the hard part. Figuring out who to report them to is absolutely the tricky thing, but you can almost always take an educated guess as to which slack channel to put it into and somebody will probably come along and help guide you to somebody who can actually get there and make something happen.
Here’s the meet. How you can actually help the WordPress team make things more accessible. This is, of course, one of those really big broad areas. I tend to divide things primarily into four areas, organizational, documentation, testing, and then of course development. I think what people mostly think of as contributing to an open source software project is the development part. It’s creating patches. It’s actually changing code that is going to directly go into the system. All of those other aspects are crucially important as well.
Organizationally, there’s a lot that can go in, and all of these things can be a small amount of commitment, things like running meetings and taking minutes. If somebody can just attend a meeting just for the sake of keeping it on track and documenting them, taking minutes from what actually happens in that meeting, that is incredibly useful because it means that somebody who maybe would rather go off and write some code, has time to do that.
It can also mean huge time commitments like being the core release lead for the accessibility focus. That’s a task I’ve never taken on, because frankly, I just don’t have that kind of time. That’s a big commitment because you really then have to be personally taking the job of monitoring everything that’s changing in a release to make sure everything’s being considered. The last few releases have not had an accessibility release lead because nobody has had the availability to step in and do that, but it is definitely something that’s useful.
Even just helping to set goals, coming to a meeting with an idea of, “Here’s an issue that I think we really need to tackle,” and raising it can be incredibly valuable. There’s a lot that goes into organizing. I think it’s something that if people really want to just help make things happen, it can feel overwhelming to step into simply because there’s a lot of stuff already going on. It’s not like you can just step in and immediately say, “All right, I’m going to organize this now.” Like, “Well, it’s already running, it’s already happening. You need to find a way to actually keep track of something and make it easier to organize.” That might mean getting access to make.wordpress.org/accessibility, to just update things, write posts about what’s going on. People are pretty willing to give access to those sorts of things once you’ve at least got some basic level of trust built up in the community.
When you’re getting started with organizing, it doesn’t even necessarily mean that you’re coming to the WordPress accessibility team meetings. You may not be able to do that because of scheduling. I did note that we have at least one person from Australia and one person from New Zealand at this event. That is just an ongoing challenge of setting meetings that can meet the needs of both people in the central areas of the United States and the time zones that are really quite remote in New Zealand and Australia.
You don’t have to attend the accessibility team meeting if you can attend any meeting and be the person who’s thinking about accessibility in that meeting and raising questions about, have we considered accessibility on this particular topic or that particular topic? And then perhaps make a report back to the accessibility team. Every team, in general, publishes an agenda for the most part prior to their meetings. You can always make a comment on that agenda with an issue you would like to have raised, even if you can’t actually be present.
I think it’s important that the asynchronous nature of development and contribution to WordPress does mean that we are really built around the idea that you might not be there in-person at any given time. Meetings are scheduled around the idea that the people who are trying to organize the meeting can be there at that time and they’re hoping to get feedback and information from all sorts of places outside of that.
Documentation is another really big area. The WordPress accessibility team tries at some level to maintain some documentation on basic standards of what we expect developers to take into consideration and their development for core. The simplest summary is that officially, we do require WCAG 2.0 at level AA, but having more detailed documentation on that can sometimes be helpful.
Also at some level, we like to have things be internally consistent. While there may be more than one interpretation that can meet the standards of WCAG at level 2.0 AA, for the purposes of consistency within WordPress, we might always want it to be done the same way. Because, in general, self-consistency within software is going to make things easier to use because it’s more predictable.
Doing things like going through docs throughout wordpress.org to identify accessibility issues, identify tutorials that are perhaps suggesting that you create a form, but they don’t include a label with the input, there’s all sorts of documents along those lines throughout the internet. We’re hoping to try and minimize or remove any of those within wordpress.org as best we can, but that’s a lot of time. A lot of that is just searching out reading documents and trying to figure out what’s there, because it is, as I said, a little bit enormous. There are a couple of channels for dealing with docs. There’s the accessibility docs channel, which is focused specifically on documenting accessibility. It’s usually fairly quiet because there’s not that many people contributing to it. Then there’s the central docs channel, which has a weekly chat at UTC 14:00 every Tuesday. That’s where you want to be if you want to start contributing to the docs across the entirety of WordPress. That’s where the editors for most handbooks are going to be showing up periodically and where you can get in touch with people to try and find out how you would make a change to the plugin handbook or various contexts like that.
Testing. Those are really long links and you do not need to copy them down. Those are essentially custom queries done within the WordPress track that are almost identical to each other, but are very key, different things. This is basically for finding topics that meet one or two criteria. First, if you’re testing bugs, you’re looking for anything that is not yet patched. The reason you’re doing this is you’re trying to confirm whether that bug is still present. There are over 50,000 track tickets in the system.
I don’t even know how many are currently open, but it is somewhere in the thousands. It’s a very real problem that some of those tickets are actually already fixed, but there was a duplicate that didn’t get caught or it was fixed as part of some other project and didn’t get noticed here. It is always worthwhile to actually look at it and verify that it’s still really a problem. That’s a service that can definitely be performed. That’s just a matter of finding those issues, trying to understand them. They’re not always easy to understand, and then make a comment that indicates what you learned from your testing experience.
Then there’s testing patches. These are things that somebody has attempted to fix, and we need to verify whether the patch actually does fix the problem. Sometimes it fixes the problem but creates a new one. All of these need a lot of work to make sure everything is being handled in an appropriate manner.
New issues is when you’ve found something and it doesn’t appear to be something that’s already recorded. That’s the hardest one, because the first thing you have to do is do some very complicated searching to figure out whether or not somebody has reported it before. This is one of those places where the details of how somebody wrote this down or how they described the characteristics of what they’re reporting, might just mean you don’t find it. That’s okay. There are lots of bug diagnose looking at these and if they do know that it’s a duplicate, they’ll just mark it as a duplicate and no hard feelings. Trust me, it’s happened to all of us.
In general, if you’re observing a problem that doesn’t have anything to do with the block editor or full site editing, that should be reported on track. If it is the block editor or full site editing, try and report it on GitHub. If it gets reported in the wrong place, somebody will eventually migrate it, but it is just an extra step. It slows things down, which is fine. Even if you do find an issue, if you find something and it is a duplicate that what you found has already been reported, it’s great to make a comment on that issue in either system. Make a comment either to indicate that there’s something slightly different you’ve found about this problem, maybe it doesn’t, it isn’t quite the same as it was originally reported, or if you have some more detail, make a comment to indicate if it didn’t appear to be there anymore.
It’s all about just making sure that people are aware that yes, people are paying attention to this. It’s actually something people are concerned about. When I run across an issue that was raised six years ago and has had no comments since the original reporter and somebody asking for more details, then it’s really hard to consider that a strong motivator to look at it any further, because if nobody else has reported in six years, it’s clearly not a very common problem, and it’s not going to be the top priority.
When you’re reporting your test results, this is one of those areas where being as detailed as possible is incredibly valuable. If you can indicate the exact steps you took to produce the issue, that might even mean upload– if it’s a file upload issue, that might mean actually providing the file that you used to recreate the issue, because it could be something very specific about a missing piece of metadata in the file that needs to be tracked down. Getting all of those details in place is really valuable.
Also good to have the steps to confirm if something’s fixed, when you’re adding a patch, we want to know the devices, the browser, any assistive technology in use, and the version numbers. Finally, if you can’t even reproduce the issue, let us know that. Knowing that you couldn’t reproduce it is also extremely useful information. It’s easy to get the idea that if you haven’t been able to actually get any information from testing it, you tested and tested, but you just couldn’t reproduce the issue and you’re like, “Oh, I can’t provide anything useful from this.” Well, actually not reproducing it is extremely useful. That tells us at least some information about what the current concern with this issue might be. Browsers change a lot, an issue somebody came up with six years ago simply may have been resolved somewhere else that we don’t know anything about.
There’s development. Now, obviously development, I think has probably got the most resources out and about for how you go about participating in that process. I’m not going to go into a lot of detail on it, but there are some things to definitely be aware of. If you are looking at any ticket at all that doesn’t currently have a patch, don’t hesitate to create one. That can be somewhat modified if there’s a lot of heavy activity and people discussing it, you might want to touch base with some of the other people working on the ticket, ping them on slack, or ping them in a comment on the ticket to see if anybody’s currently working on one, because it is obviously possible somebody’s been working on it for a week and just hasn’t uploaded it yet.
In general, don’t wait, and ask for permission. Don’t consider it to be something that is owned by somebody else, therefore they’re going to do it. Ownership of a ticket in WordPress track doesn’t have anything to do with being the person to actually solve the ticket. Owning a ticket on track, literally just means you’re trying to shepherd this through. You’re following it, you’re going to make comments on it, you might be taking responsibility on reviewing the patch and verifying that it’s going to work, but there’s no obligation there that you actually do the work to fix it yourself. Just because a ticket is owned, doesn’t mean you should hold back. That’s not a worry.
What makes a good patch?. Now, this is one of those areas where as a WordPress core committer, I have very strong opinions, and this all has to do with how much work I have to do on a patch to get it from the point where I have it to where it can actually be committed to WordPress. Some of the ideal things are, ultimately, it’s going to have to follow the PHP CS styles in order to be committed. That’s a relatively minor thing to fix it. It has to do it eventually. It would be great if it did it from the beginning. It’s going to have to handle any escaping or sanitizing correctly.
If you aren’t comfortable with the security functions in WordPress, they’re definitely worth reading up on and making sure you’re clear on it. It needs to be documented. That as a core committer, I’m definitely going to be looking at it. If I can’t tell what this code was intended to do, and it’s in this patch, I’m going to be very hesitant and I’m definitely going to throw it back for more information. It needs to avoid breaking backward compatibility, and that can be a huge thing. I understand that you may not realize when you make this patch that it’s going to break something. I’ve done that too. I’ve broken things, I’ve even committed things that broke things, and then learned about that later painfully after the version was released. That was exciting. Try as much as possible to avoid that. Then the last one that’s really actually one of the most crucial things, although it may not seem important is that it doesn’t alter any code or any code formatting that isn’t directly within the scope of the patch. That is all about the fact that that just makes it extremely difficult to figure out what has changed. When you’re looking at, because we do a lot of code archeology in core committing. There’s a lot of trying to figure out, “Okay, when did this change? How did it change? What changes it that caused this bug? Why did it change?” That’s where all of this documentation and everything is so crucial.
If you suddenly have a patch where there’s a lot of code in WordPress that does not actually follow the current PHPCS style guide because it’s old. It’s fine to consider that as something that should be changed. If so, the patch should be only changing the style. If you’re actually changing functionality, you should only change the functionality because if it’s also changing the style throughout the file, I’m not going to be able to figure out which change is relevant. That’s a shockingly important one that I have come to find very, very important since I became a core committer.
Why contribute? It’s hard for me to tell you why you should contribute. I can tell you why I would like you to contribute and that’s because there’s an enormous amount of work to do and I can’t really do it by myself, but ultimately the reason I contribute is because I want to see change. WordPress is enormous. WordPress impacts millions and millions and millions of people. There are hundreds of contributors to it, but accessibility is one of the smallest teams we have. In fact, all of the teams contributing to the classic WordPress interfaces are short of contributors right now. There’s been a huge amount of investment towards working on the block editor, which needs it, it does need development, but it’s left a lot of the other things, the backbone behind. We need a lot more, we need more people getting involved. A small change in WordPress is something that’s going to impact millions of people.
This is really what it comes down to for me at the end is why I contribute to WordPress. I’m not a huge fan of full-site editing and I’m only reluctantly more comfortable with the block editor, even though I still think there are a lot of big problems with it, but I have never even considered doing something like moving over to contribute to classic press, for example. The reason for that is because of impact. I could make a change to classic press, and it would impact a handful of people, but if I can make that same change to WordPress, it will affect millions more people. Even though it can be very difficult to even get a small change made because of just the weight of what is it, 19, 20 years of history in the code base, the impact is really important. I hope you will consider coming in and sharing and trying to help make WordPress more accessible. Now, I’d happily take questions because that’s it for my talk.
>> AMBER: I have a few, let me find myself here. All right. The first question was, you had mentioned when you were talking about documentation that the docs try to meet, I believe this was the context, try to meet WCAG 2.0. The question was why 2.0AA and not 2.1AA?
>> JOE: Well, to be very simple it’s because that was set before 2.1 was published. It hasn’t been the top priority to update that. I do know that the accessibility commitment document is in the process of being rewritten. I know I’ve made 20 or 30 comments on the rewrite, so I don’t know how far away that is from being published, but ultimately we will switch over to 2.1 and probably the next week 2.2 will be published. The reality is when you make a commitment, a long time advance to a large weighty system, it can take a while to really get caught up. Also, honestly, there’s a lot of work just to get WordPress to really, truly meet 2.0. Until we’re 100% convinced of that, it’s hard to say, “Oh, let’s add more criteria and move further along.” That doesn’t mean that we don’t actually try and meet those criteria. It’s just not actually literally written into the documentation.
>> AMBER: Yes. Nathaniel asked, is WordPress doing any automated testing internally for accessibility? He says selenium plus X has worked well for the.net apps I’ve seen. Do you know if there’s any linting or automated testing that happens of the code?
>> JOE: Not a lot.
>> AMBER: Why is that?
>> JOE: I know that there’s a lot of stuff being thrown around. Let me think. There’s nothing in the core test suite. There might be a little bit in the Gutenberg test suite. I know that there’s a conversation about getting block output tested. A big part of the problem, I think is just not having a lot of headless environment so that the build process really includes something that can be accessibility tested. I don’t have a lot of involvement with the test suite team, so I don’t know exactly what the limitations are and where that all stands. There’s been a lot of emphasis on the migrations required to get PHP 8 Plus properly supported. I know that’s been a pretty bearish process. I also know that as a plug-in developer, having to get all of those changes made for all of my plugins it’s been a strain to catch up.
>> AMBER: Yes, we just did well, we did PHP 8 compatibility with accessibility check and we took away 5.6 because it was like we can’t support both.
>> JOE: There’s only so much you can do. I fully understand that. The compatibility gets really very stressful. I think also for the admin accessibility testing, I’m not sure that it’s seen as being as valuable as it perhaps could be. There are a couple of different opinions about that. There are people who would like to really double down on accessibility testing, particularly within the block editor test suite. There’s a concern from within the accessibility team that passing those tests would be seen as sufficient.
>> AMBER: If they added automated tests.
>> JOE: It’s hard enough to get expert reviews requested on changes. I have a dread of a world where developers can just get an automated pass and just consider that to be good enough. On the other hand, it would be incredibly valuable at just avoiding some of the really dumb mistakes that we do catch. It’s not been that long since I last caught a button with no accessible name. That is an easy check for automation to flag just some pretty straightforward linting could make sure you just can’t commit it that way. I would really like to see at least a limited set of tools used to prevent those sorts of issues. I’d also like to see better acknowledgement that passing those issues does not make the product accessible.
>> AMBER: Is that just a matter of somebody being like, here’s the Linter I built.
>> JOE: There’s a lot that looks that way, yes. [crosstalk].
>> AMBER: Going and being like let’s put it in.
>> JOE: Yes. I’m reasonably confident that oh, I’m going to butcher Justin’s last name. Justin, Ahinon, Iano–. I don’t have any idea how to pronounce his last name. A-H-I-N-O-N. I’m fairly confident he has actually worked on a puppeteer implementation using Axe, but I don’t, I haven’t looked at it, so I don’t really remember.
>> AMBER: Yes, that would be interesting. Lynn was asking, does WordPress use JIRA for tracking tickets?
>> JOE: No.
>> AMBER: How are tickets all tracked do you feel like?
>> JOE: Well, there’s two systems for tickets. One of them is Trac and it’s a heavily customized version of Trac that has been in use now for, since at least 2003. I’m not sure how early they went into it. That can be found at core.trac.wordpress.org. Then the other one is GitHub issues.
>> AMBER: Would you be able to, and this I’m putting you on spot because I haven’t warned you about this, but I was wondering this while you’re talking, would you be able to share your screen and like show us an example of a ticket that somebody could jump on?
>> JOE: I can certainly look.
>> AMBER: It’s an accessibility ticket, and just like, what would you do?
>> JOE: Sure.
>> AMBER: You go to core.trac.wordpress.org.
>> JOE: Yes.
>> AMBER: And click tickets.
>> JOE: Let’s see, I will just go to accessibility tickets so you select by focus and then you violate WCAG.
>> AMBER: Meaning that, that’s not an accessible dropdown. Is that what that means?
>> JOE: Exactly, meaning that by selecting something in the dropdown, it then sends you to that page.
>> AMBER: Without a submit button.
>> JOE: Exactly. That said, you can also get to this page via other means. It’s not like that’s your only option. This is just taking you to all of the tickets that have a focus on accessibility with no particular organization. Right now we’re in the alpha phase. Pretty much anything is a good thing to work on, but particularly these things that are slated for the next release.
I need to move all of your photos out of the way so that I can see things. All right. Most of these have patches already. One that I own is marked for commit. I don’t remember that. I’ll have to look at that. I would start by maybe looking at one that doesn’t have a patch. Now this has been currently blocked because of a device testing issue. This has already been patched. The problem here is that we want the admin menu to be automatically dismissed on mobile devices when you click on the content, rather than having to move all the way up to the menu toggle button, which is way up at the top of your mobile device to close the menu. That is an accessibility issue because for people with low mobility, getting all the way back up to that button after you’ve navigated down to wherever you are can be a challenge.
It would be much more improved if by removing focus from the menu, it could then close. However, there is a device problem, and nobody who’s been testing it has a device that triggers it, if I remember correctly, it’s some older iPhone. Let’s see, I’m scrolling all the way down. This is a very long ticket it’s been going on for a while. I think the notes are maybe on the revert and it would require some searching, but regardless, the issue here is that compatibility with a particular device.
Really this is something where anybody with that device available is exactly what we need to be able to actually test it. The problem was that when you got the patch set, there were certain mobile devices that would hide the menu if you clicked on the menu. You could never really use the menu, which is obviously a major problem.
>> AMBER: Just to make sure I’m understanding. In this instance, we would need to touch the patch and make sure that it solved the problem.
>> JOE: Yes.
>> AMBER: Where would you even download this version of WordPress? Because obviously it’s not the actual version of WordPress?
>> JOE: Well, and that can be one of those things that can be a little bit challenging. This case it’s possible the patch would need to be refreshed because it’s fairly old.
>> AMBER: Would it be in this thread somewhere?
>> JOE: What it is the patches are always going to show up at the top. This is where some development experience is going to be required. This one was actually done via poll request. You could probably, if you can clone WordPress in GitHub, you should be able to apply this polling request to your branch, and then you’d be able to test it from that, but we will have to be able to build it locally.
>> AMBER: That’s the problem. I was like, “Why did you just use BrowserStack”, you can’t install Browse– Yes, right like.
>> JOE: It only happened on an actual mobile device. It did not happen in emulation, so it got tricky.
>> AMBER: I feel like I saw a conversation recently in the accessibility Slack channel about trying to come up with an easier process for new versions of whether I was Block Editor or WordPress just in general and being able to spin those up, even if you’re not a developer to test for problems. Is that still something that’s outstanding?
>> JOE: I know that exists for Gutenberg. There’s a site called I think it’s Guttenberg.run where you can just give it a poll request ID and it’ll apply it and spin up an instance, but I don’t think that exists as of yet for Core.
>> AMBER: That would be a cool thing for somebody to make.
>> JOE: It would be, absolutely.
>> AMBER: Because I feel like that would definitely [crosstalk] speed up some of this, right? If I’m not-
>> JOE: It would–
>> AMBER: -a technical person is like, “I just want to test things with my screen reader, but I don’t want to have to build a WordPress site because I’ve never done that before.”
>> JOE: Well, and one thing that the WordPress accessibility team has done in the past, and I don’t think anybody’s currently running this right now, but we used to maintain an installation where we would apply patches and then send it out to testers to test. I’m happy to continue to do that. It’s just that we don’t currently have a list of people to send it to.
>> AMBER: Everyone [crosstalk] volunteer to test.
>> JOE: Yes. If you just want to contact me, I can just set something up. I can certainly do that.
>> AMBER: That’s a good segue into Sharon asked she’s planning to get the Trusted Tester designation. Will that be enough to participate in testing for WordPress?
>> JOE: I don’t know what the Trusted Tester designation is.
>> AMBER: Oh, that’s like part of Section 508. I’m pretty sure, it’s like a federal government.
>> JOE: Got it.
>> AMBER: Training for auditing websites.
>> JOE: What was the question?
>> AMBER: I think the longer question on that, she was wondering if that would be all right for testing, but maybe the better question is, do you have to have any certifications or training in order to test for accessibility in WordPress?
>> JOE: No, there’s no training or certification required because ultimately what we’re concerned about is what our users expect and what they experience. We don’t really care whether it’s a Section 508 issue. Obviously if it is, that makes it a higher priority, but if it isn’t, that doesn’t make a not priority.
We’re not bound to limiting our accessibility fixes to only things that are documented in WCAG or Section 508. Really, as far as we’re concerned, if somebody has an issue, they should report it and we will have to make a judgment in some cases, if it doesn’t map to any criteria we will, of course be looking at it from the perspective of, well how much of a problem do we think this is? But if somebody is having a problem using something, then that is something we want to know about and want to think about.
>> AMBER: Do you feel like there are specific screen readers. Are people currently testing more in JAWS or NVDA, or Voiceover, or is it a mix?
>> JOE: I would say it’s mostly NVDA and Voiceover on the fairly obvious grounds that they’re free. I mostly test in JAWS right now, on the grounds that for some reason, recent versions of NVDA crash Notepad++ and that’s just inconvenient. It’s one of the environments I use to code, we don’t want to talk about my current setup, I currently have VisualStudio, and PHPStorm and Notepad++ depending on what I’m working on. We don’t need to talk about that.
>> AMBER: The bottom line is anyone who’s interested in testing or providing feedback, it’s helpful and test however you would normally use WordPress, or if you’re testing with the screen reader, and even if you don’t naturally use a screen reader every day, use the screen reader that works best for you and that’s helpful feedback either way.
>> JOE: Absolutely and I think one thing that I didn’t mention that I absolutely should is, if you’re raising an issue, keep them small. Like, there’s one outstanding issue right now, which where the issue is, media library doesn’t work with voice command and I mean, the fundamental problem with that is that it is enormous. It literally applies to the entirety of the media library and from a practical standpoint, to actually solve the problem, it’s going to be much faster if it’s a small, well contained issue and fine if there’s like 60 of them, because you in detail, went through a whole bunch of stuff and then raised 60 separate issues but it means that we can, it’s much easier to just kind of chip things off and go okay, now we’ve got those five resolved. Now let’s move on to these five, as opposed to just an enormous issue that you look at and go “Oh, my god, I can’t deal with that.”
>> AMBER: Well, it’d be more like, the love more button doesn’t work with voice command.
>> JOE: Exactly.
>> AMBER: Yes, every individual piece should be its own ticket.
>> JOE: I will also note that that ticket is possibly 10 years old and there’s been a lot of work done on the media library since then. I can’t say for sure. That’s a good example of a ticket that really needs to be retested because it’s a very old ticket. It’s outstanding and it’s outstanding because we don’t have people who are using voice command to test it. I mean, I don’t have anywhere near enough experience with voice command to really do that myself. We need a contributor who actually uses that, who can go through that and start to document something more detailed about how that works.
>> AMBER: This is more of a philosophical question on that front. What do you think that we could do as business owners or abled users of WordPress, to get more people with disabilities involved? Is that a matter of like, committing some percent of our revenue to donate to something that pays for user testing? Is it volunteering our time to just get more people with disabilities aware of WordPress, what do you think that might look like?
>> JOE: I mean, in my opinion, it comes down to paying people to do it and that is one of the places where the accessibility team is particularly poorly supported. Almost every team that as far as I know has at least one contributor who is sponsored by their company, and the accessibility team does not have anybody who’s sponsored. When none of your contributors have funding, it really limits what you can do. I mean, I contribute as much as I can, but from a practical standpoint, I also do have to run my business and that makes my contribution a little bit irregular. Sometimes I can do a lot sometimes I can’t.
>> AMBER: Yes. I think that’s something that we’ve been mulling on a little bit internally and just talking about, what does it take to get some of those bigger companies that do sponsor contributors to see value in the accessibility team? If some of us have smaller companies, and we can’t do that yet, right?
>> JOE: Right and I think there’s a lot of emphasis on sponsoring people and training people to have better knowledge about accessibility and I think that’s great and I think that in general, the level of code that sponsored contributors are contributing now is at a reasonably high level for accessibility but there is a very significant divide between a subject matter expert, and a very skilled developer with some training in accessibility and it does mean that we’re much less likely to see some really awful things contributed but a subject matter expert has a lot of benefit in being able to really try and look at the system on a larger scale and are we doing what we need to do in the best possible way? Are we being consistent about it, as opposed to is this specific interaction, meeting basic standards and that kind of thing gets reflected in pointless use of ARIA labels for example? Are you like, yes, that’s great. You have an ARIA label on here, but it is the same text as the button itself. It was totally unnecessary.
>> AMBER: You didn’t need it. Yes, I think that’s interesting to think about, like, how can we fund that more, that can make a bigger difference? I think the only other question that I had, and then anyone else, if you have a chance, and you have questions, feel free to throw them in Q&A. Otherwise, I think we’ve answered just but all them, was you did mention earlier about the WordPress PHPCS styles? Where are those found? Are those in one of the handbooks about contributing or if someone–
>> JOE: Yes, there’ll be a few, look at the core developer guide, I mean, the full PHPCS styles, they’re actually maintained on GitHub. I mean, that’s an automated test library. You can absolutely use them in any plugin, I use them in all of my plugins because, I mean, if nothing else, it’s just good practice. It may helps make sure that I’m keeping in mind what I actually need to do, it’ll help me spot what I need to do elsewhere but, you can find information about them at make.wordpress.org/core/handbook. Maybe I should just go to that page and locate it because I might be making that up.
>> AMBER: Yes, sounds good. I think those are all the questions, this has been really helpful and I know I myself have been like, I should do more and then I always get overwhelmed. I really appreciate you diving in and showing us more detailed and making it sound not scary.
>> JOE: They are PHP coding standards. They are all documented here but it is generally easier.
>> AMBER: I don’t think you’re sharing them. Maybe you can–
>> JOE: I’m not, you’re right. I’m not.
>> AMBER: You can put the link in the chat, if that’s easier too.
>> JOE: I will but I will also share the screen. Why not have both covered, right? There they are.
>> AMBER: This is what we need to be familiar with, if we are going to try and contribute code.
>> JOE: It’s certainly very helpful. I mean, all of the core committers certainly will make those changes. It’s going to greatly improve the likelihood and speed that a patch can move from concept to commit, if it’s already showing up meeting standards and expectations and there’s a lot of all of the standards are documented here, the JavaScript standards, [inaudible] documentation standards. It’s all there.
>> AMBER: Thank you. Where can people get a hold of you if they have follow up questions or want more information?
>> JOE: I would say you can either get me in the WordPress Slack instance at JoeDolson or you can ping me on Twitter, Twitter/JoeDolson. I’m Joe Dolson pretty much everywhere. That’s going to be the easiest way. I would say you can contact me by email but at this point, I’m overwhelmed with email that there is a strong possibility I’ll just get lost.
>> AMBER: Yes, I feel you on that one too. I have emails in there that have been sitting for several weeks waiting on me [inaudible].
>> JOE: Weeks, that’s all? Nothing.
>> AMBER: I think about once a month I break down and I am like, I need to go back through all of these emails and figure out what I’m doing with them and I spend almost the whole I don’t know, like, Friday evening or something just going through my inbox.
>> JOE: Yes, definitely. Very understood.
>> AMBER: Well, thank you, everybody. Really appreciate it and tuning in and for the great questions and thank you, Joe.
>> JOE: Thank you.
[] [END OF AUDIO]
