Bruce Lawson’s personal site

Yesterday I was writing a presentation about web accessibility to deliver at Southamption University as part of an Opera Education university tour, and decided to include an example of a site that was a business for disabled people.

The example I used was of soundsdirty.com, a website full of erotic mp3s for the visually impaired. (Previous safe-for-work write-up.)

They had movies with subtitles and audio description. They had an excellent visual design statement:

This site uses cascading style sheets for visual layout. This site uses only relative font sizes, compatible with the user specified “text size” option in visual browsers. For a detailed overview of how to change font in your browsers please visit the ‘customize site’ link (access key U)
If your browser or browsing device does not support style sheets at all, the content of each page is still readable. The site has the ability to quickly change the font and background color to a high contrast black and white page layout. This feature is recommended for partially sighted, dyslexic and color blind users.

They had the most interesting access keys I’ve ever seen:

• Access key E - Erotic Stories
• Access key F - XXX Films
• Access key X - Sex Sounds
• Access key M - Member Stories
• Access key D - Doctor Erotica

And even a panic button:

The site contains a ‘Blank out link’ (access key Q). This feature jumps to a blank page and will stop all assistive technologies. This feature can be useful if you need to get off the site quickly!

And now the domain name goes to one of those stupid “this domain has been acquired for a customer” placeholders.

I really hope it hasn’t gone .. well, tits up, as it was a good and memorable example of web accessibility. And it gave me the opportunity to title a slide “sounds dirty, code’s clean”.

One of the things that have long irritated me about HTML is the restriction on what elements are allowed inside lists.

The specs for both HTML 4 and 5 allow only li for ul, ol, and only dt and dd are allowed inside dl definition lists. I’d like to expand that to allow h1…h6, section and div.

I was talking to two of Opera’s Standards reps, Anne van Kesteren and Lachlan Hunt, about this and they suggested that I make a proposal to the HTML 5 working group, with appropriate use cases.

So before I make a tit of myself by putting flawed proposal to that somewhat grumpy group, I thought I’d do what Eric Meyer did and ask developers at large what you think. Here’s my reasoning—and if you have any more use cases or objections, please let me know.

Allowing headings (h1…h6) in lists

Until recently, I worked for the Law Society and Solicitors Regulation Authority. In such a business, we spent a lot of time marking up rules, regulations and statutes.

In the UK, as most (all?) other jurisdictions, laws and rules are written with numbered paragraphs. Within those lists are headings that introduce sections. The headings are not part of a list item, but group list items. Check out any of the thousands of examples at Office of Public Sector Information or the UK Statute Law Database.

Here’s a small but nevertheless real-world example: take a quick look at the Solicitors’ Practising Certificate Regulations 1995 (PDF 34K), which I naturally want to mark up like this:

<ol>…
<h2>Commencement</h2>
<li> These regulations replace the Practising Certificate Regulations 1976 in relation to all practising certificates, and applications for practising certificates, for any period commencing on or after 1st November 1995.</li>
<h2>Requests for information</h2>
<li>In addition to information supplied on any prescribed form under these regulations, solicitors must supply to the Law Society such information as to their practice as solicitors as the Society shall from time to time reasonably require for the purpose of processing applications.</li>
<h2>Replacement date and conditions</h2>
<li>The replacement date for every practising certificate shall be the 31st October following the issue of the applicant’s current practising certificate.</li>
<li>Every practising certificate shall specify its commencement date, its replacement date, and any conditions imposed by the Law Society</li>
…</ol>

You’ll notice that the heading "Replacement date and conditions" is not part of either of the following two items, so is not a child of either li. Instead, it groups (or introduces) them, and therefore, its semantically most appropriate location is as a child of the surrounding ol.

Another way to mark up this document is as a succession of headings and paragraphs, with each paragraph beginning with a hard-coded paragraph number, perhaps surrounded with a span that is styled with dislay:block; in order to make the number look like a list marker. This spectacularly fails the Bruce Lawson Markup Duck Test which states that if it looks like a duck, walks like a duck and quacks like a duck then it is a duck: a list of paragraphs, each beginning with a number indicating the order of the paragraphs is an ordered list, and needs to be marked up as one.

Take a more complex example, Legal Services Act 2007, paragraphs 203-206. This legislation is a long list of numbered paragraphs, interspersed with headings to group the following paragraphs into sections. Being more complex, this legislation has nested (ordered) sublists, but the same logic and basic structure holds here too:


