Bruce Lawson’s personal site

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.

The American National Federation for the Blind brought a class action lawsuit against target.com for inaccessibility of its website (which is, interestingly, “powered by Amazon.com”).

After lots of to-and-fro, news came today that Target have settled, paying $6million into a fund from which those affected by its inaccessiiblity (blind people in California) can claim.

Presumably (I am not a lawyer, but am I gorgeous) this sets a precedent in the USA that many businesses will find unwelcome, but which will presumably lead to more accessible websites.

So why only two cheers?

Well, $6million is lots of money, but given that Target gives away $3million every week “to its local communities through grants and special programs”, it isn’t such a great investment by Target. The terms of the settlement also means that the only people being catered for by this settlement are blind screenreader users:

NFB will run an automated monitoring tool called Worldspace on Target.com every quarter…

Target shall ensure that the Target.com website meets the Target Online Assistive Technology Guidelines, attached as Exhibit C [not on website], and that blind guests using screen-reader software may acquire the same information and engage in the same transactions as are available to sighted guests with substantially equivalent ease of use.

Upon completion of the changes to Target.com pursuant to Section 6.2 herein, the NFB shall certify the Target.com website through its NFB Nonvisual Accessibility Certification program using the standard techniques and criteria of that program.

NFB will annually report to Target the results of user testing by 5 to 15 blind persons with varying skill levels and using JAWS…

Target shall ensure that complaints received from guests regarding the accessibility of Target.com by those using screen-reader technology are reported to a Target employee responsible for ensuring that Target.com is accessible.

Target shall provide to the NFB a quarterly summary of any complaints received from guests regarding the accessibility or usability of Target.com by those using screen-reader technology…

NFB Nonvisual Accessibility Certification. Upon completion of the changes to Target.com pursuant to Section 6.2 herein, the NFB shall certify the Target.com website through its NFB Nonvisual Accessibility Certification program using the standard techniques and criteria of that program.

I have no idea what the NFB Nonvisual Accessibility Certification program actually entails, but the NFB’s legitimate remit probably means it’s concerned only with screenreader access:

Working with members of the technology community, the National Federation of the Blind has developed a rigorous procedure by which Web sites and applications that have made special efforts to be accessible to the blind can be identified and recognized.

Accessibility is more than just blind people who use screenreaders. It’s a pity (but it’s understandable) that the NFB didn’t think of other groups with accessibility problems and require development to standards laid down in the internationally-recognised, open WCAG guidelines rather than their own proprietary process.

The danger is that corporations and developers will start developing for the assistive technologies and monitoring tools (machines) rather than people, and that would be a very retrograde step.

Comments on the Opera Developers Network blog, please (no registration required).

Recently, Opera sponsored Geek in The Park 2008 by picking up the tab for audio transcription of the talks. It’s one thing that often gets overlooked by conferences and it’s something that Opera takes very seriously. Equally, you can’t expect speakers and organisers of a grassroots event to pay for it when they’re giving their time for free.

The company I used is called Casting Words, and I want to recommend them to you. After cleaning up the audio, I uploaded it to their site and selected their six-day turnaround service at $1.50 per minute. Four days later the transcripts were returned, with very few errors, particularly when you consider the technical nature of the content. You get them returned as text, RTF and HTML, and the markup is not bad: it’s set out as blockquotes with speakers’ names in cite elements.

The only problem is that multiple paragraphs inside blockquotes are marked up with double br elements rather than wrapped in p elements, so I emailed their support to ask them if it would be possible to amend their publishing system accordingly. Rachel wrote back “Thanks for letting us know about this, we will make that change.”

Now that’s service.

And when a 45 minute conference talk only costs £30 to transcribe, it’s difficult to imagine why organisers of for-profit conferences wouldn’t provide a transcript of their events.

(The transcriptions are being checked by the speakers and will be published when they’re proofed.)