There’s a quote by Tim Berners-Lee, Director of W3C and inventor of the World Wide Web, that says, “The power of the web is in its universality”. As people who make a living by making websites, it’s our responsibility to ensure everyone has access to them. Web accessibility seems like a tall order on paper, but it’s definitely much easier than it sounds.
Scalable Vector Graphics (SVGs) have been around since 1999, but they have seen a real resurgence in use as design interactions have become more complex and CSS/JavaScript have replaced antiquated animation programs such as Adobe Flash.
When I first started learning web development I thought hiding content was simple: slap display: none; onto your hidden element and call it a day. Since then I’ve learned about screen readers, ARIA attributes, the HTML5 hidden attribute, and more!It’s important to ensure our websites are accessible to everyone, regardless of whether or not they use a screen reader, but with this myriad of options, how do we know when to use what?There are four main scenarios where you may wish to hide content:1. Hiding content for everyone, regardless of whether they use a screen reader2. Hiding content for screen readers while showing it to other users3. Showing additional content for screen readers while hiding it from other users4. Hiding content at specific screen sizesLet’s dive deeper into each of those scenarios to learn how to handle them.
One of the central themes of my talk on The Lean Web is that we as developers repeatedly take all of the great things the web and browsers give us out-of-the-box, break them, and then re-implement them poorly with JavaScript.
We recently conducted an audit of automated accessibility testing tools. We built a website full of accessibility failures to test them on. We've published our findings here.
I’ve organised my WCAG 2.0 checklists by level (read more about WCAG 2.0 levels here). If you’re attacking the guidelines in order (and I suggest you do), you’ll move from Level A (Beginner) through Level AA (Intermediate) and on to Level AAA (Advanced).
It’s no secret that the topic of web accessibility is on a meteoric rise. Thousands of lawsuits and tens of thousands of demand letters served to small business owners (but not just them, see Dominos’ supreme court ruling), have driven an increase of over 400% in Google searches for an ADA and WCAG compliant solution, from Jan 2019 to Dec 2019.
The focus of web accessibility is often on web development – the things that happen in HTML, CSS, or JavaScript. Optimal accessibility should start much earlier, as part of the visual design process. This infographic highlights many important principles of accessible design
A well-written DoD can serve as a checklist for the team, provides a shared understanding on the quality of the work, and helps the product owner in the acceptance process.When you include accessibility in the DoD, you make it an important quality of your product. Each backlog item should comply with the Definition of Done, it helps you spot and tackle accessibility issues before they’re deployed to production.
Aims to be the biggest checklist of inclusive design considerations for the web ever. Includes items for accessibility, performance, device support, interoperability, and language. Pull requests welcome!