QuirksBlog

Syndicate content
Updated: 9 hours 55 min ago

Progressive enhancement and accessibility

Thu, 02/18/2021 - 1:29am

This article asks a question I don’t know the answer to: What is the exact relationship between progressive enhancement and accessiblity?

I mean, there is considerable overlap between the two. Good progressive enhancement can help accessibility, while accessibility can guide progressive enhancement decisions.

When I created the progressive enhancement reading list for my PE course in March I asked for good articles. I got a few submissions that I eventually rejected because they were about an accessibility problem that isn’t (quite) PE. Still, these submissions indicate that PE problems can be confused with accessibility ones. We instinctively we feel there’s considerable overlap between the two.

Still, they are not the same. You can have an thorny progressive enhancement problem that poses no accessibility problems, and you can have an accessibility problem that bears no relation to progressive enhancement.

The problem is that I can’t quite put my finger on where progressive enhancement and accessibility meet. Well, they can meet in individual problems, but that’s not what I mean. I’m looking for serious theoretical thought, and so far I haven’t found any. Also, my brain refuses to throw out a workable definition and stays stubbornly silent.

So can anyone define the relationship between progressive enhancement and accessibility? You can reach me via Twitter or my contact form.

Progressive Enhancement reading list 2021

Thu, 02/18/2021 - 1:23am

In March I am going to teach the Progressive Enhancement course of the Web minor at university for the third time. I decided to expand the reading list for this course, and here I present the version I’m going to use in 2021.

img { max-width: 100%; } Defining progressive enhancement

Let’s start at the original definition of progressive enhancement.

In 2008 Aaron Gustafson published Understanding Progressive Enhancement at A List Apart, and placed progressive enhancement at the forefront of web developer thinking. Aaron did not invent the concept — he points to prior art by Steve Champeon and Nick Finck. Still, Aaron’s article popularised the concept.

Aaron compares progressive enhancement to its precursor graceful degradation and finds that PE is the better approach — something that has become generally accepted since then. He also described progressive enhancement comprehensively, and we essentially still follow his definition.

Chris Taylor sees progressive enhancement as technical credit, the opposite of the technical debt you incur when you quickly insert some hacks to get the system to work and solemnly resolve to fix them “later.” (Hint: later never comes.) PE is the opposite: it prevents problems from arising, and thus saves you time in the future. The article also contains a useful overview of progressive enhancement principles.

Progressive enhancement also helps you combat browser incompatibilities. Justin Crawford, Chris Mills, and Ali Spivak make the web work for everyone by addressing cross-browser problems and their causes (which mostly come down to web developers not quite knowing what they’re doing). Better browser compatibility leads to better accessibility, and also to better results, since users will switch sites if they encounter problems. The best way to get these results is to practice PE. (And there we go again: PE and accessibility are clearly related. But how exactly?)

Their browser market share notes are worth repeating. Although Chrome is the largest browser, in January 2021 it still has only 63% of the market according to StatCounter. That sounds like a lot, but it means 37% of your users do not use Chrome. Don’t leave them out in the cold.

Does this sound theoretical? Let’s get practical. Robin Whittleton explains why we use progressive enhancement to build GOV.UK and walks you through the decisions. This is still a high-level overview, but it was actually used in an actual major website. We’ll see gov.uk in action later in this reading list.

Progressive enhancement and UX

The Nielsen Norman Group discusses the role of enhancement in web design and shows that progressive enhancement is useful in non-technical contexts as well. Where the previous articles focused on technical issues, this one gives a good theoretical overview of PE from a UX perspective.

What is progressive enhancement’s purpose in user interface design, and how do you decide which functionalities should be progressively enhanced? The article offers a few hardware examples, for instance the mouse wheel, which was a progressive enhancement when it was introduced, and still is, because touchscreen devices as well as keypads lack a wheel (and, in fact, a mouse). Input modes are ruled by PE, too.

Two excellent general rules are worth quoting in full:

  1. Don’t add other enhancements that provide the same functionality. [...] You want to give people the chance to practice and strengthen the enhancement; if you add other enhancements for the same interface functionality, it will be less likely that any one of them will get enough use.
  2. Be consistent. Use the same enhancement everywhere you can. That is, try to give users many opportunities to practice and thus strengthen the association between the enhancement and its effect in the interface. (Remember, repetition is the mother of retention.) Ideally, designers should use the same enhancements across many different sites, to allow people to learn them.

