Paul Irish

Making the www great

The Skinny on IE’s Update Policy

Every month, WebKit, Firefox and Opera are shipping incredible features; IE10 is also going to settle up and even out those HTML5 Test scores (plus some features they may debut, like Grid Layout!). But while these features are becoming available in some browsers, most of us can’t use them because we have a sizable audience who have been left behind on old browsers. A while ago I made a big fuss about IE’s lack of solid upgrade path and how it meant we’d end up with 10 major versions of IE in the wild. But luckily, things took a turn for the better when Microsoft announced a new autoupdate policy for IE.

I wanted to take a moment to explain what this IE update policy means for us web developers.

The big change is how IE now interacts with Windows Update: Before you had to opt-in to have “Recommended” updates installed automatically. It’s likely few folks did. Now, IE upgrades are shipping as “Important” and this class of updates are defaulted to install automatically. A user can still opt-out and immediately after the announcement of this feature they also published details on how enterprises can opt-out. But still, this is a good move, it helps.

The policy manifests as:

  1. Windows XP holdouts on IE6 or IE7 get the boot up to IE8
  2. Windows Vista and 7 users still on IE7 or even on IE8 get shunted up to IE9
  3. IE10 only works on Win7+, and while no policy has been published for Win7 users, it’s likely any IE8/IE9 users will be moved up to IE10.

A very smart policy call was that this update policy also includes all of China, which is important because most of their Windows installs are not genuine. Microsoft decided they should get the IE bump anyway, which is great because China has been dominated by IE6 and IE8 for ages.

This update procedure was scheduled to start in Australia and Brazil in January 2012. If we look at what happened in Brazil, we have a good shift of users but it’s flattened out with a nontrivial amount of left behind users: (see the two blue lines in the chart below)

(Source: StatCounter Global Stats - Browser Version (Partially Combined) Market Share)

Australia has a similar swap of users from IE8 to IE9 but IE8 still remains steady above 10% overall share there.

Microsoft is in a tough spot in that they have enterprise customers who have developed their intranet applications in an extremely poor manner and they break outside of old browsers. But we’re going to need some more pushes from them and us, the developer community, to get in a better state. We want to develop for the web platform of now, not the platform of four years ago.

TL;DR: There is now a policy in place, but evidence indicates that it’s not as effective in eradicating these zombie browsers as what we need. Personal opinion: we need to do better.

Hopefully this clarifies a bit about the mechanics of the update procedure. Please do correct me if anything is wrong and I’ll update the post.

2012.08.07: Added TLDR. 2012.07.02: To see this update policy in better context it’s probably useful to Read this Developer’s Guide to browser adoption rates and check the charts from Ars Technica below.

