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.

On the Web Standards Project site, I’ve announced that Patrick Lauke and I are part of the team drafting BS8878, the first British Standard for web accessibility. Patrick and I are also now the co-leads of the WaSP ATF.

Given that two days ago at a conference, I was mistaken for Patrick, I would like to say this now: there is no truth in the rumour that Patrick and I are siamese twins, joined at the ego. In fact, we’re very very different: I’m short, shaven-headed, portly, uncouth and forty. Patrick’s thirty.

I’m still working out my whole response to the Microsoft versioning idea (and feeling sad as the WaSP eats itself).

But there’s one practical problem with the suggestion that pages without the MMM™ (Magic Microsoft Metatag™) become ossified under IE7 for all time. IE7 (and its predecessors) makes some in-page links entirely inaccessible to keyboard users. Yes—completely unreachable to blind people and those with motor impairments.

Read Gez Lemon’s Keyboard Navigation and Internet Explorer article for a full investigation of the problem, but in a nutshell:

…when using the keyboard to navigate to an in-page link, pressing the tab key once the target has received focus causes IE to continue navigating from the start of the document (or more accurately, the closest ancestor with the hasLayout property set to true).

If you have IE7, you can check out my IE7 keyboard navigation test page. Activating the first link should put focus in the last paragraph; a further tab should take you to the very last link on the page. But IE just takes you back to the top, making that link impossible to reach.

There are code workarounds—but if a site-owner doesn’t know to add the MMM™ to the top of their pages, they’re unlikely to know or care abut those workarounds.

So freezing the web to IE7 levels consigns much of it to perpetual inaccessibility.

There’s been a bit of a kerfuffle lately over the Opera complaint that Microsoft is a monopolist that doesn’t uphold Web Standards. I’m glad that I’m not the only one who believes that it’s perfectly feasible for Microsoft and Opera to continue to work with each other on CSS, regardless of their current spat.

While I share Andy Clarke’s frustration about the glacial pace of change, I think the idea of having web professionals oust the browser manufacturers from main specification process, relegating them to “a Technical Advisory Panel to look over the Project’s proposals” is unworkable and potentially more cumbersome. Imagine if you’re hired to develop a website for a large oganisation and play no part in the specification process, but merely get a spec arrived at by competing, squabbling end-users who then say “implement this”. Without the active, day-to-day involvement of the browser vendors, specs would be slower, less coherent and probably unworkable. It’s important to remember that it doesn’t matter when CSS3 becomes a recommendation, it won’t magically upgrade all the browsers; the spec is only useful when (and if) it is actually implemented by the vendors.

I’m also glad that Opera have raised the stakes with a complaint to the European Union. A few frustrated outbursts aside, I’ve never been anti-Microsoft—but I am most definitely anti-monopoly. A monopoly can never benefit consumers, and it must be forced to compete. That force can’t come from the market (it’s a monopoly), so must come from government or similar organisation.

When Microsoft had a competitor in Netscape, it innovated: Internet Explorer had the best CSS support and IE6 was a marvellous browser that ushered in the era of CSS-based design. But once Microsoft killed Netscape, Internet Explorer stagnated , causinng the woe that we still partly feel today. But 18 months ago there was a convincing new competitor in Firefox, Microsoft began innovating again—and look! IE8 passes Acid2!

So I’m glad that Opera are trying to break Microsoft’s monopoly. Being British, I also admire the plucky Norwegian underdog, and I’m personally convinced that Opera are concerned at the highest level with upholding standards. I’m persuaded by Molly of the sincerity of the I.E. team, but I have no faith that those at the top of Microsoft would give a shit about standards if their profits or monopoly were threatened.

But take a breath, and step back from all of this and look at the radically new landscape that surrounds us.

What we see is another browser war, but based on who can uphold standards best. Opera go to the E.U. with a complaint that I.E. doesn’t uphold standards; a day later, I.E. announces that it passes Acid2, even though they knew that a week ago. What can have caused that announcement, other than the impetus to brag about your standards support? The good news is that the browser manufacturers see standards and interoperability as useful armaments rather than troublesome impediments.

So, while the browser manufacturers are upholding standards, what are the Web Standards Project doing? Zeldman writes,

I’m disheartened by the general lack of leadership. I wish The Web Standards Project would either disband or get meaningfully busy.

Now, I’m only a newbie WaSP task force member, not a real, clever WaSP, but my take is that everyone’s been caught off guard—when the traditional enemies are doing your work for you by promoting standards, it’s somewhat disconcerting. And without a real enemy, things fragment in a loose confederation of individuals.

My personal “enemy” is inaccessibility, and James Craig, Patrick Lauke and I fought a battle wth Microformats advocates because some of their patterns are functionally inaccessible. It was a gruelling battle, involving disagreements with other WaSP members, and in the face of overwhelming apathy, we withdrew.

The other problem is with Ajax (“Accessibility Just Ain’t eXciting”). Most Ajax remains fundamentally inaccessible—and despite the valiant efforts of Derek Featherstone, Gez Lemon, Steve Faulkner, Brothercake and Jeremy Keith—few people give a toss.

