In web development, designing an accessible loading button is a real head-scratcher. There's no easy one-size-fits-all solution, but understanding the various approaches improves your ability to make accessible experiences. So, how do we make a loading button accessible?

The Straightforward Approach

Let's begin with what seems the most straightforward: just slap on a spinner and call it a day.

There are multiple ways of implementing a loading spinner. Here I have implemented it using solely CSS, so the spinner is not detected by screenreaders. The details of the styling are not important, but I promise I’ll share with you the whole snippet at the end of this post. The most important thing is it hides the text for visual users and adds a spinner.

Here’s an abstraction:

This approach has its pitfalls. While visually it indicates loading, it does nothing to communicate this state to users relying on assistive technologies. The text is still available for screenreaders, but it only says “Submit”:

One easy way to improve this, is to change the aria-label of the button while loading:

Now a screenreader will read “Loading” if the loading status is changed.

We have actually made an accessible loading button!

We could end this article there, but one common issue for a loading button is to prevent users submitting while loading status is active.

But disabling a button has caveats you should be aware of.

The Disabled Attribute: A Common Misstep?

It might seem logical — disable the button while the action is in process:

This prevents any interaction with the button, so multiple requests won’t be sent. It also adds some styling, indicating for visual users the button is not interactive. For screenreaders, it will be read as “Loading, disabled, button”, which seems swell.

However, disabled may also be problematic for screenreaders. When a button is disabled, it's removed from the tab navigation. This entails if a keyboard user is tab-ing through a page, a disabled button will not be focused.

Not being able to find a button doesn’t sound too accessible to me — so what are the alternatives?

Aria-disabled: Interactivity Maintained

Here's where aria-disabled steps in. Unlike the traditional disabled attribute, it keeps the button interactive, allowing focus, but still telling a screenreader the button is disabled:

One important thing to remember, is that it’s an aria- property, so it only affects screenreaders. It does not affect styling or prevent submits.

To make aria-disabled also visible for sighted users, you can simply style the button if aria-disabled is set:

To prevent submits, you can do an early return on your submit function:

So now we have two possible implementations of a disabled, loading button.

But you may also have seen aria-busy — is that something you should be using?

Aria-busy: Maybe relevant?

aria-busy tells the screenreader an element is “busy”, which sounds suitable for a loading button:

But aria-busy might not work as you expect. After you press the button, it won’t immediately notify you about its busy-ness; it still reads “Submit” then “Loading”. You only get the word “busy” included with the screenreader if you enter the element from somewhere else, such as leaving the button and refocusing it. Then it will read “Loading, busy, button”. This shows the importance of updating the aria-label to communicate its state.

There’s also another gotcha with aria-busy you should be aware of. It hides the busy element’s children from screenreaders. This is by design, as aria-busy is intended to prevent the screenreader to read incomplete elements.

So in the case below, it would not read the loading text:

We have multiple implementations of loading now — what does the industry use?

Learning from the industry

It's instructive to look at how various UI libraries handle this issue. Here solutions vary from only setting disabled, only setting aria-disabled, only setting aria-busy or a mix.

Let’s first look at what some global libraries does it:

Atlassian: aria-disabled. https://atlassian.design/components/button/examples#loading

Material UI: disabled. https://mui.com/material-ui/react-button/

shadcn: disabled. https://ui.shadcn.com/docs/components/button#loading

In Norway, some of the biggest libraries also have a mix of decisions:

Common public library, designsystemet: aria-disabled. https://storybook.designsystemet.no/?path=/docs/felles-button--docs#bruk-av-spinner-til-å-lage-en-knapp-som-laster

Entur: aria-busy and aria-label. https://design.entur.no/komponenter/knapper/button

Vy: aria-busy and disabled. https://spor.vy.no/components/button

Nav: disabled. https://aksel.nav.no/komponenter/core/button#buttondemo-loading

Lets comment some of these choices.

Let’s just first comment the use of disabled — wasn’t that a misstep?

First of all, you should avoid the use of disabled, and instead use feedback text and early return. But in the case of a loading button, it is OK to use disabled, assuming the wait won’t be too long. For a loading button the user may already have focus on the button, and you can tell the user what’s happening by changing text from “submit” to “loading”.

With disabled the user may know that the button will be unavailable to tab for a little while, but it’s still possible to use voiceover-button + arrows to navigate to it.

If the waiting time is too long, e.g. more than 10 seconds, a user may be confused to what is happening. Nav suggests in this case to add more feedback with text, progress bar or use a loading skeleton.

Why might libraries have such a range of decisions?

One answer is simply that there’s not only one correct solution. There are multiple ways to understand a button is in a loading state. Some screenreader-users may be used to one way, and another group may be used to another way. You just have to user test with your audience.

Another aspect is that the above mentioned libraries use default values for loading state. But there may be situations where one method is better, and it’s possible for consumers to overwrite.

Conclusion

In summary, creating an accessible loading button requires a nuanced understanding of different attributes and their implications for accessibility. What a perfect solution is, has a boring answer: it depends. It depends on the context and the users' expectations. By examining various approaches and understanding their trade-offs, developers can make more informed decisions and create more inclusive web experiences.

