But it's not just what technologies they use, but what technology we even consider a part of a stack. What full-stack means morphs over time. We're in a place right now where knowing JavaScript grants you a full-stack merit badge. You can work with client site frameworks, architect components and piece them together to build an entire front end. You can write web servers. You can write back-end code that talks to APIs. You can do all the state management you need. You can construct build processes and deployment pipelines. You can even bring CSS into JavaScript if you're so inclined.

While the seemingly popular aria-label is a perfectly valid way to add an accessible name to a button (and/or other components), it is certainly not the only way, let alone the best. You could always just put text in it, for example. But what if the designer or the UI enforces the absence of visual text next to an icon? There is a handful of ways that an icon button can be implemented accessibly. This article is an overview of them all.

Continuing a series on the display property in CSS, this time Rachel Andrew takes a look at what happens when you use grid as a value of display, with added information about how subgrid changes that behavior.

This bookmarklet hides the content of the page, and shows a quick guide to using VoiceOver. It’s designed to help you learn how to use the basics of VoiceOver, which can help you design and build your service to better meet the needs of screen-reader users.

The main point that I think hasn’t really been communicated enough is that icon fonts exist in a place that would seem to be outside of the web standards mainstream. Specifically, the font loading poster child—the font-display descriptor—has no valid value that is compatible with icon fonts.

When you load an icon font, you often never want the fallback text to render. It isn’t a typical Flash of Unstyled Text (FOUT) scenario. If the fallback text for an icon font renders, who knows what you might see.