Equalify’s mission is to make the web more accessible, and I believe that making WordPress more accessible is key to that mission. In standing behind that belief, we donate our platform (and I donate my time) to WordPress.
My first step in making WordPress more accessible is understanding what websites their organization runs. This document outlines the steps to this process of “Domain Discovery.”
Step 1: Finding Stakeholders
As with many Universities we work with, the WordPress organization has different stakeholders that run different websites. I integrated myself with various WordPress teams to understand who controlled what. That led to a big spreadsheet of different websites (you can see the spreadsheet at this link).
A vital column in my giant spreadsheet is “Repo URL”. That’s the URL where we would report Accessibility Issues. Getting a clear place to report issues is vital in actually making the websites accessible.
Step 2: Initial Scans
Once I knew what needed to be scanned, I used Equalify to do an initial scan of WordPress properties. This scan reported over 4 million violations. Big numbers like that helped get people excited about the project and establish a baseline to compare our progress against.
Here’s an example of the kind of excitement we got from our initial scan:
I also shared all results with the WordPress team when the scans were complete. Transparency creates buy-in. We aimed to get as many people in the WordPress community on board with our project as possible.
All data was posted on a public repo here: http://github.com/equalifyEverything/eudaimonia-wp
Step 3: Prioritizing Sites
Not all of the 400-plus sites needed to be scanned every day. After about a month, I realized that a few sites should have priority over others. Specifically, I decided to prioritize recently redesigned sites.
I let various WordPress teams know that I would regularly scan sites that had priority. That led to team leaders contacting me when their site was ready to scan.
Step 4: Posting Tickets
I used an experimental Equalify AI feature to help me write tickets. That feature looks at data, finds patterns, and creates tickets around issues.
Single issues, like creating an Aria-landmark, worked stunningly. Equalify and a ChatGPT-powered integration wrote a ticket that I only had to provide a small number of updates to. Here’s a related issue I posted: https://github.com/WordPress/wporg-mu-plugins/issues/622
Other issues, like color contrast issues, didn’t work with the AI tools. I had to spend a lot of time tuning the data and ChatGPT to create a useful ticket. Here’s an example of a ticket that was successfully created after lots of tuning: https://github.com/WordPress/wporg-main-2022/issues/472
Overall, the biggest lesson from posting tickets is to make sure the information is useful to developers. Equalify can be tuned for every project, so I’ve kept this running list (linked) with feedback that I’ll implement in future scans.
Step 5: Supporting & Advocating
My goal is to support the WordPress project with Equalify for as long as possible. I’ve created a weekly call in the WordPress Slack to give updates on accessibility testing progress. I also make myself readily available for any feedback and chime in on GitHub issues related to the accessibility problems I post.
Again, Equalify’s mission is to make the web-accessible. I hope that my work with WordPress works toward that mission.
Leave a Reply