March 2016

This article was originally posted at A List Apart, and generated a lot of very thoughtful and insightful comments. It has since been taken down, and re-posted at Heather Burns’ site. It’s always a sad thing when big-name web publications sensor in order to avoid or deflect controversy.

Digital legislation is confusing and outdated—Heather Burns shows how professionalizing the web industry can help.

Source: The Perfect Storm in Digital Law

This entire article is worth a thoughtful read, and I think it has implications for not only those of us who work as web professionals generally, but accessibility professionals in particular as well.

Specifically, the accessibility profession is going to have to join the greater web profession in working towards a solution to the problems outlined here, and in order to do that, it’s going to have to become a lot less insular. It’s going to have to learn to play well with the greater web community, regardless of whether or not that community as a whole has signed onto accessibility as a right and obligation.

In other words, every one of us is going to have to shelve our pride in whatever we work on and learn to play ball professionally witheach other and other communities who are going to have to come under our umbrella, because we’re up the creek if we don’t get it together.

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.

Since PHP 7 is shiny and new, it unsurprisingly got a lot of coverage. If you’re migrating from PHP 5, or considering doing so, this talk will let you know what to expect. It also gives some brief information on the grace periods which have been extended to the 5 branch, including specifics on PHP 5.5 and PHP 5.6.

https://www.w3.org/WAI/gettingstarted/tips/

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.