Category Archives: Web

Screen readers 1, humans 0

Spoken version: MP3 | OGG

Yesterday I sent out a one-question survey on Twitter about screen readers. I’d had this fantastic idea for a website plugin that would enable blog editors to easily record an audio version of their blog posts when publishing [1]. Vision-impaired users would rejoice, website traffic would shoot up and I’d be rich and famous. To double-check, I asked the following question which was retweeted and replied to by several kind souls:

I expected replies along the lines of “stupid question, of course a human recording is better but we have no choice”. How wrong I was.

If you’re not sure how a blind or low-vision user can “read” a webpage, listen to the following short video showing a screen reader in action.

When I’ve seen friends use screen readers it’s always struck me as sounding difficult to understand and likely to get annoying after a while. Where’s the warmth or personality in that mechanical voice?! But I was enlightened as to how incredibly empowering this technology is and the replies I got were pretty unanimous — screen readers win hands down.

Benefits of screen readers

  • Ability to control such as jumping forwards, backwards or elsewhere in the page
  • Ability to check spelling
  • Ability to listen by word
  • Ability to change reading speed (humans are too slow)
  • Ability to follow links

Some of these are also possible with JavaScript, e.g. changing the speed of an audio file, but it would add an extra UI to the interface that the user is already familiar with. I suppose it’s similar to my beloved Kindle — I now feel the limits of books printed on paper compared to ebooks with their dictionary lookups, highlighting, linking, etc.

The only non-unanimous opinion was for fiction where a human narration is sometimes preferred for continuous reading and to feel emotion.

So another day older, another day wiser and thanks to everyone who sent comments.


  1. When editing a blog post, it should be possible to use getUserMedia to record the audio, send that to the Web Audio API and export it as a WAV file using the Recorder.js library. Then get the WAV file transcoded to OGG or MP3 via an online API such as (no affiliation) and uploaded to cloud storage. The resulting URL could be inserted into an audio element at the top of the blog post, a bit like this one.

Responsive is not just visual: Three useful web APIs

A mobile user using a laptop outside.Mobile users are on the go. They’re rushing to get a train or busy meeting people. They don’t have much time and they’re on a slow connection. Right?

The answer of course is not necessarily. So-called mobile browsing could include shopping online while tucked up in bed, sending messages while watching TV or giggling at silly photos while relaxing in a cafe. It could also include being out and about but not using a mobile device.

In reality we have no idea what the users of our website are doing or where they are, and it would be a huge invasion of privacy if we did! Our fancy responsive designs should therefore not only look good but also be flexible enough to handle a variety of situations.

In other words, responsive doesn’t mean responding to screen size or even device capabilities. It means responding to the user’s environment (as much as possible).

But enough chatter. How can we do this in practice?

There are three handy web technologies that take us part of the way there: the Battery Status API, the Network Information API and Ambient Light Events. Support for all of them is mostly Chrome and Firefox for now, but keep an eye on and for the latest support info. And now, on to the APIs…

Battery Status API

Why use it

Knowing whether your user is plugged in or not and whether their battery has much juice left can influence how your site reacts. Battery-draining features such as repeated actions and animations can be reduced or disabled, for example. Or you could notify the user and offer to save the current state in case there’s a sudden shutdown.

How to use it

The spec had a rewrite recently and now uses shiny new promises. The advantage of this is that the API is asynchronous, meaning that when you call the getBattery() method the browser makes sure the BatteryManager object is ready before you try to read its attributes. Those attributes are:

  • charging (a boolean)
  • chargingTime (in minutes)
  • dischargingTime (in minutes)
  • level (a number between 0 and 1)

Each of these attributes has an event so you can listen for when they change. In practice, you could use the attributes and events like this:

