The only problem is that it sounds robotic. It has the same vocal fidelity as a 1980s Speak 'n' Spell toy. Monotonous, clipped, and painful to listen to. For some people, this is a feature, not a bug. I have blind friends who are so used to eSpeak that they can crank it up to hundreds of words per minute and navigate through complex documents with ease.

For the rest of us, it is a steep and unpleasant learning curve.

There are lots of modern TTS programs using all sorts of advanced AI. Many of them are paywalled or require you to post your text to a webserver - with all the privacy and latency problems that causes. Some are restricted to high-powered GPUs or other expensive equipment.

Piper is different. It is local first, runs quickly on modest hardware, and is open source.

The easiest way to install it on Linux is to use Pied - a simple GUI which allows you to select languages, listen to accents, and then install them.

It will change your speech-dispatcher to use the new Piper voice. That means it is immediately available to your Linux DE's accessibility service and to apps like Firefox.

I now have a reassuring Scottish lady speaking out everything on my computer.

For example, the code might say: <img src="whatever.gif" alt="Two cute kittens are playing on a blanket">

If you are blind, you get an idea of what's being conveyed by that image. If you're on a train and the WiFi craps out just before the image loads, you'll also benefit! If the image is of text in a language you don't read, your device can translate it for you.

The alt text can be as long or as short as is necessary. It might just be "kid giving a thumbs up" or it could be incredibly detailed. Here's how the BBC's Newsbeat typically adds alt text for younger viewers:

Is that too much? Maybe. It depends on your audience. For partially sighted kids who crave the same pop information as their sighted peers, I think it is great.

So alt text is a good thing. But people are lazy and don't always write it. Perhaps the answer is to embed alt text inside image metadata?

It's a lovely idea - and technically feasible - but it fails to account for user needs.

And that brings me to the point of this post. Who is your alt text for? What information are you trying to share?

Here's a good example. I looked at a bunch of popular memes which had alt-text pre-populated in them. Here's what they said:

Terence Eden

@Edent@mastodon.social

Whenever people talk about embedding alt text into images, I remember that lots of gif search services already try to do that.

Here's BlueSky's gif service. I searched for some popular memes. Each had alt-text baked in.

Take a look and tell me if you think that the embedded text conveys the sentiment of the image? If you couldn't see the animation, would you understand what was going on from that alt?

2025-09-07, 21:11 12 boosts 22 favorites

OK, so sometimes the captioner makes a mistake and thinks the Chuckle Brothers are kissing (WTF?!) perhaps we can excuse that as being an obscure image. But the "idiot sandwich" one is inexcusable. It's a popular meme with a specific meaning.

Which leaves me with a few questions for you:

• If you saw that the image you were sharing had crap alt text - would you bother editing it?
• Is bad alt text worse than no alt text?
• Can the same image have multiple meanings?
• Have you spent any time browsing the web with images turned off? Did you enjoy it?

You can find out more about Alt Text on the RNIB site.

I'd purchased an eBook and was appalled by how crappy the accessibility was. If you don't know, modern ePub books are just HTML wrapped in a zip file. They have all of the accessibility advantages of the web and should be easy to read no matter if you're sighted or not.

But not this eBook! Part of the story concerned WhatsApp messages sent by the protagonist. Here's one of them:

See that smudge in the middle? The one smaller than a full stop? That's meant to be an emoji. Rather than use an actual emoji, they've stuck in a tiny pixel image which won't scale with text size.

Here is is:

Can't see it? Let me blow it up to a more readable size.

OK, that's annoying for sighted readers, but just about understandable. What about people who are using a screen reader? Luckily, ePubs can use HTML's "alt text" feature which will describe an image which can't be seen.

Curses! That's, perhaps, not too annoying for a decorative image - but later in the book there are pictures of a ransom note. Despite the plot-twisting text in the illustration, the alt text just says "image".

I found the publisher's website and scoffed at their proclaimed accessibility statement. I sent them an email which basically consisted of the above. I realised it was probably futile, but I've got to spend my privilege points somehow.

The next day, they wrote back!

I wanted to reply to let you know we are taking our commitments to accessibility in our ebooks seriously […] I will get our ebook team to check this as a matter of urgency and get back to you with an update.

Fair play. But talk is cheap, would they actually take action? A few days later, they sent a follow-up:

We have checked the file for this title again and found issues with it. We have sent this back to the conversion house to have the file corrected and expect this to be delivered by the end of the week. We would then expect this corrected version to be with Kobo by the end of the following week, i.e. 25th July.

