Accessibility

Accessible Text Labels For All

When you navigate this page using VoiceOver, and use the Form Controls menu, you’ll get a list of all form controls on the page, including the Add to Cart buttons.

Quickly scanning these buttons you can tell that they provide very little value, as there is no way to tell which product each button corresponds to. How does a user know which button they want to go to and press if they don’t know which product it corresponds to?

[…]

A popular example of Voice recognition software used to browse the Web is Dragon Naturally Speaking.

[…]

Seeing it in action is the best way to get an idea of how it’s used. So, to quickly demonstrate how it is used on the Web, Level Access created a video demoing Dragon Naturally Speaking to fill out a form on a page. The following video is a short clip from their video which you can find and watch in full on [YouTube].

 

When the dragon user (in the video) wants to select a form control, he speaks out the visual text label of that control. This is one of many reasons why visual labels are important in user interfaces.

So when we have a series of Add to Cart buttons, a dragon user will speak the label of the button in order to interact with it. This is why adding text in the middle of the string makes it inaccessible. The content in the middle of the string would break the visible label. The user would be telling dragon to interact with a button whose label is not what it visually appears to be.

[…]

So whenever you need to add additional text to a visible label, it best come after what’s visually shown.

Similarly, always ensure the accessible name (announced by screen readers) matches the visual label as much as possible. This means that you’ll also want to avoid adding a label using aria-label that does not match the text label that is shown on a control.

Screen reader order of precendence for interpreting content

Whether you build a widget as a web component using standards, Vue, React, or any other framework, or with a combination of HTML and JavaScript, screen readers that encounter your widget will look for clues in the rendered markup to discern what it is and tell users that they’ve encountered a search box, menu, or carousel.

Screen readers generally follow this order of precedence:

  1. Look for explicitly set ARIA attributes (roles, states, properties), and in the absence of those:
  2. Interpret any implicit roles from markup semantics (form elements, paragraphs, lists, etc).
  3. Read any text available in the markup.

If no discernable semantics exist (think ARIA-less <div> or <span> tags), it skips to #3. So when you omit ARIA, you’re rolling the dice on whether users will understand that your <ul> is a menu and not simply a list. When you omit ARIA and semantic tags, you’re leaving it up to your users to figure things out (and potentially abandon your product because it doesn’t work).

Focus rings on Discord

This is a fascinating deep dive by the people at Discord on their development of a focus ring component and all the problems they had to overcome:

Browsers implement default focus rings that apply to all elements, but the ability to style these is (currently) very limited. These rings, while they have recently improved greatly in Chrome and Edge, are also not very pleasant when integrated with the rest of Discord’s design, and other browsers like Firefox are almost entirely invisible in most cases due to the thinness and low contrast of their styles.

As such, we want to implement a custom focus ring style. At a glance, this seems relatively simple, but when dealing with the variety of use cases Discord has for these rings, the list of requirements quickly grows, and the options for implementations shrink.

Ideally, we want to match the browser’s focus ring behavior exactly. Within Discord, this means that a comprehensive focus ring implementation needs to:

  • Perfectly map to the element that has focus (with exceptions listed below).
  • Follow elements as they move when containers scroll.
  • Follow elements as they animate and transition within the document.
  • Not be clipped off when the focused element is bounded by overflow: hidden or other bounding techniques.
  • Respect occlusion of overlapping elements, but not be occluded by an element’s own z-index.

Additionally, to be able to implement pleasant and overall better focus styles for various elements in the app, we have additional requirements to be able to:

  • Apply the focus ring on a different element than the actual focused element
  • Provide positional offsets to adjust ring placement around the element.
  • Adjust ring styles to match the look and feel of the surrounding context (could include changing border radius, color, shape, and more)
  • Specify a style for when focus is within an element, for example to indicate the bounds of a widget.

See the source link for the rest.

Building Flexible Components With Transparency

I sometimes forget that transparent colours can solve certain contrast and design issues like the following:

Three boxes with light grey borders, the third of which is placed against the same light grey, causing the box's border to disappear due to lack of contrast.

