Live Caption yourself using Azure Cognitive Services and Ably Realtime

Very cool project by Jo Francetti in which she created a live captioning service.

She uses a webpage on a phone to capture her speech — using getUserMedia() — which she then sends over to Azure Cognitive Services’ “Speech to Text” Service to get back the text. The text eventually ends up on the flexible LED display.

Making a wearable live caption display using Azure Cognitive Services and Ably Realtime →

💡 This looks like a perfect use case for the Web Speech API. Unfortunately that API is Chrome only right now …

The difference between aria-label and aria-labelledby

Léonie Watson (@LeonieWatson) explains the difference between aria-label and aria-labelledby:

The aria-label and aria-labelledby attributes are both used to give an element it’s accessible name. The difference between aria-label and aria-labelledby is where they get that piece of text, and the clue is in the name. The aria-label attribute gives an element its label; an element with the aria-labelledby attribute is labelled by something else.

But don’t go adding of them everywhere, as you might not need ARIA (see The First Rule of ARIA) 😉

The difference between aria-label and aria-labelledby

Semantically Identify a Heading Subtitle with ARIA role="doc-subtitle"

Over at CSS-Tricks, Chris takes a look at how to mark up a “Double Heading”, a common pattern where you have a big heading with a little one preceding/succeeding it (as pictured above).

After going over a few options, the answer comes from a tweet by Steve Faulkner: use role="doc-subtitle" for the secondary heading. As per spec:

An explanatory or alternate title for the work, or a section or component within it.

   <h1>Chapter 2 The Battle</h1>
   <p role="doc-subtitle">Once more unto the breach</p>

Oh that’s nice! Support from JAWS/NVDA seems ok so it’s perfectly fine to use.

HTML for Subheadings and Headings →

Making accessible to as many people as possible

With the new Facebook coming soon to all users, the developers saw an opportunity to build a11y in from the start:

To make the new site more accessible, we were able to introduce guardrails right from the beginning, integrate focus management into the core infrastructure, support features that weren’t available when we built the original site in 2004, and build in monitoring and analysis to help prevent regressions as we continue to add new features.

One of the things I like — and something that’s been often discussed, even way before this Github Issue — is the introduction of a generic Heading component. Leveraging React Context, they then render Contextual Headings.

This snippet for example:

  Main heading
     Nested heading
   Nested content

Renders this markup:

<h1>Main heading</h1>
	<h2>Nested heading</h2>
	Nested content

Making accessible to as many people as possible →

React Spectrum – A collection of libraries and tools that help you build adaptive, accessible, and robust user experiences.

By Adobe:

React Spectrum includes three libraries:

  • React Spectrum — A React implementation of Spectrum, Adobe’s design system.
  • React Aria — A library of React Hooks that provides accessible UI primitives for your design system.
  • React Stately — A library of React Hooks that provides cross-platform state management and core logic for your design system.

React Spectrum →

Alternative text for CSS generated content

Great find by Stefan Judis:

Today I learned that the content property supports a way to define alternative text for generated content.

You can specify the alternative content after a /:

.new::before {
 content: url(./img/star.png) / "New!";

Here’s how that works with screen readers:

.new-item::before {
  /* "black star" and element content is read out */
  content: "★";

  /* "Highlighted item" and element content is read out */
  content: "★" / "Highlighted item";

  /* Generated content is ignored and only element content is read out */
  content: "★" / "";

Doesn’t work in Safari nor Firefox at the time of writing though.

The CSS “content” property accepts alternative text →

Guidelines for text fields design

Text fields are probably one of the most used interface components; contact forms, payment details, account creation, lead generation. Users definitely need to interact with text fields when using your product. The purpose of this post is to highlight some of the key guidelines which I follow when it comes to designing better text fields.

It’s pretty basic things that, unfortunately, a lot of people seem to forget.

Guidelines for text fields design →

💵 This linked article is stuck behind Medium’s metered paywall, which may prevent you from reading it. Open the link in an incognito window to bypass Medium’s ridiculous reading limit.

Methods for assigning an accessible name to a form control

Adrian Roselli:

Too often folks will grab ARIA first to provide an accessible name for a thing. Or they may sprinkle hidden content around a form. In most cases the impact of those decisions is unknown. The assumption that they do the same thing, give the same output to all users, is wrong.

In short, here’s the priority he follows when assigning an accessible name to a control:

  1. Native HTML techniques,
  2. aria-labelledby pointing at existing visible text,
  3. Visibly-hidden content that is still in the page,
  4. aria-label.

Good ole’ HTML first, the rule of least power in action 😉

My Priority of Methods for Labeling a Control →

HTML: The Inaccessible Parts

Dave Rupert:

I’ve always abided in the idea that “HTML is accessible by default and then we come along and mess it up. But that’s not always the case. There are some cases where even using plain ol’ HTML causes accessibility problems.

I’m going to start rounding up those HTML shortfalls in this here post as a little living document that I can personally reference every time I write some HTML.

Let this be an actionable list for browser vendors/spec writers to work on.

HTML: The Inaccessible Parts →

You shall not open links in a new window or tab

Something we already knew, but that’s now written down by Adrian Roselli in a nice post:

Regardless of what accessibility conformance level you target, do not arbitrarily open links in a new window or tab. If you are required to do so anyway, inform users in text.

Great to see that the statement is backed by the Web Content Accessibility Guidelines (WCAG):

WCAG Link targets fall under Guideline 3.2: Predictable, and state that web pages must appear and operate in predictable ways. Specifically, Success Criterion 3.2.5: Change on Request states that changes of context (such as new pages or windows) must be initiated only by users and that users can disable them otherwise.

And if you do need to use a new window/tab also add rel="noopener noreferrer" for security reasons.

Link Targets and WCAG 3.2.5 →