After years and years of successive abstractions, we have prioritised the comfort of the person writing the code over the survival and agency of the people using it. Innovation that excludes people isn’t innovation; it’s just shiny exclusion.

I’d feel better if the CSSWG did a better job of outlining risks and best practices, at least beyond stale WCAG links and suggestions that user style sheets are the best approach to get around forcing animations on users. Granted, the CSSWG had shown a certain amount of ignoring the Priority of Constituencies of late, so I’m also not terribly surprised.

Empowering humans to communicate in a more accessible way prevents the problem at its source, avoiding the need to rely on expensive, unreliable machines to try and patch it in real-time afterwards.

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.

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.