As usual, Jason Grigsby nails it:
Done and done.
This is an excellent post about progressive enhancement from the “technical credit” (as opposed to “technical debt”) point of view.
This is an excellent missive from Nicholas covering the progressive enhancement debate.
First … progressive enhancement isn’t about having a JavaScript vs. JavaScript-disabled experience, it’s about providing the best possible user experience throughout the entire lifecycle of the web application. …
Second, progressive enhancement isn’t a strict prescription, it’s a way of thinking about the software you’re building. … Instead, it encourages you to think more deeply about the problem you’re trying to solve, and guides you towards solutions that work for the maximum number of users.
These two points are why I believe progressive enhancement is as relevant today as it has ever been. The only difference now is that we have more options for improving the user experience than ever before.
I couldn’t have said it better myself.
Accessibility is hard. It’s a broad term encompassing a variety of special needs ranging from low vision and color blindness to motor impairment and language barriers (to name but a few) which means guaranteeing our projects are “100% accessible” is a significant challenge.
Accessibility becomes even more of a challenge when you begin to factor in the dependency chain. Blind and low-vision users, for example, often use screen readers in order to access the Web. With screen readers, we need to consider the capabilities of both the browser and the screen reader being used. If either piece of software isn’t up to the task or contains a bug our users suffer for it.
Getting multiple inter-dependent programs on the same page sometimes requires that we do things we’d rather not do. This post from Steve Faulkner chronicles one such case where the particular versions of Chrome and JAWS required for a project didn’t see eye-to-eye on the semantics of heading levels. He talks about the issue and the less-than-optimal fix he had to put in place to ensure users got the experience they were meant to.
Very clever bit of flexbox here for laying out text optimally when you don’t know its length.
I don’t know that I would consider it a hack so much as pushing flexbox beyond what most people would even consider doing.
I love how Mandy deftly wove progressive enhancement into her content strategy and publishing discussion:
Perhaps ironically, we’ve found that the best way to create that resiliency is by harking back to the web principle of progressive enhancement: each story created in Chorus begins as a platform-neutral collection of text, images, and video. That foundation ensures that we can publish that story as easily to our own platform as to, say, AMP or Apple News, and be confident that our audience will experience that story in a way that fits whichever platform they are using. On our own platform, we’re then free to enhance up, adding stylistic or experiential flairs that elevate the experience of the story. This practice — which I refer to unoriginally as progressively enhanced storytelling — also has the added benefit of helping us make our content more accessible to more kinds of users, especially those with disabilities. (It wouldn’t be inaccurate to consider speaking browsers one among the many platforms we must publish to.)
A hilarious and completely accurate reflection on the cultural similarities shared by JavaScript and crossfire enthusiasts.
Last week, my colleague Nolan Lawson wrote a lengthy post about his struggles with progressive enhancement. In it, he identified a key tension between the JavaScript community and the progressive enhancement community that has, frankly, existed since the term “progressive enhancement” was coined some 13 years ago. I wanted to take a few minutes to tuck into that tension and assure Nolan and other folks within the JS community that neither progressive enhancement nor the folks who advocate it (like me) is at odds with them or their work.