This free day-long online event all about accessibility and inclusive design is happening right now. You can join live, or catch up on the talks that have already happened, like the excellent talks from Russ Weakly and Manuel Matuzović.
The annual day-long online accessibility event is back on September 23rd.
No sign-up. No registration. All sessions are streamed live and publicly on the Inclusive Design 24 YouTube channel.
No matter what time zone you’re in, you can tune in to some excellent-sounding talks tomorrow.
No sign-up. No registration. All sessions are streamed live and publicly on the Inclusive Design 24 YouTube channel.
This gets me right in the feels.
I can’t believe I was lucky enough to contribute to 24 Ways seven times over its fifteen year lifespan!
When people ask where to find you on the web, what do you tell them? Your personal website can be your home on the web. Or, if you don’t like to share your personal life in public, it can be more like your office. As with your home or your office, you can make it work for your own needs. Do you need a place that’s great for socialising, or somewhere to present your work? Without the constraints of somebody else’s platform, you get to choose what works for you.
A terrific piece from Laura enumerating the many ways that having your own website can empower you.
Have you already got your own website already? Fabulous! Is there anything you can do to make it easier for those who don’t have their own sites yet? Could you help a person move their site away from a big platform? Could you write a tutorial or script that provides guidance and reassurance?
I love this use of e-ink to play a film at 24 frames per day instead of 24 frames per minute.
Blogging about what you are working on is is really valuable for the writer because it forces you to think logically about what you are doing in order to tell a good story.
It’s also really valuable to blog about what you’ve learned, especially if you’ve made a mistake. It makes sure you’ve learned the lesson and helps others avoid making the same mistakes.
They let me write a 24 Ways article again. Will they never learn?
This one’s a whirlwind tour of using a service worker to provide a custom offline page, in the style of Going Offline.
By the way, just for the record, I initially rejected this article’s title out of concern that injecting a Cliff Richard song into people’s brains was cruel and unusual punishment. I was overruled.
Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.
Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.
I thought this post from Drew was a great way to wrap up another excellent crop from 24 Ways.
There are so many new tools, frameworks, techniques, styles and libraries to learn. You know what? You don’t have to use them.
Great advice from Una on getting buy-in and ensuring the long-term success of a design system.
24 Ways is back! Yay! This year’s edition kicks off with a great article by Hui Jing on using @supports:
Chances are, the latest features will not ship across all browsers at the same time. But you know what? That’s perfectly fine. If we accept this as a feature of the web, instead of a bug, we’ve just opened up a lot more web design possibilities.
Charlie conducts an experiment by living without JavaScript for a day.
So how was it? Well, with just a few minutes of sans-javascript life under my belt, my first impression was “Holy shit, things are fast without javascript”. There’s no ads. There’s no video loading at random times. There’s no sudden interrupts by “DO YOU WANT TO FUCKING SUBSCRIBE?” modals.
As you might expect, lots of sites just don’t work, but there are plenty of sites that work just fine—Google search, Amazon, Wikipedia, BBC News, The New York Times. Not bad!
This has made me appreciate the number of large sites that make the effort to build robust sites that work for everybody. But even on those sites that are progressively enhanced, it’s a sad indictment of things that they can be so slow on the multi-core hyperpowerful Mac that I use every day, but immediately become fast when JavaScript is disabled.
Some great thoughts here from Francis on how crafting solid HTML is information architecture.
Some really great CSS tips from Rich on sizing display text for multiple viewports.
I really, really like Heydon’s framing of inclusive design: yes, it covers accessibility, but it’s more than that, and it’s subtly different to universal design.
He also includes some tips which read like design principles to me:
- Involve code early
- Respect conventions
- Don’t be exact
- Enforce simplicity
Come to think of it, they’re really good design principles in that they are all reversible i.e. you could imagine the polar opposites being design principles elsewhere.
Ethan demonstrates progressive enhancement at the pattern level using flexbox.
I’ve found that thinking about my design as existing in broad experience tiers – in layers – is one of the best ways of designing for the modern web.
I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:
- The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
- In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
- The next time a user clicks, rather than being sent to the server, the client-side app is in control.
- If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.
YES!!!
Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:
Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.
My contribution to this year’s edition of the web’s best advent calendar.
A superb article by Josh on planning for progressive enhancement—clearly laid out and carefully explained.