Parroting Pareto

One of the principles underlying the design and development of microformats is to adapt to current behaviors and usage patterns. This ensures that microformats are built upon data that people are already publishing. It’s a lot easier to get people to format existing data than it is to change what they publish entirely. That ties in with another principle: ease of authoring is important.

A lot of the watchwords of microformats dovetail nicely with , also known as the 80/20 rule. In the case of microformats this means aiming for low-hanging fruit and solving 80% of the problems with 20% of the effort.

The Pareto principle has proven to be a very good guide for microformats, especially when you consider :

  • infinitely extensible and open-ended
  • an attempt to get everyone to change their behavior and rewrite their tools
  • a whole new approach that throws away what already works today

The success of microformats can almost certainly be attributed to the Pareto-driven principles underlying their creation. That success—and the success of the community clustered around microformats—has prompted other movements to adopt similar working principles, WHATWG being the most visible exemplar.

But…

I am more than a little concerned at the way that studying existing behaviour is being held up as a make-or-break point in discussions around HTML5. Unlike microformats, HTML does need to cover a lot of situations including some that fall far outside the 80%-90% curve.

Accessibility is the most obvious area of contention. By their very nature, accessibility concerns are not going to affect the majority of users. That doesn’t mean they can be dismissed. This is as true for microformats as it for HTML5. Technically, the could be dismissed simply by invoking the Pareto principle but that would clearly be an untenable position. Instead, the microformats community and the accessibility community have been working together towards possible alternatives (the first step being to document test cases—the have been working their asses off at that).

So accessibility is an area where the Pareto principle simply doesn’t hold up, in my opinion. That’s why I’m concerned by Mark Pilgrim’s dismissal of the longdesc attribute. It’s a well-reasoned dismissal founded almost entirely on existing behaviour: most people aren’t publishing images using longdesc, therefore it should be dropped. Similar research has been used to justify the non-requirement of the alt attribute and, God help us all, the reintroduction of the font element. It’s all very well-reasoned and logical. It’s also, in my opinion, wrong.

We know that most Web pages are crap— is a relative of the Pareto principle. If existing behaviour is given such importance in the development of HTML5, then the format will only end up codifying what most people are publishing: crap, in other words.

The longdesc situation is a classic case in point. Here’s an attribute that is actually supported in assistive technology; an unusual situation, given Freedom Scientific’s usual glacial pace. That’s not the problem. The problem is that not many people are implementing longdesc. The solution is either:

  1. educate publishers or
  2. provide an alternative and lobby screen-reader manufacturers to implement it—good luck with that.

I’m not having a go at Mark here and I don’t want to single him out at all. My concern lies with the over-reliance by the WHATWG on the Pareto principle in general and existing behaviour in particular. I think that justifications based on raw numbers are behind most of the concerns of the HTML 4 All group.


On an unrelated note… let me quickly point out another issue with the Pareto principle, unrelated to HTML. The 80/20 is misleading. Human minds are pattern recognition machines; as soon as we see the numbers 80 and 20, our brains jump to the conclusion that they are both fractions of the same total (100). In fact, they are percentages of different totals. The Pareto principle could just as easily be the 80/30 rule or the 90/20 rule.

Have you published a response to this? :