We have also been spot-checking other files to see if there is a wider issue and where necessary will follow the same workflow to ensure fully accessible versions are available as widely as possible.

And, you know what, I think that's totally reasonable. Yeah, they should have caught it before publication - but it is a complex book and they're a small publisher. They took my complaint seriously and actually did something about it.

A week or so rolled by and they sent me this:

Just to update you that we have been back and forth with the conversion house getting this title up to scratch. There were various complicating factors which should now be resolved and an updated file has now been distributed and should be available through your chosen retailer presently. If you have any other queries please do let us know.

I logged on to my eBook provider, clicked "read" and…

It was fixed! All the images had decent alt text as well.

Rather annoyingly, the retailer didn't notify me that there was an update available. I can't blame the publisher for that though.

Still, 3 weeks from report to fix is pretty good I reckon.

When I last contacted a publisher about a mistake in their ebook, it took over 3 months to fix it. Perhaps things are slowly getting better?

Anyway, please complain about poor accessibility. Don't shout into the void of social media - write a polite but insistent email telling (not asking) people to fix their shit. Sometimes, just sometimes, it does work.

Anyway you should read The Mysterious Case of the Alperton Angels by Janice Hallett - it is brilliant and accessible.

You could read the book linearly - but it is much more suited to dipping into. Want to know exactly how to do something? There's almost certainly a recipe in here for you. Within the first few minutes of reading, I'd already discovered some stuff I didn't know - for example, the <q> element changes its quote style based upon its parent's language.

It is, of course, a fully accessible ePub - with plenty of useful alt text and semantically-rich metadata. Even better, it is gorgeously formatted - with excellent use of colour and typesetting throughout.

I particularly like that every section ends with a "discussion". The accessibility world is one of compromises - he invites you to think about the choices you're making and their trade-offs.

Manuel is very generous with his links to sources. You'll find dozens of blog posts, articles, and tutorials written by amazing people. It is slightly annoying that all the links go through the https://oreil.ly/ link shortener. I guess it means they can be updated if the original link dies, but it would be nice to see the destination before clicking.

Like lots of O'Reilly books, it is priced firmly in the "professional development" bracket. So get your boss to buy you a copy!

Extracting meaning from the words you are reading is seamless. The occasional antediluvian aphorism notwithstanding, your eyes glide across the page and your brain rapidly fills with thoughts.

I can feel your fingers itching to write a reply. You probably don't even glance at the keyboard as your mind instantly constructs beautiful sentences, in perfect grammar. Your fingers dance a steady 60WPM.

"Why do people put their tutorials on YouTube?!!?", you cry and rage.

There are three main reasons. In no particular order:

1. YouTube is monetised and the written word isn't. "Like and Subscribe" pays the bills in a way that text doesn't.
2. Some information is better shown visually. Seeing what an icon looks like and how a screen is supposed to react is useful semantic information.
3. It is easier.

Reading and writing are difficult. Go find any 7 year old and ask them to tell you a story - they will happily chat away for hours as they regale you with epic tales which would make Homer blush.

Now ask them to write their story down.

Kids can be pretty fluent speakers and listeners by the time they're 5.

But writing and reading takes longer.

I've redrafted this blog post a few times. I've gone back and tweaked the wording. I thought heavily about the exact structure I want to use.

I also held this conversation in a pub, with a friend. Despite the volume of other patrons, our inebriation, and the distractions around us, speaking and listening was simple. I expressed meaning, they received and understood me.

Writing is effort. It is especially hard for some people.

Speaking is easy. It also allows for a much greater array of semantic nuance.

Videos show details that text simply cannot capture.

Some people don't have the cognitive ability to fluently express themselves in your chosen medium.

I think this post sums it up best:

pdcawley

@Piers Cawley

You know what's more punk than grumbling at young people who don't cleave to your media preferences?

Learning to adapt and engage with what they're telling you through their chosen media.

Signed, a grumpy and only mildly punk old fart.

---

Further reading

• How People Read (GOV.UK)

A few weeks ago, we were discussing the need for better cybersecurity in their architecture. We spoke about several aspects of security, then they asked an outstanding question.

"What should I buy to be secure?"

It took a few moments to tease out exactly what they thought they were asking. In their mental model they could just buy a box which did what they needed. Want to print from any workstation? Buy a big HP network printer. Want to get WiFi in the office? Buy a bunch of access points. Want a website? Buy a WordPress. Want security? Buy a [fill in the blank]?

Their notion is that most things are products. This is a common belief. I've had clients ask "What do I buy to make this accessible?" or "What can I buy to improve usability?"