<ol>
…
<li><h5>
The giving of notices, directions and other documents in electronic form</h5>
<ol>
<li>[subparagraph 1]</li>
<li>[subparagraph 2]</li> …
<li>[subparagraph 8]</li>
</ol>
</li>
<h4>Orders, rules etc</h4>
<li><h5>Orders, regulations and rules</h5>
… lots of subparagraphs …

</li>
<li><h5>Consultation requirements for rules</h5></li>
<li><h5>Parliamentary control of orders and regulations</h5></li>
<h4>Interpretation</h4>
…
</ol>


A counter argument is that that these whole piece of legislation is an ordered list of sections, each containing a sublist list of paragraphs within that section.. And that is an legitimate way to look at it, except that the actual numbered paragraphs would no longer have the correct paragraph numbers auto-generated, as they’d be split into sublists.

Playing with CSS counters wouldn’t help, as different lists are treated as separate entities, so numbering in one list can’t follow on from numbering in another list. To avoid the paragraph immediately below a section heading (the h4 in my code example above) going back to 1, you would have to give the li a start attribute and hard-code the paragraph number, making a mockery of the idea of automatically generating numbers in ordered lists. Even if it could be faked with CSS counters or hardcoding the start attribute, it shouldn’t be because that fails the Duck Test, too.

HTML 5 sections

For HTML 5, it would be ideal if the spec allowed the new section element to be a child of a list. This means that content could be pulled from a CMS into different pages with different heading hierarchies, and the headings would automatically be the correct level within that context. This is an idea from the XHTML 2 spec, which has an unnumbered h element:

Structured headings use the single h element, in combination with the section element to indicate the structure of the document, and the nesting of the sections indicates the importance of the heading. The heading for the section is the one that is a child of the section element.

In HTML 5 this is complicated by backwards compatiblity, so any heading element from h1…h6 can be chosen, and the headings and sections algorithm determines what “level” it actually is. (See A Preview of HTML 5 for a more readable discussion of section).

I’ve marked up the Practising Certificate example as HTML 5 and styled the various different levels of h1s using CSS so you can see a practical example of the usefulness of allowing headings and section to be children of a list.

Headings in definition lists

An example in a definition list would be similar. Here’s a real-world glossary marked up as a definition list (which is the best way to mark them up, in my opinion, although some favour tables).

A really long alphabetical glossary would be enhanced by dividing it up with headers for each letter of the alphabet, for reasons of scannability, or so an on-the-fly table of contents generator could make a linked table of contents above the glossary.

That could be done by the following (illegal code):

<h1>Glossary</h1>
<dl>
<section>
<h1>A</h1>
<dt>Aardvark</dt>
<dd>Never hurt anybody</dd>
<dt>Allegro</dt>
<dd>The lower limbs of people standing side-by-side</dd>
<dd>The finest car known to man</dd>
</section>
<section>
<h1>B</h1>
<dt>Bee porn</dt>
<dd>See Christian Heilmann, Tom Hughes-Croucher</dd>
</section>
</dl>


You might say that each letter of the alphabet should have its own dl. I contend that a glossary is a single entity, not twenty-six different lists and would reply "Tish and pish, sir. You are a nincompoop, and your words are balderdash, poppycock and gobbledegook."

And I’d be right, and you’d be sorry.

Allowing div as a child of a list

While we’re talking of rules and specifications, I’d like to know why I can’t use div inside a list.

Mostly I’d like to do this so that I could properly style definition lists to look like tables.

You can’t reliably style definition lists at the moment, but you can if you can wrap a dt and its associated dds in a div. This is illegal, but works cross-browser already.

I agree with the HTML 5 gang when they refuse a new grouping di element (presumably "definition item"), saying "This is a styling problem and should be fixed in CSS. There’s no reason to add a grouping element to HTML, as the semantics are already unambiguous."

Yes, there is no reason for a new definition grouping element; we already have a generic grouping element called div. And, yes, it’s true that it’s a problem for CSS, but with all the other stuff on the CSS Working Group’s agenda, they’re unlikely to get round to it soon.

It must be a common problem (the HTML 5 crew cite it as a "frequently asked question") and it can be easily solved using the interoperable, backwardly-compatible method I outlined above.

It also raises a philosophical question: I can understand why there are restrictions on where some elements can go (for example, it would make no semantic sense to allow a list inside an image), but why restrict where an author can put an element that has absolutely no meaning ("The div element represents nothing at all")?