// Prepare a function to display the battery status
function showStatus(battery) {
  battery.onchargingchange = function () {
    console.log('Charging: ' + battery.charging);
  battery.onchargingtimechange = function () {
    console.log('Charging time remaining (mins): ' + battery.chargingTime);
  battery.ondischargingtimechange = function () {
    console.log('Discharging time remaining (mins): ' + battery.dischargingTime);
  battery.onlevelchange = function () {
    console.log('Battery level: ' + battery.level);

// Check for browser support first
if (!!navigator.getBattery) { // The latest API is supported
  // Use the battery promise to asynchronously call showStatus()
  navigator.getBattery().then(function(battery) {
} else if (!!navigator.battery) { // The old API is supported
  var battery = navigator.battery;

Guille Paz has made a nice battery status demo which includes code for the old and new versions of the spec.


This API has the best support of the three with Opera, Chrome and Firefox having implemented it. In the case of Firefox, the implementation currently uses an old version of the spec so for the time being it’s best to allow for both versions in your code.

Network Information API

Why use it

You’re probably aware of the navigator.onLine HTML5 attribute and its wide browser support but that only tells us if the user is connected to a network or not. For more detailed information about the network we need the aptly-named Network Information API. With the data it provides you could opt to show smaller or lower-quality images to users on slow connections, or only show a video background when you know the network speed is fast. Be careful when making assumptions though — wifi doesn’t necessarily mean fast.

How to use it

When fully implemented this provides the type and speed of connection using two attributes (type and downlinkMax) on the global navigator object. Let’s jump straight into an example…

// Some browsers use prefixes so let's cope with them first
var connection = navigator.connection || navigator.mozConnection || navigator.webkitConnection;

// Check for browser support
if (!!connection) {
  // Get the connection type
  var type = connection.type;

  // Get the connection speed in megabits per second (Mbps)
  var speed = connection.downlinkMax || connection.bandwidth;

So easy! The type values are a pre-defined selection of self-explanatory strings:

  • bluetooth
  • cellular
  • ethernet
  • none
  • wifi
  • wimax
  • other
  • unknown

Network speed, when available, is exposed as downlinkMax, previously called bandwidth, although in reality this is difficult for browsers to measure so it may be a while before we’re able to use it. You can also attach a change event listener to navigator.connection to be even more responsive.

For a more thorough look at this API and its background, Aurelio De Rosa has written a good tutorial and network information demo which I recommend.


In the browsers I tested only connection.type was supported properly and that was only in Chrome for Android and Firefox Mobile/OS (you may need to ensure dom.netinfo.enabled is set to true). It’s still early days for this API but its simplicity means it could easily be incorporated into your website or app.

Note: There is a version of the spec hosted on that currently says work on it has been discontinued. This refers to an older version and current work is being done in the GitHub-hosted version, which should eventually migrate to the W3C site.

Ambient Light Events

Why use it

We’re probably all familiar with struggling to read a screen in bright sunlight. Increasing the contrast of what’s displayed on the screen or hiding distracting backgrounds can make content much easier to read in such cases. The opposite is true — reducing how vivid a design is can avoid users screaming and covering their eyes when in a dark environment.

How to use it

Tomomi Imura, AKA @girliemac, has the definitive lowdown on how to respond to differing levels of light. Eventually we’ll all be able to use CSS4 media queries so when the light-level is dim, for example, we can respond accordingly. In the meantime though, there’s the more precise JavaScript approach which gives you access to data from the device’s light sensor. You just listen for a devicelight event and use that event’s value attribute to get the brightness of the user’s surroundings measured in lux. For example:

window.addEventListener('devicelight', function(e) {
  var lux = e.value;

  if (lux < 50) {
    // ambient light is dim so show lower-contrast version

See Tomomi's article for a more detailed example with added CSS and a link to her ambient light demo on CodePen.


At the time of writing support is only available in Firefox and Chrome beta for Android but here's a short video of her code in action:

Of course, these are not the only web technologies that are part of responsive web design but if you want to show the world that you know more than just media queries, they're a good place to start.

On Responsive Images — An interview with Dr. Stanley Dards

Wanting to serve different size images to different size screens is nothing new but at last the web has a practical solution for responsive images and art direction. Thanks to a lot of hard work by a lot of people, the Responsive Images Community Group has achieved the goal of seeing its API becoming a valuable building block of the web.

The <picture> element and its related srcset and other attributes are already being incorporated in Blink, Gecko and WebKit, have been included in the HTML5 validator and are part of the WHATWG HTML5 spec. A triumph of common sense and cooperation — hurrah!

To celebrate this, I was lucky enough to interview Dr. Stanley Dards, the wise old man of the web, to get his unique insight on the topic.

And here’s a good practical summary of responsive images and how you can use them today.

The Internet, the Web and an old book

Cover of Running Linux bookNot long ago, I was explaining to a translator the difference between the Internet and the Web. Understandably they thought they were the same thing, as most people do.

Jump forward a few weeks and I’m packing boxes ready to move house, wondering what I can throw out. A dusty edition of Running Linux from 1996 — surely that can go, being so out-of-date? But flicking through it I noticed a chapter devoted to “The World Wide Web and Mail” and this little gem:

The WWW provides a single abstraction for the many kinds of information available from the Internet.

And there you have it. Much more succinct than my long-winded attempt at explaining the difference. But the part that made me smile was this:

The World Wide Web (WWW) is a relative newcomer to the Internet information hierarchy. The WWW project’s goal is to unite the many disparate services available on the Internet into a single, worldwide, multimedia, hypertext space. Although this may seem very abstract to you now, the WWW is best understood by using it.

A page from Running LinuxReading this 17 years after it was written, it almost seems quaint — it’s hard to imagine now that readers of a technical manual would not know what the Web is. And yet because the book assumes no previous knowledge it manages to teach a concept in a way that’s clear and stands the test of time.

Who says technical books lose their value as they get older?

On vendor prefixes — An interview with Dr. Stanley Dards

At last, the existence of vendor prefixes, one of my pet peeves, is under the spotlight. Also at last, the fact that not all modern browsers are WebKit (shock!) is getting some attention.

I (personally) believe vendor prefixes cause more harm than the problem they were designed to solve, namely how to elegantly introduce experimental features in browsers. My belief is that a non-browser-specific prefix such as -beta- has fewer obstacles to overcome than other proposals. Having said that, there’s clearly no easy, one-size-fits-all answer but hopefully more awareness and public discussion will lead to a more plausible solution.

So far, there have been great contributions to the discussion from all sides. A selection of ones I’ve found valuable, but may not necessarily agree with, are listed here:

And as if that wasn’t enough, here are the insights of one Dr. Stanley Dards: