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.

But if I had to pick on WordPress for anything, it would be the lack of a systematic way to recognize contributors to the project who don’t write code.

We tell others who aren’t contributors yet that they can contribute to WordPress without writing a line of code. I think that statement shows up in some form or other in just about every contribution pitch. And yet, we act like the coders are the only ones who deserve official recognition. We showcase the newest ones on the “About” page of every new WordPress install or major update. But we have no system for acknowledging all the people who volunteer in the support forums, test code for accessibility, design, or any of the myriad other tasks required to run a project of this size.

It’s not that I’m saying coders shouldn’t be recognized. They contribute in a huge way, and they deserve recognition for their efforts. But so do the support volunteers, the testers, the evangelists, the designers, and every other non-coder who helps with WordPress in any way.

I think WordPress does an excellent job on most things, even things that other open source projects struggle with. But I think we can do a lot better when it comes to acknowledging our contributors, and if we do, we would demonstrate in a concrete way that our non-coding contributors really do matter and are vital to the project.

Don’t believe me? there’s a lot of data to back up that claim.

The short version is, if you want your message to have an impact, don’t use more than two of them per social media message. Three or more and your message starts to become diluted, and your intended audience will ignore it. This is especially true on Twitter, though less so on other social networks like Instagram or Google Plus. On Facebook, hashtags are pretty much useless.

This is also worth keeping in mind if you’re posting the same content to multiple social networks. Don’t cram your content with hashtags on Twitter just because it’s going to Instagram, for example.

And of course, when using hashtags, make sure they’re relevant. Nothing will kill a message faster than its being tagged with an inappropriate hashtag, or tagged with something that happens to be trending or that has a lot of followers.

So the next time you want to strangle one of your friends for using too many hashtags, now you can do it politely, and explain that there are data to back you up.

A critical bug that can leak secret cryptographic keys has just just been fixed in OpenSSH, one of the more widely used implementations of the secure shell (SSH) protocol.
The vulnerability resides only in the version end users use to connect to servers and not in versions used by servers. A maliciously configured server could exploit it to obtain the contents of the connecting computer’s memory, including the private encryption key used for SSH connections. The bug is the result of code that enables an experimental roaming feature in OpenSSH versions 5.4 to 7.1
“The matching server code has never been shipped, but the client code was enabled by default and could be tricked by a malicious server into leaking client memory to the server, including private client user keys,” OpenSSH officials wrote in an advisory published Thursday. “The authentication of the server host key prevents exploitation by a man-in-the-middle, so this information leak is restricted to connections to malicious or compromised servers.”

Source: Bug that can leak crypto keys just fixed in widely used OpenSSH

The OpenSSH maintainers have released a patch that fixes this, so if you’re using OpenSSH, update. It’s always important to make sure you’re running the latest versions of the things you depend on, especially when security fixes are involved.

And if you haven’t done so already, please consider contributing to free software like this. Free, (as in freedom) is everyone’s responsibility, and even if you’re not a coder, you can still contribute. All of the security, server-side software, and the client-side software used to interact with the server, which is widely used is free software. In order for that to remain the case, the upkeep of said software/tools canot be left to “other people.” so if you haven’t done so already, consider giving something back to the communities whose software you freely use to get your work done, or daily tasks completed. Your contributions, whether in time and talent or monetary form, make a difference.

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.