As promised, here’s the implementation of the loading button:

How would you implement an accessible loading button?

Making an accessible loading button: Aria-disabled with friends

Denne artikkelen tar deg stegvis gjennom hvordan man kan lage et enkelt API som lar deg hente og poste julehilsner ved hjelp av rammeverket Ktor.

Lettvinne Julehilsener med Ktor

Velkommen til enda en artikkel på Bekk.christmas! I dag på selveste julaften skal vi utforske Ktor, et moderne og lettvektig Kotlin-rammeverk, og bruke det til å lage et enkelt API for å hente og poste julehilsener i ekte juleånd! So lets go-hohoho!

Trinn 1: Besøk Ktor Start-siden

Gå til start.ktor.io i nettleseren din. Her har du muligheten til å konfigurere ditt Ktor-prosjekt ved å velge de nødvendige avhengighetene.

Trinn 2: Konfigurer prosjektet

Velg et passende navn; f.eks "Ktor-julehilsen" og velg "Gradle" som byggverktøy, trykk "add plugins" og legg til følgende avhengigheter:

Routing

Status-pages

Content-negotiation

kotlinx-serialization

Jackson

Exposed

Du kan også legge til flere avhengigheter etter behov.

Trinn 3: Generer prosjektet

Trykk på "Generate" for å laste ned zip-filen som inneholder prosjektet.

Trinn 4: Åpne prosjektet

Pakk ut zip-filen og åpne prosjektmappen i din foretrukne utviklingside, for eksempel IntelliJ IDEA eller Eclipse.

Trinn 5: Konfigurer database

I prosjektets src mappe vil du finne Applikation.kt. I denne filen ser du et enkelt oppsett som konfigerer serialisering, databases og routes. Naviger inn til configureDatabases()-funksjonen i plugins/Databases.kt og ta en titt. Her har start.ktor.io generert opp eksempel kode for interagering med en User database via en user-service. Det finnes også eksempler på routing som tar i bruk denne user-servicen gjennom CRUD-endepunkter.

Vi skal jo eksponere endepunkter for å sende og hente ut julehilsner så her må gjøre noen endringer. 

Start med å lage en ChristmasGreetingService.kt:

Her har jeg brukt eksempelet og modifisert koden til å bruke ExposedGreeting som utgangspunkt for interagering med databasen.

Oppdater så Databases.kt  med denne koden:




Nå har du en fungerende database og en service for å hente og legge til hilsener.

Trinn 6: Legg opp Routes

Naviger til Routing.kt og modifiser den på følgende måte:

Her tar vi bruk julehilsen-servicen og lager endepunkter for å poste og hente en spesifikk julehilsen samt. alle julehilsener.



Trinn 7: Flett alt sammen

Endre Applikation.kt til å se slik ut:

Og Voilá! Du har et fungerende API for å sende og hente ut julehilsener.

Er'kke verst det?

Oppsummering:

Nå vet du mer om hvordan Ktor fungerer og hvor lett det er å få opp noe som fungerer. Anbefaler å ta en titt på Ktor sin dokumentasjon for videre læring. Dokumentasjonen er, i klassisk JetBrains stil, utrolig sweet å lese og navigere i -> ktor.io



Takk for at du tok turen innom, ha en fortsatt God jul og kotlin-programmering! 🎄🚀 

Introduksjon til Ktor

Caching might be one of the hard things in computer science, but wow, it's fun when it works! Let's dive into some cool new caching strategies!

Sometimes, old stuff is the coolest. In a world saturated with new technology every day, I find solace in learning something new about a technology I have been using for decades. The fact that even the building blocks of the technologies I use every day still have something new to teach me, just feels good for some reason.

This year, my team and I spent three months implementing a new version of a fairly popular website in Norway, and during that process I spent a bunch of times trying to make everything as fast, responsive and available as possible. Since we were using Remix to implement the new web platform, I started looking into more of the core web fundamentals. What I learned turned out to be incredibly useful for me – and hopefully it will be for you too.

This article will teach you two (fairly) new caching strategies that helped us save money, reduce load time by a ton, and greatly simplify our code.

I know I should know how caching works on the web, but ehm…

Before we dive into my new cool findings, I want to give a quick introduction on what caching is, and how caching works on the web.

Caching is a way to temporarily store data, so we can retrieve it quicker than we would from the original source. We do it all the time, often without noticing. Our CPUs cache data it needs within a millisecond or two, memory chips store cache data we need almost as quickly, and even our hard drives cache stuff we’ve accessed recently so that we don’t have to look it up from the storage unit itself.

When doing web development, there’s a few ways we can cache data as well. We can cache data in our JavaScript applications (hello useState), we can ask the browser to cache stuff for us, and we can use a globally distributed cache layer, called a Content Delivery Network (or CDN, for short) to cache documents and assets closer to the user than our origin servers. There are lots of other ways, of course, but these seem to be the most common ones.

