
Inclusion can take many forms.
alt
textInclusion can take many forms.
When you’ve worked on the web for as long as I have, you see trends come and go. I’ve witnessed at least three different eras where folks began to put all their eggs in the JavaScript basket, only to realize the massive hits they were taking to performance.
In this piece for WebPageTest, Scott Jehl uses a new “experiments” feature to demonstrate how serving HTML would make a ton of popular websites much, much faster. Some of these companies learned this lesson previously (and even wrote about it) only to have thrown their own advice out the window, which is disappointing.
Serving HTML will always result in faster page loads. There is no way around that. Sending your JavaScript framework to the client and having it render the HTML adds a ton of extra steps:
Compare that to the HTML-first route:
Sure, on subsequent navigations having JavaScript request only the bits and pieces you need is a performance win, but that first render is a beast. And you can totally load that JavaScript later, after the page is rendered.
This piece offers an excellent overview of a handful of common biases and how they can negatively impact our work.
For even more detail (and biases), I highly recommend David Dylan Thomas’ book Design for Cognitive Bias.
Last month, Senator Tammy Duckworth (D-Ill.) and Representative John P. Sarbanes (D-Md.) introduced the Websites and Software Applications Accessibility Act—I’m gonna call it the WS3A for short—simultaneously in the U.S. Senate (S. 4998) and House of Representatives (H.R. 9021) to explicitly bring websites—and other forms of digital media that didn’t exist when the ADA was signed into law—into the purview of the Americans with Disabilities Act (ADA). I am definitely in favor of this effort as it removes the ambiguity that currently exists in U.S. law as to whether websites are governed by the ADA. The WS3A is a reasonable framework, but there is still a lot of work to be done when it (hopefully) passes.
Are you a web professional (or aspiring web professional) who is looking for career guidance and opportunities? Consider applying for my 2023 mentorship cohort.
This post offers straightforward guidance on how to ensure your interactive components are easily understood by people who rely on screen readers and other assistive technologies. And, honestly, Hidde’s authoring guidance is applicable to the main content of your site as well.
Another great post about the combined power of ARIA & CSS to enable your designs from truly semantic markup.
This is an approach I’ve used often with complex interfaces like tabs and it works a treat.
Interesting study of ~2 million Dutch smartphone users reveals how many people are using accessibility features on their phones (and which ones). It’s more than you think.
Another deep dive into details
and summary
, courtesy of Scott. He’s tested so many permutations and edge cases that this is really required reading if you’re considering using this element pairing for progressive disclosure.
<details>
and<summary>
elements are complicated. Saying don’t use them isn’t really practical and there’s a lot of good things about them. But they do have bugs. … It really just all comes down to what sort of experience you want to provide to people, and how OK you might be knowing that the native elements are going to be exposed differently, have different gaps but also different features to them.
A deep dive into color contrast ratios in relation to the A-AAA compliance levels. Why should you care?
Around the world, about 70% of individuals that have a diagnosed disability experience blurred vision. But working towards full compliance doesn’t just help individuals with visual impairments and disorders—it actually creates a better user experience for everyone.