Internet Explorer 6, despite all of the well known issues, was a breath of fresh air. We could use a lot of CSS2, we could lay out our pages using CSS, and many people decided that Internet Explorer was the browser they were going to support. This led to a raft of “only works in Internet Explorer” sites and applications, the reason why we are still stuck with IE6 today.

Ten years later. In many ways we are in the place that we wanted to be, when we were campaigning for web standards adoption by developers and browser manufacturers. Our browsers do support W3C specifications. We don’t have rafts of crazy bugs in standard features or vendor specific implementations of those features that vary wildly. I can build a complex layout and load it up in Internet Explorer 9, the latest Firefox, Opera, Safari and Chrome and it all look pretty much the same. This is what we were asking for.

It could not be said however, that all browsers are equal in 2012. Some have moved more quickly to implement parts of the CSS3 specification even when they are just at Working Draft status. Browsers have implemented these new features using Vendor Prefixes, enabling them to implement a feature that might change as it goes through the W3C process. Vendor Prefixes to some extent have helped to prevent the situation arising again where we have a standard feature implemented in different ways by different browsers. Thinking back over our history I believe that to be a good thing.

Whether you like Vendor Prefixes or not, we have a problem. Due to the rise in mobile browser usage, and many of those mobile browsers being based on WebKit, many developers have decided to essentially only use the -webkit- prefix, even for properties that have been implemented by other browsers. Today Daniel Glazman, W3C CSS Working Group Co-chairman, wrote a blog post, Call for action: the open web needs you now!. He, and the W3C CSS Working Group is concerned that if this continues, other browser manufacturers will simply start implementing the -webkit prefix.

This approach seems very likely. If other browser manufacturers have implemented these features under their own prefix, yet web developers do not use those prefixes, then it makes their browsers look less capable than those based on WebKit. By simply implementing the -webkit prefix sites will look better in these browsers.

If this happens then we end up with a web once again controlled by one browser manufacturer. Once again we run the risk of having sites built only for one platform, and finding it very hard to get that platform to go away if things move on. Please read the above post. Please think about it every time you have to ensure your site works well in a browser that is over ten years old. Please do your bit to prevent -webkit becoming a de facto standard and hurting the Open Web.

How can you help?

1. Read the original post – Call for action: the open web needs you now!
2. If you have sites that test for WebKit browsers or only implement -webkit prefixes please take some time and update any -webkit-only property to use the other vendor-specific prefixes and non-prefixed versions.
3. Sign this petition & pledge telling browser makers not to implement the -webkit-* vendor prefix and promising to update the sites under your control.
4. Remove -webkit-only testing from repositories on GitHub – Pre-fix the web!

More commentary on the issue

• Remy Sharp: Vendor Prefixes about to go South
• Gilles Vandenoostende: On Vendor Prefixes
• Christian Heilmann: Now vendor prefixes have become a problem, want to help fix it?
• Bruce Lawson: On the Vendor Prefixes Problem
• Aaron Gustafson: This must not happen!
• Eric Meyer: Unfixed

Web Standards Sherpa came about because we wanted to create a repository of best practices information while, at the same time, providing mentorship opportunities for practicing web professionals. With those goals in mind, we began to throw around ideas of what that could look like and we realized a pseudo-critique site could fit that bill perfectly. We say “pseudo” because the reviews we’ll be posting on Web Standards Sherpa are not traditional critiques, but rather focused reviews of a particular aspect of a site.

The elevator pitch on the site sets it up well:

Web Standards Sherpa’s experts provide helpful, pragmatic and up-to-date advice on best practices for web professionals everywhere.

In terms of format, our plan is to bring on amazing authors for a period of 3-6 months or more at a time, with new articles coming out weekly. We’ve kicked things off with pieces by Erin Kissane, Jared Spool, and yours truly; Dan Rubin and Derek Featherstone are on deck for the next two issues.

In order to get the ball rolling, we’ve chosen a handful of sites to look at, but our goal is to have users submit their own work to get honest feedback. We’re not looking to tear down your work, but we are looking to help everyone get better at their job. If you’re struggling with your navigation, for instance, you could submit your site and ask for our thoughts. If you’re unsure your approach to scripting a particular widget is the most efficient or are concerned about its accessibility, you should submit that too. We see Web Standards Sherpa as a way to let you glean advice from some of the smartest folks in the industry and provide you with the opportunity to learn from real world examples of what people are doing right and where there is room for improvement.

We hope you’ll help us out by “feeding Shirley” (our mountain goat mascot) and submit your sites for review.

Is W3C saying that CSS3 is part of the HTML5 specification?

No. However, many HTML5 Web sites and applications do take advantage of CSS3 for styling and presentation.

This is a good start, but there is still a lot to be done. The main HTML5 logo page still includes non-HTML5 (or event HTML5 web app-related) technologies such as CSS3, SVG, etc. And the Badge Builder still assembles a badge that makes these technologies appear subordinate to HTML5 as opposed to framing them as complementary, but distinct entities. We hope the FAQ change is not the end of their efforts to fix the potential confusion they have caused and that they will continue putting things right over coming days.

On a related matter…

As you probably heard, the WHATWG has decided to drop the “5” from their work on the HTML language:

…we realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call “HTML5″ complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves.

At first blush, many of us were a little distraught by this decision because we thought the W3C might decide to follow suit, but after thinking on it a bit, the decision makes sense: the WHATWG can work on the HTML markup language in a fluid way and the W3C can take snapshots of that work and christen it with a version number for reference purposes.

Some might argue that version numbers are meaningless on the ever-evolving web, but they do help us establish mile-markers or guideposts which aid in both education and accountability. Sure, both versions 4 and 5 of HTML are still HTML, but, as the saying goes, you can’t build on shifting sands. It’s frustrating to teach from an ever-changing spec. The same goes for authoring to one. Some manner of stability is necessary so you know what is “true” now (or at least at some point in time), even if those circumstances may change in six months or six years. Not having a version number will make it really hard to educate people about the current set of new HTML features, and how they differ from the old version (which rather contradicts the purpose of the HTML5 logo in the first place).

Not that there was really a question, but we stand by our sentiment that the final (as in W3C) version of HTML5 should continue having a version number while the version-less WHATWG version is used for continuing development.

It’s a huge project and we’re looking for as many volunteers as possible. If you’d like to help translate or help with localizing content for your local education system email the ILG leads and we’ll put you in touch with other volunteers.

Full details abut how to get involved can be found in the Internationalizing and Translating InterAct forum.

Thank you to everyone who’s involved so far!

These suggested that for government web sites, webmasters need not test in less popular browsers (those with less than 2% in that site’s usage statistics) and that there should be a page on the site listing the popular browsers which had been tested with 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”.

I called on readers to email the consultation address and object that the guidelines did not advocate web standards and methodologies like progressive enhancement to ensure that all browsers were served. The Register carried the story, and two days after I made that call, the author of the guidelines, Adam Bailin, commented that over 400 people had already emailed him.

Last Friday, 16 January, Adam published the revised browser testing guidelines, and he’s done a great job of including best-practice development. The guidelines point to the BBC‘s support table as a good example of graded browser support, and notes the importance of supporting standards-compliant browsers (paragraphs 17-18):

Coding a site to web standards should ensure that any browser that supports web standards will render and behave as intended. Therefore your browser testing matrix must include browsers that support web standards.

You should follow a progressive enhancement approach to developing websites to ensure that content is accessible to the widest possible number of browsers.

The importance of valid code is noted (paragraphs 21-23):

All (X)HTML content must validate with respect to your chosen DTD.

You must use valid CSS for the presentational layer of your website including layout and styling. (X)HTML tables should only be used for presenting tables of data.

Code used for adding richness to the user interface (e.g. JavaScript, ActionScript) must be ECMAScript-compliant.

The guidelines now emphasise functionality over identical layout across browsers (paragraph 39):

You should check that the content, functionality and display all work as intended. There may be minor differences in the way that the website is displayed. The intent is not that it should be pixel perfect across browsers, but that a user of a particular browser does not notice anything appears wrong.

Graceful degradation without scripting/ plug-ins and accessibility are required (paragraphs 41-42)

You should also test your website to make sure that it works with scripting and plug-ins turned off.

Some users will be unable to use pointing devices so you should verify that the site works using a keyboard only.

I could be churlish and quibble about a couple of points in the document that I personally disagree with, but I won’t; the philosophical framework of the new Guidelines is a scalable, future-proof one that will properly serve taxpayers, web visitors and government webmasters in the UK.

I’d like to congratulate Adam Bailin and the team who revised the guidelines, and I’d like to congratulate every one of the 400+ readers who took the time and the trouble to write and support web standards.

It’s a job well done.

(Disclosure: I work for Opera, the browser vendor, and wrote the Opera consultation response).

The W3C has launched the W3C Validator Donation Program to give Web people and organizations the opportunity to support what must be one of the most commonly used tools by those in our profession.

Think about it — how many times a week do you ping one of the validators to check your HTML, CSS, or feeds? Don’t you occasionally run the link checker on your site to find broken links? If you’re like me or any of the designers or developers I know, you probably rely on these services a fair bit.

As explained by Olivier Théreaux in his recent blog post, the donation program isn’t about paying for bandwidth or servers, it’s about continuing to improve the validators to support new languages, to fix bugs, and to add new features.

So what are you waiting for? Get in the holiday spirit and give to the W3C Validator Donation Program!

Polish Translation

BSI British Standards is inviting all interested parties, and in particular marketing professionals and disabled web users, to review and comment on the draft of a new standard on accessible web content. DPC BS 8878 Web accessibility – Building accessible experiences for disabled people – Code of Practice is applicable to all public and private organizations wishing to offer accessible, usable web content to their customers. [...]

Based on PAS 78: 2006, Guide to good practice in commissioning accessible websites, DPC BS 8878 informs organizations of their legal responsibilities in relation to web accessibility, calling on them to appoint a specific person or department to oversee activity. [...]

Julie Howell, Chair of the committee responsible for drafting DPC BS 8878, commented, “Once published, this standard will be a fantastic tool for organizations wishing to understand their responsibilities in enabling disabled people to use web content. DPC BS 8878 encourages the enhancement of the overall user experience – a much more holistic approach than we have seen previously and one that I hope will yield exciting results. Right now we want to encourage as many people as possible to read and comment on the draft standard to ensure it is as relevant as possible.”

Read the full media release: BSI British Standards invites comments on new draft standard on accessible web content.

WaSP Accessibility Task Force co-leads Bruce Lawson (Opera Software) and Patrick H. Lauke (University of Salford) — who have been jointly representing their employing organisations and the Web Standards Project itself on the committee responsible for drafting the standard on behalf of BSI — would like to encourage feedback on DPC BS 8878 through the BSI British Standards Draft Review system.

Deadline for review is the 31 January 2009. Publication of BS 8878 is expected in summer 2009.

Update

The draft is now also available for download in PDF and Word format.

See also:

• Out-law.com: BSI consults on first British Standard for accessible websites

In early October I was lucky enough to spend some time in China talking to web professionals and students alike about web standards and their current status. It was an interesting couple of weeks that really opened my eyes to what the challenges are when following best practices. What hit me most is that those who support standards are a small and often isolated voice with little or no resources in Chinese to help back up or explain why we need standards and what the benefits are. Here I give a broad overview of what I learnt, challenges and hopefully some ideas of how we can help improve things.

Please do leave a comment if you have any suggestions, thought or insights. I’d also like to expand on the list of resources below so if you have any then post links and I will update the list.

Market forces

