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.
A nice tool for choosing colour palettes that look good and are also accessible.
Seems like ages since I’ve seen Saqib. He’s been working on something very nifty indeed:
…Seeing AI, a research project that helps people who are visually impaired or blind to better understand who and what is around them. The app is built using intelligence APIs from Microsoft Cognitive Services…
On universal design: “We’re reframing disability as an opportunity.”
One day someone will write a history of the Internet, in which that great series of tubes will emerge as one long chain of inventions not just geared to helping people connect in more ways, but rather, to help more and more types of people communicate just as nimbly as anyone else.
I don’t care about Opera Mini (I’m not its Product Manager). In the same way, I don’t care about walking sticks, wheelchairs, mobility scooters or guide dogs. But I care deeply about people who use enabling technologies — and Opera Mini is an enabling technology. It allows people on feature phones, low-powered smartphones, people in low-bandwidth areas, people with very small data plans, people who are roaming (you?) connect to the web.
Here’s a bit of convergent evolution: Hugo’s script is similar to what I wrote about recently.
He also raises a point that Kevin mentioned:
I would like to investigate on the
summaryelements as they are basically a native implementation for content toggles.
For some reason
details never got much browser love, even though it’s clearly paving a well-trodden cowpath.
A very lightweight script for toggling the appearance of elements in an accessible way.
Three very easy to implement additions to scrollable areas of your web pages:
role="region", and an
Use the right element for the job.
- Does the Control Take Me to Another Page? Use an Anchor.
- Does the Control Change Something on the Current Page? Use a Button.
- Does the Control Submit Form Fields? Use a Submit.
A great description of a solid architectural approach to building on the web (and not just for accessibility either).
Marco gives a run-down of the basics of getting accessibility right on the web. Nothing here is particularly onerous but you’d surprised how often developers get this wrong (or simply aren’t aware of it).
He finishes with a plea to avoid unnecessary complexity:
It really isn’t hard to get the basics of accessibility right on the web …and yet those basics are often neglected.
Here’s a handy shortlist to run through, HIKE:
- H stands for headings and semantic markup.
- I stands for images and labels.
- K stands for keyboard navigation.
- E asks for you to ACT with a little extra love for custom components and more.
(ACT = ARIA, Colour Contrast, Text Size)
The best ARIA role is the one you don’t need to use.
Jennison Asuncion outlines the problem with relying on a swipe gesture for interactions.
I would say that this could be expanded to just about any interaction: it’s always dangerous to rely on one specific gesture. It’s always better to either provide multiple ways of accomplishing a task, or to simply take a declarative approach, get out of the way, and let the user agent handle it.
Some mea culpas from a developer at Medium. They share so that we may learn.
This is such an incredibly useful resource by Steve and Léonie: documenting how multiple screen readers handle each and every element in HTML.
It’s a work in progress, but it’s definitely one to remember the next time you’re thinking “I wonder how screen readers treat this markup…”
The inaugural London accessibility meet-up is happening on October 28th with two great presenters: Robin Christopherson and Julie Howell—that’s right; she’s coming out of retirement for one last talk!
All the videos from the excellent Responsive Field Day are now available. Even better, the audio is also available for your huffduffing pleasure!
All the presentations and panels were great. Sophie Shepherd’s terrific talk has really stuck with me.
A handy little bookmarklet for doing some quick accessibility checks.
A great run-down by Heydon of just one ARIA property: aria-label.
Marcy’s Tumblr blog of examples of accessibility in action on the web.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
I completely share Bruce’s concern about the year-zero thinking that’s accompanying a lot of the web components marketing:
Snarking aside, why do so few people talk about extending existing HTML elements with web components? Why’s all the talk about brand new custom elements? I don’t know.
I’m a fan of web components. But I’m increasingly worried about the messaging surrounding them.
A great presentation on web components by Marcy, with an emphasis on keeping them accessible.
Yesterday, Aaron gave a great talk at BD Conf about forms. In one example, he was using
aria-describedby. I was a bit confused by the differences between
aria-labelledby, so Aaron has very helpfully clarified the distinction.
A great technique from Heydon for styling radio buttons however you want.
Heydon Pickering put together a great collection of accessible self-contained interface patterns that demonstrate smart use of ARIA.
It’s great to see the changes that Facebook’s four-person accessibility team have managed to push through.
This is a great initiative. I’m going to learn a lot from it. I hope that I might even be able to contribute to it sometime.
A worrying look at how modern web developers approach accessibility. In short, they don’t.
The low-hanging fruit of accessibility fixes; it’s worth bearing these in mind.