In the topsy-turvy world where browser manufacturers are promoting standards, many opinion formers and web standards advocates are so transfixed with the shiny shiny Ajax and hCard baubles that they don’t see that they’re in mortal danger of becoming part of the problem.

Who wants to rail with me against the latest marketable sexy Web 2.0 bells and whistles?

Thought not.

I’ll just carry on evangelising semantics and accessibility in the companies that employ me, at workshops, on my blog and hope this current tizzy dies down.

Cross-posted to the WaSP site, but this news was so shocking I had to check that it’s not April Fools Day yet:

Amazon.com, the leading online retailer, and the National Federation of the Blind have entered into a cooperation agreement. Amazon.com will make its Web site and e-commerce platform fully accessible to the blind in collaboration with the Access Technology staff of the NFB. Full release

Now, this is almost certainly because the NFB are suing Target.com (which is “powered by Amazon”), but is nevertheless welcome news. I hope, though, that the fact NFB are leading the way doesn’t mean that it’s a single-issue revamp. Let’s hope that for two things:

• the developers remember that not everyone with a disability is blind: accessibility is more than just assisting the visually impaired
• they use decent, semantic html for the site. Not every disability-lobbying site gets that.

On February 3rd, I’m doing a talk at the free WebDD conference at the UK Microsoft campus, called Web Accessibility: What, Why, How, and Who Cares? which is “a whistlestop tour around how to use Web Standards to make sites that are accessible to disabled people, usable for all and profitable for your client. Warning: contains topless photography”.

Some bloke called Patrick Lauke is also banging on about CSS in a talk called Doing it in style: creating beautiful sites, the web standards way.

Why not come along? It’s a great chance to meet the two hunkiest WaSP ATF dreamboats, and we’ll be available for signing breasts and buttocks.

At last, the podcast audio and transcript of the talk Patrick Lauke and I gave at Geek In The Park.

Riddled with swear words (all Patrick), rambling at times (that Patrick again), you might nevertheless find it useful. (Summary)

Initial transcript provided by CastingWords, with subsequent editing by me and Patrick. Patrick did nearly all the work, and paid for the transcription. What a guy. Released under Creative Commons Attribution-NonCommercial-ShareAlike 2.0.

The great thing about English summers is that we pasty-faced Brits get to do communal activities alfresco. Last week I watched The Real Lady Macbeth in Stratford, in a dell between Trinity Church and the River (and got comprehensively soaked in the storm).

Last night was the inaugural gig of my band, Gaoler, on a farm in the Vale of Evesham, playing under canvas, looking across miles of green and the Cotswolds.

And on Sunday 27th, there’ll be an open-air geekfest in Royal Leamington Spa called “Geek In the Park“.

Continue reading Geek In The Park – 27 August

June 2013: I’ve seen this page used as supporting evidence to say that the final WCAG 2 guidelines don’t matter. Please note that I was criticising a previous, draft version of it. This page is no longer current; it’s dated 2006 whereas the final guidelines are dated 2008.

There’s been some excellent discussion about the last call for comments on WCAG 2.0, both on the Web (see Joe Clark’s “To Hell with WCAG 2” and on w3c lists), and also in the hollowed-out volcano where the WaSP Accessibility Task Force meet. The fact that the w3c have extended the review period shows that they’re listening to legitimate criticism.

In many ways, the discussions about the document reflect the disparate philosophical positions within the community on what “accessibility” means. While the ATF hammer out a joint statement on this version of WCAG 2, here’s my personal take on it. This is the first W3c spec I’ve tried to read, so maybe my comments are based on daft mis-readings of the spec. Please do tell me if so.

Executive summary

The ideal of WCAG 2 is measurable, testable guidelines that are technology-agnostic, and will therefore not date so quickly. This is a noble ideal, but the realisation is flawed. While WCAG 2 doesn’t seem to be inherently evil, its message is diluted, both substantively (no requirement for valid code, tables are explicitly allowed for layout) and by excessive verbiage and jargon. Like shandy, it’s not an unpleasant drink, but it doesn’t hit the spot like a nice pint of bitter does – and that’s what I was hoping for.

Continue reading WCAG 2.0: when I want a beer, don’t give me shandy

I’ve been worrying about Ajax accessibility for a while now, so I was delighted to read two very interesting items of research on Ajax accessibility which were published last week. Brothercake ran some tests and wrote,

I’m forced to conclude that, unless a way can be found to notify screen readers of updated content, AJAX techniques cannot be considered accessible, and should not be used on a production site without a truly equivalent non-script alternative being offered to users up-front. (Source)

Meanwhile, Joe Clark found what appears at first sight to contradict Brothercake’s research, when he tested a real-life Ajax application:

Everybody could do everything. It just wasn’t all that convenient. (Source)

Actually, these aren’t contradictory at all. Making Ajax apps accessible is a brand new endeavour. So there aren’t any hard and fast rules about what works and what doesn’t. Paraphrasing PAS 78 (because Christopher Okonjo at the British Standards Institution told me not to quote it):

Test your pages, you wanker. With assistive technologies. And real disabled people. Or you’re a bigger nob than you look.

Even when you’re sure of your assumptions, a bit of testing works wonders. And with Ajax, any assumptions seem destined to be proved wrong by testing.
Continue reading Ajax, accessibility and assistive technology