js;dr is JavaScript required; Didn’t Read.
Pages that are empty without JS: dead to history (archive-org), unreliable for search results (despite any search engine claims of JS support, check it yourself), and thus ignorable. No need to waste time reading or responding.
Also known as, if it’s not curlable, it’s not on the web.
Visually-hidden styles are used to hide content from most users, while keeping it accessible to assistive technology users.
It works because the content is technically visible and displayed — it appears in the accessibility tree and the render tree, both of which are used by assistive technologies — it’s just that the rendered size is zero.
Our industry has largely settled on a standard CSS pattern for this, refined over years of testing and iteration, by many people. This pattern:
.visually-hidden {
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}
[…]
This article is not about when or why you would use visually-hidden content. There’s a number of excellent articles that discuss these questions in detail, notably Scott O’Hara’s Inclusively Hidden. But most of them don’t go into much detail about the specific CSS involved — why do we use this particular pattern, with these specific properties? So today I’m going to dissect it, looking at each of the properties in turn, why it’s there, and why it isn’t something else.
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:
- Look for explicitly set ARIA attributes (roles, states, properties), and in the absence of those:
- Interpret any implicit roles from markup semantics (form elements, paragraphs, lists, etc).
- 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).
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.
There are plenty of stories floating around about how some organization improved performance and suddenly saw an influx of traffic from places they hadn’t expected. This is why. We build an experience that is completely [unusable] for them, and is completely invisible to our data. We create, what Kat Holmes calls, a “mismatch”. So we look at the data and think, “Well, we don’t get any of those low-end Android devices so I guess we don’t have to worry about that.” A self-fulfilling prophecy.
I’m a big advocate for ensuring you have robust performance monitoring in place. But just as important as analyzing what’s in the data, is considering what’s not in the data, and why that might be.
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.
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:
The Pale King, the late David Foster Wallace’s final novel, was published in 2011. It’s about IRS employees in Peoria, Illinois
And it’s incredibly boring.
I’m not being cruel — The Pale King contains an intricate description of a traffic jam, a long list of tax forms, and an entire chapter devoted to mundane office tasks. As Michael Pietsch, the book’s editor notes, “David set out to write a novel about some of the hardest subjects in the world — sadness and boredom.”
Defending boring UX is a slightly easier task. I just want to get you excited about the invisible, unsung work required to build useful and understandable digital products that truly satisfy user needs.
Boring defined
Boring user experience is clear and straightforward content, design, and code that solves key pain points. No surprise. No delight. It’s the non-design of IA Writer or the simple poetry of plain language.
Unboring is an error message that requires a PhD to unpack or Microsoft Word’s everything-plus-the-kitchen-sink approach to software.
[…]
Boring UX emerged in 2012 with the launch of GOV.UK, a government site that proved straightforward digital design can improve the lives of millions of people. As the jury who awarded the site Design of the Year 2013 put it, “It may not look particularly exciting or pretty, but that is not the point. This is design in the raw, providing vital services and information in the simplest, most logical way possible.”
[…]
Boring doesn’t always save lives, but it usually improves them. The titans of the web — Wikipedia, Reddit, Google, Amazon, Dropbox, GitHub — look boring when compared to Snapchat, The Outline, or Bejeweled. But boring companies have millions of repeat users because their products actually work.
[…]
“Only when a product is functional, reliable, and usable can users appreciate the delightful, pleasurable, or enjoyable aspects of the experience,” notes Fessenden. In other words, boring underpins delight — and sometimes boring is delightful. Popular apps like Pocket and Instapaper, along with Safari’s reader view, turn exciting into boring by rescuing content from the evil clutches of hyperactive design and indestructible retargeting ads.
[…]
If you’re truly user-centric, admit that the most meaningful life stuff happens beyond the borders of tiny glowing rectangles. UX folks are brokers and intermediaries, not rock stars or ninjas. Your job is to swallow some boredom so people can live better lives.
And if that sounds a bit dreary, remember the words of David Wallace in The Pale King: “If you are immune to boredom, there is literally nothing you cannot accomplish.”
