Back in the bad old days, before the WordPress Accessibility Team really got off the ground and came into its own as a well-loved and respected part of the WordPress project, I used to see a lot of claims from theme vendors, page builder vendors, and plugin authors, (both free and premium), that their products were accessible, or sec. 508 compliant, or the like. Thanks to the work of the accessibility team, and its individual members, that is no longer the case. Not only are plugin and theme authors less likely to declare their products accessible without asking someone to check it, (or paying for work in some cases to ensure that their products are in fact accessible), the term accessible has been more or less swopped out for accessibility-ready, meaning that you can create an accessible site with it, but there’s also room to make your site less accessible by not following the author’s recommendations for settings. All of this makes me very proud. We’re making progress towards full inclusion for everybody, regardless of ability or language spoken, and we’re also making sure we point out where we still have room to grow.

Some of Adrian’s techniques from the linked post above will work in this ecosystem, and some won’t. But either way, this is a great roadmap for users who are either downloading or purchasing premium products to test claims of accessibility if any are made. The testing technique, and the filing issues technique, are also great ways for users or other developers to help the process of “make accessible all the things” move forward. Just make sure you’re polite and respectful when filing reports. The difference here, as with other open source projects, is that the majority of the time, these developers are putting their free time into these projects, and do not have dollars to spend on proper accessibility consulting or remediation.