Adrian Roselli has written what I think is an excellent post on how to test a vendor’s claims of what I like to refer to as a11yworthiness.
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.
In case you’ve been living under a rock for the last couple of days, the WordPress Accessibility Team announced that WordPress is going WCAG. That means that all new or updated code for WordPress core, as well as bundled themes, must be WCAG 2.0 level AA compliant.
Maybe you’re already familiar with the basics of accessibility. If you are, excellent! But if you’re looking to level up, you may be wondering where to start doing that.
The W3C can help with that
the World Wide Web Consortium, (W3C) has some very helpful resources on accessibility, including tips for getting started on accessibility. There are resources for designers, content writers, and developers.
Although this resource is billed as a getting started guide, I can almost guarantee there will be something for everyone here, from beginner to advanced. There are a lot of little details to cover when it comes to making the web accessible, and it’s easy to miss things when you’re trying to juggle accessibility among all the other project requirements you need to fulfill. Especially if accessibility isn’t your day job.
So give the above resource a look, and follow all the links. You’ll be leveling up in no time.
Dries Buytaert asks “Can we save the open web?” and makes an amazing case for why we should. I agree with and endorse basically everything in that post.
Source: Saving the Open Web | Matt Mullenweg
The post Matt links to is an excellent one, and the only thing I would add to it is that saving the open web is everybody’s responsibility. Over the last couple of decades, we’ve allowed the web to become broken in various ways, and we all have a share in its brokenness. Saving the web, making it open again, and fixing the brokenness are all interrelated in my opinion, and I think we need to take some time, slow down a bit, and start fixing this. This will include very sexy things, (like emerging technologies), and very unsexy things, (like web developers learning to HTML, CSS, PHP and JavaScript properly). All four of those technologies are very important, and, if handled and interacted with properly, can do some amazing things. But all of us need to crawl on the floor with all of these before we can run with them, and that includes crawling on the floor with HTML before we get to play with the cool things like JavaScript. Do HTML badly and your PHP and especially JS will also be done badly.
The U.S. Department of Justice has yet to issue regulations on how e-commerce operators and governments can meet their website accessibility obligations under the Americans With Disabilities Act. In the meantime, many of the country’s top retailers are being hit with lawsuits for allegedly failing to make their websites accessible to the legally blind.
Source: Fighting for Accessible Websites Under the ADA: Daniel Goldstein, Brown Goldstein Levy, Baltimore
While I have yet to hear of any WordPress-specific agencies or shops whose clients have been shaken down by the National Federation of the Blind, this trend is on the upswing. So if you’re not building accessible websites for your clients yet, please start. Don’t ask them if accessibility is a requirement. If you start at the beginning, it’s not going to be a large expense. Please don’t make your clients wait until they get a demand letter or a lawsuit over their website. By that point, the costs of remediation go up exponentially, and you end up with an unhappy client. So don’t put your clients at risk by leaving accessibility until the end, or out of the equation altogether.
Layout tables are probably one of the most hated web things within the accessibility community. They used to be all the rage before CSS became popular, and they were used inline among other HTML elements to control positioning.
As a result of their overuse, screen readers ignore them by default. Well, they mostly do.
VoiceOver, the built-in screen reader on the Mack, is apparently the exception. As long as a layout table has no borders, VoiceOver will ignore it as such and only give you the option to view data tables from its rotor. But if you add any kind of border, including transparent ones, that goes out the window and VoiceOver will report the existence of the table from the rotor. This is true regardless of whether or not the layout table has headers.
Layout tables are bad. Layout tables without headers are even worse. Layout tables with borders can have the added value of extra annoyance for VoiceOver users.
Friends don’t let friends use layout tables, so as a service to the WordPress community, here’s yet one more reason not to use them. See the link above for all kinds of CodePen goodness and screenshots.
I’ve been asked again and again over the years what the absolute basics of web accessibility are. And while I always thought that it is not so difficult to find resources about these basics, the recurrence of that question prompted me to finally write my own take on this topic.
Source: The web accessibility basics – Marco’s Accessibility Blog
This guide to accessibility basics is a very handy reference for anyone who’s interested in getting started with accessibility. Reading WCAG can seem daunting, (I don’t know of a single accessibility professional who truly enjoys the experience), and if you’re only reading WCAG and its associated documents, accessibility will appear to be harder than it actually is.
The takeaway from this guide is: Use native HTML elements where possible. Where it’s not possible, use Aria to compliment your custom elements and make sure to provide the semantic information that’s no longer implicitly provided, which is basically everything: Role, state, and property.
There are talks on WordPress.TV about all of this, but this guide along with several of the other posts at Marco’s blog can serve as a handy textual reference.