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 →

Debunking the Myth: Accessibility and React

Mark Steadman from Deque:

React can be an accessible application framework with the right knowledge and the right know-how. The stigma that it is not an accessible framework is simply not true. It has some of the best built-in accessibility functionality there is out there, and a large community of accessibility advocates that are creating content that is easily consumable in your application.

As Chris Coyier said it:

React didn’t use a <div> for a <button>, you did. React didn’t force extra markup all over the page when you decided to not use a Fragment. React didn’t forget to change the title of the page because that was something you neglected.

Yes! Yes! Yes! … A thousand times YES!

I see many (new) devs enter the JS game to just start throwing things around, totally unaware of (or even worse: neglecting) the foundation layers which JS enriches: HTML and CSS. It all starts with HTML and semantics — many unfortunately tend to forget this.

With a huge chance of sounding like a skipping record regarding this: go read Jeremy Keith’s post “Robustness and least power”. In said post he quotes Derek Featherstone who said:

In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.

Data attributes & progressive enhancement by Derek Featherstone

Embrace the platform, folks.

Debunking the Myth: Accessibility and React →

Why <details> is Not an Accordion

Dave Rupert on why that (wonderful) way of Using the <details> element to create modals and menus is not good for semantics.

Because <summary> has role="button", it eats the semantic content of elements inside it.

So that big <h1> inside of your <summary> becomes just another piece of text, sans semantics.

I especially like this part of his post too:

At the risk of being a broken record; HTML really needs <accordion>, <tabs>, <dialog>, <dropdown>, and <tooltip> elements. Not more “low-level primitives” but good ol’ fashioned, difficult-to-get-consensus-on elements. A new set of accessible controls for a modern era…

Why <details> is Not an Accordion →

💁‍♂️ FYI: We already have a <dialog> element, as detailed here. At the time of writing it is supported in Chrome (by default) and in Firefox (behind a flag). A polyfill is available.

Making a Better Custom Select Element

24ways – the advent calendar for web geeks – is back! First post is “Making a Better Custom Select Element” in which Julie Grundy tries to create an accessible Custom Select Element:

Sometimes, I can’t recommend the select input. We want a way for someone to choose an item from a list of options, but it’s more complicated than just that. We want autocomplete options. We want to put images in there, not just text. The optgroup element is ugly, hard to style, and not announced by screen readers. The focus styles are low contrast. I had high hopes for the datalist element, but although it works well with screen readers, it’s no good for people with low vision who zoom or use high contrast themes.

Here’s a pen with the result:

Making a Better Custom Select Element →

Indicating focus to improve accessibility

Great article by Hidde. It totally rhymes with my Building Better Forms™ by not taking away affordances post.

It’s a common, but fairly easy-to-fix accessibility issue: lack of indicating focus. In this post I will explain what we mean by focus and show you how focus outlines make your site easier to use.

Indicating focus to improve accessibility →

Accessible Icon Buttons

Sara Soueidan:

An icon button is an icon that triggers some sort of action on the page. More accurately, technically speaking, an icon button is a button that contains an icon and no (visible) accompanying text.

Putting aside the UX side of the coin and whether or not an icon alone is enough to convey meaning and functionality to users, many implementations of these buttons today lack the proper accessibility that makes them meaningful to users of assistive technologies.

Sara gives us 5 techniques to solving this.

Accessible Icon Buttons →