In the main those drivers that we see supporting web standards in some European countries, Australia and the States almost act as the opposite in China. There is no legal requirement to make your website accessible and market forces don’t seem to provide a significant enough push. Market forces is an interesting one. I’ve long held that the business case around web standards is essential even in a country that has a legal requirement for sites to be, for example, made accessible. The reasoning for this is that a site owner may be aware they legally have to make a site accessible but unless they see the direct benefit to them they may not implement accessibility properly and instead merely opt to do the bare minimum that needs to be done to comply with the law.

Currently in China there is a weak business case for web standards for a number of reasons. For one Internet Explorer 6 is still the dominant browser with a 95% market share. In general people are tied into using IE6 as most e-commence sites rely on ActiveX to work. This means that there is a trend towards building web pages that only work in IE6 with other browsers given less focus. This is gradually changing however with the rise of alternative browsers such as Opera, Safari and Firefox and Google Chrome. In fact the arrival of Google Chrome did a lot to raise awareness of alternative browsers in the web design community. Developers I spoke to however were very quick to point out that while they may use an alternative browser to IE when building and testing sites they still made heavy use of IE in day to day browsing simply because so many sites depend on it.

This lack of demand for compliant websites is a problem as without the demand there is little incentive for individual developers as well as companies. This may change however, especially as more and more multinationals outsource and base their development work there. With this increasing hopefully the trickle down theory will hold true and multinationals will have an impact on raising knowledge and awareness. When I asked one developer from Microsoft how he got into web standards he said that it was because the company sent over someone especially to train employees in standards based development. This was great to hear and certainly a key channel for advocating web standards. Opera, a long time champion of web standards (disclaimer, I work for Opera but all opinions are my own) are also playing an active role in advocating web standards. It’s at the heart of the development cycle in the Chinese office and the team are also very active in taking part in meet-ups and conferences.

Legal support

While there is a lack of concrete law to support accessible websites it was interesting to see how the Olympics had affected awareness. Public spaces, streets and buildings were much more accommodating and accessible as a result of the games and had done much to make people more aware. This is a start at least and links in well with the UN Convention for the Rights of Persons with Disabilities which China ratified in July of 2008. The Convention is the first international legally-binding convention designed to protect and promote the rights of persons with a disability. As China has ratified the Convention they now have to legally support access to information, recreation, employment and education. As Article 9 states:

“State Parties shall also take appropriate measures to…promote access for persons with disabilities to new information and communications technologies and systems, including the Internet”.

It remains to be seen the direction this will take but at least China is signed up.

Grass roots advocacy

Most exciting of all was the passion and commitment shown by many web professionals I spoke to. There are some influential bloggers in China who are doing great things to promote standards. Notable bloggers include Jun Chen Wu and Xian An AKA Real Lazy. When talking with Xian An he mentioned that back in 2005, when he first started blogging about standards, he was getting around 1000 hits per day. This seemed to prove that there was a desire for people to learn more or, even if they were not researching for information about standards directly, they are landing on his site which was able to introduce standards.

This seemed to make sense as all the developers I spoke to said they they were more or less self taught. As with many countries web development and standards aren’t always covered in university courses so designers and developers have to self teach. One big drawback here however is the lack of resources in Chinese. This is compounded by the fact that while some ebooks exist they can be too expensive to buy for many people.

Probably most exciting while I was there however was the opportunity to take part in the first ever Web Standards Cafe in Beijing sponsored by Opera. The subject was Web Standards and Web 2.0 and focused largely on how we can support web standards in China. Combining grass roots advocacy such as this with BarCamps I think is a positive way forward.

Supporting web standards in China

There a few things that we can start doing now to help promote web standards and accessible web design in China. It may seem like a daunting task but if this is tackled bit by bit there is no reason why standards can’t become more popular. As the old Chinese saying goes “Tell me and I’ll forget; show me and I may remember; involve me and I’ll understand”. It’s not long ago that in Europe, Australia and the States that we were fighting for basic adherence of web standards, it’s worth while to look back and learn from that experience. For now I see the following as being instrumental to enabling web standards.

