Accessibility

The first thing I noticed when reading his piece is that how he experienced the term is different from how I have. Which means we’re off to a good start. 😃

So, let’s address the myth head-on. Accessibility does not limit your color palette choices. What feels limiting is often a lack of knowledge about WCAG color contrast, how to build accessible color palettes in tools like Figma. And sometimes, a lack of creativity.

When something conforms to a standard, it “meets” or “satisfies” specific requirements in a standard.

Organisations can comply with regulation, for instance the laws and regulations that EU Member States adopted following Directive (EU) 2019/882, the European Accessibility Act.

We can build UI components with accessibility in mind. We can also document accessibility specifics alongside them. Both are helpful and recommended. What about claiming conformance? In this post, I'll talk about how WCAG doesn't allow for that, and why I believe that's a good thing.

The Accessibility Maturity Snapshot is a high-level self-assessment tool designed to help you understand your level of digital accessibility readiness and implementation.

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.