The panel is using a subtle gray (#ddd) to draw a border between its contents and the surrounding page. But when the page background gets closer to #ddd, the design doesn’t work as well.

Using transparency, we can keep the same effect on white backgrounds while ensuring increased contrast on other backgrounds. Here I use a black color set to 0.135 opacity instead: rgba(0, 0, 0, 0.135). This matches #ddd on white backgrounds but automatically appears darker on other backgrounds:

Three boxes with light grey borders, against progressively darker grey. The borders are transparent, so they add their grey with the background, thus retaining contrast.

This technique also works well on lightly colored backgrounds. The panel will pick up the underlying colors and display them through the transparent black:

Three boxes with light grey borders, against different coloured backgrounds.

Accessibility issues with toasts and how to mitigate them

You may have recently read Adrian Roselli’s Scraping Burned Toast, Chris Coyier’s summary of the current “toast conversation”. Or maybe you’ve browsed the GitHub repository for A Standard ‘Toast’ UI Element and its WICG discussion thread.

Or maybe you’re familiar with the concept of toasts from Android development and Material Design.

But regardless of how familiar you are with the concept of a “toast”, work has been progressing on try to pave the existing cow paths different UI library definitions have set for said potential component. Unfortunately, the level of concern given to the accessibility and inclusive UX of a toast component varies quite a bit, depending on which component library you review.

[…]

Defining a toast

[…]

At a high level, toasts should be used to indicate the completion of a task or process initiated by the user or the application itself. For instance, a notification verifying the saving of a file, that a message had been properly sent, or a that a meeting was about to start.

If someone were to ignore, or miss a toast message, due to its timed display, there should be no negative impact on their current activities or the status that the message conveyed. Using the previous examples, ignoring a toast message would still mean that a file was saved, that a message was sent, or that a meeting was about to start.

[…]

Inclusive UX of a toast

A toast component should be considered a type of status message, and thus should be given a role="status". This will ensure that when a toast is displayed on screen, its contents will be, politely, communicated to assistive technologies, such as screen readers.

Ideally, a toast component should contain no interactive controls, as by doing so an immediate divergence of inclusive UX is introduced.

 

See the source link for a list of issues and some ways to mitigate them.

How My Brain-Damaged Mother Changed How I Look at Interface Design

My mom is an O.G. console cowgirl, a real-life hidden figure. Working for Ma Bell in the early ’70s, she was responsible for administrating some of the most powerful computers then in the country, the ones that drove our telephone systems. “I’m one of only seven people who know how to program these,” I remember her once bragging as she swept her hand across a clean room the size of an aircraft hanger filled to the ceiling with blinking, whirring mainframes.

But Sally Brownlee isn’t so good with computers anymore. Last March, she was hit by a car while walking her dog. Everyone survived, but Wally lives with another family now (he’s happy; I hear they have a beach house), and as for Mom, who suffered permanent brain damage, she’s not the same in innumerable ways. But in no way is the change more quantifiable to me than when I watch her stares uncomprehendingly at the keyboard of her laptop, or try and fail to use her iPad for the umpteenth time. This woman’s technical expertise launched a billion phone calls, yet now, she is routinely thwarted by what many hail as one of the most accessible UIs on the planet.

[…]

[T]he older we get, the more we act like we’re cognitively disabled: Again, according to Nielsen, people’s ability to use websites effectively declines 0.8% every year over the age of 25.

“It happens naturally,” [Lisa Seeman, a member of IBM Accessibility Research and the editor of the World Wide Web Consortium’s standards for making designs for individuals with cognitive disabilities] explains. “We get older, and even without having something like dementia, we become less capable of figuring new things out.” And this isn’t true only for seniors. Cognitive ability is a spectrum, not a binary switch: It goes down when you’re stressed, tired, depressed, hungry, or in pain. “Everybody has the same cognitive impairments when they’re stressed or depressed,” Seeman says.

In other words, cognitive accessibility isn’t just relevant for people with brain damage, like my mother. It’s relevant to everyone, from people with migraines to neophytes in emerging markets who don’t have software translated yet into their local languages.

[…]

So what’s the answer? A system-level toggle you flip to tell software you’re cognitively disabled, which then dumbs down your interfaces accordingly? Nothing so gauche, laughs Seeman. Where the industry needs to go, she says, is dynamic UIs: Interfaces that aren’t built on an assumption of computer literacy but adjust to a user’s capabilities in real time. “What we need are interfaces that meet the user where they already are,” she says.

An Alphabet of Accessibility Issues

A is blind, and has been since birth. He’s always used a screen reader, and always used a computer. He’s a programmer, and he’s better prepared to use the web than most of the others on this list.

B fell down a hill while running to close his car windows in the rain, and fractured multiple fingers. He’s trying to surf the web with his left hand and the keyboard.

C has a blood cancer. She’s been on chemo for a few months and, despite being an MD, is finding it harder and harder to remember things, read, or have a conversation. It’s called chemo brain. She’s frustrated because she’s becoming more and more reliant on her smart phone for taking notes and keeping track of things at the same time that it’s getting harder and harder for her to use.

See the source for the rest.

Brutalist Web Design

The term brutalism is often associated with Brutalist Architecture, however it can apply to other forms of construction, such as web design.

[…]

The term brutalism is derived from the French béton brut, meaning “raw concrete”. Although most brutalist buildings are made from concrete, we’re more interested in the term raw. Concrete brutalist buildings often reflect back the forms used to make them, and their overall design tends to adhere to the concept of truth to materials.

A website’s materials aren’t HTML tags, CSS, or JavaScript code. Rather, they are its content and the context in which it’s consumed. A website is for a visitor, using a browser, running on a computer [or mobile device] to read, watch, listen, or perhaps to interact. A website that embraces Brutalist Web Design is raw in its focus on content, and prioritization of the website visitor.

Brutalist Web Design is honest about what a website is and what it isn’t. A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

They list the following principles: