Even though it looks like a lot of code, we’re really doing a few pretty standard WordPress things to register and render a custom web component. And, since we packaged it up as a plugin, we can drop this into any WordPress site and start using our component to our heart’s content.
A short while ago, Chrome broke the web by disabling alert(), confirm() and prompt() dialogs from cross-origin iframes… Given Chrome’s near-monopoly control of the browser market, I’m genuinely concerned about what this all means for the future of the web. An ad company shouldn’t have this much influence over something that belongs to all of us. I don’t know how to fix the standards process so that it’s more representative of the diversity of the web’s stakeholders, but I’m increasingly convinced that we need to figure it out.
I wanted to share this guide to designing accessible focus indicators because focus styles are a recurring discussion I have with designers I work with on most projects, so I thought it would be useful to provide this guide as a helpful reference. This guide is aimed at both designers who want to learn about accessibility considerations for designing focus indicators, as well as developers who want to implement them.
In general, I don’t think the question should be whether a component uses its own framework or not. Instead, the question should be: Is this component small enough/fast enough for my use case? After all, a component can be huge without using a framework, and it can be slow even when written in vanilla JS. The framework is part of the story, but it’s not the whole story.