Progressive

Ethan Marcotte wrote this on Twitter on Monday:

Nostalgia for the heyday of web design has to be balanced with the knowledge that much of what we did “in the old days” was woefully, thoroughly inaccessible. We should acknowledge what an era did well, sure. But we need to be critical and clear-eyed about what it didn’t do well—and whom it excluded.

Inclusive design has come a long way. Of course, we still need to do much, much better. Even in 2020, the vast majority of websites still isn’t accessible. But at least, there seems to be a raised awareness for the topic within the web community. In the last few years, several books, articles, talks, and even whole conferences around inclusive design have certainly left their mark. Many of us now know that the privilege of building websites comes with the responsibility to build websites for everyone and, in this way, to provide access to technology for everyone.

Access to technology for everyone doesn’t come easy, though. As Ethan points out, “in the old days”, websites were highly inaccessible. The Flash era didn’t do much to improve accessibility on the Web either. Screens readers can scan linear, static HTML, but the dynamic, constantly changing nature of Flash sites made it almost impossible to optimize a Flash site so that a screen reader user would have a valuable experience. Besides that, Flash websites often also needed a lot of bandwidth and at least a decent CPU to run smoothly. And because you basically could do anything in a Flash movie, people did everything: There were no rules, no standards, no patterns, no fallbacks.

The progress we have nevertheless seen over the last two decades is the result of an ever-growing number of people pushing hard against the status quo. And this is not only true for accessibility, but also other essential building blocks of a modern, inclusive Web: Web standards, usability, performance, security, interoperability, and robustness. The Web of today is in many ways so much more mature than the Web of the early 2000s. And the progress in all of those areas makes the Web more inclusive already.

Enhance!

One of the most useful strategies – and philosophies – to build inclusive experiences for the Web is progressive enhancement. Coined in 2003 by Steven Champeon and Nick Finck, it describes the idea that instead of building exclusive websites for latest browsers and devices, it is much smarter to build a basic experience first which is then progressively enhanced (aha!) to provide a richer, more advanced experience as opportunity allows. That way, you make sure that your product is usable by people with any kind of device, on any kind of network connection, and with any kind of assistive technology.

Jeremy Keith likes to break progressive enhancement down into three steps that are as powerful as easy to remember:

  • Identify core functionality.
  • Make that functionality available using the simplest possible technology.
  • Enhance!

Sounds straightforward, right? Yet, wherever I look, I can’t escape the feeling that this approach is still, even after almost 20 years, more of an exception rather than the rule. Yes, I know a lot of people who know what progressive enhancement means and also practice it. They start with structured content, or at least with semantic HTML, add CSS that works well in older browsers, sprinkle in all the new layout goodness for modern browsers, and, in the end, they enhance all of this with JavaScript – including better accessibility support. But I have also worked with even more people who have no idea what progressive enhancement even means. They might have heard of the term but also often mistake it for graceful degradation. And who can blame them? The complexity of the modern Web is breathtaking and the things one could learn and incorporate into their practice endless. But that’s exactly why learning about progressive enhancement would be so valuable for those people: Progressive enhancement is not yet another technology or passing fad. It is a lasting strategy, a principle, to deal with complexity because it lets you build inclusive, resilient experiences that work across different contexts and that will continue to work, once the next fancy JavaScript framework enters the scene – and vanishes again.

But why don’t more people practice progressive enhancement? Is it only because they don’t know better? This might, in fact, be the primary reason. On top of that, especially many JavaScript developers seem to believe that it is not possible or necessary to build modern websites and applications that way. All they know is their hammer and so they just can’t imagine how one could possibly build a product like Hey! without megabytes of client-side logic, hot module replacement, and virtual DOMs. Meanwhile, they introduce huge amounts of technical debt and continue to build exclusive experiences that remind me a lot of the Flash era. Even progress bars are making a comeback. Can you tell which way the wind is blowing?

In my experience, it is also quite hard to change the culture and processes of agencies and web development studios. Many designers don’t know about progressive enhancement either and modern design tools also don’t support the layered approach of progressive enhancement. Imagine what a difference it would make if a designer could turn off a web font in her design tool or even switch off all the styles to see nothing but the underlying semantic structure of her layout. For now, the only design tool that can do such things, is the browser. And this is why I will continue to advocate for more interdisciplinary collaboration within teams and more prototyping. Because in order to practice progressive enhancement well, every member of the team has to be able to make well-informed decisions. If a designer never sees a design in its most basic form, how can she possibly improve this state of the system?

Some look at progressive enhancement like a thing from the past of which the old guard just can’t let go. But to me, progressive enhancement is the future of the Web. It is the basis for building resilient, performant, interoperable, secure, usable, accessible, and thus inclusive experiences. Not only for the Web of today but for the ever-growing complexity of an ever-changing and ever-evolving Web.

If you want to learn more about progressive enhancement, read those two books to get started:

Aaron Gustafson’s Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement in invaluable and explains the core idea as well as many examples very well. You can even read the first edition for free – and then buy the second edition!

Resilient Web Design by Jeremy Keith is a delightful journey through the history of the Web that brilliantly explains what it means to build for the Web and why progressive enhancement is at the core of creating resilient, future-proof experiences. It is a free online book.

-

This is the 43rd post of my 100 days of writing series. You can find a list of all posts here.

~

13 Webmentions

Photo of Baldur Bjarnason
Baldur Bjarnason
“Progressive · Matthias Ott – User Experience Designer” matthiasott.com/notes/progress…
Photo of Jeremy Keith
Jeremy Keith
Progressive · Matthias Ott – User Experience Designer July 24th, 2020 Progressive enhancement is not yet another technology or passing fad. It is a lasting strategy, a principle, to deal with complexity because it lets you build inclusive, resilient experiences that work across different contexts and that will continue to work, once the next fancy JavaScript framework enters the scene – and ...
Photo of Adactio Links
Adactio Links
Progressive · Matthias Ott – User Experience Designer matthiasott.com/notes/progress…
Photo of Michael Scharnagl
Michael Scharnagl
Progressive »But to me, progressive enhancement is the future of the Web. It is the basis for building resilient, performant, interoperable, secure, usable, accessible, and thus inclusive experiences.« matthiasott.com/notes/progress…

Likes

Reposts