Accessibility as craft
It is obvious to give images and videos alternative text. Rauno Freiberg’s Crafting the Next.js Website raises the less obvious case: illustrations built out of HTML and CSS, where a screen reader walks the user through many elements and may still not convey what is on screen. His fix, credited to Adrian, is to set aria-hidden on the inner HTML and write a custom aria-label on the group, so the user reaches one element and gets a description. The Vercel site in What will you ship? applies it everywhere: supplementary visuals are treated as images with role="img", an aria-label that describes just enough relevant detail, and an aria-hidden inner tree, so that illustrative elements are explicitly separated from interactive ones. The pixel icons, drawn in Figma and extracted into matrices by a Ruby script, are rendered to canvas, and the canvas is hidden while the wrapper carries role="img" and a label, because “we treat the icons as images.”
The code block is the essay’s best worked example. The team went over the page with VoiceOver dozens of times, and three problems surfaced: the file icon announced itself as “image”; the copy button described neither its purpose nor gave feedback when pressed; and the line numbers were road blocks of noise that could be mistaken for code. Most fixes were trivial. The icon got aria-hidden, since the file name already includes the type. The copy button got an aria-label. For feedback on copy, an ARIA live region with role="log" and aria-live="polite" carries the visually hidden text “Copied code to clipboard”; the element is hidden visually without display or visibility, which would hide it from assistive tech too. Because the code is complementary to the page, the block is an aside with a label describing what the code does at a high level, so a reader can skip it or dive in.
Line numbers are pseudo elements driven by a CSS counter, and since there is no DOM node you cannot put aria-hidden on one. The answer is the second value of content, which is alternative text for pseudo elements: .line:before { content: counter(line) / ""; } says that nothing should be announced. Combined, the fixes mean a screen reader gets more information not on one page but on every example the component powers, hundreds of them.
Focus is where accessibility turns into a consistency problem. The previous section covered Rauno’s double-shadow focus ring and Discord as the model; the part to carry here is his observation that even the best sites miss, that the difficulty is not one page but a large surface area shared across teams, and that a reliable ring on every focusable thing is the work. Emil Kowalski’s design engineering skill, excerpted in Agents with Taste, adds two rules of the same kind: when small buttons are hard to tap, use a 44px minimum hit area, drawn with a pseudo element; and cap body text at about 65ch so line length stays comfortable to read. Jim Nielsen’s flexbox gap dead zone from the last section is the same rule seen from the other side: the target a person can hit should be at least as big as the thing they see.
Kathryn Gonzalez, who built and led DoorDash’s Design Infrastructure org (design systems, design engineering, prototyping, accessibility), gives the plainest definition of why, in a 2020 interview: accessibility is “a way of thinking and designing so that we’re not only building something that works for the narrow group of people that look like us, but for people with different kinds of mental and physical capabilities and circumstances.” Her 2017 post How to Build a Modal turns that into takeaways from shipping one: consider modal accessibility from the start, treat the WAI-ARIA documentation and examples as your friend, and test on real devices, because her team had tested mobile only in Chrome’s responsive mode and found that overflow: hidden was not enough to stop the body scrolling on iOS. A shared component, she argues, becomes the tool that distributes those practices to everyone who uses it, which is exactly what Rauno’s code block did for hundreds of examples.
Jim Nielsen adds an argument for craft that has nothing to do with delight. In A Sloppy Interface Is a Security Liability (August 2026), prompted by Feross Aboukhadijeh’s talk on the Axios npm phishing attack, which used a fake Microsoft Teams interface of the kind an AI can vibe code trivially, he proposes “interface and interaction design as a security control.” Not everyone consciously notices world-class polish, but some do, and he has always used the quality and care of a digital experience as a heuristic for authenticity and competence. The logic runs the other way too: the easier it is to sloppily reproduce what you sloppily ship, the easier your brand becomes a vehicle for exploiting your customers. “If everything you make was produced from a single prompt, then everyone else is one prompt away from imitating you.” The protection is the stuff that is hard and expensive to fake because it is hard and expensive to notice you need to: micro-interactions, loading behaviour, copy and voice, edge cases. Accessibility work sits squarely in that list.
The Vercel essay names the elements of an interface almost everyone experiences: page speed, legible typography, information honesty, layout stability and scannability, accessible focus states, auditory feedback, and sensible DOM ordering. They are invisible, and so they are the first thing traded away when shipping fast. Take the opposite stance. Label every illustration as one image, give every dynamic message a live region, silence decorative pseudo content, make every focusable thing show its ring, make targets at least as large as they look, and test with the screen reader and on the device, not the emulator.