I like this approach to offering a design system. It seems less prescriptive than many:
Designed not as a rule set, but rather a toolbox, the Data Design Language includes a chart library, design guidelines, colour and typographic style specifications with usability guidance for internationalization (i18n) and accessibility (a11y), all reflecting our data design principles.
The obvious answer to why you should build a website that doesn’t need
jsis… because some people don’t usejs. But how many?!
A handy little script from Aaron to improve the form validation experience.
Though I didn’t make the connection until much later, the philosophy of progressive enhancement in web design, which I’ve been advocating for nearly two decades now, is very much the embodiment of equity. It’s concerned with building interfaces that adapt to a wide range of circumstances, both tied to an individual user’s capabilities as well as those of the devices, networks, and environment in which they are accessing our creations.
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!
I really enjoyed Laurie’s talk in Berlin a few weeks back. I must blog my thoughts on it.
But I must admit that something didn’t sit quite right about the mocking tone he took on the matter of “the fundamentals” (whatever that may mean). Chris shares my misgivings:
Those websites that don’t load on slow connections, or break completely when a JS file fails to load, or don’t work for people with visual or physical impairments?
That’s not an issue of time. It’s an issue of fundamentals.
I think I agree with Laurie that there’s basically no such thing as fundamental technologies (and if there is such a thing, the goalposts are constantly moving). But I agree with Chris with that there is such a thing as fundamental concepts. On the web, for example, accessibility is a core principle of its design that should, in my opinion, be fundamental.
This, basically:
Do I wanna see teenagers building frivolous websites? Absolutely. But when people are getting paid well to build our digital world, they have a responsibility to ensure the right to engage with that world for everyone.
A fascinating account of the history of JAWS and NVDA.
This is why prefers-reduced-motion matters.
This is a terrific resource! A pattern library of interactive components: tabs, switches, dialogs, carousels …all the usual suspects.
Each component has an example implementation along with advice and a checklist for ensuring its accessible.
It’s so great to have these all gathered together in one place!
Another post prompted by my recent musings on writing alt text. This time Michelle looks at the case of text-as-images.
Prompted by my recent post on alt text, Geoff shares some resources on the right length for alt attributes.
The only person who wants a carousel on your site is you. That’s it. It’s a self-serving vanity project so that you can showcase all of your babies at the same time without telling the world which one is your favorite.
“Be linkable and accessible to any client” is a provocative test for whether something is “of the web”.
People are propelled by their interests, and web developers have a lot of space to be interested in all sorts of stuff. For you, it may be JavaScript ‘n Friends, or HTML and CSS. Maybe it’s all that stuff, but put aside your preferences for a moment and answer me this: what are you helping people to do? If the answer involves any remotely routine or crucial purpose, consider putting aside your personal desire for excitement. Instead, make boring things that are usable, accessible, and fast. Ours is a job done by people for people, not a glamorous rockstar gig.
Excellent advice from Jeremy who wants us to build fast, reliable, resilient websites …even if the technologies involved in doing that don’t feel exciting.
Central to that endeavor is recognizing that the browser gives you a ton of stuff for free. Relying on those freebies requires a willingness to not
npm installa solution for every problem — especially those that are best solved with CSS and HTML. Those technologies may seem boring, but boring is fast. Boring is usable. Boring is resilient and fault tolerant. Boring is accessible. When we rely wholesale on JavaScript to build for the web, we’re inevitably reinventing things. At worst, our reinventions of rock-solid HTML features — such as client-side form validation — break in unexpected ways despite our carefully written tests. At best, a flawless reimplementation of those features adds unnecessary code to applications, and depends on a technology less fault-tolerant than CSS and HTML.
Our mental model for how we build for the web is too reliant on canned solutions to unique problems.
This is very perceptive indeed.
Compounding this problem is that too few boot camps are preparing new web developers to think critically about what problems are best solved by JavaScript and which aren’t — and that those problems that are best solved by JavaScript can be solved without engaging in frivolous framework whataboutism. The question developers should ask more often when grappling with framework shortcomings shouldn’t be “what about that other framework?”, but rather “what’s best for the user experience?”.
This is an excellent initiate spearheaded by Nicole and Sarah at Google! They want to fund research into important web UI work: accessibility, form controls, layout, and so on. If that sounds like something you’ve always wanted to do, but lacked the means, fill in the form.
Eric’s response to Chris’s question—“What is one thing people can do to make their website better?”—dovetails nicely with my own answer:
The two real problems here are:
- Third-party assets, such as the very analytics and CRM packages you use to determine who is using your product and how they go about it. There’s no real control over the quality or amount of code they add to your site, and setting up the logic to block them loading their own third-party resources is difficult to do.
- The people who tell you to add these third-party assets. These people typically aren’t aware of the performance issues caused by the ask, or don’t care because it’s not part of the results they’re judged by.
All the talks from this year’s State Of The Browser event are online, and they’re all worth watching.
I laughed out loud at multiple points during Heydon’s talk.
This looks like an excellent (and very reasonably-priced) online event happening on November 12th with three panels:
Do you need a button for your next project but you’re not sure about the right markup? Don’t worry, The Button Cheat Sheet™️ has got you covered.
Spoiler alert: it’s the button element.