Aaron Walter created the Hierarchy of User Needs model, which forms the basis of a theory of user delight: why usability is the foundation for delightful experiences, also by the Nielsen Norman Group (image below borrowed from this article).

Delight is all very well, but without a solid foundation of usability, reliability, and functionality it falls flat. If something looks gorgeous but is incomprehensible, doesn’t always work, or doesn’t work at all, it is useless. The relationship between the four layers of user needs is pure progressive enhancement: the next layer is only useful if the layers below it work, and for each functionality you have to decide in which layer(s) to put it.

The PE layers

Let’s return to the technical aspects of progressive enhancement.

In order to progressively enhance a site you first need to define its core functionality. As Andy Bell says, a minimum viable experience makes for a resilient, inclusive website or app. He argues that porting the idea of a minimum viable product to the website experience is a good starting point for your PE project. Which core functionalities are required to give any user the opportunity to finish the task at hand? How do we identify a minimum viable experience, and how do we layer JavaScript functionalities on top of them?

Speaking of layers, Hidde de Vries explains why it's good for users that HTML, CSS and JS are separate languages. He argues that separation of concerns between structure, presentation, and behaviour remains a good thing. This impacts progressive enhancement by forcing you to think about which functionalities you should implement in which layer(s).

So let’s go through the layers.

Layer 1: HTML

Terence Eden discusses the unreasonable effectiveness of simple HTML by telling a story about a user being forced to work on a government-related task on the PlayStation browser (which is — let’s call it not good and leave it at that). The user managed to do what she set out because the site she needed had a simple, good HTML structure that works in any browser. This is what core functionality and minimum viable experience are all about. And you just need HTML to do it.

Dave Rupert created an indispensable list of HTML: the inaccessible parts, where he gives a round-up of accessibility problems with HTML elements. If you want to use any of these HTML elements you should apply the principles of progressive enhancement to make sure they work everywhere. This shows that HTML is not necessarily restricted to the lowest, functional layer but can also enhance (or detract from) the reliable, functional, and pleasurable layers. (Also, it shows yet again there is a close relationship between progressive enhancement and accessibility.)

Léonie Watson wrote a short note on progressive ARIA where she shows that changing the role of an element (here a link to a button; why?; but this happens all the time) also means you should make sure users can click it with the Space key. This is possible for buttons, but not for links, and if you change a link to a button the browser doesn’t automatically add the Space key. So you have to progressively enhance it.

Layer 2: CSS

I have not been able to find specific articles about CSS and progressive enhancement, although they must be out there. I’ll update this section when I find any.

Layer 3: JavaScript

Then we come to the elephant in the room: JavaScript. I mean, everyone has JavaScript, right? As Stuart Langridge shows, this is untrue. Even if the user doesn’t disable JavaScript explicitly there may be many reasons why they don’t have JavaScript.

Incidentally, measuring the number of users who turn off JavaScript is very easy. Just tweet something like “No one turns off JavaScript anyway,” wait for about a day for people to tell you in no uncertain terms they do in fact turn off JavaScript, count these reactions, and you know how many people turn off JavaScript.

Given that JavaScript is a progressive enhancement challenge, not only because it can be absent but also because “modern” web development uses such an incredible amount of it, Jeremy Keith’s 2014 call to be progressive remains relevant today. This article summarises an interesting discussion from those days and contains a lot of excellent points about how to view progressive enhancement, browsers, JavaScript, and more.

Jeremy calls for more server-side components:

Personally, I try not to completely reinvent all the business logic that I’ve already figured out on the server, and then rewrite it all in JavaScript. I prefer to use JavaScript—and specifically Ajax—as a dumb waiter, shuffling data back and forth between the client and server, where the real complexity lies.

I also think that building in this way will take longer …at first. But then on the next project, it takes less time. And on the project after that, it takes less time again. From that perspective, it’s similar to switching from tables for layout to using CSS, or switching from building fixed-with sites to responsive design: the initial learning curve is steep, but then it gets easier over time, until it simply becomes normal.

Did anyone listen to him in the years since 2014? (Hint: no.)

Chris James gives a quick overview of the past web, when things were still good, and describes the Web I Want. Then he gives a useful overview of why we don’t need that much JavaScript in our pages: HTML is already perfectly suited for showing content pages.

