It’s unfortunate that the state of open source CMS accessibility has forced the organization to narrow its selections to proprietary software options for its first redesign in more than a decade.

I share this sentiment. Also deeply curious since the cursory notes on accessibility for both of the reviewed CMSes seem to highlight a ton of issues like “Buttons and Checkboxes are built using div elements” or most inputs lacking clear focus styles. An element like the Calendar for choosing a post date seems entirely inoperable with keyboard on Craft, for example, while WordPress’ has had significant effort and rounds of feedback poured into that element alone to make it fully operable.

We always have a long way to go to continue to make WordPress usable and accessible to the vast majority of people, and there will always be disagreements on whether we are hitting the mark or not on specific parts of the experience, even within the contributors working to make WordPress better day to day, but overall I think the effort exhibited from those contributing to the software is steps ahead. In my opinion, building a components API that can lead to better accessibility baselines for developers extending WordPress is on its own very impactful and equally challenging.

Then there’s also the recommendations to the person authoring content, from heading outlines to color contrast in different places, on top of ensuring the semantics of blocks in the front-end are the best they can be. We ought to continue being our harsher critics, but in these wider comparisons I think we also need to retain perspective.