While Microsoft may pay lip service to web standards, a look at their product line suggests they have no interest in supporting the standards they’ve helped create. Face it, xHTML and CSS just aren’t as sexy as .Net and web services. Microsoft clearly has other priorities and a closer investigation of the facts seems to indicate that support for web standards is hardly a blip on their corporate radar.

Allow me to elaborate with a few examples:

Microsoft.com: Any discussion about Microsoft’s support for web standards should begin with their corporate website. If Microsoft cared about web standards, you would expect them to use those standards on their own website. You’d probably even expect their home page to validate (or at least come close). Instead, Microsoft can’t even be bothered to declare a doctype.

I realize valid HTML is a controversial topic. We all know how hard it is to keep a site valid. One day your site validates, the next day some stray entity or attribute throws your site out of compliance. My point is that those of us who are serious about web standards make an effort. Microsoft’s failure to declare a doctype on their home page indicates they’ve made no effort.

Dig deeper into the source code of Microsoft.com and you’ll find one coding atrocity after another (font tags, nested tables, and embedded images that simulate a styled list, etc.). It’s as if the developers of Microsoft.com have no clue what CSS is, let alone how to use it. To Microsoft’s credit, they seem to be using their own tools to create and maintain their website. My problem with those tools is that they encourage the worst sort of design habits. They certainly don’t encourage the use of web standards. Which leads me to . . .

FrontPage: Web professionals don’t take FrontPage seriously — it’s a fact. The problem is that much of the rest of the world views FrontPage as the most cost effective way to manage a website. Managers love it because “it’s so easy anyone can use it”. Organizations buy the marketing hype without the slightest concern for the code FrontPage is generating (“It’s Microsoft, it must be compatible”). Since the product ships with some versions of Microsoft Office, FrontPage has more or less become the de facto standard for managing departmental websites. Unfortunately, most organizations don’t realize what they’ve gotten themselves into until they try to migrate their legacy FrontPage website to a shiny new content management system. There’s simply no good way to automate this sort of conversion. Suddenly FrontPage doesn’t seem like such a bargain.

Microsoft’s marketing machine boasts about FrontPage 2003′s powerful code editing mode, professional design tools, and database integration. Sounds great. How about a tool that creates valid xHTML and encourages novice content authors to format their pages using CSS and semantic markup instead of font tags? As it is, FrontPage seems to invite novice web authors to do the wrong thing at every possible opportunity. FrontPage has enabled so many departmental webmasters to create so much bad HTML that I fear we’ll never fully recover from the damage that’s been done. Microsoft is directly responsible for this.

Visual Studio: As one developer on Microsoft’s Channel 9 blog recently noted about Visual Studio, “creating xHTML compliant websites is a pain in the ASP.net”. In the know Microsoft developers speak in hushed tones about ‘Whidbey’, the next generation .Net development tool that will reportedly support xHTML and CSS (no, these same insiders don’t seem to think it’s strange that the current set of tools don’t already support web standards). In the meantime, the current generation of Microsoft’s professional development tools seem to be no better than their consumer tools are at supporting web standards. .Net developers seem perfectly happy with a tool that might render an unordered list as a table (Microsoft in general seems to have some strange aversion to unordered lists).

To be fair, it seems that Microsoft is attempting to address these inadequacies, but one suspects that unless the new tools are absolutely foolproof, it’ll be mighty difficult to train developers to change their way of thinking. After all, Microsoft’s website doesn’t validate — so why should mine? Then there’s all that legacy code to think about. It’s extremely unlikely that the new Studio product will provide much assistance in migrating bloated and invalid code from previous versions.

Microsoft Word: I’ve written at length on a couple of occasions about Microsoft Word’s inability to easily export documents to clean xHTML. If you’re using a content management system with a built-in WYSIWYG editor, it’s likely that a simple cut-and-paste from Word into your article editing page will produce undesirable results when that content is published within a standards compliant website. One has to wonder if it’s really all that difficult to generate clean xHTML from MS Word. Just once I’d like to see Clippy tapping on my monitor asking me if I want clean xHTML. Something tells me this won’t happen in my lifetime.