Finally, Thomas Steiner explains how to progressively enhance your Progressive Web App by digging into layers of JavaScript support in an advanced article. Assuming JavaScript is present, he gives an example where a simple but insufficient JavaScript is enhanced when the browser supports the File System Access API. He then gives a few other examples of modern APIs and how to feature-detect them. This is on a site by the Chrome devrel team, so it’s Chrome-centric in the features it treats, but the techniques Thomas teaches are applicable anywhere.

Practical examples

Jim Nielsen shows how he is progressively enhancing a small widget. This is a simple, first PE mini-project that is well suited to understand the basic concepts. He uses JavaScript to progressively enhance a static page, and the key takeaway is how the script changes the page’s static content.

Andy Bell (again) studies the power of progressive enhancement. He discusses a (no longer existing) web app in PE terms: start with the core functionality, then layer extras on top. Contains an excellent, simple bit of advice on how to handle the fact that some browsers don’t support CSS grid. This article highlights practical PE decisions and how they work.

Chris Scott created a practical Progressive Enhancement and Data Visualizations example project where he progressively enhances a timeline by first creating a solid HTML structure, then adds some presentational CSS, and then layers JavaScript and SVG on top that changes the presentation considerably.

That’s it. That was the reading list.

If you know of more good articles for the next version you can reach me via Twitter or my contact form.

Progressive Enhancement reading list, draft 1

Thu, 02/11/2021 - 1:24am

In March I am going to teach the Progressive Enhancement course of the Web minor at university for the third time. I decided to expand the reading list for this course, and here I presented draft 1 and asked for feedback.

Meanwhile the reading list is done and I removed this draft. Also, I have a question about progressive enhancement and accessibility that I wasn't able to solve.

Thidrekssaga XI: Sigfrid’s death

Tue, 01/19/2021 - 4:53am

Just now I published part XI of the Thidrekssaga: Sigfrid’s death.

The story now switches to the Niflungen and Sigfrid. First Sigfrid’s youth is treated — and it sometimes seems a parody of the traditional hero’s story. Then the Niflungen are briefly introduced and Hagen loses his eye. Then the marriages of Sigfrid with Grimhild and Gunther with Brunhild are related.

Finally, Grimhild and Brunhild quarrel, and Hagen decides to kill Sigfrid. This sets the stage for Grimhild’s revenge.

Enjoy.

Thidrekssaga X: The battle of Gransport

Thu, 01/07/2021 - 12:47am

Just now I published part X of the Thidrekssaga: The battle of Gransport.

After helping Attila and Erka, Dietrich asks for their help to return to Bern. He sets out with a large army of Huns and battles Ermenrik at Gransport. His brother Diether and the two sons of Attila and Erka die in the battle, and Dietrich is so upset that he returns to Soest without following up on his (apparent) victory.

Enjoy.

Driver or mechanic?

Tue, 01/05/2021 - 5:33am

The tools vs knowledge argument goes something like this:

Random web dev
You don’t have to know CSS. Or basic JavaScript. I mean, our great toolchain has all of that covered, right?
Me
If you’re a web developer you should know something about CSS and JavaScript. What if your tool doesn’t support your use case? Or what if they are terrible for performance?
Random web dev
Nonsense. I’m much more productive with my trusty tools.
Me
But having some basic knowledge is part of being a professional web developer.
Random web dev
I mean, if you drive a car you don’t have to know how it works, right? You just drive it.

Over the past ten years I have heard this drive a car analogy more often than I care to remember. Superficially, it’s an interesting one, but I found I disagree with it.

This article has been translated into Russian.

To me, we are not the drivers of the car called the World Wide Web, but its mechanics. And mechanics should definitely know something about the contraption they’re building and maintaining, right?

In fact, the more I think about it the more I see this as the fundamental question.

What would you prefer to be: a car driver or a car mechanic?

I’m sure a few people’s interest will be piqued by my question. Still, analogies like this one should not be taken too far. They can easily confuse the issue instead of clarifying it.

The problem is that people start to fill in details that the analogy doesn’t support. Exactly what does the car represent? The web, a web site, or the production process? And what does driving mean? Surfing the web, building a site, or something else? And who exactly is symbolised by the mechanic? Or the tools?

The discussion could easily degenerate into a shouting match about the meaning of the analogy while everybody forgets about the actual tools vs knowledge issue the analogy was supposed to clarify.

Something else I noticed over the last twenty years is that people resort to homely comparisons only when they have run out of actual arguments, or when they don’t really understand the issues involved. So they conjure up an image of something that everything can relate to and pretend it settles the discussion.

