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.

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.

Does the Americans with Disabilities Act apply to the web?

Sadly, accessibility’s ultimate cliffhanger once again reaches an awkward denouement, leaving us deflated, and looking at yet another boring sequel. The National Federation of the Blind v. Target lawsuit, which promised to be a landmark case in determining the applicability of the ADA, was settled on Wednesday. The key provisions of the settlement have Target paying $6 million in damages to the members of the class action (which consists of legally blind people who have been denied Target’s online services), and agreeing to remove accessibility barriers to blind users by February of 2009.

As with most settlements, however, Target admits no wrongdoing, and so the ADA’s applicability to the web remains fuzzy. (Especially to a non-lawyer such as myself; please don’t consider this as anything like legal advice.) The legal ramifications of this case may not be as clear-cut as some of us would have liked, but it’d be hard to argue that after this decision people with disabilities are in any way on shakier legal ground.

One twist in this case was the application of two California laws: the Disabled Persons Act and the Unruh Civil Rights Act. Both of these offer protections over and above those of the ADA, for California citizens, such as the named plaintiff, Bruce Sexton. Even if we ignore the ADA for a moment, this means that sites who do business in California could be liable under these laws for denying access.

Whatever the legal ramifications may be, those of us who advocate accessibility don’t want to make this into a series of legal battles. There are no winners there. (Okay, besides the lawyers.) We want people to realize that engaging with people with disabilities well before the threat of legal action arises is always the best approach. When a company stalls and takes a case to court, delays, public relations nightmares, and skyrocketing costs are all that happens. In this case, Target will pay out well over $6 million in damages, when one-tenth–maybe even a hundredth–of that amount could have paid a dream team of accessibility-savvy designers ready to solve the actual issues at hand.

The question that’s on our minds today–whether ADA applies or not–ultimately doesn’t make much difference. In fact, it’s a major distraction from the heart of the matter. People of all kinds want to participate in all the activities the web has to offer. And many disability advocacy groups are reaching out to site admins to raise awareness of the barriers they face. The best thing you can do is to prepare yourself and your site with a little education and some fine tuning. When you’re in a lawyer’s office talking about the ADA, or any other accessibility statute, chances are you’ve already missed out on the most important part of the conversation. And that’s going to cost you, whether you win or lose.

Update: This post has been translated into Polish.

As you may recall, the version targeting opt-in requires developers to use the new X-UA-Compatible HTTP header (or the meta equivalent) in order to take advantage of the standards-based layout and scripting improvements in the IE8. Under the current setup, any page/server not opting-in to would continue to render and behave as though it were being viewed in IE7, even if the site was being viewed on IE8, IE9, or IE1000. This doesn’t sit well with many standards-aware developers who think that the IE team got it backwards; many of them believe that you should have to opt-in to keep your site from being interpreted by newer layout and scripting engines. (Folks interested in hearing both sides of that argument should check out the latest issue of A List Apart, where Jeremy Keith and Jeffrey Zeldman square off on the topic.)

In our “round table” discussion, we talked about several proposals from the community that could help bring IE8′s standards mode to the masses, including:

• encouraging Microsoft to ship a patch to IIS that automatically targets sites run on that server to IE7 (in hopes of avoiding the potentially catastrophic impact IE8 may have on intranets and the like);
• shipping the IE8 beta with standards mode on by default just to see how many sites break; and
• making IE8 a standalone browser, capable of being run side-by-side with IE7 to allow users the flexibility of using one broswer for some sites and the other for other sites.

If you are interested in listening to or reading a transcript of the discussion, you can do so by following one of these links:

• WaSP Round Table: IE8′s Default Version Targeting Behavior [mp3]
• WaSP Round Table: IE8′s Default Version Targeting Behavior [transcript]

I’d like to give special thanks to fellow WaSPs Glenda Sims and Steph Troeth for organizing, producing, and transcribing this Round Table.

This buzz has been translated into Polish.

A few days ago, Scott Gilbertson declared “[t]he iPhone is Internet Explorer 4 all over again,” alluding to the walled-off nature of many web sites and apps being developed just for the iPhone (as they were back in the day with IE 4). Joe Hewitt was quick to reply, arguing that being like IE 4 is not such a bad thing, claiming that the devices drives innovation on the web, which is what’s needed.

So where does that leave us? Well, I’m not sure I’ve figured that out yet, but I wanted to put together some of my thoughts and see what you think as well.