In all these cases there are unscrupulous people who will sell you a magic cure-all - but the real answer is that these things are a process; not a product.

Yes, you can buy tools which will help improve your security / accessibility / usability etc. But unless you put processes in place to get people to use them effectively, the tools are useless.

People need to understand why something is important. They need processes which support best practices. The business needs a holistic understanding of how these processes improve the business. And that is all underpinned by tools which make it possible.

There's no magic box which can both protect you from your CEO accidentally CCing confidential data to a competitor and stop DDoS attacks. An accessibility overlay won't help you if your staff refuse to incorporate alt text into their workflow. Automated code testing can't stop you building things without testing them with users.

Security is a verb - it is a doing word. Accessibility is a verb - it is a doing word. Usability is a verb - it is a doing word.

Buy nouns which support your verbs.

It relies on the new-ish :has() CSS pseudo class and the positively ancient filter() CSS function.

Here's the code in all its glory:

body:has( > #dark-mode-checkbox:checked ) {
  filter: invert(1);
  background: #000;
}

#dark-mode-checkbox:checked ~ img {
  filter: invert(1);
}

That does three things. If the body has an <input id="dark-mode-checkbox" type="checkbox"> which is selected, then:

• Invert all the colours on everything on the site.
• Manually set the background of the body, because the above is only filtering the descendants of the body.
• Find any images and invert them, so they're the right colour.

Here's some minimum viable HTML:

<body>
  <input id="dark-mode-checkbox" type="checkbox">
  <label class="dark-mode-label" for="dark-mode-checkbox">Enable dark mode</label>
  <h1>Heading</h1>
  <p>Test</p>
  <img src="https://placecats.com/128/128" alt="A cute cat">
</body>

Demo

You can play with the demo.

It should look like this:

Caveat

A few issues:

1. This doesn't yet work on Firefox. Even if you enable layout.css.has-selector.enabled in about:config. Support is coming soon™.
2. Inverting colours isn't the same as a properly designed dark mode. You absolutely shouldn't use this in production.
3. There are no accessibility guarantees. Please test this before subjecting your users to it.
4. This doesn't remember your user's choice. So they'll need to toggle it on every page load.
5. Who knows what eldritch horrors this will unleash upon humanity.

The WordPress Media Library lets you set the alt text of an image. But, crucially, this alt text can be different when the image is used as a featured image.

Here's how to find all your featured images which don't have alt text.

One Liner

Paste this into wp shell to get a list.

foreach (get_posts( array( 'post_type' => 'post', 'post_status' => array('publish'), 'posts_per_page' => -1,) ) as $post) { if( simplexml_load_string( get_the_post_thumbnail($post) )["alt"] == "") { echo $post->post_date . " " . get_site_url(). "/wp-admin/post.php?post=" . $post->ID . "&action=edit " . $post->post_title . "\n"; } }

An explanation

To get the image element of the featured image, use get_the_post_thumbnail(1234); That will spit back:

<img width="800" height="400" 
     src="https://example.com/test.png"
     class="attachment-post-thumbnail size-post-thumbnail wp-post-image"
     alt="This is some alt text."
     decoding="async" loading="lazy" />"

If there's no alt, you'll see alt="".

Getting an attribute out of a scrap of HTML is simple. We're going to be naughty and pretend this is XML. Shhh! Don't tell the W3C!

$xml = simplexml_load_string( get_the_post_thumbnail(1234) );

The alt text can be retrieved with:

$alt = $xmlEl["alt"];

So anything where $xmlEl["alt"] == "" is an image without alt text.

Finally, the code generates a link to the edit page of the post.

That meant I couldn't see the images on the other half of the page for the rest of the journey. I had a sea of broken images.

Even though the page had fully loaded, the images were set to "lazy" loading. When my browser sees <img src="example.jpg" loading="lazy" /> it defers downloading the picture until it is about to scroll into view.

There's a few reasons why this is a good thing. If I leave the page before scrolling down, the browser doesn't waste time, energy, or bandwidth downloading images which will never be seen. That's good for my battery life and cheaper for my bill. It also saves the server from flinging bits around the world which are promptly trashed⁰.

And yet...

It seems that every time I'm on a train - or somewhere else with spotty Internet access - I run in to a situation where I previously had plenty of bandwidth and battery, but my user-agent decided it knew best. So it didn't attempt to load images until after I lost signal.

There's no way to disable Lazy Loading on Android Chrome or Android Firefox.

