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: hiddenor 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.
Little #a11y tip for you: If you are using a status message bar, you’ll want it to be a live region. But it should aslo be discoverable in case the messages are missed when they’re announced. Good case for an
<aside>:<aside aria-live="polite" aria-label="Status"> ... </aside>
I sometimes forget that transparent colours can solve certain contrast and design issues like the following:
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
rgba(0, 0, 0, 0.135). This matches
#dddon white backgrounds but automatically appears darker on other backgrounds:
This technique also works well on lightly colored backgrounds. The panel will pick up the underlying colors and display them through the transparent black:
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.
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.
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.
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.
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.
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:
For years, we studied teams rolling out new designs, to see if we could mitigate negative reaction to new releases and design changes. We studied hundreds of product and service rollouts. We watched and learned from the reactions of thousands of users.
When we dug into what those users’ reactions [were], patterns emerged. The users told us the changes inconvenienced them. They had no idea the change was coming and suddenly it was in their face. Users were upset because they were surprised.
They also told us the old version worked fine. Even when it took a while to get comfortable, they learned it. Many users mastered difficult-to-use designs.
Everything was different when the new version arrived. What they’d mastered before didn’t help them now. The company said it was an improved design, but they couldn’t see the improvements. Why should these users learn something new that doesn’t help them? Users were upset because they couldn’t see the value.
We also saw many instances where users didn’t react negatively to changes. Often, they didn’t react at all. We saw new designs that didn’t affect the users’ behaviors and they didn’t pay attention to it.
In these cases, the changes were often not noticeable. Sometimes the changes were small and isolated. Yet, we also saw users seemingly not notice several updates with extensive changes. (In more than one instance, an entire application’s infrastructure had been rewritten without a single user noticing.)
In cases when the design changes were noticeable, the designers gave the users control to switch when they wanted. The designers showed why the change was valuable to the users. And the designers made the transition easy by taking the knowledge and experience their users already had with the product into account.
There are many design considerations for making your content more accessible to all. Some things to think about and build into your design workflow include:
- Choose a common font that most users have encountered before.
- The “serif vs. sans-serif debate” is not a huge deal if you choose a common font family or one that has unique characters.
- Avoid specialty display fonts or font families that are not unique (ex. letters or numbers that could mirror each other).
- Your fonts should have a minimum size of 14px (ideally more) and when coded should use relative values.
- Pay attention to color and contrast! Use tools to check the ratio between the text and background and be wary of gray.
- Don’t rely on color alone to signify information (ex. “click on the red button”).
- Clearly define paragraph and letter spacing.
- Do not let the overall width of the content exceed 80 characters (40 characters for logograms).
- Avoid paragraph alignment (such as justified) which creates whitespace within the content.