There are some great hands-on accessibility patterns in this talk transcript from Scott.
A plug-in for Sketch that allows you to simulate colour blindnesses and check colour contrasts.
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.
- Temporarily Hidden Content
- Purposefully Visually Hidden Content
- Purposefully Visual-Only Content
There’s a lot of great knowledge in here that can be applied to plenty of other interface elements too.
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.
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!
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.
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?”
A new media query that will help prevent you making your users hurl.
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.
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.
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.
aria-current attribute is very handy and easy to implement. Léonie explains it really well here.
Some great thoughts here from Francis on how crafting solid HTML is information architecture.
A fascinating piece by Eleanor on the typographic tweaking that the Wellcome team did to balance the competing needs of different users.
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.
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?