The Good

The version of Safari packaged with the iPhone is, without a doubt, the best mobile browser I’ve seen to date. It renders normal web pages brilliantly and the pan and zoom functionality offers a pleasant alternative to the re-flow or squeeze-it-in display models of other mobile browsers.

The Bad

Two words: “standards support.” While mobile Safari performs brilliantly when it comes to CSS rendering, it does have a few problems.

1. It does not apply handheld stylesheets – I can understand the use of screen styles when handheld stylesheets aren’t available, but it would be easy to include a switch to turn off screen styles and load handheld styles if a handheld stylesheet is encountered.
2. Event handling – The iPhone introduces some new interaction models, but has not (according to the documentation or under user tests) given us a window into those actions (such as zoom, pan, etc.). Furthermore, as Joe points out, events like mouseover, mousemove, etc. are not supported. Sure, some of the traditional events have no meaning in the iPhone interface paradigm, but the virtual keyboard doesn’t even fire onkey* events and there’s no way to know if the user is scrolling.
3. iUI – I feel kinda bad placing iUI in the “bad” list, but the markup required to make it work leaves a lot to be desired. It is a great interface, but it enforces some pretty awful coding practices. I’m hopeful it will get a little more attention on the standards end and move into the “good” category.

The Ugly

Alright, so the big ugly to me comes down to one thing and one thing only: iPhone only apps/sites.

Since its release, designers and developers have been building interfaces to their sites and applications for the iPhone. Unfortunately, many have been doing so in a way that leaves the remainder of the mobile web with nothing. Personally, I’ve been kind of torn about mobile segmentation as I feel it goes against the “write once, deploy everywhere” ideal of web standards, but I understand the need for stripped-down interfaces on mobile devices (due to the currently high cost of mobile bandwidth in many places, etc.). But now we are witnessing a schism within the mobile world, dividing it into people with the iPhone and everyone else. This, I feel, is bad for the web and particularly bad for the mobile web.

For the record, I don’t buy the argument that web standards stifle creativity; in fact I believe quite the opposite: web standards enable creativity. It is my firm belief that we owe a great deal of the innovation on the web today to web standards (including XHR, which, as you recall is not a standard…yet). It was only when we had a solid foundation upon which to build that our creations could reach such lofty heights.

So what do we do?

While it is arguable that the iPhone is a lot more fun to design and build for than other mobile browsers (even the venerable Opera Mini), that does not mean it’s OK to hang a sign on the door of your web shop reading “No Blackberries.”

Now don’t get me wrong, I am not saying that you should not support (or even cater to) the iPhone. All I am saying is that you should not support the iPhone and snub all other mobile devices. If you want to build a mobile interface to your app, do it like Twitter and others have. Writing a POSH interface is dead easy and, even with the lack of solid CSS support on most devices, it is usable by pretty much anyone on the mobile web. So start there. Then use progressive enhancement to add new layers of interaction to your mobile site/app. It not only makes sense, but it’s The Right Thing To Do™.

One that has been particularly close to me, or rather one that has provided me with a lot of opportunity to rant, is the responsibility of developers of user agents.

Any effort on the part of web authors to add accessibility features is rendered useless if browsers and assistive technologies don’t take advantage of them. User agent developers need to ensure that their products support these features and, most crucially, make them available to users in an accessible and obvious manner.

Although far from perfect, the W3C’s User Agent Accessibility Guidelines (UAAG) 1.0 do provide a good starting point.

What follows is a quick run-down of most of UAAG’s guidelines and checkpoints, annotated with comments, suggestions, personal gripes about current levels of implementation, and wishlists for future browser versions.

Admittedly a tad rough around the edges, this is a first attempt at crystallising some of the discussions I’ve had with fellow ATF colleagues, members from the W3C, and other accessibility aficionados.

Read the full article: Current browsers and the User Agent Accessibility Guidelines 1.0.

Microformats are a great idea. They allow the embedding of parsable, semantic data (like contact information and event details) into regular web pages. With the right plug-in, that information can be saved directly to your calendar program or address book. Like Microformats, a portion of web accessibility is about making web pages more machine-readable, and by doing so, making them more usable to human beings.

Most of the time, Microformats and the principles of accessibility coexist harmoniously.

Abbreviations in Microformats