Internet Explorer. Standards compliant web developers are well aware of the myriad of hacks required to effectively use web standards in the most popular web browser on the planet. It’s as if Microsoft takes pleasure in making the simplest tasks near impossible. Search Google for Interent Explorer CSS Hacks and you’ll find tens of thousands of pages devoted to working around Microsoft’s browser. It’s been noted that these same hacks will likely come back to haunt us all at some point in the future. It seems quite apparent that IE‘s CSS quirks are greatly responsible for many web developers’ failure to embrace xHTML and CSS as the standard method for developing websites. IE’s poor support for standards has given a generation of web designers the impression that the standards are broken.

If Opera and Mozilla are capable of supporting web standards, why can’t Microsoft? In fact, it seems like small, independent software developers and the Open Source movement are leading the way, while Microsoft is barely keeping pace, despite its presence in the organization responsible for developing these standards. The best CSS editors on the market are TopStyle from Bradbury Software and Style Master from WestCiv. How is it that independents with limited resources are producing better standards based tools than the richest corporation on the planet? Could it be that Microsoft views web standards as a threat? After all, web standards imply a cross-platform, cross-application document format. One of the prime strategies Microsoft used to achieve their dominant market position is the proprietary file format. Web standards are clearly a threat to proprietary file formats.

It’s hard to say exactly what Microsoft’s problem might be. What are we to believe? Either Microsoft is hopelessly behind in their support of web standards, or they’re subverting standards to protect their market share. Or maybe Bill Gate secretly loves table-based layouts (he does seem to fit the profile). Some insiders have suggested that the company has been so obsessed with security issues for the past couple of years that they’ve lost touch with everything else. To me, that seems like the most unlikely scenario.

Regardless of what Microsoft’s excuse may be, the fact is that the current incarnation of their product line lacks any meaningful support for web standards, something that they will have to face head on as they move forward with their recently publicized accessibility initiative. They can’t achieve their goals without addressing the problems they’ve created — and the tools they’ll be using will not help. Considering Microsoft’s dominance in the marketplace, it’s remarkable that the standards movement has made as much progress as it has in the past couple of years.

Against a backdrop of hyper sensitivity to accessibility issues Veen steps up and announces, “I don’t care about accessibility.” Veen’s proclamation was met with a few nervous chuckles followed by an uncomfortable moment of silence before he began to build his case.

Veen, of course, was exaggerating his position to make a point. After proclaiming he didn’t care about accessibility, he went on to explain what he does care about: professional web design practiced as a craft by skilled practitioners who understand the limits of the media as well as the opportunities presented by the media. He noted that in the past he always had problems working with print designers who felt constricted by the limitations of web technology — but those designers are no longer a problem for him because he no longer works with them. The designers Veen works with now are steeped in web standards and interactive design, and welcome the challenges of their chosen media. Because Veen is now fortunate enough to be working with skilled web craftsmen, accessibility is much easier to achieve.

He went on to demonstrate a few standards based sites that degrade gracefully and work well with assistive technologies. His presentation was a welcomed contrast to what might have turned into a prolonged debate on the proper implementation of access keys.

For me, this was one of the most memorable presentations at this year’s SXSW — others must have felt the same since a Google search on “Veen ‘I Don’t Care About Accessibility’” returns 316 hits (that’s about two results for every person in the room at the time Veen made his comment, but since he was also working the back channel via iChat there may have been some remote participants).

Matt May has another perspective on Veen’s now infamous assertion. In his post titled I Care About Accessibility, May is concerned that some designers may have taken Veen’s claim at face value, while missing the rest of his message. One can only imagine what sort of damage the ‘I Don’t Care About Accessibility’ meme might inflict on the efforts of accessibility advocates everywhere. I can already hear the phrase “But Veen said . . .” ringing through conference rooms across America.

I have to admit that there is a certain danger in taking Veen’s approach — especially in a world where so many decision makers are just now learning about the issue of accessibility. In many cases those same decision makers are also looking for an easy way out.

I was pondering all of this yesterday when I received the latest press release from UsableNet. The message was touting the latest succesfull implementation of the LIFT Text Transcoder. The County of Sacramento has just implemented LIFT on 40 county-run websites.