Conclusion

I see the argument against over-complicating a specification, but I think that if a new spec can’t accommodate real-world examples of content then the specification is not in danger of over-complication—rather, it’s currently over-simplistic. HTML 5 has been bravely making itself backwards-compatible and thereby becoming more complicated in some areas (such as the algorithm for working out the importance of headings in sections), so slight extra complication to help developers can also help its adoption.

Thank you for reading this far, dear reader. Am I talking nonsense? Have I missed something obvious? Do tell, before the HTML 5 gang employ sarcasm or scorn at me.

Introduction

This is Opera Software’s response to the Public consultation on browser standards for public sector Web sites by Central Office of Information (COI).

Opera Software ASA is a company headquartered in Norway. Noway is a signatory to the European Economic Area Agreement, which guarantees free trade with all EU states and cooperation in such matters as consumer protection, culture, education, and information services (see http://www.eu-norway.org/about/eeaforside.htm).

Many of our users are within the United Kingdom and the European Union, and we feel that the draft guidelines (“the guidelines”) potentially disadvantage them.

We support the aim of the COI to ensure inclusion by testing public authority Web sites on a range of browsers. It is also laudable that the COI requires that Web sites be made accessible to people with disabilities and across multiple operating systems.

However, we feel that there are some aspects of the browser guidelines that need re-drafting. We request that our concerns be considered and give permission for them to be quoted with attribution in any report on this consultation.

Executive summary

Opera believes that the current guidelines attempt to reinvent a wheel that has already been satisfactorily invented and refined over time by other large organizations, both public and private. Reusing their work reduces costs to taxpayers.

Also, Opera believes that the guidelines in their current form

• are anti-competitive, as they perpetuate dominance in the browser market by giving the impression that alternative browser products are inferior, and those who choose to use them are not worthy of consideration,

• inconvenience users unnecessarily by asking them to install new software,

• do not promote best practice development and may lead to more expensive development and testing,

• are too fragmented,

• insufficiently “future-proof” Web sites, by ignoring methodologies which would ensure compatibility with mobile phones and other devices,

• ignore plug-ins which have capabilities independent of browsers, and

• do not sufficiently ensure accessibility by disabled users.

Recommendations

The guidelines should recommend using Web standards and a best-practice development methodology called “progressive enhancement”. This will help ensure compatibility across browsers, rather than aiming at different browsers as if they are completely separate targets.

For testing, the guidelines should recommend adoption of browser support matrices such as the one provided at http://www.bbc.co.uk/guidelines/futuremedia/technical/browser_support.shtml/ by the BBC, which is a well-respected Web brand with a public-service duty and a huge, diverse audience.

This would support

• greater competition in the browser market

• greater value for money for taxpayers

• more consistency for Web visitors and developers, and

• savings on Web development costs by promoting Web standards and proven methodologies.

These benefits are also noted in the BBC’s Objectives of Web browser support, which gives the methodology by which their browser-support matrix was devised at Appendix 2.

Guidelines restrict choice

Guidelines confuse popularity with capability

Paragraph 15 says “There may be specific browsers that you choose not to fully support because they are either old or unpopular.”

It is legitimate to choose not to support old browsers fully that are not capable of rendering sites made with Web standards and progressive enhancement.

However, it is wrong to decide not to support a browser purely because it is “unpopular”. If it is capable of rendering the site, it should be supported.

The guidelines’ introduction states, "It is important to declare which browsers your website has been tested on. This demonstrates a clear commitment to your audience. Users will want to know whether or not your website works with their browser."

We disagree. By naming the browsers on which a Web site has been tested (simply because they are more “popular”), the impression is given that browsers that were not mentioned are somehow “second class”, and its users are not worthy of attention, which demonstrates a clear lack of commitment to audience needs.

We recommend adopting a testing statement such as that used by the Solicitors Regulation Authority:

Browser compatibility

It doesn’t matter how old your browser is—you can use this website. It looks different in some older browsers, and is mostly text in very old browsers (like Netscape 4, or Internet Explorer for Macintosh). But the information is the same, and so are the things you can do.

Guidelines inconvenience users

This erroneous impression of less “popular” browsers as being inferior is reinforced in the sample “browser support statement” in paragraph 12.

Webmasters are advised to list browsers they have tested in as “supported”. The example browser support policy statement includes the message "We advise you to upgrade your browser version as far as your computer allows and if possible to one of those listed above".

There are also many reasons why a user may not be able to change their browser easily – for example, they

• may not be using their own computer and be on a shared computer; therefore, they are unable to change or update the browser,

• may use a particular browser because of security or privacy settings,

• may use a particular browser due to features that help them access and are unable to use another browser comfortably,

• may not know how to change their browser.

Many users of the most “popular browser” made no conscious choice to use that browser. On the other hand, we know that many Opera users choose Opera because of features such as excellent keyboard support, the built-in voice browser, intelligent zoom, and fit-to-width display, which are very useful for people with disabilities. It is unreasonable and unfair to suggest that they upgrade because a Webmaster has elected not to test in Opera.

Potentially anti-competitive

Not only does this inconvenience the user, but we strongly believe that this is anti-competitive.

The guideines help perpetuate current market shares by encouraging users of “unsupported” (in reality, “untested”) browsers to replace their current browser with another.

(Disclosure: The EU Commission are opening an investigation into an anti-trust complaint filed by Opera on 12 December 2007, regarding Microsoft bundling Internet Explorer in the Operating System and not implementing Web standards.)

Guidelines do not promote best practices

The guidelines are published because it is “impractical and inefficient” to test in all browsers. Presumably this should be interpreted as the COI suggesting that it is not cost-effective to do so. However, it is unnecessary to do so if best-practice Web development is followed.

Best practices should be central to guidelines

The section “out of scope” notes, “How to code for browser compatibility [and] Development methodologies such as graceful degradation and progressive enhancement,” are out of scope.

Additionally, paragraph 40 notes “These guidelines do not advocate specific development methodologies, for example, graceful degradation or progressive enhancement. However, it is widely accepted that sites conforming to open Web standards such as XHTML and CSS are more likely to work well across a wide range of browsers. The importance of working to technical standards is highlighted in Minimum technical standards”.

Opera believes that the guidelines must recommend the development methodology known as “progressive enhancement” which, when based on Web standards, would reduce inconsistencies between browsers resulting in greater interoperability.

When this methodology is employed, users of the most capable browsers automatically receive the highest quality user experience, while users of less capable browsers will receive content and be able to access basic functionality. Therefore, no-one will be “locked out", whereas being "locked out" is much more likely if you choose consciously to test only in/support specific browsers.

Guidelines erroneously treat Web as a visual medium

The guidelines treat the Web as if it were a visual medium such as print, in which designers specify pixel-perfect layout and can rely on that being delivered to the consumer.

This is not true and is inappropriate for public-service websites, where the emphasis is on content rather than aesthetics.

Paragraph 41 says, “A browser is semi-supported if the content and navigation works but the website does not display as intended”.

It is incorrect to judge a Web site on whether it displays “as intended”. A Webmaster cannot mark a browser “down” as semi-supported because it does not have curved borders, opacity, or the same fonts as those on a designer’s machine.

By emphasizing “intention”, the guidelines legitimize preservation of design as a goal. In the past, this has led many bad design decisions such as fonts being expressed in pixel sizes which cannot be resized in Internet Explorer, for example.

The Web site should be judged on whether the recipient can use it in a format that (s)he wishes. If, for example, a browser mis-renders a site built with Web standards, such that content is obscured or is illegible, then that browser is unsupported.

If a browser renders the content as legible, the navigation usable and functionality operable, then that browser is fully supported in the context of a public-service site.

Best practices lead to cost-savings

Recommending best practices whereby developers code to internationally-agreed standards rather than to circumvent the quirks of today’s market leaders leads to cost savings throughout the life-cycle of a Web site:

• It is more cost-effective to build right than to correct during testing, so explicitly advocating progressive enhancement results in more efficient development and Web sites being quicker to market.

• Reducing inconsistencies through smarter development ensures that the “testing” phase is shorter and, in the case of static pages of content, it should be possible to reduce testing to a quicker “verification” stage that quickly checks across a range of browsers that there are no significant inconsistencies.

• Once deployed, Web sites built using valid, semantic (X)HTML and CSS are more maintainable because they are in accordance with international standards.

Guidelines are too fragmented

The guidelines mention design methodology and minimum technical standards in paragraph 40, but it is a leap of faith to assume that everyone else will read the second document.

The guidelines are written “for all website managers, web developers and web testers delivering public sector websites”, so we recommend that all the guidance relevant to these groups be amalgamated —or developers will naturally assume this supersedes all other guidance and start developing to browsers.

Additionally, the “Minimum Technical Standards” document is dated May 2002 and is obsolete; it mentions CSS 2 as the latest version, allows HTML tables for layout, and does not mention Scalable Vector Graphics (SVG).

Opera recommends modernizing this document and incorporating the updated guidelines into a comprehensive document aimed at the target audiences named on the cover.

Guidelines do not address mobile and other devices

Paragraph 39 notes that Guidance on support for mobile platforms will be the subject of future guidance. Other devices are described are similarly “out of scope”. (Paragraph 37 also notes, “Guidance on support for mobile platforms will be the subject of future guidance”; we assume this is an editorial error.)

This further fragments the guidelines, as readers will have another set of guidelines to check.

Different guidelines are unnecessary. Recommending a progressive enhancement methodology ensures that Web pages work across all browsers and devices.

Guidelines ignore plug-ins which are independent of browsers

The guidelines ignore the subject of browser plug-ins, such as those that allow readers to access PDF, MP3, video, and Flash content. These plug into a browser but are independent of it. Therefore, a group of users running the same version of a browser may have different versions of plug-ins and receive markedly different experiences.

For example, a visitor running Opera 9.5 with Flash Player 6 would not be able to take advantage of any accessibility features built into a Flash movie, while a visitor running Opera 8 with Flash Player 7 would be able to use those accessibility features, because the plug-in has a higher specification, even though the browser is less capable.

The guidelines should address plug-ins, independently from browsers.

Opera also suggests that the guidelines for Web developers require the use of open standards wherever possible, while allowing content that requires plug-ins as a secondary delivery method.

Guidelines should recommend testing by disabled users

Opera welcomes the guidelines’ inclusion of a requirement that Web sites be tested with assistive technologies.

However, the guidelines currently legitimize a sighted developer using a trial version of a screenreader and comparing the synthesized speech with the words on a screen, which is inadequate testing; a sighted user cannot have the same experience or knowledge of the tool as a real user.

Therefore, we believe that it should incorporate guidance from the British Standards Institution’s Publicly Available Specification (PAS) 78, Guide to good practice in commissioning accessible websites:

• “All organizations, regardless of size, should ensure that those testing the website are different from those developing it.”

• “Website commissioners should conduct user testing with disabled participants to ensure that their websites are accessible and usable by disabled people”

• User testing should include users from a range of disabilities and preferences, including a mix of beginners and experienced web users using a range of assistive technologies.

Inadequate definitions/ ambiguities

• Paragraph 46 suggests testing “ability to bookmark” as part of testing a Web site. That is a browser feature, not a developer-authored feature and thus out-of-scope.

• Why are Rich Internet Applications separated out? The requirement for sites to work with scripting turned off, etc., is not solely related to RIAs.

Too many trademarks used in examples

We would prefer it if more than one trademark were used as illustrative examples, or none at all, as currently the guidelines erroneously give the impression that only one browser exhibits the qualities being discussed.

For example, we would prefer it if paragraph 50 were redrafted to read, “Certain browsers (e.g., Firefox and Opera) are developed using cross-platform technology (e.g., Java) and, therefore, behave similarly on different operating systems,” or “Certain browsers are developed using cross-platform technology …”.

Contact details

These comments were written by Bruce Lawson, a Web Evangelist representing Opera Software ASA. Bruce may be contacted via brucel@opera.com for any clarification of these comments.

Comments on the Opera developers’ network, please; no login required.

The Web Accessiiblity Initiative’s Accessible Rich Internet Applications Suite, WAI-ARIA is a simple way to add information to HTML that can make Ajax applications accessible. It’s being supported by all the big four browsers and screenreaders are starting to support it.

Therefore, although the specification is still formally in “Working Draft” status, the W3C are encouraging authors to use it now. I plan to; it’s the only game in town to add the necessary semantics to lovable old HTML 4 until HTML 5 is widely implemented.

To encourage adoption, there is a mailing list called the Free ARIA google group which you can read and join.

Opera is taking the message to the Ajax crew at the Ajax Experience conference next week, and Anne Van Kesteren is presenting “Ajax 2.0” in which he’ll introduce and demo ARIA (and other exciting things).

Speaking from my experience as a web author, though, one of the things that might slow adoption is the fact that new semantics like ARIA don’t validate against the old HTML specs. As someone who has spent half a decade badgering people about valid code, I know that lots of enlightened organisations don’t allow invalid code on their websites—and these are just the kind of thought-leaders who I’d like to see adopting ARIA.

The experimental HTML 5 validator has support for ARIA but doesn’t have the kudos of the W3C name.

So, I suggest that the W3C to add ARIA to the official validator. That would send a strong message about its commitment to ARIA, as well as allow codeshops, organisations and individuals who want validation to use it, to the immediate benefit of web users with disabilities.

Added Tues 30 September: Steve Faulkner, of the Paciello Group and member of the W3C’s Protocols and Formats Working Group has asked if the W3C can build an a validator that can test (X)HTML and ARIA conformance.

When I was told that our Fronteers conference talk on Accessiblity and SEO was being videoed, I warned my co-presenter, Vasilis, not to watch himself under any circumstances. (Though you might want to watch it- transciption “coming soon”).

He didn’t heed my warning, and told me today “I didn’t listen to your advice, I watched part of the video of our panel session. I haven’t left the house since and I only talk when it’s dark (-:”

I only managed to sit through 30 seconds - long enough to tell myself to

• stop fidgeting
• stop chewing gum
• lose 10 kilos

and was somewhat chastened to see the first Google ad next to the vid says “Cut down 9 lbs of stomach fat every 2 weeks by obeying this 1 tiny rule”. Even Google thinks I’m fat—the bastard.

Couple of other things:

• The second batch of the Opera web standards curriculum has been released. This deals with CSS. I particularly like the articles by Tommy Olsson, who has a knack of finding simple terms to explain difficult concepts like inheritance and cascade, floats and clearing and the different positioning models (static and relative, absolute and fixed).
• Our monthly State of the Mobile Web report is out: this month is on the “long tail effect” in which users spend a lot of time looking at the less popular Web sites. I’m very interested in matters mobile, now I’m officially a member of the W3C’s Mobile Web Best Practices Working Group.

A while ago, Eric Meyer suggested that HTML 5 should allow any element to turn into a link by taking an href attribute - see his Any-Element Linking Demo. I suggested that, as a stop gap, HTML 5 should legalise the fact that all the big five browsers already allow the a element to surround multiple elements and block level elements.

I’m delighted to report that my fellow Opera lovegod, Anne van Kesteren, tells me that HTML 5 now legalises this behaviour. So instead of coding a news “teaser” like this:


<h3><a href="story.htm">Bruce Lawson as Obama's running mate!</a></h3>
<a href="story.htm"><img src="bruce.jpg" alt="lovegod" /> </a>
<p><a href="story.htm">In answer to McCain's appointment of MILF, Sarah Palin, Obama hires DILF, Bruce Lawson, as his running mate. Read more!</a></p>


you can say:


<a href="story.htm">
<h3>Bruce Lawson as Obama's running mate!</h3>
<img src="bruce.jpg" alt="lovegod" />
<p>In answer to McCain's appointment of MILF, Sarah Palin, Obama hires DILF, Bruce Lawson, as his running mate. Read more!</p>
</a>


You can’t nest anchors (”there must be no interactive content descendant”) because that wouldn’t be compatible with current browsers.

2022 can’t come soon enough!

(Of course, you can do this now; that’s kind of the point with lots of the HTML 5 spec.)

Added 2 October: something’s missing

What I can’t believe I didn’t notice until today is that the HTML 5 spec doesn’t handle making rows in tables into links. Ironically, this was Eric’s original use-case—and the main feature of his demo. I noticed it when looking at the WHAT-WG’s FAQs for something else.

Presumably, it’s not in the spec because it’s not backwardly compatible. Bugger.

What a lovely city Amsterdam is. And what jolly civilised people the Dutch are. I had a lovely couple of days at the Fronteers conference.

The organisers laid on a boat trip through the canals of Amsterdam, free conference beer during the afternoon break of each day and an aftershow party with traditional Dutch food.

I challenged the Pete Le Page from the Internet Explorer team to a drinking contest. Although I initially threatened to drink so much that he would have Layout, we eventually called a truce thanks to the diplomacy of that Henry Kissinger of DHTML, Stuart Langridge (seen making the peace sign). The other presenters were as charming as Pete, and I was especially glad to meet Vasilis van Gemert, with whom I’d worked to get our slides together.

Thanks PPK, Fronteers members and all the attendees for a lovely conference.

The slides for the panel that Vasilis and I presented on SEO and accessibility are on the Opera Developer’s Network.

A mixed bag of a post as I rush to get a plane to Amsterdam for the Fronteers conference that starts tomorrow (I’m speaking—come along!).

UK government draft browser guidance is daft browser guidance

I’ve written a piece for the Web Standards Project about a new government consulation on proposed guidelines on browser testing. Sounds yawnorama, I know, but please read it and respond to the government: if it goes unchallenged, it will reduce choice, inconvenience users of government websites and lock smaller browsers (like Opera, who I work for) out of the market. It looks like we struck a chord; Adam, who wrote the draft guidelines, says that they’ve had approximately 400 responses already. In three days!

Accessiblity in suit and tie

I’ve written a piece for thinkVitamin called Accessibilty in suit and tie about how to “sell” accessibility inside a corporate organisation, with crap technology and the like. It’s a more generic version of my long long article Standards-based corporate web development.

Hello Henny!

When I started at Opera, the top guys said to each other “Why do we only have one übergroovy kickboxing accessibility-lovin’ glamorous web evangelist? We need two! And make the other one a dame!”. Three months and an executive notice period later, in comes Henny Swann fresh from the RNIB and WaSP. (Note to Nate Koechley: Yes, Henny is a girl.)

What a great team of good-looking guys and gals I work with.

New Opera releases

Want to build your own browser in a device?

Then use the Opera 9.6 SDK to build an Opera browser in your TV, picture frame, tablet etc. This new version comes with the same compression used for Opera Mini on mobile phones, so it’s pretty jolly fast. (Developer documentation)

Opera 9.6 beta released

We’ve also released a beta version of Opera 9.6 desktop. This adds some privacy settings I like (so bookmarked URLs don’t appear in the autocomplete address bar, which can be embarrassing at presentations) and adds a low-bandwidth mode for the Opera mail client, plus some useful UI tweaks. Download it but please be aware it’s beta software, so please install it separately from your current 9.5 install

Multipack meeting on Saturday

For West Midlands web developers, and those who care for them, there’s the regular multipack meeting at The Old Joint Stock in Birmingham, to catch up with all the goss from Geek in the Park and dConstruct. Wish I could be there (but will be flying in from Amsterdam) as it’s always a pleasure and a warm welcome.

The summer hols are over and it’s conference season again. This week, on Thursday 11 and Friday 12 September, I’ll be at Fronteers in sleepy Amsterdam, speaking with the lovely Vasilis about SEO and accessibility. Chris Mills from Opera will be talking about Professionalism, and Anne van Kesteran will present on video in HTML 5.

In addition to the Opera Tambourine Band, you can see luminaries like Microsoft’s Pete Le Page pimping discussing IE 8, Christian Heillman and Stuart Langridge doing inimitable JavaScript ginger ninja things, and the co-inventor of CSS, Bert Bos, will be talking about the CSS box model. (Here’s the full line-up).

PPK is the organiser, and says that it

will focus narrowly on CSS and JavaScript…We have asked all speakers to dig deep into one narrowly defined topic of their choice. Therefore the Fronteers 2008 sessions will likely have a highly technical bend and discuss advanced tips and tricks.

Tickets are 250 Euro-thingies (which is about £200 in proper money) for both days, lunch and Party. See you there, I hope.

dConstruct 2008

I had a jolly good time for my first ever dConstruct, as evidenced by my dConstruct 2008 Photos. Despite the horrid weather and over-abundance of beer, I even managed to listen to some sessions.

The highlight for me was Joshua Porter’s “L****aging Cognitive Bias in Social Design” (sorry, I can’t bring myself to type the L-word). There were lots of interesting copywriting and design techniques discussed, and a very useful statisitic: on one client website he increased sales by between 10 and 20% simply by removing the requirement to register with the site before the purchasing process.

Opera sponsored the transcribing of the speeches, so I’ll soon put a link to that speech here (but here’s Alistair Campbell’s notes for now.)

The people at the conference were awesome; it was great to hang out with old mates like Matt and Pete Aylward and new mates like the lads from Finland, the groovy accessibility chicks and Jake Smith, a scouser with the temerity to call me a “pint-sized walking ASBO“.

Usability people wanted

Want to be Bristol’s answer to Jakob Nielsen? Well, you can’t be, because Alistair Campbell does that. But the company he works for, Nomensa, are hiring usability people, so send them your CV. If you get the gig, you owe me a meal out. Deal?

I’m a Web Evangelist for Opera, but this post does not represent the official Opera position.

It comes as no surprise that Google was working on its own browser. When your entire multi-billion dollar business is on the web, you’re inevitably going to want some control over the mechanism by which people view it.

I imagine that Chrome was built as a Google Docs viewer. Google owns search, so can serve up adverts when people are doing that. But most people spend a lot of the day typing into Word, Excel etcetera, and not looking at Google’s adverts. Similarly, most people don’t use the vast majority of the features of Microsoft Office, so don’t need to pay the large sum of money that the Office suite costs. If those people can be persuaded to use Google Docs, Google can simultaneously deprive Microsoft of some revenue while showing discreet ads in the document.

Google Chrome has Gears built in, so people can work on the document when they’re off the web, and save shortcuts to documents on their desktop, just like a traditional desktop application. It’s also why Chrome is relatively lacking in chrome and browser controls: it feels less like the web and more like the desktop.

It seems to me that Chrome is designed to compete with Microsoft Windows as an Operating System and Office as an application: Microsoft’s biggest revenue earners (as far as I know).

It surprised me that it didn’t choose Gecko (the engine that powers Firefox), having invested so much in making Firefox fly. But I guess it pays not to keep all your eggs in one basket. Certainly, it doesn’t want to kill Firefox; it still makes a lot of money from people searching through it. And browsers aren’t its prey.

Competition between browsers can only help a consumer, although it can hurt developers if it’s like the Microsoft/ Netscape browser wars. But Google chose Webkit, which powers Apple’s Safari, so it should be pretty standards-compliant and therefore be not too onerous to test, and therefore little of an overhead for businesses with websites or those who make them.

This competition will also help us at Opera. Firstly, on those services Google provides (like Maps, Docs and Analytics) we’ve had compatibility problems as Google didn’t test with Opera properly. Those days are over: it can’t be evil and deny entry to a competitor (which we are, in the browser market). Google now advocates testing across all browsers:

Internet users have an increasing number of choices for web browsers today, including Firefox, Safari, Opera, and now Google Chrome. Sometimes web pages look and work differently in each browser, so it’s important to test your site across all of them to ensure all your visitors can enjoy the experience you’ve designed. (My emphasis)

There are a lot of features of Chrome borrowed from other browsers. Google acknowledges the influence of Firefox and WebKit, but not all the things it borrowed from Opera, which is a shame, but we’re used to it: Ben Ward wrote on Jon Hicks’ blog

I think I’m just sour at their presentation of Opera’s features as their own. The whole comic reads like the speed dial and omnibar are ingenious ideas that Google thought up to revolutionise your web experience. Then whilst Mozilla and WebKit get special thanks in the final panel, Opera gets nothing.

I don’t even use Opera, but in an industry where we preach so much about attribution and respect for the work of others, I’m not happy at the way Google have just danced in like this.

I replied “if there’s one thing that my three months at Opera has taught me (apart from how to drink like a Norwegian) it’s that Opera is constantly overlooked when it comes to doling out the props for its innovations or initiatives.” (That could be why we’re even overlooked in the Chrome user agent string Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.X.Y.Z Safari/525.13, thereby identifying itself to web servers as 1) Mozilla 2) WebKit, 3) KHTML, 4) Gecko, 5) Safari and 6) itself.)

The best thing about Chrome to me is the exposure it’s getting. It was even on the TV news last night. Hopefully, people who always thought that the big blue “e” and the Internet were synonymous will now realise that there is choice in the browser market, and they will make that choice rather than go with the pre-installed browser. Some will choose Chrome, some will choose Firefox and some will choose Opera, and that’s how it should be.

What’s your take, dear chums?

Browser tests (added Sunday 7 Sept)

Techradar tested Chrome against Safari and Opera, concluding the overall winner is Opera, saying

We’re big fans of Apple hardware and software, but Safari for Windows is half-arsed. It’s great on the Mac, but we can’t think of a reason why Windows users would want it - especially now Chrome offers essentially the same rendering engine with a better interface, lower memory usage and better performance.

So Chrome wins? Not quite. It definitely has the edge when it comes to JavaScript performance, but speed isn’t everything - if it was, our cars wouldn’t have doors, roofs, stereos or air-conditioning. Creature comforts are important to most of us, and on that front Opera is the only browser here that really delivers.