HTML has an abbr element used for abbreviations. This element is used by assistive technology, including the most popular screen readers, to expand abbreviations such as ADA and lbs. The benefit to disabled users is that, the screen reader can decipher what the abbreviation means and say the appropriate, expanded version. For example, when a sighted individual sees, “20 lbs,” he will think, “20 pounds.” A screen reader will either try to pronounce the phonemes literally, or spell it out, in this case as “el bee ess.” The abbr element is the method to give the additional information (“pounds”) that makes it more comprehensible to the person listening:

20 <abbr title="pounds">lbs</abbr>

Microformats recommends the use of an abbr-design-pattern which, in some circumstances, is completely in line with the proper use of the XHTML <abbr> element. The Microformat, hCard, can use the abbr-design-pattern to specify country codes as fully-expanded, country names.

<abbr class="country-name" title="Japan">JP</abbr>

In this use, the benefit of <abbr> is twofold: screen readers can speak the word, “Japan” to vision-impaired users, and Microformats parsers can understand the address is in the country of Japan. This is the intended use of <abbr>; it’s accessible, and it’s extendable as a Microformat design pattern.

And the creator(s) saw that it was good.

hCalendar’s Original Sin

The creators of Microformats strayed from their accessible, semantic intentions when they extended the abbr-design-pattern to the datetime-design-pattern. This idea, though paved with good intentions, was a workaround for a browser bug and, like many others, has unintended, harmful side effects.

The datetime-design-pattern is a way to show a readable date (such as “March 12, 2007 at 5 PM, Central Standard Time”) to humans and a machine-readable date (such as the ISO 8601 formatted “20070312T1700-06”) to the Microformat parsers. When crossed with the abbr-design-pattern, the result is this.

<abbr class="dtstart" title="20070312T1700-06">
 March 12, 2007 at 5 PM, Central Standard Time
</abbr>

As you may have guessed from the previous examples, screen readers expanding the abbreviation will try to read the title element. JAWS helpfully attempts to render numeric strings into human-readable numbers, so “1234” is spoken “one-thousand two-hundred thirty-four” instead of “one two three four.” Given a title value of “20070312T1700-06”, JAWS and Window Eyes both try to read an ISO date string never intended to assault human ears:

Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six. (JAWS 8 on IE7: MP3, Ogg)

Though it may sound silly, the screen readers’ behavior is implemented according to the HTML 4 specification.

The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression. (HTML 4, ABBR)

Unlike the ISO date format, the “full or expanded form” is intended to be human-readable. Yes, machine-readable, but for the consumption of a human, and in this case, spoken literally to a human. The Web Content Accessibility Guidelines (WCAG) explicitly defines the expansion of abbreviations as an accessibility advantage, and the most popular screen readers do so.

If an abbreviation fell in the forest…

There are debates about the semantics of the <abbr> element, and everyone is entitled to his own opinion. Is it legitimate to say “5 PM on January 5th” is an abbreviation because it omits the year? Probably. Is “5 PM on January 5th 2006” an abbreviation because it omits the time zone? Perhaps. We don’t contest that those human-readable dates are “abbreviations for a full-qualified date and time.” We contest that, according to the HTML specification, an ISO date string is not a legitimate, human-consumable, expanded form of that date and time.

What isn’t in question though, is that the use of an ISO 8601 date in an <abbr> title attribute renders the content inaccessible to users of assistive technology.

Accessibility, “in the wild.”

The Microformats group is vehemently opposed to hypothetical situations as the basis for a Microformat change. Real-world examples are often requested, or as they commonly phrase it, examples “in the wild.”

We remind the Microformats group that real-world screen reader implementations existed, according to spec and “in the wild,” long before the Microformats design patterns, and we encourage the group to respect those real-world implementations, rather than focusing on hypothetical situations such as:

In the future one could imagine a CSS rule and perhaps a CSS property or two that would automatically transform and present such ISO8601 dates from ‘title’ attributes of <abbr> elements into whatever datetime format the user preferred… (source)

What’s the Alternative?

The point of this article is not to offer a solution, but to shed light on an inaccessible practice that must change. We encourage the Microformats group to consider the problem, whether or not they accept any of the following, proposed solutions. That said, we offer these ideas as carrots to accompany our cudgel.