For those of you who aren’t familiar with the LIFT Text Transcoder, it’s a product that will automatically create a text-only version of your entire website. According to UsableNet:

“LIFT Text Transcoder allows you to easily and quickly add the valuable “text-only” version to every page on your web site, providing the best possible access to your site for people with disabilities.”

“The best possible access” for people with disabilities? There are so many things wrong with this claim, I’m not sure where to start. Aside from the fact that this statement assumes that all disabled users are visually impaired, it also makes the false assumption that all web content is magically made more usable by simply removing images.

A quick review of the Sacramento County website should dispel anyone of this notion almost immediately. The home page’s HTML doesn’t validate, there are several accessibility problems on the entry page, and the cluttered design and seemingly random navigation is far from usable. Ah, but there’s that ‘text only’ link near the top of the page. If (and that’s a big if) this site’s disabled users make it that far they’re treated to a plain-text version of the home page that, while technically compliant with section 508 guidelines, does not in any way provide a better user experience. It’s certainly no easier to navigate, and extremely challenging to find anything useful (although we are informed that the site banner is a “Collage with basketball, ballet and river boats”).

The problem with products like the LIFT Text Transcoder is that they appeal to people who really don’t care about web accessibility. Decision makers who have just been informed that they have a problem they were not previously aware of are usually looking for the quickest possible solution. If that solution comes in the form of a piece of software that purports to provide “the best possible access” for people with disabilities, you can probably guess what decision will be made. Executives will buy LIFT thinking they’ve just bought a lifetime pass on the accessibility issue — problem solved. Meanwhile, the underlying structural problems that contribute to the most common accessibility and usability problems go unaddressed.

In UsableNet’s defense, they do make a variety of other tools that appear to be more substantial than the LIFT Text Transcoder, and elsewhere on their website they note:

“LIFT Text Transcoder is not a complete solution for providing an accessible website”

Despite the disclaimer, I think the damage has already been done. I doubt that many decision makers looking for a quick fix will make it this far. Even if they do, they’ve already been conditioned to think that accessibility is a problem that can be addressed with automated technology and minimal human intervention. Worse, these systems seem to reinforce the belief that web design is the end result of some commmoditized product, rather than the result of an ongoing effort to improve communications by crafting a quality user experience. The former is cheap and requires little thought. The latter is hard and requires organizational commitment.

In contrast to LIFT’s automated approach to accessibility, Veen’s position seems positively enlightened. The Veen approach places an emphasis on well architected information, good design, educated designers, and a commitment to standards. While these elements are not always guaranteed to produce accessible web content, they’ll usually get you pretty darn close. In most cases close enough to bring your site into compliance with a minimal amount of effort. The result will almost certainly be a better user experience for all of your users.

Links:

• Matt May – I Care About Accessibility
• Jeffrey Veen – I Don’t Care About Accessibility
• UsableNet’s Text Transcoder
• Sacramento County
• It Could Be Worse
• Zeldman On Lift

While there are now numerous examples of major corporate websites adopting web standards, there’s nothing to keep the public/non-profit sector from following suit. Web Standards are for everyone. With a bit of education, advocacy, and training, non-profits can easily reap the benefits of standards in the same way the corporate sector is.

It seems quite obvious that corporations are not adopting web standards because of some innate sense of social responsibility. Businesses are attracted to standards because of the many cost related benefits they offer. Standards offer lower cost of maintenance, ease of implementation, and better cross-platform support. It just so happens that increased accessibility is a byproduct of using the most recent technology.

Non-profits and government agencies should realize they can lower their costs and improve the quality of their websites by embracing standards and by rejecting authoring tools that mangle code. In most parts of the world non-commercial agencies are under increased pressure to do more with less. What better way to economize than to make a commitment to standards?

Has your educational, non-profit, or government agency made a commitment to standards and accessibility? If so, leave a comment telling us about your experience. And by all means, link to your site.

A quick check of the page in question produced interesting results. The page rendered perfectly in Mozilla, Opera, and Safari. Internet Explorer was another issue entirely. The columns seemed to melt together in ways that defied web physics.