2012.09.21: Months later, the net effect of the update campaign is complete. It pushed a whole bunch of users up to IE9 but IE8 usage remains solid. :( WinXP is a big problem here, obviously. We have to explore other ways to move these users off a zombie browser…

(Consider the two blue lines)

Source: StatCounter Global Stats - Browser Version (Partially Combined) Market Share

Accessibility and Developers

Jacob Thornton has an inspiring slide deck on accessibility that brings to fore some of the concerns that web developers have with implementing features around accessibility.

For a very long time, developers have been told about making websites ‘accessible’. Like it is a faucet that should be turned on or off. Till Victor Tsaran’s demonstration of using a screenreader (which was in 2007 - a very long time since accessibility evangelism began) - very few web developers had any idea of the real immediate impact of implementing accessibility features.

During a Nicholas Zakas & Victor Tsaran talk years ago I finally grokked the easiest rule for a first step towards accessibility. For such a long time, we conflated functionality while JavaScript-disabled with “being accessible”. It took me years to learn that making it keyboard-navigable was the top priority.

Just as a datapoint, The WebAIM survey results (published yesterday) reveal 98.6% of screenreader users have javascript enabled.

What we need

People like Jason Kiss and Steve Faulkner who detail the behavior and support in browsers and screenreaders are providing the developer community with invaluable knowledge, stuff that is far more worthwhile than publishing a yet another list of you-should-do-these-things. (See also my resources list in the semantics post).

Most developers have no idea what effect adding ARIA markup to our documents has on people using screenreaders. We need that. Actual before-and-after video stuff makes this topic real. See zomigi’s recent post: videos of screenreaders using ARIA, for great examples.

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is not at all appropriate for a web developer audience.

Just like it’s valuable to witness an a11y usability session where you see how disabled people use your site, I think it’d be useful for the accessibility community to see how developers build, because thus far there has been a disconnect in communicating effectively. I don’t think we need more on the ground evangelism yet. There is a dearth in online resources at the moment, developers need to know these practical ways of using and having users benefit from accessibility techniques:

  • Which features should I use and which should I avoid (which features are actively harmful because of shoddy screen reader/other a11y tech support?)
  • What are the top priorities for developers to implement?
  • Videos of screenreaders in use (Thanks Zoe!)
  • What one thing can I do as a web developer to my sites and apps that dramatically improves the UX for disabled users
  • How do some of these features work? What are they for? A demonstration of how each feature makes an impact or gets used by a user would be most helpful (e.g. how do focus rings work?).

Screenreaders & browsers

Also, I’m not quite sure how everyone else feels, but from here it feels like yelling at a fucking brick wall with JAWS and Window Eyes. We just kinda hope and pray their support for things improve. As a pragmatic approach, I tell developers that if it works in NVDA, good enough. We have a mess of browsers we need to support already, dealing with ATs that lag years behind is not at all feasible.

A lot of developers do not understand that accessibility first comes from implementing the platform accessibility API by browsers such that screen readers can take advantage of the rendering. Most operating systems expose an API that allows browsers to map what is rendered on the screen to one of the interfaces that the operating system’s accessibility API exposes.

A series of stairs and a ramps interleaving between them

Unfortunately, there has been no specification, so each browser has been left to do whatever it wants in terms of defining the relationship between a HTML element and the accessibility interface. Hopefully this will change with the HTML to Platform Accessibility API implementation guide and ensure each browser exposes each element consistently to the Platform Accessibility API.

Which shores up a greater concern: Better accessibility starts with the browser (and the platform). Browsers should be able to handle content loaded dynamically rather than expecting developers to do it for them. If content on a page that is displayed is altered, it needs to be noted to the accessibility api transparently instead of having developers bolt on extra markup to do so.

Accessibility should not be opt-in but opt-out.

This post is a elongated version of the comment I left on Karl Grove’s Barriers to improving the accessibility game plan. It was probably the best post on a11y I’ve ever read. I really liked his approach in evolving the a11y strategy and left my thoughts.

Thanks to Divya Manian for her thoughts and words on this post. Thanks to Jason Kiss for reviewing drafts.

June 1: Added link to freshly published WebAIM survey results 2012. I encourage you to read the whole thing, as it’s a fascinating view into an audience we have challenges understanding.

2013.06.06: This has been translated into Czech: [Dostupnost a Vývojáři](

Talk: Tooling & the Webapp Development Stack

One of the things I recognize at Google is how productive developers surround themselves with powerful tools for iterative development and debugging. For us front-end developers, the ecosystem of tools has exploded in the past two years, as we have a lot more software and libraries beyond Firebug and jQuery to help us build webapps. In the talk below I walk through the current ecosystem of tools and how they can make your development experience a more enjoyable one.

My slides:

Because there are so many tools around, I wanted to break them down somehow. I think contextualizing the tools as to what phase of development that assist with works well:

(You could think of the Y-axis here as the amount of code in a project..)

Looking at our tools this way we end up with:

  • Boilerplate
    • You likely start a project with more than a single blank text file.
  • Authoring Abstractions
    • CSS preprocessors, Languages that transpile to JS, Templating
  • Frameworks and Application Stack
    • Clientside MVC, UI Components, Widgets
  • Iteration Workflow
    • Browser Devtools, Browser/Unit/Integration Testing
  • Performance Tuning
    • Profiling, Memory mgmt, browser instrumentation
  • Build & Optimization
    • Minifiers, Concat, Image compression…
  • Deploy
    • Continuous Integration, Continuous deployment

I’ve been thinking a lot about workflow and integrating these tools together. Screencasts like Andrey Tarantsov’s Sublime Text Workflow really excite me and I’m eager to see more people exploring a robust development setup.

2012.05.16: Mr Jon Kemp wrote up an outline of my talk with all the links, for easy clickability: