Skip to main content

Tagged “accessibility”

A Global Design System, by Brad Frost

Hard to argue with Brad’s logic.

Right now, vast numbers of human beings are devoting their time and energy to designing, building, documenting, and maintaining the exact same set of common components.

Our efforts to reduce duplicative work at the individual level are resulting in duplicative work at the inter-organization level.

A Global Design System would improve the quality and accessibility of the world’s web experiences, save the world’s web designers and developers millions of hours, and make better use of our collective human potential.

Invisible success, by Eric Bailey

Here’s Eric Bailey with some very relatable thoughts on the need to tell design system stories even though it’s difficult.

The component works. And because it works, nobody pays attention to it.

This is the promise of a design system made manifest: Consistent, quality experiences for complicated interactions, distributed at scale with minimal fuss.

This is objectively great. The problem, however, is how we talk, or fail to talk about this type of success.

Component specifications, by Nathan Curtis

Nathan on how complex components require comprehensive specifications rather than ill-advised assumptions, and how Figma can be used to guide engineers to reliably build such components.

I’m still amazed when designers schlep together a few pictures, publish a configurable Figma component, point their developer counterparts at the main component and say “Use Figma’s inspect tool.”

Things have changed. Components are more complicated. Designers are delivering to many different developers. Accessibility has risen to the fore. For design systems that scale, teams are finding it necessary to write down all the details again.

No Style Design System

Adam Silver’s collection of accessible form-related components – a companion to his book Form Design Patterns – is a brilliant reference.

Use Mac Zoom to show the text a screen reader gets

I picked up a good accessibility testing tip from my work colleague Max today.

On a Mac, if you open System > Accessibility > Zoom, you can enable “hover text”. This allows you to hold down command (cmd) and then whatever is under the mouse will be shown. This shows the same text that a screen reader sees so it’s good for checking if bits of the page respond to a screen reader.

Accessible interactions (on Adactio)

Jeremy Keith takes us through his thought process regarding the choice of link or button when planning accessible interactive disclosure elements.

Progressively enhanced JavaScript In Real Life

Over the last couple of days I’ve witnessed a good example of progressive enhancement “In Real Life”. And I think it’s good to log and share these validations of web development best practices when they happen so that their benefits can be seen as real rather than theoretical.

Assistiv Labs

A tool for testing how accessible your experience is on various assistive technologies – perhaps “like BrowserStack but for screen readers”?

Assistiv Labs remotely connects you to real assistive technologies, like NVDA, VoiceOver, and TalkBack, using any modern web browser.

A11y is not “extra effort for people with disabilities”

Strong agree with these sentiments regarding accessibility expressed by Max Böck and Andrey Okonetchnikov on Twitter.

From Andrey:

If you’re building UI, it’s your responsibility to make it work for everyone. Clients often tell me “we don’t care about accessibility” but in reality they do want keyboard support at the very least. So I just build my UI in a way it works without discussing it. It’s my job.

How-to: Create accessible forms - The A11Y Project

Here are five bite-sized and practical chunks of advice for creating accessible forms.

  1. Always label your inputs.
  2. Highlight input elements on focus.
  3. Break long forms into smaller sections/pages.
  4. Provide error messages (rather than just colour-based indicators)
  5. Avoid horizontal layout forms unless necessary.

When there is no content between headings

Hidde de Vries explains why an HTML heading should never be immediately followed by another.

When you use a heading element, you set the expectation of content.

See all tags.

External Link Bookmark Note Entry Search