• Translated resources – top of the list has to be the availability of translated and free resources for people to use. Currently many individuals have contributed their time to translating (see the resources section below) but I can’t help thinking that larger organisations should contribute to these efforts. Check out instructions and guidance on translating W3C resources for more information.
• Multinational responsibility – large international organisations who actively promote and support web standards internationally should do what they can to help support web standards locally in China. This could be done via training in-house, sponsoring free or affordable courses or helping translate resources into Chinese. This should not be restricted to China only.
• Grass root advocacy – developers understand the challenges and problems developers face better than anyone else. Advocacy through blogs, forums, BarCamps and Web Standards Cafe are always a useful way to go. This may take a different shape in China to suit cultural norms but communication and sharing have to be at the root.

So if you are a blogger, a developer, someone in a position to translate or communicate knowledge within your organisation then share what you have. As I mentioned above please do leave a comment if you have any suggestions, thought or insights. I’d also like to expand on the list of resources below so if you have any then post links and I will update the list.

Resources

• Information Accessibility for People With Physical Disabilities Technical Requirements for Web Accessibility (Simplified Chinese), Ministry of Information Industry Telecom Research Institute, the Internet Society of China, Harbin
• Web Content Accessibility Guidlines 1.0, translated by Jun Chen Wu (simplified Chinese)
• Dive into Accessibility, Taiwan, (traditional Chinese)
• Dive into Accessibility, Taiwan (simplified Chinese)
• Realazy, blog about Chinese web standards (simplified Chinese)
• Web Accessibility Toolbar Chinese language version developed by WAT-C and Jun translated by Jedi (Chinese)
• Getting started, making a website accessible, translated by Eagle Liang (simplified Chinese)
• Don’t use “Click here” as link text, translated by Eagle Liang, (simplified Chinese)
• Why tables for layout is stupid: problems defined, solutions offered (simplified Chinese)
• Why tables for layout is stupid: problems defined, solutions offered (traditional Chinese)
• Web Standards switch, translated by Yammie Yuen (simplified Chinese)
• Government web standards usage, People’s Republic of China (English)
• W3C China office (simplified Chinese)
• BarCamp Beijing (English)
• BarCamp Shanghai (English)
• CSS Zen Garden (Simplified Chinese)
• Opera, W3C and Web standards by Zi Bin Cheah (Simplified Chinese)
• Opera Web Standards Curriculum (English)

For a full list of translated standards in Chinese visit the W3C translation page.

Finally, a huge thank you to Jun Chen Wu for the translation.

WCAG 2

Shawn Henry writes of WCAG 2,

Over the last few months, the Web Content Accessibility Guidelines (WCAG) Working Group has been going through a process to ensure that WCAG 2.0 can be implemented. Developers and dsigners from around the world gave WCAG 2.0 a “test drive” in their own Web content.

The result: Successful implementations in a wide range of sites including education, commerce, government, and a blog; in languages including Japanese, German, English, and French; and using a wide range of technologies including scripting, multimedia, Flash, and WAI-ARIA. You can get the nitty-gritty details from the Implementation Report.

It’s possible that WCAG 2 could be the new accessibility standard by Christmas. What does that mean for you? The answer: it depends. If your approach to accessibility has been one of guidelines and ticking against checkpoints, you’ll need some reworking your test plans as the priorities, checkpoints and surrounding structures have changed from WCAG 1. But if your site was developed with an eye to real accessibility for real people rather than as a compliance issue, you should find that there is little difference.

mobileOK Basic Tests

I’ve mentioned this largely so you don’t have the same worries with them that I did. Crudely speaking, they’re an automated test that a site will be OK on a very low-spec mobile mobile device called the “Default Delivery Context” (DDC) so there are certain rules in the validator such as a page cannot be larger than 20K. This caused me some degree of tizzy, until I read the caveats at the top of the specicaton:

mobileOK Basic primarily assesses basic usability, efficiency and interoperability. It does not address the important goal of assessing whether users of more advanced devices enjoy a richer user experience than is possible using the DDC.

