You know, we use ad-blockers as well.
We gotta keep those servers running though. Did you know that we publish
useful books and run
friendly conferences — crafted for pros like yourself?
E.g. our upcoming SmashingConf New York, dedicated to smart front-end
techniques and design patterns.
Rod is a web developer based in southern Germany. Having been a freelancer for a decade, he’s now working on Qivicon, Deutsche Telekom’s Smart Home platform. Before focusing himself on all things in the browser, he mostly did PHP and was quite decent with databases and distributed systems for scalability and redundancy. Created URI.js, worked on Smarty.
I’ve been a web developer for 15 years, but I’d never looked into accessibility. I didn’t know enough people with (serious) disabilities to properly understand the need for accessible applications and no customer has ever required me to know what ARIA is. But I got involved with accessibility anyway – and that’s the story I’d like to share with you today.
At the Fronteers Conference in October 2014 I saw Heydon Pickering give a talk called “Getting nowhere with CSS best practices”. Among other things, he made a case for using WAI-ARIA attributes like aria-disabled="true" instead of classes like .is-disabled to express application state. It struck me then and there that I was missing out on a few well-prepared standards, simply because ARIA belongs to that accessibility space that I had no idea of.
This article is packed with a number of quirks and issues you should be aware of when working with CSS3 transitions. Please note that I’m not showing any workarounds or giving advice on how to circumvent the issues discussed.
This article covers the most important things that you will need to consider before and while writing your own utilities and libraries. We'll focus on how to make your code accessible to other developers. A couple of topics will be touching upon jQuery for demonstration, yet this article is neither about jQuery nor about writing plugins for it.