Originally, we considered the datetime attribute, found only on <ins> and <del> elements, and wished that we could use the datetime attribute instead of a title on a span, except it would be invalid code. Some have proposed using custom attribute namespaces for Microformat data, but the Microformats group is strongly opposed to this, and for a simple and valid reason. Microformats are intended to be “simple conventions for embedding semantic markup in human-readable documents.” Opening the floodgates to custom DTDs and namespaces would quickly raise the complexity level of Microformats to that of RDF, greatly reducing its adoption and therefore its relevance.

So we went back to basics: the existing elements and attributes of plain old semantic HTML.

The datetime-design-pattern was initially proposed as a workaround for a browser bug where the object element and the data attribute were a more appropriate choice. The authors knew this, but could not determine a way to structure it without browser bugs.

We looked again and found a way for Microformats and accessibility to play nicely once more; a way inspired by Microformats’ own empty object include-pattern.

The Object Example

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <object>
  <param name="value" value="20070312T1700-06" />
 </object>
</span>

The markup is still fairly simple, it retains its semantic purity, and it’s accessible. But…

What’s the Catch?

The catch? Okay. Even when the browsers are instructed to hide the <object>, there are still some minor display bugs in Internet Explorer (screen shot) and Safari (screen shot). At the time of this writing, Internet Explorer (version 7) doesn’t honour the space characters in the text around the object, and Safari (WebKit nightly) adds extra line breaks.

Many developers could overlook these flaws. Most designers would not. It’s an easy CSS fix: wrap the object in one extra <span> element and hide it instead.

The Hacked (Ugly) Object Version

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <!-- the extra span element to be hidden -->
 <span style="display:none">
  <object>
   <param name="value" value="20070312T1700-06" />
  </object>
 </span>
</span>

Unfortunately this code sample fails the “ugly” test and isn’t as rooted in simplicity as we’d prefer, so what about some other, simpler variations?

The Span Title Version

<span class="dtstart" title="20070312T1700-06">
 March 12, 2007 at 5 PM, Central Standard Time
</span>

The Empty Span Version

<span class="dtstart">
 March 12, 2007 at 5 PM, Central Standard Time
 <span class="value" title="20070312T1700-06"></span>
</span>

Like the abbr-design-pattern, both of the previous examples use the title attribute to store the ISO data. The second version just avoids GUI tool tips. With custom verbosity settings, it is possible that a screen reader user may hear the text spoken in either example, but that circumstance is much less likely than a fully-expanded ABBR.

We are not recommending the abolishment of the abbr-design-pattern, just its misuse. Again, we encourage the Microformats group to consider the problem, whether or not they accept any of the proposed solutions. All of the examples listed are more accessible than the abbr-design-pattern. Check the final examples for details.

Like we said, we like Microformats. Their simplicity and usefulness means that they’re on the verge of widespread acceptance. We urge the Microformats community to re-evaluate the accessibility of the specification now, before the technology goes mainstream and it’s too late.

This article was co-authored by Bruce Lawson and James Craig, and incorporates feedback from other members of the Accessibility Task Force.

(Added 13 February 2008) “Configuring links in Screen readers” by Mike Davis looks at the screenreader accessiiblity of the Microformat Include Pattern. (Bruce)

There’s been a lot of discussion about the W3C’s recent decision to continue the development of HTML around the web lately. Blog posts, and messages that have been sent to mailing lists or posted on forums, revealed many questions and misconceptions about the future of HTML (including HTML 5 and XHTML 2), the WHATWG and the W3C’s new HTML Working Group.

Some people asked for new features; others were wondering if formerly deprecated elements would return; some had comments and criticisms about the decision itself, the WHATWG or W3C process; and a few raised concerns about the WHATWG and W3C ignoring the needs of particular groups. The WHATWG, who are in the process of developing the next version of HTML (called HTML 5), feel that it’s important to not only listen to all of this feedback, but to actively seek it out and respond so that we can develop a language that meets your needs.

There are many ways in which you can participate. The most direct approach is to make your voice heard by subscribing to the mailing list. However, not everyone has the time to participate, or keep up with the high volume of messages sent to that list. Some people feel that the current drafts of HTML 5 (Web Applications and Web Forms) are rather daunting. Others feel that because they can’t afford the substantial W3C membership fees, they wouldn’t be listened to anyway.

If, for any reason, you feel that you either cannot participate, or would be uncomfortable in doing so, that certainly doesn’t mean you shouldn’t be heard. The WHATWG needs to hear from you and wants to know what you think about HTML.