So, I guess I'm stuck. Lazy loading seems like one of those things which is great in certain circumstances, but has a pretty horrible failure mode¹.

Anyone else feel this way?

For example <img src="monalisa.jpg" alt="A painting of the Mona Lisa.">

Most social networks will let users add alt text to help describe their images. Brilliant!

But... People don't always add alt text when they upload an image. They may not realise it is helpful, or they don't know how to write a good description, or they may not have time to write something suitable. This leads to a frequently asked question: "Should I embed the alt text inside the image file? That way, whenever people share the image the alt text will automatically be attached!"

Here's my attempt to answer that.

Short answer

No.

Long answer

Nooooooooooooo!

Reasoned Answer

It is complicated.

On a technical level, yes. Most modern image formats allow you to add image metadata - known as EXIF. This EXIF commonly contains GPS location, timestamps, make and model of camera, etc. Here's an example from one of my photos:

There are a pre-defined list of acceptable EXIF tags one of which is "ImageDescription", which is defined as:

A character string giving the title of the image. It may be a comment such as "1988 company picnic" or the like. Two-byte character codes cannot be used. When a 2-byte code is necessary, the Exif Private tag UserComment is to be used.

So, there you have it. Yes you can embed text inside an image. With the right software you can read it. So, technically, you can stuff alt text in there and have a website automatically add it to the alt attribute.

But this is only half the story. What an image represents is highly context dependent.

In her article about using AI to automatically provide image captions, Léonie Watson makes that point that alt text needs to be:

provided by a content author who knows exactly what's in the image, why its being used and the context its being used in.

Take this very real photo of a famous actress who I just got an AI to dream up.

What's a suitable alt text for this image?

• Famous actress Claire Flumptron standing on the red carpet.
• Claire Flumptron shows off her brand new arm tattoo which has strange mystic runes covering her forearm.
• Designer Giovanni Tuccini's new red dress has a small strap over the shoulder.
• AI image where the hand is strangely deformed and the neck looks twisted beyond human endurance.
• Smiling woman with cropped blonde hair and heavy eye makeup.
• Last known photo of the Mayor (right). His blurry face is smiling.
• ...

There's no "right" answer. It depends on what the image is being used to illustrate.

A picture may be worth a thousand words. But those thousand words depend on context.

Update Here's another good example of embedded alt text failing badly.

Terence Eden

@Edent@mastodon.social

Whenever people talk about embedding alt text into images, I remember that lots of gif search services already try to do that.

Here's BlueSky's gif service. I searched for some popular memes. Each had alt-text baked in.

Take a look and tell me if you think that the embedded text conveys the sentiment of the image? If you couldn't see the animation, would you understand what was going on from that alt?

2025-09-07, 21:11 12 boosts 22 favorites

For more information on writing good alt text, see Harvard's Digital Accessibility​ blog and Design102's guide.

Using a mouse? Nope, that won't work either.

The only way to navigate to it is via keyboard navigation. Hit your Tab ⭾ button!

There's a little bit of me wants to build an entire website which can only be navigated by keyboard. What would the world look like if Engelbart never invented the mouse? Or if Johnson never published his work on touchscreens?

Anyway, there are two ways to do this. The first is to create an anchor with no content.

<a href="https://example.com/"></a>

Because there's no content between the opening and closing <a> elements, most browsers won't present it as a target for a mouse cursor or finger.

There's a second method, which only works at discouraging mouse use. It's possible to style a cursor with CSS. And that style can be "none"

*, *:hover { 
  cursor: none !important; 
}

The cursor is still there, but it is invisible. Which makes it difficult to know where your mouse is clicking.

Now, should you do this? No. It is silly. Reducing accessibility like this is never a good idea. But it is a fun experiment.

Thanks to Manuel Matuzović for inspiring me.

"In Hamlet, Act Ⅳ, Scene Ⅸ..."

Most people with a grasp of the interplay between English and Latin would say "In Hamlet, Act four, scene nine". And they'd be right! But screen-readers - computer programs which convert text into speech - often get this wrong.

Why? Well, because I didn't just type "Uppercase Letter i, Uppercase Letter v". Instead, I used the Unicode symbol for the Roman numeral 4 - Ⅳ. And, it turns out, lots of screen-readers have a problem with those characters.

Don't Know Much About History

Unicode contains the range of Roman numbers from 1 - 10, plus a couple of compound numbers, 50, 100, 500, and 1000 - in a variety of forms.

Why does Unicode contain these number which, to most people, are just squashed together Latin letter? As ever with Unicode, it is a mix of legacy and practicality.

