Tags: a11y

180

sparkline

Initial thoughts on standardizing form controls | Greg Whitworth

Greg has done a lot of research into developer frustrations with customising form controls.

My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.

How to Section Your HTML | CSS-Tricks

A deep dive with good advice on using—and labelling—sectioning content in HTML: nav, aside, section, and article.

Drop caps & design systems - Vox Product Blog

Sit down and listen to a story from uncle Ethan.

Baking accessibility into components: how frameworks help

A very thoughtful post by Hidde that draws a useful distinction between the “internals” of a component (the inner workings of a React component, Vue component, or web component) and the code that wires those components together (the business logic):

I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?

An Introduction to ARIA States | a11y with Lindsey

A very useful explanation of the ARIA attributes relating to state:

  1. aria-expanded,
  2. hidden,
  3. aria-hidden, and
  4. aria-current.

Reducing motion with the picture element

Here’s a clever tiny lesson from Dave and Brad: you can use prefers-reduced-motion in the media attribute of the source element inside picture.

Accessible Icon Buttons — Sara Soueidan – Freelance-Front-End UI/UX Developer

Sara runs through the many ways of providing an accessible name to an icon button, backed up with Scott’s testing.

Accessible Color Generator – Learn UI Design

This looks like a really useful tool for generating accessibile colour combinations from a starting colour.

Lighthouse | Eric Bailey

What if accessibility were a ranking signal for Google search results?

Here’s a thought: what if Google put its thumb on the scale again, only this time for accessibility? What if it treated the Lighthouse accessibility score as a first-class ranking metric?

Welcome to Acccessible App | Accessible App

A very welcome project from Marcus Herrmann, documenting how to make common interaction patterns accessible in popular frameworks: Vue, React, and Angular.

Columbia & Elm; Fairfield & Gloucester. — Ethan Marcotte

Coffee talk with Ethan Marcotte. Today’s special: inclusivity.

I want to get there: to have nuanced discussions about text descriptions; I want to read poetry in alt text; to have our work’s success measured by how broadly it can be accessed; to create moving, beautiful experiences for people who may not use the web like I do.

Naming things to improve accessibility

Some good advice from Hidde, based on his recent talk Six ways to make your site more accessible.

Accessibility Events | CSS-Tricks

If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.

Improving accessibility with accessibility acceptance criteria — Paul Hayes

Wouldn’t it be great if every component in your design system had accessibility acceptance criteria? Paul has some good advice for putting those together:

  • Start with accessibility needs
  • Don’t be too generic
  • Don’t define the solution
  • Iterate criteria

Defining Productivity — Jeremy Wagner

We have a tendency in our line of work to assume that what benefits us as developers translates to a benefit for those who use what we make. This is an unsafe assumption.

Building accessible websites and apps is a moral obligation | Go Make Things

  • Morality is not always relative.
  • You’re a web professional.
  • The web is accessible out-of-the-box. We break it.
  • It’s not on people with disabilities to tell you how you screwed up.
  • It should be easier. This is our job.

Accessibility for Vestibular Disorders: How My Temporary Disability Changed My Perspective · An A List Apart Article

This is a fascinating insight into what it’s like to use the web if you’ve got vertigo (which is way more common than you might think):

Really, there are no words to describe just how bad a simple parallax effect, scrolljacking, or even background-attachment: fixed would make me feel. I would rather jump on one of those 20-G centrifuges astronauts use than look at a website with parallax scrolling.

Every time I encountered it, I would put the bucket beside me to good use and be forced to lie in bed for hours as I felt the room spinning around me, and no meds could get me out of it. It was THAT bad.

Apple’s new feature a step towards digital apartheid - Axess Lab

I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid.

A progressive disclosure component - Andy Bell

This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).

Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset

City life | Trys Mudford

Not only does the differentiation of terms create a divide within the industry, the term ‘web app’ regularly acts as an excuse for corner cutting and the exclusion of users.

Straight-talkin’ Trys:

We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.