…The Best Practices, and hence the tests, are not promoted as guidance for achieving the optimal user experience. The capabilities of many devices exceed those defined by the DDC. It will often be possible, and generally desirable, to provide an experience designed to take advantage of the extra capabilities.

So my advice: make your pages as long as the content requires, no longer or shorter. Use the images that the content and design needs, and let the user decide whether he or she wishes to accept your images. Make sure all images that convey information have explanatory alternative text for those who can’t consume your images.

Now that sounds familiar…

Last friday, the UK government’s Central Office of Information (COI) published a public consultation on browser standards for public sector websites:

This guidance has been developed to assist those delivering public sector websites to determine which web browsers to use for testing. Public sector websites have a responsibility to be inclusive and not exclude groups of users but it would be impractical to test websites on every available browser.

So far, so apparently reasonable. I’m pleased to see that the COI advises that browsers on Windows, Mac and Linux be tested, that assistive technologies be tested, and it’s good that the draft guidance recognises that different sites have different target audiences.

But the central premise of the draft guidelines is fundamentally flawed.

Playing the numbers game

The central message of the draft guidelines (which are not available in HTML, only Word (280K) and PDF (160K)) is that public sector webmasters need not test in less-popular browsers.

If a browser appears in visitor logs as being below an arbitrary percentage of total “unique visitors” then it should not be listed as being “fully supported” in the site’s accessibility or help pages.

It may be listed as "semi-supported", which is defined: "A browser is semi-supported if the content and navigation works but the website does not display as intended”. Intended by whom? Are we back to the bad old days when webmasters strove for pixel-perfect rendering, even on governmental sites which are largely content-driven rather than design-dependant?

This page is best viewed with Browser X

The COI says “Avoid using statements such as, ‘this page is best viewed with Browser X’", and then goes on to advocate pushing users to change their browser.

There are many reasons why people use minority browsers, like Opera, Flock, Camino, OminWeb, Konqueror and the like (full disclosure: I work for Opera). A large percentage of visitors to the WaSP website use browsers other than the Web’s most numerically popular browser, for professional or political reasons. Others use a smaller browser for accessibility reasons, or because it’s familiar, or because they prefer the user interface, or just because they like it. Choice and personal preference is the heart of an open Web.

But the COI believes that it’s legitimate to suggest that visitors to government websites should change their preference, working methods and computer setup because of its testing policy. The example browser support policy statement, that they advise publishing on an accessiiblity or help page, says (my emphasis):

[Website name] has been tested on a wide range of browsers:

[List supported browsers here]

We advise you to upgrade your browser version as far as your computer allows and if possible to one of those listed above. However, the following browsers should also provide access to all of the content and navigation on the site:

[List semi-supported browsers here]

In short, in order to save costs on testing, the COI is advocates browser upgrade. By encouraging people to move from minority browsers to majority browsers, it works against the minority browsers ever increasing their market share in that sector, and the public sector is a big sector. It also sets a terrible example to organisations outside the public sector who are only just being cajoled out of the “build for IE” mindset.

Swimming against the tide

In the introduction to a document that wishes to help webmasters save money by limiting the range of browsers used for testing, it says that "how to code for browser compatibility" is "out of scope". This is bizarre; how can the single most effective way to reduce the cost of development be considered out of scope? This goes completely against the recent rise of the standards movement led by the WaSP, which was founded in 1998 to fight for standards that reduce the cost and complexity of development.

The guidelines note

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.

This is entirely back-to-front. The guidelines should be advocating a specific development methodology: they should recommend designing to Web Standards. Costs will be driven down, even if testing is performed across more browsers, because there will be fewer inconsistencies and less recoding to fix inconsistencies.

The COI should also advocate publishing information in open formats, such as HTML, and practice what it preaches.

Respond to the consultation

All UK and European developers have the right to respond to this consultation, which closes October 17, 2008. We hope that you will do so, because UK government websites have a lamentable track record, and we invite you to post your response on your site and link to it in the comments below, to inspire others.