The Unicode standard says:

Roman Numerals. For most purposes, it is preferable to compose the Roman numerals from sequences of the appropriate Latin letters. However, the uppercase and lowercase variants of the Roman numerals through 12, plus L, C, D, and M, have been encoded for compatibility with East Asian standards. Unlike sequences of Latin letters, these symbols remain upright in vertical layout. Additionally, in certain locales, compact date formats use Roman numerals for the month, but may expect the use of a single character.

Far be it for me to disagree with the learned authors of the spec, but I think they may have erred slightly on this one. While it may be preferable to re-use Latin letters, it leads to ambiguity which can be confusing for a screen-reader.

Practical Examples

Let's write out the numbers using regular letters. Suppose you were talking about "Romeo and Juliet, Act III, Scene I". Most screen readers will see the "III" and correctly speak aloud "Roman three" or similar. But when they get to the "I" it becomes ambiguous. Most will read out "Eye".

Screen-readers rarely look at the whole sentence for context. Which means they get confused. It's fairly obvious that XIV should be "fourteen" as there's no English word "xiv"⁰. But what about "MIX" - is that 1009 or the word "mix"?

Anyone who has watched the BBC knows about their fondness for displaying in Latin the year a programme was made. MCMXCVI is particularly challenging for a screen-reader!

Testing It

I took the following sample sentence - using both letters and Roman numerals.

Text. In Hamlet, Act I, Scene XI the year is MCMXCVI and they are watching Rocky V.

Roman. In Hamlet, Act Ⅰ, Scene Ⅺ the year is ⅯⅭⅯⅩⅭⅥ and they are watching Rocky Ⅴ.

Here's how various services coped:

Amazon Polly

First, the good news. Amazon's Polly read the Roman numerals perfectly. It even pronounced ⅯⅭⅯⅩⅭⅥ as "nineteen ninety six".

Microsoft Edge Read Aloud

I tried with Microsoft Edge's Read Aloud TTS.

It and makes a bit of a hash of the English and just skips the Roman numerals.

Google Text To Speech

The same was also true with Google's TTS products.

Espeak NG

The venerable Linux utility came out with this.

It gets the "Capital i" incorrect, and reads the Roman numerals as their Unicode code points.

Jaws

My good friend Léonie Watson who writes extensively about accessibility was kind enough to record some other samples for me.

Here are Jaws' "Expressive":

And Jaws' "Eloquence:

NVDA

Léonie also provided a recording of NVDA Microsoft One Core

Narrator

And here's Narrator making a right mess of it.

Others

If you know of any other screen-readers, or text-to-speech engines which can cope with this, please let me know!

Fixing it

On Linux, I raised a Pull Request to fix espeak-ng.

The rest of the services don't seem to have a way to easily report bugs to them. If you know a way to raise issues with these screen readers - please do so!

Yes. Yes it is. And it's pretty simple. Well, OK, it's CSS, so simple is a relative term!

Let's take a broken image like <img src="http://example.com/bigfoot.jpg" alt="The best quality photo of bigfoot!" />

There are two slightly different ways to style the text.

The simplest way is to give the image some CSS relating to its font, colour, and background.

img {
    font-family: monospace;
    color: #000;
    background: yellow;
}

If the image loads, the CSS has no effect (well, you might see the background colour if the image loads slowly or if it is transparent). But if the image fails, the alt text picks up the font and text colour specified. That seems to work reliably on Firefox, Chrome, and WebKit.

With Firefox, however, you can go a little further. The alt text of a missing image is appended to the DOM as a ::before pseudo element. Which means it can be styled directly.

img::before {
    font-family: monospace;
    color: #000;
    border: .25em dotted red;
    background: yellow;
    padding: .25em;
}

You can go as ridiculous as you like. It will only show up when an image fails to load. Sadly, that does seem to be FF specific. I couldn't get it working in Chrome or Safari.

There's one more thing you can do. You can append text to the end of your alt. For example:

img::after {
    content: " Image did not load.";
}

Demo

img {
    font-family: monospace;
    color: #000;
    background: yellow;
    box-shadow:inset 0px 0px 0px 1px #f00;
}
img::before {
    font-family: monospace;
    color: #000;
    border: .25em dotted #f00;
    background: #ff0;
    padding: .25em;
}
img::after {
    content: " ❌";
}

Cross Platform Compatibility

I've tested in on the three major browser rendering engines:

Do note that Safari will only display the alt text if the image is large enough to contain it.

Should I use this?