The question of whether tools are enough to build websites or knowledge of the underlying technologies is also necessary will not be solved by homely car comparisons, but only by actual arguments about the tools vs knowledge issue.

Despite all this I find I like the question I asked above, since it forces you to make a fundamental decision. So I’m going to let it stand, even though it hitches a ride on a potentially confusing car analogy.

As a web developer, would you prefer to be a driver or a mechanic?

Thidrekssaga IX: The Wilkinen wars

Fri, 12/18/2020 - 5:16am

Just now I published part IX of the Thidrekssaga: The Wilkinen wars.

Whilt etaying at Attila’s court Dietrich fights in a few of his wars and saves queen Erka’s honour (and head). Attila and Erka are grateful, and in the next chapter they are willing to help Dietrich in return. Also, this part contains a realistic report of a siege, and the only heroic deed of Wolfhart, Dietrich’s nephew, who plays a rather large role in other Dietrich sagas, but not in the Thidrekssaga.

Enjoy.

user-scalable=no and suppressing zoom suppression

Tue, 12/15/2020 - 2:31am

The story goes as follows: Once upon a time there was a meta viewport property called user-scalable=no that suppressed pinch zoom on the page it was on. As a result users could not zoom in, even if they needed to. This was obviously a bad idea, and therefore browsers stopped supporting it.

At least, I thought that was the story. Turns out it isn’t.

This weekend I was alerted that suppressing zoom still works in Android browsers, though not on iOS. A quick test determined that Chrome, Edge, Firefox, and UC on Android obey user-scalable=no and do not allow the user to zoom. Only Samsung Internet keeps its cool and allows zooming.

<meta name="viewport" content="width=device-width, user-scalable=no"> Awful. Also, gatekeeping

Just in case you need it spelled out: suppressing user zooming is awful.

Despite the continuing perfection of my 50-year-old eyesight, the vast worldwide conspiracy that is resizing all fonts to smaller and smaller values forces me to zoom in on sites whose clueless designers — who I believe should be relegated to designing physical flyers for third-rate coke-fueled ad agencies, even though that thought makes me a gatekeeper, which is much worse than shitting all over basic web accessibility, so let me stress how wonderfully welcome to our world these designers are — think a 6px font is the most fitting choice.

When I can’t zoom in I get cranky and write snarky comments on my blog.

Technical details

Let’s return to the positive and praise Apple for a short while. On iOS, suppressing zoom has been disabled since iOS 10, though an exception was made for the WebView, because it might not be fitting to zoom a part-native-part-WebView application. Mmmm ... ok, I kind-of see the point here.

Still, it’s possible to turn off zoom suppression programmatically in the WebView, and rather to my surprise the creators of Chrome on iOS — which, remember, uses the iOS WebView, and not Blink, as its rendering engine — chose to do so. Or maybe the default has changed, I don’t know. In any case Apple is mostly on the right track.

So is Samsung; by default, zooming is enabled. Yay! My choice for Samsung Internet as my default mobile browser has been vindicated. I’ll stick to it, thanks so much.

The other Android browsers, Chrome, Edge, UC, and Firefox, all suppress user zooming. The fun part is that the Chromium-based browsers only need user-scalable, while the =no bit is strictly optional. To prove this point I ran a test with user-scalable=anti­disestablish­mentaria­nism. It suppresses zoom in the Chromium browsers. Apparently pinch zoom favours dis­esta­blish­ment.

Firefox has a somewhat more strict syntax, where user-scalable without arguments suppresses zooming, as do the arguments no and 0, but any other value is rejected and does not suppress zooming.

Fortunately an explicit user-scalable=yes or 1 works in all browsers, and zooming is not suppressed.

On the whole, double-tap zooming is also suppressed in these instances. I must admit I did not test this for all possible arguments in all browsers, but since it makes sense that all types of user zooming would be suppressed, I am willing to believe there is no difference between pinch zoom and double-tap zoom.

User settings

I seem to remember that Google said at one point that they’d remove zoom suppression, and, judging from the thread, so did others. I searched and searched, but could only find the 2013 bug report that caused user-scalable to be added to the browser. So I think I just misremember; or maybe it was floated as an idea at one point but never got implemented.

For a moment I thought the default had changed several times, when an old Chrome 47 I found on one phone did allow me to pinch-zoom, but on further investigation it turned out I had switched on the setting that allows me to zoom. After I switched it off zoom suppression was enabled.

