Bruce Lawson's personal site

A while ago, there was discussion in CSS Working Group about an alt property to be added to CSS. Its purpose is to let assistive technology know the meaning of unicode characters inserted into a visual rendering of a document with CSS generated content. The problem is described by James Craig, Apple’s nice accessibility chappie.

It’s been shipping as -webkit-alt for a year now, and has just been added to the draft CSS Pseudo-Elements Module Level 4 spec. Let’s say you’re using a star glyph to show something is “new”, by generating CSS content using a class of .new as your selector:

.new::before { 
  content: url(./img/star.png);
  alt: "New!"; 
}

The alt gives information to assistive technology.

The alt string can be blank. Assume you’re generating “►” to show that a widget is expandable. Because you’re a lovely human being and a responsible developer, you’re using aria-expanded="false" in the HTML. Therefore, you’d use empty alt in the CSS that generates the glyph to prevent assistive technology “helpfully” reading out “Black right-pointing pointer” after the AT has relayed the ARIA information to the user:

.expandable::before {
  content: "\25BA"; /* a.k.a. ► */
  alt: ""; 
  /* aria-expanded="false" already in DOM, 
     so this pseudo-element is decorative */
}

Update 17:05 GMT fantasai of the CSS WG has mailed the CSS Working Group protesting against the syntax above. I don’t have any horse in the syntax race; my aim with this post is to show that we need some mechanism to give alternate content to assistive technology given that we allow non-textual content to be generated via CSS.

When I tweeted about this earlier, a few people objected to the concept because it adds content to CSS. But that ship has long sailed, with the content property that people have been using for ages. If you say “adding non-decorative content to a page is a misuse of CSS that merits the author 100,000 years in purgatory with Tim Berners-Mephistopholee pouring hot Ovaltine over their dingle-dangles whenever they try to sleep”, I will vehemently nod my agreement.

But sometimes, for organisational reasons, or because you inherited code, or you’re refactoring code from before you saw the light, you’re working with CSS that generates icons. This new property at least allows an author to make that content more accessible.

Years ago, I joined a web team a week after their brand new website had been delivered, months late and squillions over budget, by Big London Agency PLC. The site was a vile splodge of nested layout table cells and spacer GIFs with “click here” links pointing to PDFs. Of course, I could have instantly resigned my job and let the bank repossess my house.

Instead, I gently pointed out to any who would listen the inadequacies of the site and made plans about how it could be refactored. But while biding my time, I was also making small tweaks here and there to make it better and incrementally more accessible; removing duplicate link text from title attributes, changing “click here”s, putting blank alt text on spacer GIFs in the small parts of the template I controlled.

This was before the days of ARIA but I would have jumped at the chance of adding role="button" to the horrible mess of nested <div>s that the CMS spat out. Yes, it’s much better to spend a fortune getting the external CMS provider in to change the templates, the retest every single form on every single browser – but that simply wasn’t possible.

Two years later, when the senior manager who commissioned the terrible site left and we could jettison it, we did. And then we did it right. But for those who needed the content and were unable to wait nearly three years (that is, everyone), I’m glad I applied sticking plasters and polished turds.

It’s often said that if a job’s worth doing, it’s worth doing well. But it’s also wise to remember: sometimes, if a job’s worth doing, it’s worth doing badly than not at all. If you must have meaningful content generated by CSS, at least now you can make it accessible.

Update 1 May 2020: The syntax has now changed. Ian Lloyd tweeted

.warning-with-alt:before {
 content:"! " / "Warning ";
}
...
<p class="warning-with-alt">Be careful

It announced “Warning Be careful�� in VO/Chrome combo. All other browsers I tried on Mac ignored the whole line, so no pseudo content added. Andy Ronksley wrote

The alt text is added to the content property now (after the forward slash). Last time I used this a few years back, Safari only supported the older syntax. Sounds like Ian has confirmed it still doesn’t support the new syntax.

(Last Updated on 1 May 2020)

Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)

14 Responses to “ Notes on draft CSS “alt” property ”

Leave a Reply