That's kinda up to you, sport. I think it's an interesting way to make it obvious that an image has broken. If you do use it, please make sure that the alt text is as legible as possible.

About a decade ago, I wrote about how the Twitter archive works and where it is deficient. Things have got better, but there are still annoying limitations.

For example, Hannah Kolbeck - founder of the Alt Text Reminder Bot recently pointed out that there's no alt text in the archives.

Here's a snippet of Twitter's JSON for an image I posted:

"media" : [
   {
      "expanded_url" : "https://twitter.com/edent/status/1579574033720705025/photo/1",
      "indices" : [
        "66",
        "89"
      ],
      "url" : "https://t.co/J1hr0ZfbTl",
      "media_url" : "http://pbs.twimg.com/media/FevGM32XEAA0FX2.jpg",
      "id_str" : "1579574018776174592",
      "id" : "1579574018776174592",
      "media_url_https" : "https://pbs.twimg.com/media/FevGM32XEAA0FX2.jpg",
      "sizes" : {
           "small" : {
                "w" : "680",
                "h" : "510",
                "resize" : "fit"
              },
              "medium" : {
                "w" : "1200",
                "h" : "900",
                "resize" : "fit"
              },
              "thumb" : {
                "w" : "150",
                "h" : "150",
                "resize" : "crop"
              },
              "large" : {
                "w" : "1236",
                "h" : "927",
                "resize" : "fit"
              }
       },
       "type" : "photo",
       "display_url" : "pic.twitter.com/J1hr0ZfbTl"
     }
],

Lots of different media sizing options, but no room for accessibility.

By comparison, the Mastodon social network gives you the alt text. Here's a snippet of Mastodon's JSON for the same image which was cross-posted:

"attachment": [
   {
     "type": "Document",
     "mediaType": "image/jpeg",
     "url": "/media_attachments/files/109/145/933/102/890/212/original/84ae501e39f45091.jpg",
     "name": "A sign for priority seating. The pregnant person's face has been replaced by 😍. The person holding a baby has a face of 😫. The elderly person with a cane has 🥴.",
     "blurhash": "UhKdk{0LRit6-:t6WCWC-oxaRmWBozt7xaa|",
     "width": 1236,
     "height": 927
   }
],

Mastodon is a friendlier alternative to Twitter and - mostly - gets accessibility right. There's still some work to do

You can fix Twitter's missing alt text using Hannah's Alt Text Archive Tool. That'll get you a JSON file full of your alt text, which you can use to recreate your archive.

Look, it's obvious that Alan doesn't give a flying fuck about accessibility, so I don't expect this to change any time soon.

Instead, people should do what they did when MySpace went to shit; move to a different platform.

Join Mastodon today!

Now, if you're using the Classic editor, you'll get a larger and resizeable box for entering alt text.

Because the text entry uses <textarea> most browsers will also show any spelling errors. Good spelling is essential for people who use text-to-speech to read out alt text.

Huge thanks to the WordPress team for doing all the hard work to make sure this works properly. I hope this will encourage people to write longer and more useful alt text.

Thing 1 | Something Else | Another Thing.

This provides clear visual separation between logical groups. But there are a couple of problems. Firstly, the separator character may not be interpreted correctly by screen readers. They may read out "Vertical Pipe", which isn't very user friendly. Similarly, robots may not attach the correct semantics to the separator. Which is a problem if you're trying to do machine learning on text.

HTML and CSS are about the separation of content and style. So let's examine the ways we can provide a better way to do separators.

Hide Them

I think that this is the least satisfying method.

<span aria-hidden="true">|</span> Thing 1 <span aria-hidden="true">|</span> Something else

The aria-hidden tag hides the content from accessibility software. It is specifically designed to remove purely decorative items. But, because the separators are simply removed, the text runs together. That's a problem for screen readers.

CSS Borders

This is another popular way to visually distinguish groups.

span {
   border-right: solid #000 1px;
}

<span>Thing 1</span> <span>Another thing</span>

You can style the CSS however you like. Depending on your layout, you may need to use :not() on the last element to prevent an unnecessary separator.

But, again, there's no way for a screen reader or robot to know that the content is supposed to be distinct from each other.

⋮:before and ::after?

Similarly, the ::before and ::after selectors can be used to add content before/after an element:

span::after {
   content: " | ";
}

<span>Thing 1</span> <span>Another thing</span>

Abuse the <hr> element?

This is a bit wacky. The <hr> element is a - somewhat - outdated way to provide a sectioning break by drawing a horizontal line. But it is accessible in CSS. By changing its rotation and width, it makes a passable vertical separator!

