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.
10 guidelines to improve your web accessibility | Aerolab
Creating Accessible SVGs | Deque
See No Evil: Hidden Content and Accessibility - Cloud Four
Accessibility Insights
mapbox/remark-lint-link-text: A remark-lint plugin that warns against non-descriptive link text.
We are actively destroying the web | Go Make Things
What we found when we tested tools on the world’s least-accessible webpage - Accessibility in government
WCAG 2.0 checklist - a free and simple guide to WCAG 2.0
💬1 - We Analyzed 10,000,000 Pages and Here’s Where Most Fail with ADA and WCAG 2.1 Compliance - accessiBe
Web Components and the Accessibility Object model (AOM) - 24 Accessibility
Innovation in the web without sacrificing Accessibility – INNOQ
WebAIM: Web Accessibility for Designers
Access simonmcmanus.com. Simon McManus
chai-a11y-axe - npm
How to include accessibility in the Definition of Done — Accessibility for Teams