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.
On the need for a way to mark parts of a document as “inert” while the user is interacting with modal content.
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.
Two sides of a debate on progressive enhancement…
Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:
Joe Hoyle disagrees:
Caspar acknowledges this:
I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).
But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:
Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.
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.
Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.
Websites can be viewed by anyone with a web browser.
And that doesn’t mean foregoing modern features:
A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.
This is why progressive enhancement is so powerful.
My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.
Brad points out the importance of supporting—which is not the same as optimising for—the non-shiny devices out there.
I really like using the Kindle’s browser as a good baseline for checking that information is available and readable.
I like this nice straightforward approach. Instead of jumping into the complexities of the final interactive component, Chris starts with the basics and layers on the complexity one step at a time, thereby creating a more robust solution.
If I had one small change to suggest, maybe
aria-label might work better than offscreen text for the controls …as documented by Heydon.
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.
Because in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.
It will come as no surprise that I agree with every single word that Tim has written here.
The minimum dependency for a web site should be an internet connection and the ability to parse HTML.
A great description of progressive enhancement.
Progressive enhancement in its basic form means not making assumptions
You can now read Aaron’s excellent book online. I highly recommend reading the first chapter for one of the best descriptions of progressive enhancement that I’ve ever read.
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.
Patty Toland — Design Consistency For The Responsive Web (Smashing Conference Freiburg 2014) on Vimeo
Patty’s excellent talk on responsive design and progressive enhancement. Stick around for question-and-answer session at the end, wherein I attempt to play hardball, but actually can’t conceal my admiration and the fact that I agree with every single word she said.
Léonie gives a great, clear description of how screen readers switch modes as they traverse the DOM snapshot.
Steve shares my concerns …but he still refers to my post as “piffle”.
I can’t win.
Alice Bartlett shares her experience of getting aria-live regions to work in a meaningful way.
Heydon Pickering put together a great collection of accessible self-contained interface patterns that demonstrate smart use of ARIA.
Bruce’s thoughts on ensuring accessibility in Web Components. He thinks that the vocabulary of ARIA is up to the job, so that’s good enough for me.
Some sensible thoughts from Addy on how Web Components might be peer-reviewed.
A healthy dose of scepticism about Web Components, looking at them through the lenses of accessibility, security, and performance.
I share some of this concern: Web Components might look like handy ready-made out-of-the-box solutions, but the truth is that web developers have to do much more of the hard graft that was traditionally left to the browser.
Scott writes an absolutely spot-on skewering of the idea that progressive enhancement means you’re going to spend your time catering to older browsers. The opposite is true.
Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.
A love letter to HTML, prompted by the line-mode browser hack event at CERN.
A cogent definition and spirited defence of progressive enhancement:
Progressive Enhancement is an extension of our shared values on the web and goes to the root of the web. I believe—and hope you agree—that the web is for everybody and should be accessible regardless of the device a user brings to the party.
Preach it, Karen!
“Why would someone ever want to do that?” is the wrong question. It doesn’t matter why they want to do it. The fact is that people do. The right question, the one that we all should be asking, is “how can we make a better experience for them?”
Yet another timely reminder from Tim, prompted by the naysayers commenting on his previous excellent post on progressive enhancement, universal access, and the nature of the web.
A great call-to-arms from Tim, simply asking that we create websites that take advantage of the amazing universality of the web:
The web has the power to go anywhere—any network, any device, any browser. Why not take advantage of that?
Inevitably there is pushback in the comments from developers still in the “denial” stage of coming to terms with what the web is.
Carousels are shit. Auto-animating carousels are really shit. Now proven with science!
It’s great to see the changes that Facebook’s four-person accessibility team have managed to push through.
I’ll be speaking at this event in London on Thursday. It would be lovely if you could come along. It’s free!
These seem just about as reasonable as any other CAPTCHA.
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.
An ever-timely call-to-arms from Eric:
Sir Tim Berners-Lee envisioned the web as open and accessible for everyone, no matter where they comes from, what speed their connection is, how capable their browsers are or how good their eyes or hands or both work. I feel proud every day to make that vision reality, and it is the job of web developers to make it a reality.
He’s right. We have tremendous power and privilege, and correspondingly tremendous responsibility.
A behind-the-scenes look at how Gov.uk is handling mobile devices. Spoiler: it’s responsive.
I found this particularly interesting:
When considering the extra requirements users of different devices have we found a lot in common with work already done on accessibility.
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.
My case for the obsoletion of longdesc (Was: 48-Hour Consensus Call: InstateLongdesc CP Update) from James Craig on 2012-09-15 (email@example.com from September 2012)
James Craig is a mensch. This is how you give feedback to a working group.
Why mobile Web accessibility matters - best practices to make your mobile site accessible | mobiForge
There’s some great practical advice for building accessible mobile web apps here.
Bruce’s thoughts on the proposed inclusion of a “content” or “maincontent” element in HTML5.
Personally, I don’t think there’s much point in adding a new element when there’s an existing attribute (role=”main”) that does exactly the same thing.
Also, I don’t see much point in adding an element that can only be used once and only once in a document. However, if a “content” or “maincontent” element could be used inside any sectioning content (section, article, nav, aside), then I could see it being far more useful.
If you make inaccessible iOS apps, you really only have yourself to blame.
There are also some handy tips here for getting to know VoiceOver.
A really nice site dedicated entirely to making the web a better place for the colourblind.
Oh, this is just wonderful: a camera that outputs a text description instead of an image (complete with instructions on how to build one yourself). I love it!
A cautionary tale from Stuart. We, the makers of modern technology, are letting people down. Badly.
We’re in this to help users, remember: not just the ones who think as we do, but the ones who rely on us to build things for them because they don’t know what they’re doing. If your response is honestly “well, he should have spent more on a phone to get something better”, then I’m exceedingly disillusioned by you.
I can’t remember the last time I read something I disagreed with so fundamentally. This sums up the tone of the article:
Accessibility is not a right; it’s a feature.
I do not agree. I do not agree at all.
(Also, the pre-emtive labelling of anyone who may disagree with your point of view as defending a “sacred cow” is as tired and misguided as labelling anyone who disagrees with your viewpoint as a “fanboy”.)
Yes, yes, yes! This article does an excellent job of explaining what Captchas are attempting to do and why, therefore, they are so utterly shit.
This helps to clarify the difference between native semantics and ARIA additions.
This is a great response to my recent post about semantics in HTML. Steve explores the accessibility implications. I heartily concur with his rallying cry at the end:
Given some recent hand-wringing about the web as a “platform,” it seems appropriate to revisit this superb article from Ben. The specifics of the companies and technologies may have changed in the past year but the fundamental point remains the same:
Everything about web architecture; HTTP, HTML, CSS, is designed to serve and render content, but most importantly the web is formed where all of that content is linked together. That is what makes it amazing, and that is what defines it. This purpose and killer application of the web is not even comparable to the application frameworks of any particular operating system.
Andy responds to Joe Hewitt’s recent despondent posts about the web. I tend to agree with Andy: I think comparing the web to other “platforms” is missing the point of what the web is.
See also: http://benward.me/blog/understand-the-web
John reinforces the importance of universal access above the desire to build only for the newest shiniest devices:
Universality is a founding principle of the web. It is the manifesto the web has been built on, and I believe one of the key drivers of the almost unimaginable success of the web over these last two decades. We ignore that at the web’s peril.
A great reminder from Bruce that we need to remember to use cutting-edge web technology responsibly.
Leonie points to a change in the semantics of the a element in HTML5 that could be very handy for accessible navigation.
A cute website that’s a call-to-arms against low-contrast text on the web.
Derek runs some tests on how screenreaders behave when block-level elements are wrapped in links, which is now legal in HTML5.
Ignoring the awful misleading title, this is a really good post from Paul on his personal experiences dealing with accessibility on one or two projects.
A superb post by Dan on the bigger picture of what’s wrong with hashbang URLs. Well written and well reasoned.
A nice succinct description of the placeholder attribute, with an emphasis on accessibility.
This consortium of institutions and universities came together “to provide practical solutions and expertise in digital preservation.”
PLANETS stands for Preservation and Long-term Access through Networked Services.