Tags: accessibility




A plug-in for Sketch that allows you to simulate colour blindnesses and check colour contrasts.

Inclusively Hidden | scottohara.me

Comparing different ways to hide content accessibly:

There are three reasons behind hiding content in an interface, and it’s important to identify what those reasons are, as they will correlate with the appropriate technique needed to hide such content.

  1. Temporarily Hidden Content
  2. Purposefully Visually Hidden Content
  3. Purposefully Visual-Only Content

A Todo List

A great step-by-step walkthrough by Heydon of making an accessible to-do list, the “Hello World” of JavaScript frameworks.

There’s a lot of great knowledge in here that can be applied to plenty of other interface elements too.

The Analog Web | Jim Nielsen’s Blog

This is wonderful meditation on the history of older technologies that degrade in varied conditions versus newer formats that fall of a “digital cliff”, all tied in to working on the web.

When digital TV fails, it fails completely. Analog TV, to use parlance of the web, degrades gracefully. The web could be similar, if we choose to make it so. It could be “the analog” web in contrast to “the digital” platforms. Perhaps in our hurry to replicate and mirror native platforms, we’re forgetting the killer strength of the web: universal accessibility.

Inclusive Components

A great new site from Heydon:

A blog trying to be a pattern library. Each post explores the design of a robust, accessible interface component.

The first component is a deep dive into toggle buttons.

Apple has given my son a hand! – the surprised pessimist

One of the accessibility features built into OS X:

Using Switch Control, and tapping a small switch with his head, my son tweets, texts, types emails, makes FaceTime calls, operates the TV, studies at university online, runs a video-editing business using Final Cut Pro on his Mac, plays games, listens to music, turns on lights and air-conditioners in the house and even pilots a drone!

How Our CSS Framework Helps Enforce Accessibility | eBay Tech Blog

Following on from Ire’s post about linting HTML with CSS, here’s an older post from Ebay about how being specific with your CSS selectors can help avoid inaccessible markup getting into production.

Do we need a new heading element? We don’t know - JakeArchibald.com

Jake is absolutely spot-on here. There’s been a lot of excited talk about adding an h element to HTML but it all seems to miss the question of why the currently-specced outline algorithm hasn’t been implemented.

This is a common mistake in standards discussion — a mistake I’ve made many times before. You cannot compare the current state of things, beholden to reality, with a utopian implementation of some currently non-existent thing.

If you’re proposing something almost identical to something that failed, you better know why your proposal will succeed where the other didn’t.

Jake rightly points out that the first step isn’t to propose a whole new element; it’s to ask “Why haven’t browsers implemented the outline for sectioned headings?”

(I added a small historical note in the comments pointing to the first occurrence of this proposal way back in 1991.)

Accessibility and Performance | MarcySutton.com

When I heard about Universal JavaScript apps (a.k.a. isomorphic JavaScript), despite the “framework hotness”, I saw real value for accessibility and performance together. With this technique, a JavaScript app is rendered as a complete HTML payload from the server using Node.js, which is then upgraded as client resources download and execute. All of a sudden your Angular app could be usable a lot sooner, even without browser JS. Bells started going off in my head: “this could help accessible user experience, too!”

An Introduction to the Reduced Motion Media Query | CSS-Tricks

A new media query that will help prevent you making your users hurl.

Most of the web really sucks if you have a slow connection

Just like many people develop with an average connection speed in mind, many people have a fixed view of who a user is. Maybe they think there are customers with a lot of money with fast connections and customers who won’t spend money on slow connections. That is, very roughly speaking, perhaps true on average, but sites don’t operate on average, they operate in particular domains.

Detecting text in an image on the web in real-time - Tales of a Developer Advocate by Paul Kinlan

The text detection API is still in its experimental stage, but it opens up a lot of really interesting possibilities for the web: assistive technology to read out text, archiving tools for digitising text …it’s all part of the nascent shape detection API.

Improving accessibility in Co-op wills – Digital blogs

Some interesting insights from usability and accessibility testing at the Co-op.

We used ‘nesting’ to reduce the amount of information on the page when the user first reaches it. When the user chooses an option, we ask for any other details at that point rather than having all the questions on the page at once.

Using the aria-current attribute – Tink

The aria-current attribute is very handy and easy to implement. Léonie explains it really well here.

Front-End Developers Are Information Architects Too ◆ 24 ways

Some great thoughts here from Francis on how crafting solid HTML is information architecture.

Accessibility Whack-A-Mole · An A List Apart Article

A fascinating piece by Eleanor on the typographic tweaking that the Wellcome team did to balance the competing needs of different users.

What the Heck Is Inclusive Design? ◆ 24 ways

I really, really like Heydon’s framing of inclusive design: yes, it covers accessibility, but it’s more than that, and it’s subtly different to universal design.

He also includes some tips which read like design principles to me:

  • Involve code early
  • Respect conventions
  • Don’t be exact
  • Enforce simplicity

Come to think of it, they’re really good design principles in that they are all reversible i.e. you could imagine the polar opposites being design principles elsewhere.

FormLinter—Detect common issues that hurt conversions

A little tool for testing common form issues.

  • Did we remember to give every input a label? (No, placeholders are not an adequate replacement)?
  • Do our labels’ for attributes match our inputs’ ids?
  • Did we take advantage of the url, email, and password input types, or did we forget and just use text?
  • Are our required fields marked as such?

Results of the 2016 GOV.UK assistive technology survey | Accessibility

The Government Digital Service have published the results of their assistive technology survey, which makes a nice companion piece to Heydon’s survey. It’s worth noting that the most common assistive technology isn’t screen readers; it’s screen magnifiers. See also this Guardian article on the prevalence of partial blindness:

Of all those registered blind or partially sighted, 93% retain some useful vision – often enough to read a book or watch a film. But this can lead to misunderstanding and confusion