CSS and accessibility both arrived at an inflection point this week. Browser APIs are maturing across vendors, but underlying platform inconsistencies still trip up production use. Meanwhile, accessibility tooling is scaling exponentially as regulation and AI adoption accelerate, even as organizational commitment remains inconsistent.
What's !important #17: Custom Highlight API, CSS Navigation Matching, Fixing text-stroke, and More
The CSS Custom Highlight API now has cross-browser support, letting you style arbitrary text ranges without DOM manipulation. This matters for search highlighting, collaborative editing cursors, and syntax highlighting that won't break selection behavior. The paint-order fix for text-stroke rendering is equally practical: strokes now render underneath text instead of on top, preventing clipping.
::highlight(search-results) {
background-color: yellow;
color: black;
}
.outlined-text {
-webkit-text-stroke: 2px black;
paint-order: stroke fill;
}Axe-core at 5 billion: Accessibility meets the moment
Axe-core downloads tripled in a year to 10 million per day, driven by global accessibility enforcement (European Accessibility Act, Canada's enhanced phase, Australia's WCAG 2.2 Level AA) and AI agents now using it for testing. The post rightly emphasizes that automated testing catches only baseline issues; true compliance requires purpose-built tools and manual review. Regulation is forcing accessibility into CI/CD pipelines, but the tooling gap between "no obvious violations" and "usable by real people" remains wide.
A Model for WordPress Accessibility
Adrian Roselli's 2019 proposal for a funded WordPress accessibility team reads like a case study in organizational failure. Gutenberg required a 329-page accessibility audit, yet Automattic (a billion-dollar company) continued relying on volunteer labor instead of hiring experts and integrating WCAG compliance into development. Updates through 2026 show nothing changed; WordPress's founder eventually dismissed the accessibility team's authority entirely. This is what happens when platform stewardship treats accessibility as optional overhead instead of foundational infrastructure.
Dark mode toggles: two states are enough
Lea Verou argues that light/dark toggles don't need a third "system" option if you default to prefers-color-scheme and let users override when clicked. The simpler UI reduces cognitive load and matches user intent better than three-state controls. Commenters push back that explicit three-state controls make the current mode clearer, which matters for settings panels. Both perspectives hold for different contexts; navigation chrome benefits from simplicity, settings screens from explicitness.
Under-Engineered Comboboxen?
The native <datalist> element looks promising but breaks in production: completely non-functional in Firefox Android, options disappear in landscape mode on Chrome Android, no zoom support for the list, inconsistent voice control. Screen readers mostly work, but mobile bugs and cross-browser divergence mean most teams should avoid datalist until browsers converge. This is the web platform's eternal tension: native elements promise simplicity but ship half-baked, forcing teams back to custom implementations.
The week's reads share a theme: tooling and standards are advancing, but gaps between specification and reliable implementation (or organizational commitment) still define what ships. Accessibility testing scales to billions of downloads while foundational platforms ignore it structurally. CSS gets powerful new APIs while native HTML elements remain unreliable across browsers.