Let’s talk about settings. Chrome, Edge, and Firefox allow users to override user-scalable=no and suppress zoom suppression. (Does that last clause sound complicated to you? Congrats, you now understand part of the problem.)

Here are the settings:

  • Chrome on Android: Settings -> Accessibility -> Force enable zoom
  • Edge on Android: Settings -> Accessibility -> Force zoom
  • Firefox on Android: Settings -> Accessibility -> Zoom on all web sites
  • Samsung Internet: Settings -> Appearance -> Control the zoom on web pages; turned ON by default
  • UC on Android: Tools -> Settings (unclear gear icon) -> Browser Settings -> Font & Layout -> Force page to Zoom; BUT turning this on does nothing

Both Samsung Internet and UC have a setting as well, but Samsung Internet’s is turned on by default (i.e. it suppresses zoom suppression), while switching UC’s setting does nothing: zooming is still suppressed.

Point is: no user uses these settings, or will even know where to find them. (Be fair: would you have found them in all browsers? Would you have looked?)

OK, if you have really desperate need you might find the setting you require, but average run-of-the-mill users do not use settings, do not suppress zoom suppression, and don’t even know that they’re missing something.

In order to emulate the true user experience I never touch the settings on my test browsers. You should do the same. You should see what users see.

So user settings are not the solution. The default enabling of zoom suppression is wrong because users will not be aware they can change it.

Google, Mozilla, UC, Microsoft, up your game. Make suppression of zoom suppression the default. Make sure users can always zoom. As an added bonus we can throw all those third-rate designers who cannot design for the web under the train. (Or bus. Or car. I’m flexible.)

Thidrekssaga VIII: Dietrich&#8217;s flight

Wed, 12/09/2020 - 5:44am

Just now I published part VIII of the Thidrekssaga: Dietrich’s flight.

Dietrich’s uncle Ermenrik, egged on by his evil counselor Sibich, starts killing his family. To avoid being captured and hanged, Dietrich flees from Ermenrik’s army to king Attila in Soest. Witig and Heime have curious and badly-explained roles.

Enjoy.

Thidrekssaga VII: The tournament in Bertangaland

Wed, 12/02/2020 - 3:44am

Just now I published part VII of the Thidrekssaga: The tournament in Bertangaland.

When Dietrich has gathered twelve heroes it’s time to do something heroic. They decide to challenge king Isung, his eleven sons, and his banner bearer Sigfrid to a tournament, which forms the climax of part I of the saga and an important turning point.

Before reading this article, make a guess how this tournament ends.

Enjoy.

Thidrekssaga VI: A quarrel about Mimung

Tue, 11/24/2020 - 4:05am

Just now I published part VI of the Thidrekssaga: A quarrel about Mimung.

Here the saga reports about the quarrel between Witig and Heime about Mimung in the context of two wars and a search-and-rescue story.

Enjoy.

Thidrekssaga V: Detlef

Wed, 11/18/2020 - 3:43am

Just now I published part V of the Thidrekssaga: Detlef the Dane.

The hero Detlef comes to Dietrich's court, initially as a servant, but he pawns off the heroes' equipment to give a great feast. Once that is discovered he has to fight a duel of strength against Walther, and wins. Thus he becomes a hero of Dietrich. Also, this part shows the start of the quarrel between Witig and Heime.

Enjoy.

Thidrekssaga IV: Journey to Osning

Wed, 11/11/2020 - 1:46am

Just now I published part IV of the Thidrekssaga: Journey to Osning.

This is a complex story that tells how Dietrich wanted to forget his defeat by going on a journey alone. He defeats the hero Ecke in a curious, myth-heavy nightly fight in a forest, then makes Ecke's brother Fasold his follower. Then some frankly unbelievable hunt adventures happen, and Dietrich and Fasold rescue Sintram, Hildebrand's cousin, from a dragon. Thus Dietrich wins two more heroes before returning to Bern.

Enjoy.

Thidrekssaga III: Witig

Tue, 11/03/2020 - 2:55am

You’re in for a treat today. Just now I published part III of the Thidrekssaga: Witig.

It is the second best story in the entire saga, and I give a complete version with only minimal notes. We hear how Witig Wieland's son and bearer of Mimung comes to Bern to fight with Dietrich, how he encounters Hildebrand and Heime along the way, and how Hildebrand becomes worried for Dietrich, mostly because he knows Mimung is better than Dietrich's equipment. We also hear how he solves this problem and teaches Dietrich a lesson in the process.

Enjoy.

©2003 - Present Akamai Design & Development.