When caching data on the web, we typically use something called caching headers to specify what we want to cache, and how we want to cache it. There are lots of fun cache headers to play with, but the most important one – at least for the strategies mentioned in this article – is the Cache-Control header. Headers are part of the request that’s passed between the server and the client, providing meta information (information about information) to the receiver.

The Cache-Control header has a bunch of functionality, but here are a few examples:



There are lots more to learn about this header, and I highly recommend diving into the MDN documentation for more details.

However, there are a few strategies that turned out to be great resources for us to reduce response time, server load and cost.

A few words about CDNs

The site we implemented had a CDN (content delivery network, remember?) between the site’s servers and the end user. A CDN is a network of globally distributed machines, working as intermediate storage devices for any resources.

You typically see CDNs storing assets that never change, like images, videos and hashed JavaScript files. This lets the user download these assets from a nearby server (typically within the same state or part of the country) without going to the origin server. This is very practical, since it both drastically reduces response time for the user, as well as the load on the origin servers.

Our CDN (AWS CloudFront, if you were wondering) receives every request to our domain, checks whether it has that particular resource (file path) stored, and returns it to the user, without ever bothering the origin server. However, we also use it to serve files that do change, like CMS-backed HTML pages and JSON responses, which I what I want to talk about in this article.

stale-while-revalidate

As I mentioned earlier, the Cache-Control header accepts a bunch of different directives. One of most powerful ones, is one called stale-while-revalidate. This strategy tells our cache (CDN) to do the following:

If the CDN contains the resource that’s still “fresh” (hasn’t expired), return that resource. Done.

If the CDN contains the resource, but it has expired, return the expired resource to the user. Then, ask the origin server for a fresh version of that resource in the background, so that the next request for the same resource will be “fresh”

The tradeoff is basically this: Some users might get stale content, but will still get it quickly.

It looks like this:

What happens here is the following:

If a request comes in, and there’s less than 1 hour since the data was placed in the cache, return the resource. Don’t ask the origin server, just return the data as is.

If a request comes in, and there’s less than 1 hour since the cache expired (for instance, 1 hour and 30 minutes since the data was placed in the cache), return the stale data to the user. Next, ask the origin server for a fresh response. Save that data in the cache, and mark it as fresh again.

If a new request comes in right after (for instance, 1 hour and 31 minutes after the original data was stored in the cache), the user will receive fresh data without waiting for the origin server at all. The origin server won’t be asked for a new copy for another hour.

This is a great strategy to use when you have a bunch of consistent traffic, or if any changes to the content you’re caching can wait for a few seconds. If you have consistent traffic, the cache will always be updated, since any stale request will trigger what’s called a revalidation (”go check the origin server in the background”). Cool stuff!

Our site was based on a CMS, and any changes in the returned HTML site (or JSON data) would typically be changes to a landing page, articles etc. Yes, it’s cool if the updated page was available right away, but it doesn’t really break anyone’s experience if they are a few seconds behind the breaking news. This seemed like a wonderful strategy for us.

The result is that, for resources that change, we have a > 95 % cache hit rate. The only pages that are retrieved from the server is the ones rarely updated. We’ve set the cache threshold to about 1 hour, which means you might get 1 hour old content if you’re the first visitor to visit that page a while – but if that’s the case, chances are the page might not be the most frequently updated one you have anyways.

The stale-while-revalidate header is such a useful technique in combination with CDNs, I don’t think I’ll ever serve a site without it again.

stale-if-error

We all make mistakes from time to time. In my experience, making sure the production environment we serve is resilient from errors is the best investment you’ll ever make.

Meet the stale-if-error directive. It works in a pretty similar fashion to the stale-while-revalidate directive, but with a very specific difference:

If the origin server returns a 5xx server error (500 Internal Server Error, 503 Service Unavailable etc) for a specific resource, or if there’s a network error (a timeout) return the last cached successful response.

In other words, we can specify that if our website goes down for some time (it happens), we can return the last working version of that website for a specified amount of time. Sure, the user won’t get any new data, but at least it’ll get some data back. Your server will hopefully trigger an alarm, and you can get your server back online without the user ever noticing.

In our case, we set this cache timeout to be 12 hours:

In other words – if our website goes down, we have 12 hours to get it fixed before we ever show a 500 error page to the user. Neat!

The previous version of our website had some intricate code that dealt with downtime in downstream systems, like our previous CMS or other internal APIs. Now, however, we could delete all that code and just use The Platform like it was supposed to work.

These two directives have made wonders for both our users, servers and pocket books. We spent a bunch of time optimizing the different parameters to make them just right, and we’ll probably keep on doing so for the foreseeable future, as we learn more about our users’ usage patterns.

outline

Summary

Caching stuff is fun. Sure, it might be one of two hard things in computer science, but it’s sure a great tool to keep in your toolbox.

I hope this article inspired you to start experimenting with these caching directives on your own site, saving your team and users a bunch of headaches.

Web

Making an accessible loading button: Aria-disabled with friends

Introduksjon til Ktor

💰 is 👑 - a guide to the new 🆒 cache headers