A look at the page source revealed the problem. One of the administrative users had added a calendar item to the CMS by copying and pasting a document from Word. While our CMS does make an attempt to sanitize Word’s output, there’s only so much we can do. The resulting markup looked identical to what you would expect to see if you had exported a Word document to HTML.

It’s ironic that the process of exporting a document from Word to HTML would have the effect of breaking the web page in Internet Explorer only. It’s also pretty darned annoying.

We quickly sanitized the HTML in question and the page returned to normal, rendering consistently across browsers and platforms. We also spent some time educating the user on the potential issues involved in this sort of document conversion. Still, the potential for disaster is just a cut-and-paste away.

Clearly, user education is a big part of the solution. While the transition from Word to Web should be transparent, it isn’t. Users charged with publishing web content need to be aware of the pitfalls.

As my previous article pointed out, even if Word could do a reasonable job of converting documents to clean xHTML, most Word documents do not contain the semantic information needed to translate to an HTML equivalent. Michael Gross’ article When Word to XML Conversions Get Nasty provides a good overview of the many challenges we face in re-purposing Office documents for the web.

Your staff should not neglect proper Word markup just because Word is currently unable to easily export to the format the rest of the world uses to publish documents online. At some point either Microsoft will enhance Word to provide this functionality, or your organization will acquire document conversion tools as part of a larger document management initiative. In either case, you won’t be able to extract semantic information that doesn’t exist.

While it’s tempting to segregate Web production standards from day-to-day clerical functions, it’s important to understand that poorly trained front-line staff can have a direct impact on your website’s accessibility without ever touching your CMS (or whatever tool you may be using to publish your website).

If you haven’t done so already, it’s time to take a holistic view of your organization’s content. Inaccessible web content frequently starts out as a poorly produced Office document.

Based on the list of panels for this year’s conference we’re looking forward to several days of informative sessions devoted to accessibility, usability, and web-standards. We’re particularly excited about the prospect of so many of the leading figures in the emerging web standards community being in one place at the same time.

I have to say that I’m skeptical about these claims. Are these agencies completely unaware of Mozilla and the fact that it’s FREE? How do they rationalize standardizing on seven year old technology when the best web browser on the planet is available at no cost?

If possible, I’d like to debunk this myth once and for all so we can all move forward with accessible, standards-based design. If anyone has hard evidence of government agencies that still use Netscape 4, please post a brief comment here. I’d like to get to the bottom of this once and for all.

Microsoft’s latest offering, Word 2003, features the ability to export to numerous formats including XML and two varieties of HTML (filtered and regular). I have to admit that I held out some small hope that ‘filtered’ would produce the sort of clean code we’ve all been waiting for. No luck, the resulting HTML still included embeded ‘mso’ class references on every element. I can understand, and even appreciate, the applications attempt to generate a document specific stylesheet. I’d appreciate it even more if I could turn that ‘feature’ off.

The majority of Word documents we come in contact with are smaller content items with light to moderate formatting, and are destined for organizational websites. In all cases, those organizational websites have their own stylesheets that would easily accomodate a properly marked up xHTML document. In nearly all cases, the resulting Word document exported to HTML produces code that requires a significant amount of cleanup effort.

There are code sweepers, HTML tidiers, and even large and expensive applications devoted to the task of converting Word documents into well structured HTML. Still, by the year 2004 you’d expect this ability to be built into the core product.

In Microsoft’s defense, as this WebAIM tutorial points out, most users do not create truly structured Word documents. That is to say, most Word users will create a header by changing the selected text’s font properties rather than applying an H1 style. Clearly, this is just as much a training issue as it is a technology issue. Still, even when styles are applied consistently the resulting HTML is loaded with the previously mentioned ‘mso’ class references, not to mention <i> in place of <em> and <b> in place of <strong>.

If I didn’t know better, I might suspect that Microsoft simply doesn’t want to solve this problem. If Word could be counted upon to reliably export clean xHTML it would be much too easy for users to move their documents to some other editing tool. Bill Gates has made no secret of the fact that proprietary file formats create a market advantage for Microsoft — and major headaches for the rest of us.