hr {
   rotate: 90deg;
   width: 1em;
}

Thing 1 <hr style=""> Another thing

It can be a bit tricky to get the styling just right - but it will effectively separate logical groups.

List styling

I like using lists for things like this. It groups the items together and provides a logical "block" that either a human or robot can interpret or skip.

Here's a baroque method to make a list horizontal and to replace the content of the bullet.

#hz > li::before {
    display: list-item;
    content: "";
    position: absolute;
    margin-inline-start: -.5em;
}
#hz > li {
    display: inline-block;
    list-style-type: "|";
    padding-right: 1em;
}
#hz > li:first-child {
    list-style-type: "";
}

<ul id="hz">
    <li>Thing 1</li>
    <li>Another thing</li>
</ul>

That removes all the bullets. Then replaces every one except the first with a pipe spaced back a little from the text. And lays the list out horizontally.

If you want to change the colour or position of the bullet, you can use ::marker instead.

Mix And Match

My preferred way is to use <li>, remove the bullets, and then style a border on the left - except for the first one. This keeps the semantics of the list, and is a relatively simple piece of CSS.

#hz > li {
    display: inline-block;
    border-left: solid #000 1px;
    padding: 0 1em 0 1em;
}
#hz > li:first-child {
    border: none;
}

<ul id="hz">
    <li>Thing 1</li>
    <li>Another thing</li>
</ul>

Is there a best way?

No, it is a matter of personal taste and appetite for complexity. My "strong opinion weakly held" is that semantic HTML is nearly always preferable to just chucking stuff in a load of <span>s and <div>s. It makes the content easy to understand if you're browsing without CSS, or if you're a robot trying to understand the world.

Similarly, I think simple CSS is better than complicated CSS. Something small and human-readable is always going to be easier to understand and manage in the future.

But, if you think I'm wrong - or know a better way to lay things out - please let me know in the comments.

HTML has the concept of the lang attribute. It allows you to say that a specific element contains text in a specific human language. For example, this page starts with:

<html lang="en-GB">

That says the entire page is written in English, with the sub-type of Great Britain. This means your browser might offer to translate the page, if that isn't a language you can read. Or it might read the page aloud in a "British" accent (as opposed to American or Australian).

You can mix and match languages in a document. For example:

<p lang="en">My favourite book is "<span lang="fr">Les Misérables</span></p>".

If you don't do this, you can end up with some weird results. Imagine a page in en-AU which contained a quotes in German, which didn't use lang="de". Your computer might read it out loud and it would sound like this:

Yikes!

It turns out, you can add the lang anywhere:

The lang attribute in no namespace may be used on any HTML element. HTML specification

So, why would you want to add language to an image?

For accessibility, of course!

Consider this image

The HTML behind that image is:

<img lang="zh-CN" alt="大型载客汽车" src="example.jpg" />

That means a user-agent can offer a translation, or read the text with the correct voice Nifty!

There is, of course, a drawback. You can't include multiple languages.

Consider this photo:

There's no way to add multiple langs in an element. This is similar to the limitations of HTML's title element.

There are a bunch of ways to add long and complex descriptions to images which are probably a more appropriate way to add multilingual text.

But, there you go. If you need to add a specific language to an image, you can!

Lots of their pages had this snippet of code:

Rather than add properly accessible alt text, a developer added placeholder Latin text.

Being a good webizen, I tried to report this.

Terence Eden is on Mastodon

@edent

Hi @PostOffice,
Why is your website's alt text written in Latin? I don't think that is very accessible.
shkspr.mobi/blog/2017/11/n… pic.x.com/9fQYq92P9g

---

Post Office

@PostOffice

Replying to @edent@edent Hi Terence, we are looking into this for you. We'll be in touch once we have more info. ~Stacey

---

Of course, Twitter is where good customer service goes to die. So, it wasn't much of a surprise when it wasn't fixed a year later.

Andy Mabbett

@pigsonthewing

Replying to @PostOffice@PostOffice @edent One year on, it seem that you have not fixed this accessibility issue. The "lorem ipsum" alt attribute is still in the source of, for example, postoffice.co.uk/savings-accoun…

---

Post Office

@PostOffice

Replying to @pigsonthewing@pigsonthewing Hi Andy, I am sorry to hear it! I'll pass this on to our Web team. ~Stacey

---

I didn't make a big fuss of the 2nd anniversary. But I thought it would be nice to mark its 3rd birthday.

Terence Eden is on Mastodon

@edent

