Archive for the 'accessibility web standards' Category

Reading List

Reading List

Reading List

Notes on draft CSS “alt” property

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.

A quick tip for understanding CSS Flexbox

Quite a few people have difficulty understanding the CSS Flexible Box Model, especially the flex-shrink property. Even brainboxes like Remington Sharp find it tricky:

As a quick tip, I find a helpful way of coming to grips with it is by likening Flexbox to String Theory. Thus, flex-basis is analogous to a Calabi–Yau manifold or similar higher-dimensional analogues of K3 surfaces, and think of flex-shrink as behaving like the 7 compactified dimensions propagating from one point to another by summing probability amplitudes.

Hope this helps.

Reading List

On HTML5 vs Living Standard, W3C vs WHATWG

That nice Stephen Shankland just published a news report HTML5 is done, but two groups still wrestle over Web’s future on CNET, quoting me a couple of times.

As I’m occasionally asked questions about how I see the two different organisations working together (or not), here are the full questions that Steve asked me, and my responses (as approved unchanged by my bosses at Opera). I’m grateful to Steve for giving me his permission to reproduce them.

SS: How big a problem is it that WHATWG and W3C both are sorta kinda in charge?

BL: It’s not an especially big problem for the vast majority of developers who aren’t developing sites using still-fluid features that are only available in the latest nightlies. Where they differ, the W3C spec is a better guide to the stable features as implemented already in browsers – for example, it has dropped the <hgroup> element, warns about the lack of implementations of the outlining algorithm and has much better advice on using the <main> element today to make websites more accessible to people with disabilities.

SS: Which do you think has more power in charting the future of the standard?

BL: Neither. The power is with browser makers. As Ian Hickson of WHATWG said, it doesn’t matter what the specs say if browsers don’t implement them.

SS: It seems kind of like we have two horses pulling the same cart, with no coordination between the horses. Is this a bad use of resources? Or is that a bad metaphor?

BL: The web is the biggest platform we’ve ever had. Therefore, it has more constituencies and competing interests than we’ve ever seen. It’s absolutely right that those different interest groups slug it out. At least it’s (mostly) done openly, unlike the decisions made behind closed doors by proprietary organisations answerable to no-one.

SS: We can’t rewrite history to excise XHTML 2.0, but should the two communities work to converge into one somehow? Is that even possible?

BL: I’d like to see one community , but suspect the cultural clashes are too large. So we have to get along, working together mostly and fighting occasionally, just like a family – albeit sometimes most like the Addams Family.

SS: How much actual real-world confusion is there among developers? Where should they go to see what the “true” spec says?

BL: If you want to see what’s already implemented in browsers now, look at W3C spec. If you want to see what might be coming (or how things may change) look at WHATWG spec.

Opera implements following the WHATWG spec, because that’s where nitty-gritty of the leading-edge stuff is discussed. But we also actively support and participate in the W3C as we see the value in having stable snapshots that developers can refer to, and it’s also the forum for many other vital spec discussions about Web Manifest, Device APIs etc. It’s possible to love both and, as we’re Norwegian, our hearts are full of love for all.

CSS {all: initial} to prevent widgets inheriting CSS from a host page

Imagine you have some sort of widget – an ad box, a sign-up form, some execrable collection of social buttons, whetevs – that you’re injecting into arbitrary pages using JavaScript. You don’t want your widget to get weirdly styled by the host page’s CSS. This is when you want to undo the CSS.

Enter all: initial. This resets all CSS properties to their initial value, and undoes browser stylesheets – in this example, the blockquote is no longer indented or display:block; as you’d expect.

Other values for the property are inherit, which changes all the properties applying to the element or the element’s parent to their parent value, and unset which changes all the properties applying to the element or the element’s parent to their parent value if they are inheritable or to their initial value if not.

They’re supported in Opera, Firefox and Chrome. The Mozilla Developer Network page has good examples of these.

What’s curious, though, is that the value that would be the most useful isn’t there at all. I wouldn’t want to completely strip away User Agent styles and then have to reset elements to display block-level and then indent them in CSS. I wonder why there’s no all: ua-default (or somesuch) to reset them to the User Agent style sheet default?

Update: Saperlipopette! There’s a very good French-language post La cascade CSS avancée: all, initial et unset for those who speak Oohlala.

Reading List

Pointer Events

Microsoft wrote a spec called Pointer Events API that unifies touch, stylus and mouse inputs, and implemented it in IE11 (partially in IE10). Firefox are implementing it too. After initial enthusiasm from Google, Chrome announced that it won’t support it, after all.

  • HTTP 203: Pointer Events – 4 min video in which Jank Architect and Longpoll Lewis explain why Chrome thinks the Pointer Events API smells.
  • Jacob Rossi of Microsoft disputes the claims (G+ link, sorry).
  • More discussion about the Pointer Events Smell video from @SlexAxton, @davemethvin (jQuery): “It all boils down to ‘Why is Chrome+IE+Firefox not enough for Pointer Events, but Chrome+Firefox enough for Touch Events extensions?'”

Other standards ‘n’ shiz

Reading List