Friday Feast #22: Practicing What We Preach About Standards, Accessibility, and Starting Backwards

Some expect W3C members to follow their own Recommendations, whether their sites are personal or business. Not surprisingly then, people are writing about W3C member sites not validating and Bobby-failing accessibility related sites.

Is it fair to expect W3C members to create sites that follow W3C Recommendations? Is it fair to expect those advocating accessibility to create accessible sites? Sure. [1] The big question to answer for me, though, is to explore why they aren’t. Maybe by examining those reasons we can address stumbling blocks that impact other companies, clients, and the rest of us.

So what are possible reasons for lack of compliance? A few general reasons:

  • Lack of awareness, understanding, education about standards or accessibility
  • Lack of authoring tools that create or maintain standards-compliant or accessibility-compliant sites
  • Don’t care about standards or accessibility
  • Budget constraints, whether to upgrade the site or for authoring tools that assist with compliance
  • Lack of proof that standards-compliant sites can be more time- and cost-effective

Stumbling Blocks

In discussion lists I often read from company web developers that they’ve just been handed the company website to maintain and don’t have a clue about where to start and hadn’t even heard of standards before.

Other developers maintain their philosophies and approaches of creating sites that look identical cross-browser and cross-platform by implementing markup full of hacks and workarounds, disregarding standards-compliance. Others may have preconceived ideas or misunderstand what standards-compliance really means and refuse to even consider an approach based on W3C Recommendations or accessibility, providing all kinds of reasons why they won’t give standards a chance no matter what anyone says.

Other all-too-common dilemmas are asked from developers who’ve been handed a design to develop for a site from a graphic designer unfamiliar with the Web or standards who created a beautiful design that may work well for print but won’t work for the Web.

Sometimes the bosses giving the orders don’t know about standards, and if the developers ask about upgrading the company site to be standards-compliant and more accessible, the bosses respond that it isn’t in their budget, costs too much, they have “more important” things to do, or other reasons. When standards aren’t required by law or they can’t see solid proof of the advantages, they may not be very interested.

Wanting, Needing Proof

But what if those same developers, bosses, or clients learned that standards-compliant sites can be maintained easier and faster and be more longer-lasting, thus being more cost- and time-efficient? What if they learned that a more user-friendly e-commerce site can generate greater earnings by being more widely accessible and even loading faster? In order to be convinced, though, they probably need to see that proof. Understandable.

Looking around the Web you may see mention of this but not enough documentation to take to the boss or client. Jeffrey Zeldman’s upcoming book, Forward Compatibility: Designing & Building With Standards will provide documentation sometime next year, with an excerpt published earlier this week at Digital Web. I’ve written previously about articles that explain the benefits of standards.

CMS and Authoring Tools

And what if the developer wants to create a valid, accessible site, the boss or client OKs it, but the CMS or authoring tools they have won’t generate or maintain valid or accessible markup? This is often a major stumbling block. Part of the Web Standards Project’s Phase II mission is to help educate and work with tool makers to create tools that facilitate standards-compliancy.

To find tools, try W3C’s sections: Web Authoring Tools, CSS Authoring Tools and Accessibility Tools; and’s sections: CSS Editing Tools, HTML Editing Tools, Accessibility Tools.

Starting Backwards

My own take is that we started backwards. What I mean is that we didn’t start out over 10 years ago now designing sites, browsers, or authoring tools and related with standards or accessibility in mind, even if TBL and others had this in mind. Before long browser makers were competing for the market share and insisting on their own proprietary markup and code. It took major campaigning and pressure before the major browser makers finally began creating standards-based browsers (with even Opera promising to include full DOM support with its upcoming version 7 Web browser). More pressure and accessibility laws had to be passed in the U.S. and elsewhere before tool makers would begin to provide software to help create and maintain accessible sites.

In the meantime, many learned to create sites with hacks and proprietary markup and code, adding more with each new browser version. Old habits or approaches may be tough to change, some just don’t want to go to the effort or aren’t into continued education, even when old ways are now outdated and will create increasingly more problems.

So many were also thinking of the Web being like print (and still do), often adapting print designs to the Web. Clients insisted that their sites look absolutely identical despite the browser or platform. Designers and developers were priding themselves on being able to accommodate that.

Earlier this week Digital Web published 99.9% of Websites Are Obsolete, an excerpt from Jeffrey Zeldman’s upcoming book, Forward Compatibility: Designing & Building With Standards. This excerpt goes into a lot of what happened and why so many sites and their owners are in a quandary... or will be soon. As Zeldman also states, we really can create sites that follow standards and work well in the major browsers and even work for a variety of platforms and devices.

Web Standards Project Steering Committee members Steve Champeon and I were also interviewed this week for Digital Web. In that interview I spoke of thinking of this medium not as an extension of print but as its own unique and very flexible medium:

“The Web is NOT print. Someone looking at a printed brochure can’t change it as it’s printed that way; however, the Web isn’t at all like that print brochure. Pages are rendered differently on the multitude of browsers and platforms out there. Visitors can also change the window size to whatever they wish within their display settings, change font sizes and colors, and use their own style sheets. This is a highly flexible medium. Trying to force Web pages to look identical regardless of platform or browser is trying to force Web pages to be something they aren’t.

“Instead, I suggest marveling at this flexible and amazing medium and learning how to use that flexibility rather than trying to prevent it. Consider how amazing it is that the content can be displayed on millions of computer displays around the world in all kinds of dimensions. Pages can be stretched out and reduced, colors can be changed, fonts and font sizes can be changed at the whim of the viewer, and much more. PDAs and cell phones can access Web pages, voice devices can speak the content, and more.

“How does any of that relate to standards? Creating standards-based sites can help facilitate this medium’s incredible flexibility and use its potential. I think it’s exciting to see seemingly limitless possibilities. Understand the medium. Don’t try to force it to be something that it isn’t.”


Friday Feast archives

[1]One attitude is that rules don’t need to apply with personal sites; however, there are still those holding W3C members' personal sites accountable right along with members' company sites. Even if we exclude members' personal sites, though, there are many companies, both large and small, represented on the W3C Member List. And the Bobby-failing list didn’t surprise me either, unfortunately.

07:41 pm, pdt 6 September, 2002 Comments, Trackbacks ·';}?>

Categories: Accessibility, CSS, Design, Friday Feast, Reviews, Standards, Typography, Usability

*/ ?>