• Are there any limitations with HTML that you would like to see fixed?
• Do you have any ideas for new features?
• Is there anything you can do now in HTML, but would like to see improved?
• Do you have any concerns about the development process?
• Do you have any feedback about the new features in the current drafts?
• Do you have any questions about HTML 5?

Any questions, comments, criticisms, complaints or feature requests are welcome. Now is the time to speak up. No comment is too dumb; no question is too hard or too simple; no criticism is too harsh. If you have anything at all to say, we are listening.

Please leave a comment or post a link to an article that you have written. You will be heard and we will try to respond.

Update: This post has been translated into the following languages. This list will be updated as translations become available. Feel free to comment in the language you’re most comfortable with.

• Deutsch
• Português
• 한국어
• 日本語
• العربية
• Español
• Svenska
• Polski
• Magyar
• Afrikaans
• Italiano
• Français
• 繁體中文

Texthelp is recommended in PAS 78 for their text-to-speech software product Browsealoud, that addresses those with Cognitive & Learning Difficulties.

Now, try as I might I cannot find any particular endorsement or recommendation of their product in the PAS – and rightly so, as it’s meant to be a fairly neutral, non-vendor specific document. There is only one passing mention of Texthelp (developers of BrowseAloud) in “Annex A (informative) – Suggested user profiles” under the “Cognitive and learning” section (page 36):

Users with medium dyslexia, eg users who might change site colours and text formatting, and who in many cases might supplement this with text to speech software for reading sections of text (such as TextHelp).

So, is this going to be the new trend for marketing accessibility products and services in the UK for the coming years? Boosting one’s credibility by making references to the PAS, even going as far as claiming a recommendation? Well, I guess it’s a bit more respectable than planting fake users such as Dyslexic Duncan on forums to extoll the virtues of your product…

Incidentally, on both occasions I’ve contacted BrowseAloud for an official response…but to no avail.

And while we’re on the topic, a word of advice to web design agencies: you can stop amending your lists of services to include “websites that are PAS 78 compliant”. The PAS is not a new set of accessibility guidelines. It’s a document aimed at people who commission websites. It’s completely nonsensical for a company that develops websites to claim that their products and services comply with the PAS. At a pinch, you could say that your development processes are in line with some of the recommendations of the PAS, particularly the user testing aspects. But even that is really stretching it, in my not so humble opinion. Stick with claiming WCAG compliance. Heck, the PAS itself has the following to say about companies claiming to create sites that are “DDA-compliant”:

9.1.1 It is not possible to provide a definitive specification for a fully accessible website which will satisfy the requirements of the DDA. Website commissioners should therefore be sceptical if contracting companies declare that they will create websites that are “DDA-compliant” or “compliant with the law”. Conversely, website commissioners should not require a web designer to design a website that is “DDA-compliant” or “compliant with the law”. Until case law has been established such claims cannot be made or honoured.

If that is the general advice given with regards to companies claiming “DDA-compliance”, I’d imagine that site commissioners should be even more skeptical of companies claiming “PAS 78 compliance”.

In the process he reports that he’s learned a lot about the twists and turns of the standards process, and three of his points beg emphasis here:

• Users shouldn’t have to know or care about this stuff.
• Being able to point to real-world benefits is important.
• Shipping an implementation pretty much trumps everything else. Most technical debates are eventually settled by looking at what is in current use. Sometimes this is phrased as “letting the market decide.”

I immediately see corollaries to these statements that are highly relevant to the efforts of standards advocates, software vendors, and contributors to the W3C process, which are laid out respectively.

On the web, the line between users and publishers is blurry, and becoming more indistinct every day. This means that technologists must make tools that suit the intended audience without creating mangled output. However, they shouldn’t bother trying to please all the people all the time; common sense describes where that effort winds up.

The entire W3C process is oriented these days toward the Semantic Web, and what energy they have to spare is spent catching up to what’s already been implemented and put on the market. In the meantime, there doesn’t seem to be much direct interaction between end users of web technologies and the W3C. The consequence of this state of affairs is that the best heads with a stake in the process are up in the clouds, rather than doing work that will benefit users in the near term. That work appears too often left directly and solely to software vendors themsevles, which has brought us such <sarcasm>winners</sarcasm> as ActiveX and GoLive.

It will be interesting to see if IE7 is more than emperor’s new clothes, once it ships. It’s no secret that Internet Explorer 6 is the new Netscape 4…

The balance of the value in this post will be in the comments, so have your say!