This uses generated content in CSS to make the
aria-label attributes visible on small screens—clever!
This uses generated content in CSS to make the
Kevin writes a plea on Ev’s blog for better contrast in web typography:
When you build a site and ignore what happens afterwards — when the values entered in code are translated into brightness and contrast depending on the settings of a physical screen — you’re avoiding the experience that you create. And when you design in perfect settings, with big, contrast-rich monitors, you blind yourself to users. To arbitrarily throw away contrast based on a fashion that “looks good on my perfect screen in my perfectly lit office” is abdicating designers’ responsibilities to the very people for whom they are designing.
A good reminder from Roger on how to hide images from an SVG sprite from assistive technology (use
aria-hidden) and how to expose them (use
title elements within the sprite).
Heydon asked screen readers some questions about their everyday interactions with websites. The answers quite revealing: if you’re using headings and forms correctly, you’re already making life a lot easier for them.
I wrote a while back about how I switched from using a button to using a link for progressive disclosure patterns. That looks like it was a good move—if I use a button, I’d need to use
aria-controls and, as Heydon outlines here, the screen reader support is pants.
I’m in complete agreement with Heydon here:
But it turns out the only surefire way to make performant Web Stuff is also to just write less. Minify? Okay. Compress? Well, yeah. Cache? Sounds technical. Flat out refuse to code something or include someone else’s code in the first place? Now you’re talking.
Just like the “mobile first” mindset, if you demand that everything must justify its existence, you end up with a better experience for everyone:
A great series of short videos from Marcy on web accessibility.
In the same vein as Hugo’s script, Ire walks through the steps involved in making an accessible modal window. Seeing all the thinking and code required for this really highlights the need for a way of making the document in the background inert.
Over the years I’ve come to realize that most difficult part of making websites isn’t the code, it’s the “hidden expectations”, the unseen aspects I didn’t know were my responsibility when I started: Accessibility, Security, Performance, and Empathy.
I’m not a fan of the checklist approach to accessibility, but this checklist of checklists makes for a handy starting point and it’s segmented by job role. Tick all the ones that apply to you, and this page will generate a list for you to copy and paste.
A handy Chrome extension to simulate different kinds of visual impairment.
Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns” (Pre-Release) – Smashing Magazine
I think it’s a safe bet that this new book by Heydon will be absolutely brilliant.
It’s a handbook with valuable, time-saving techniques that will help you avoid hacky workarounds and solve common issues effectively.
Some interesting outcomes from testing gov.uk with blind users of touchscreen devices:
Rather than reading out the hierarchy of the page, some of the users navigated by moving their finger around to ‘discover’ content.
This was really interesting - traditionally good structure for screen readers is about order and hierarchy. But for these users, the physical placement on the screen was also really important (just as it is for sighted users).
A very handy collection:
This book contains frontend coding patterns (and anti-patterns) that will assist developers in building accessible e-commerce web pages, widgets and workflows.
I like that it contains a list of anti-patterns too.
There’s also a corresponding collection of working demos.
A nice little collection of interaction patterns with built-in accessibility and no dependencies.
A typically superb article by Aaron. Here, he breaks down a resilient approach to building for the web by examining the multiple ways you could add a button to a page. There’s a larger lesson here too:
We don’t control where our web-based products go or how our users access them. All we can do is imagine as many less-than-perfect scenarios as possible and do our best to ensure our creations will continue to do what they’re supposed to do. One of the easiest ways to do that is to be aware of and limit our dependencies.
Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.
Did I mention that it’s free?
Hidden little details that make a big difference for screen readers.
A website is only as beautiful as the underlying markup.
A glanceable one-stop-shop for how today’s browsers are dealing with today’s accessibility features. Then you can dive deeper into each one.