Replying to @PostOffice@PostOffice Please can I have an update to this issue? Thanks.

---

Post Office

@PostOffice

Replying to @edent@edent Hi, we have a team looking into this currently now Terence as we are concerned that you have reported this previously and it is still ongoing. I'll see if I can get you an update and thanks for your patience - Ryan

---

Which was shortly followed by:

Terence Eden is on Mastodon

@edent

Replying to @PostOffice@PostOffice Please can I have an update to this issue? Thanks.

---

Post Office

@PostOffice

Replying to @edent@edent From the conversations I have been CC;d into it is looking like there is a fix for this and it is being implemented next week. Thank you for drawing this to our attention again and apologies it has taken so long - Ryan

---

A quick check and it has finally been fixed!

It is annoying that there's no real way to get companies to fix their broken stuff. If you report it to customer services - you'll likely be ignored. It makes me wish that there were public bug trackers for everything!

<p>
 The concert is <time datetime="2020-12-24">tomorrow</time>
</p>

Then the computer knows the specific date I'm talking about. A browser could offer to add the event to your calendar, or a search engine could find events which are happening on a specific date. Nifty!

Problems in the wild

The problem comes when people use abbreviations which may not be accessible to people who use assistive technology like screen readers.

Here's an example from the BBC's news front page. That "1h" means the story was published 1 hour ago. Take a look at the code behind it: The <time> element represents when the story was originally published. The qa-status-date-output is an abbreviation of the relative time since the story was published. It is hidden from screen readers with aria-hidden="true". The gs-u-vh is the alternative text for screen readers. It is hidden from sighted users with CSS.

There are a few problems with this approach:

1. It violates the DRY principle. The time is effectively written out three times.
2. It produces conflicting or ambiguous information. All three times contradict each other.
3. If CSS isn't working, both times are displayed.

Terence Eden is on Mastodon

@edent

Replying to @edentI found this due to the strange way Lynx renders the timestamps.
Because half of them are hidden using CSS, it becomes unreadable. pic.x.com/7obyophheb

---

It also has issues when search engines see the content:

To be clear, I'm not dunking on the Beeb. They have a great set of accessibility people. I'm just wondering if there's a simpler / better way to do things?

Possible Solutions

Ideally, there would be something like aria-datetime to read out the time. But that doesn't exist.

Or, screen readers could interpret the <time> element and do something with it. But that doesn't seem well supported. And, how will a screen reader know that the salient information is a relative duration, rather than a specific datetime?

ISO8601 - the datetime standard - allows for durations. So you could write datetime="TP30M" to mean 30 minutes. But that doesn't say it was 30 minutes ago and you lose the full datetime.

Here's how I would solve it:

<time datetime="2020-11-30T09:23:48.000Z">
   <abbr aria-label="1 hour ago">1h</abbr>
</time>

That uses the <abbr> abbreviation element. A sighted reader will see the "1h", a screen reader will read out "One Hour Ago", and someone browsing in text mode will just the "1h".

I think that's a pretty optimal solution. It's clean, readable, doesn't rely on hiding any elements, and should be easy to keep in sync.

Think there's a better way? Let me know in the comment box.

A few months ago, I was involved in a medical questionnaire launch. Before it was released, I had several people send me polite (and not-so-polite) queries as to why it was taking so long. "I could build that in five minutes!" was the common refrain.

Some people, dissatisfied with our progress, did just that. They quickly built their own questionnaires and opened them to the public. That's the joy of the Web - you don't need to ask anyone's permission to publish. Some of the questionnaires were pretty good - but many were not.

Here are some of the problems I found with things which people launched in five minutes. This is non-exhaustive, and lightly edited for anonymity. But they were all genuine problems that were found. The problems broadly fell into two categories:

Security

• Submitted medical data over http.
• Allowed anyone to look up a previous submission.
• Stored medical data on a shared webhost in the USA.
• Any user could edit another user's medical information.
• Invasive advertising tracking on the form.
• No mechanism to prevent duplicate submissions.
• Loaded 3rd party JavaScript without SRI.
• Vulnerable to SQL injection.

Usefulness

• Asked for information which wasn't medically relevant.
• Didn't ask for specific information which was medically useful.
• Questions assumed users understood medical terminology.
• Used free-text boxes which another form control would be more suitable.
• Poor accessibility meant visually impaired users couldn't reliably answer some questions.

Just Five Minutes

It's really easy to build a form in 5 minutes. What takes the time is doing it right way.

Most of the time, getting the wrong answer quickly is not as useful as getting the right answer slowly.