Accessibility

There are no console errors for malformed ARIA. There’s also no alert dialog, beeping sound, or flashing light for your operating system, browser, or assistive technology. This fact is yet another reason why it is so important to test with actual assistive technology.

When it comes to running a workshop, 30 people is a large group. So, let's imagine you somehow managed to cram all of the material into a single half-day workshop, and you run it with large groups of 30 people, twice per day, 7 days per week. To get through our low-balled figure of 600 people, it would still be 9 months! That's 3 months more than you'll likely be employed for, and that's not including any coordination, scheduling, prep-time, write-up time, iteration time or specific actions that come from the workshops themselves.

What I found back then was that aria relationship attributes didn’t work when an element being referenced was outside the shadow DOM and the element referencing it was inside the shadow DOM, ditto for the opposite. It was same story for native HTML relationships as well. Fast forward to 11 years later, as in now! 2025, and the situation remains the same.

You could use standard HTML controls without all that stinking DOM darkness and encapsulation fandango fucking up your relationships. Defy the JavaScript industrial complex by any means necessary If this is not an option, then there are some ways you can work around these issues in some cases. A relatively simple example is provided:

Please, if your team cannot explain how the thing satisfies all WCAG Success Criteria at Level AA, then don’t release the thing. If the thing is a new feature for the web platform (HTML, CSS, ARIA, SVG, etc.), then don’t even propose the thing until you have its WCAG conformance sorted.

This talk, article, is for anyone who’s ever said “we need to make this accessible,” and got ignored, brushed off, or told, “We’ll do that later.” If you’re not in a leadership role, if you’re not officially “the accessibility person,” but you still want to drive change, this is for you.

So, there you have it. CSS Carousels are highly experimental, not currently accessible, and therefore, not ready for production.

building the theme has been a delicate balance of trying to manage merchant expectations with creating an accessible user experience.

Our marquee component has a pause button, respects the user preference for reduced motion, only enables focus for the first unique instance of a link, and only announces the first instance of the text. While there are certainly things that I think can be improved, a huge amount of effort was put in to make sure that disabled users would not be blocked by it. Marquees are not great for accessibility, but one that has considered accessibility is certainly better than one without.

NOBODY is saying that automated tools are not useful, only that they cannot provide comprehensive coverage of WCAG 2.2 criteria.

Many standards, especially in the last decade, don’t just streamline implementation: They open up whole new creative possibilities! CSS grid and subgrid, high-gamut color, container queries, scroll-driven animations, view transitions, color schemes and more!

Some of these ideas make it into design tools, but the wait can be long… understandably so, making interfaces for this stuff is hard! By the time Figma introduced their flexbox equivalent, the more powerful CSS Grid was already years into baseline availability.

Most HTML elements want to Elasti-Girl their way through any viewport size.

And can we talk about the awesomeness that is dev tools? In any modern browser, developers (or curious nerds of any discipline) can inspect every size, color and property of every single element of the page without any additional effort from the designer. Super-powered design specs, absolutely free.