Steven Champeon and Shirley Kaiser

In: Interviews

By Meryl K. Evans

Published on September 4, 2002

Current Climate
Get Real with Standards
Compliance

Current Climate

Digital Web: Just prior to ending Phase I, the WaSP announced that the browser makers were finally up to standards, and that the rest of the work for supporting client side standards rests in the hands of designers. How do you see the WaSP’s mission evolving at this point?

Steven Champeon: Oh, I don’t think it is all in the hands of designers at all. I’m more inclined to think that we have to educate the developers of non-browser systems, such as content management systems, authoring tools, ad banner networks, and so on. Even designers with the best of intentions can have a valid design wrecked by a CMS or the inclusion of an invalid ad banner. Of course, designers and developers are the ones with power in this case; if they demand better tools, they’ll eventually get better tools.

Shirley Kaiser: There were actually 3 main areas needing attention mentioned in the final note of Phase I—designers and developers, tool makers, and clients. Now, that the major browser makers are on board with standards-based browsers, we can turn our attention toward educating designers and developers, tool makers, and clients.

Too many designers and developers know little about standards or have misconceptions. Tool makers need to pay attention to standards to help designers and developers using their tools to effortlessly create standards-compliant sites. Our clients are so often clueless about standards, too, and we need to guide them to information or talk to them about how the Web is different from /files/includes/print.css and why using standards is beneficial. If designers and developers don’t know, they can’t relay that information to their clients either.

Regarding the tool makers, I believe Dreamweaver was the first or almost the first WYSIWYG Web authoring tool to provide downloadable plug-ins for W3C’s Web Accessibility Initiative Guidelines.

Macromedia Dreamweaver Extensions include Accessibility extensions.

Most recently, WaSP’s Dreamweaver Task Force worked with Macromedia’s Dreamweaver team, the results of which are in their tremendously improved standards support features out of the box with Dreamweaver MX. Macromedia provides downloadable extensions for U.S. Section 508 conformance.

Dreamweaver is only one of the many WYSIWYG tools out there, though, and most markup I’ve seen from WYSIWYG tools leave much to be desired. A knowledgeable developer can clean it up, but if people buy a WYSIWYG tool it must include WYSIWYG standards markup right out of the box without the need to clean it up.

Glenn Fleishman provides a comparison chart of features for Dreamweaver MX with Adobe GoLive, two major WYSIWYG tools. In the chart under the standards support category and elsewhere you’ll see that they both support HTML, XHTML, CSS, and XML technologies and I applaud that, naturally. However, Dreamweaver MX comes with pre-built accessible Web site templates and GoLive does not. Dreamweaver MX comes with sample CSS style sheets and GoLive does not. Designers and developers must be able to create standards-compliant sites effortlessly right out of the box with all WYSIWYG tools. I also feel this needs to include WAI Guidelines.

Digital Web: Hence, we meet Phase II of the WaSP. What is Phase II about? How has it changed from Phase I?

SC: We were originally focused on raising the profile of standards via press campaigns and the like, speaking on behalf of developers who arrayed themselves behind the cause. Our primary target was the browser vendors. Nowadays, the browsers will, for the most part, accept and do the right thing with a valid document, so it doesn’t make sense to continue to beat up browser vendors when there are far worse problems out there, problems that could be fixed if CMS vendors and other tools vendors cared to fix them. It’s also important to educate developers, so that’s the two-prong approach we’re taking. Educate developers, help them educate their managers and clients; and make sure that they have support from the tools vendors so that they can actually implement standards-compliant solutions without having to abandon their tools.

SK: Phase I was primarily about convincing browser makers to adhere to W3C Recommendations. While the channels are still open with the major browser makers, they’re already convinced. We’re remaining supportive of their efforts.

Phase II is primarily about standards education. It’s about educating designers and developers about why standards matter, how to create standards-compliant sites, and how to explain the benefits of standards to their clients. It’s about educating tool makers about why standards matter and to encourage them to create tools that provide an effortless ability to create standards-compliant sites right out of the box. It’s about educating clients about the benefits of standards and why standards matter. That’s a huge umbrella that covers many areas but it’s critical and important.

Digital Web: There are many sites—even good ones—that continue to omit the DOCTYPE declaration from their pages. What can be done to reach the designers who have remained blissfully ignorant of Web standards, or the resources assembled to promote them?

SC: You can’t make people think if they don’t want to, or aren’t capable. But you can reach out to the curious, the well-intentioned, and that’s what we do. Articles like this one raise awareness, or at least form part of an ongoing effort. For every Web designer who takes the lazy way out and complains about how hard it is to deal with standards, there are a few more who realize they are part of a larger and more elegant system, and that constraints enable good design.

SK: As the saying goes that you can lead a horse to water but you can’t make him drink, so the same goes with standards education. Standards need to be seen as much as possible. Providing articles on the Web and in magazines, including standards issues in textbooks that teach web design, and including standards issues in workshops and seminars can all help to promote awareness that standards exist.

Additionally, people often need a reason to look even once at something. If designers and developers can immediately see benefits and advantages to Web standards I think they’ll be more inclined to learn about standards and try a standards-based design approach. We can help facilitate that not only in words but also in actions by showing them standards-based designs that can work well for their clients or companies.

Regarding clients, clients often don’t know standards exist. Some of those who do may not care, which may be from lack of information or from being misinformed. We can help educate them by explaining standards to them at a level they’ll understand so they’ll easily grasp the benefits. Explaining cost benefits to using standards may be a language clients may far more easily understand while their eyes may gloss over if you try to explain style sheets, XHTML, or the DOM.

Digital Web: A few of the most effective ways to enhance a site’s accessibility are: to provide more text in the form of ALT and TITLE tags, to verify that forms have the LABEL element, and to offer text-based versions of sound files. These development tasks take time, which means more resource hours. How can we expect the Web site sponsor to require and pay for an accessible Web site if its sense- or mobility-impaired audience is relatively tiny, or nonexistent?

SC: Well, personally, I question whether most site sponsors know who their audiences are, due to the circularity of the reasoning—”our site looks awful in NS4, but that’s okay, we don’t have many NS4 visitors.” Well, maybe if your site didn’t exclude a specific browser, you’d have more visits from those using that browser. But I think that everyone has to make reasonable assumptions about their audiences, and build to suit. It’s all about making an effort, and keeping up that effort. Most of the things you deal with in basic accessibility aren’t much more work; others are a lot more intensive. We can’t ignore economics, but we can’t ignore our audiences, either.

SK: Accessibility guidelines aren’t just about sense- or mobility-challenged visitors, though. Alternative devices for Web viewing are on the rise, including cell phones and PDAs. RSI (repetitive strain injury) and carpal tunnel syndrome is on the rise due to computer overuse and many are turning to voice-activated software and other devices for browsing the Web. I also know of people who turn off images and JavaScript because of their laptop’s limited battery life. We have no way of knowing some of these things from our stats.

Once again, though, the saying applies that you can take a horse to the water but you can’t make him drink… unless they’re required by law. U.S. Government Web sites must adhere to the U.S. Section 508 accessibility guidelines. State and local governments may have accessibility requirements, too, and many countries around the world are adopting accessibility requirements.

I also think there’s a big misconception about the time it takes to add accessibility features to a site, especially while it’s being designed and developed. That may be at least in part due to the Sydney Olympics (2000) accessibility lawsuit in which the developers left out image ALT attributes and claimed it would cost over $1,000,000 and countless hours to fix. If WAI Guidelines are implemented from the start, it takes very little time and effort to include these accessibility features and doesn’t have an impact on the budget at all. The exception would be sound files, animation, and video movies, for example.

Digital Web: Many of the WaSP committee members are working on “strategy.” Can you explain this in greater detail?

SC: Well, it’s a matter of taking the longer view, rather than spewing short-lived tactical decisions. 🙂 On the Web, you see, such short-lived tactical decisions have a tendency to stick around and become strategic. So we’re all trying to make sure that everyone takes the long view into account.

Digital Web: What is the purpose of the newly formed WaSP LEARN Group? How does it plan to achieve its share of the WaSP mission?

SC: It’s pretty simple: they assemble resources that help you understand Web standards. Given that the WaSP’s mission involves advocacy for Web standards, it helps to have educated developers and designers on the side of the Good.

SK: WaSP’s Phase II is standards education. Whether through workshops, the WaSP site, elsewhere on the Web or via books and publications, we wish to help educate others about Web standards.

Digital Web: A frequent topic addressed by the WaSP is the W3C Document Object Model (DOM), but many users and designers are still unfamiliar with its capabilities. How would you explain DOM to a layperson, or a designer? What does DOM have to do with standards?

SC: Well, first of all, the DOM is a standard. It’s simply the exposure of your document’s structure and attributes via scripting. Every time you stick an element into a document, it should be accessible via scripts, so you can have some control over the document’s structure even after it has loaded. From simple stuff like rollovers all the way up to dynamic documents that change based on user input and interaction, the DOM is the way markup is tied to scripting and styles. The concepts aren’t hard, provided you care about what you’re doing, as opposed to thinking that giving a production person a Photoshop file is “Web design.” Sadly, many so-called web designers don’t know much about the Web, and little more about design, which isn’t just a question of visuals—it goes far deeper than that. And yet, it’s remarkably elegant as a set of interrelated systems—markup/structure, styles/presentation, behavior.

The idea is that if your markup isn’t valid, your DOM won’t be, either. And that means your styles won’t be applied as you expect. And your scripts may not work, either. Fortunately, it’s not hard to create valid markup, and there are lots of tools available to help you figure out what needs to be fixed to bring invalid markup up to spec. In my experience, most of the people who complain about standards don’t even have valid markup, so it’s no wonder their sites don’t work as expected across browser and platform. You have to start somewhere.

Get Real with Standards

Digital Web: According to one reputable designer, “What hardcore standards fanatics fail to see is that if you’re creating a graphics-intensive Web site, and still want to support 4.0+ browsers, you can’t code completely to the standards—it just doesn’t work like that in a real-world environment.” What is your response to that claim?

SC: It’s sad to see people closing themselves off to reason like that. By classifying some as “fanatics,” and by defending their own laziness or failure to keep abreast of developments in the industry, they’re bound to become obsolete, like dinosaurs complaining about all the mammals running around. I just hope they don’t ruin other people’s good sense with such nonsense.

SK: They’re misinformed.

Digital Web: A designer wrote us and said, “It’s troublesome to build standards-compliant sites because even the newest browsers vary in their levels of standards support.” Why should we bother, since nothing is ever going to work the same?

SC: More laziness, coupled with a refusal to understand that it’s not about creating sites that look the same in every browser. Come on, people—the Web was never about pixel perfect accuracy across devices. Stop complaining about it and start building real Web documents, documents that degrade and deliver across devices.

SK: Creating a Web page to look the same or not isn’t related to standards. It’s about understanding the nature of the medium with its flexibility.

The Web is NOT /files/includes/print.css. Someone looking at a /files/includes/print.cssed brochure can’t change it as it’s /files/includes/print.cssed that way; however, the Web isn’t at all like that /files/includes/print.css 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.

Digital Web: Another designer told us, “One thing that annoys me is that the Web Standards Project seems to spend a ton of time lobbying AOL/Netscape and Microsoft to create better browsers, and yet they’re not out there bashing down the doors of the independent browser makers (like Opera and the Omni group) who are currently releasing subpar browsers.”

He continued, “Opera on the Mac is a nightmare to code for, with basic support for the DOM spec missing, and its own proprietary implementation of font sizing (if I write 11px in my stylesheet, it shouldn’t show up as /files/includes/10.csspx in their browser—I don’t care what the excuse is), not to mention an inability to change dynamic elements on the fly. Omniweb lacks a ton of things as well. How come you don’t focus some of your energies on getting these things fixed, too?”

SC: I believe we’ve done quite a bit of work trying to get the browser vendors to focus on their standards compliance. We work with the Opera folks, and I believe we’ve talked to the Omniweb folks, too. Our old approach, which involved getting press coverage of failures to comply with standards, worked well with well-known browsers; it’d be less helpful for the smaller, lesser-known browsers, because, in my opinion, anyway, calling out Opera or one of the smaller browsers in a press release would be fodder for people looking for an excuse to stick with IE or Netscape, and wouldn’t make a difference to the vendors themselves. It’s tough. We know the smaller vendors are serious about standards, for the most part, but may lack the resources to implement them across the board, or have different views of which standards are important. So we work with them any way we can.

SK: Regarding Opera, WaSP is in touch with them. They’re working on DOM support for their upcoming version 7. See CNet.com’s recent article about this, my comments at WaSP’s Buzz, and Jeffrey Zeldman’s post.

Regarding smaller browser makers such as OmniWeb, check out A List Apart’s article. Join their discussion list, which their support engineers follow and answer, or write to them about the problems with their browser, and ask them to support more of W3C Recommendations.

Digital Web: Another message stated, “Since my clients still do have a significant number of NS 4.5X users and the majority are Mac users, and I am a NS 4.7 & Mac user myself, I use CSS to a limited extent. Lynx, Konqueror, are not at all a part of the picture, and Opera hasn’t yet been making its presence felt. We’ve had many more NC 4.5X users than Opera users according to recent browser stats.”

She continues, “I’d rather use valid HTML tables, etc. than a lot of questionable hacks that don’t render well, if at all, in the browsers that are important to what the site statistics show.” She has a valid point and she’s very aware and supportive of the WaSP. How can XHTML and CSS be a reality when designers and developers are still dealing with issues like this?

SC: XHTML and CSS are a reality, regardless of what anyone says—it’s not like we’re proposing an alternate view of the universe, here. This is the way things are and will be. It’s up to you how quickly you move to support them in your own sites. There’s nothing that says you can’t use valid HTML 3.2 on your sites if you want to, and no argument can convince anyone to spend money they don’t have to bring outdated designs up to date with no sign of immediate benefit.

But if they want their content to be available and usable in the future, they will have to make some possibly hard decisions. Sometimes this means leaving documents in tag soup markup. Others it means doing an accessibility review and fixing what you can. And, sometimes, it means ditching a bad path for a new, better path.

SK: XHTML and CSS are a reality and are continuing to move forward with next generation versions, whether your clients are using Netscape 4 or the recent Netscape 7. Supporting standards doesn’t mean you must ignore older browsers, though. In fact, standards-based sites can be even more accessible. So many hacks were implemented to cater to Netscape 4’s quirks, making them less accessible and more likely to break in other browsers. You really can design sites that look beautiful in Netscape 4 and follow standards. You can even create sites based on HTML 3.2 if you wish. That’s still following standards.

Especially if you need to cater to Netscape 4 browsers, I suggest a forward-thinking design approach, one that will work while those clients and their site visitors are still using Netscape 4 but also one that can quickly and easily adapt to current technologies when they finally do get current browsers.

Keep in mind that Netscape 4 is over 5 years old now, so they’re asking you to create sites for 5-year-old technology. They may not have a choice about that, and I know that is the client situation for many designers and developers. So bridge the gap with a forward-thinking approach. They’ll thank you now and also thank you later.

Digital Web: “There is a lack of CSS tools for Mac users. Jaguar is shipping with the new Macs, and it looks like an OS X-ified version of Style or Layout Master is not forthcoming in the near term. There’s no version of Top Style for Macs at all. Dreamweaver or GoLive don’t handle CSS very easily or in many cases, effectively. Since a disproportional amount of Web creatives use Macs, and those that do tend to be early adopters, I think it will take better tools for Mac users to jump on the CSS bandwagon”, says a designer. What is WaSP’s plan for the Mac side of things?

SC: I don’t think the WaSP can “plan” for any particular platform. We’re a grassroots bunch of Web developers and designers, not programmers; we can’t tell anyone what to build for a given platform. But I think the “lack of tools” argument is a cop out. If you can only build sites in WYSIWYG editors, you probably don’t know what you’re doing anyway.

SK: While there are certainly more available tools for the PC platform, there are indeed CSS tools out there for Macs. Some of the WaSP folks use Macs, too. Check out the listing at WebsiteTips.com’s links for CSS Editing Tools and W3C’s main CSS page for their listings of CSS editors. You’ll find some for Macs in both places.

Compliance

Digital Web: Some designers believe that following Web standards limits creativity in Web design. How would you define “creativity” in this context, and what are your own thoughts on this issue?

SC: That’s laziness, plain and simple. All good design happens when you know your constraints. One definition of design is that it isn’t possible without a set of constraints, that it is the relationship between the constraints and the solution that makes design possible. All they mean when they complain about these constraints is that they either don’t know how to work within them, or they’re unhappy that they have to work within them—which mean they’re unhappy being designers, and just want to play with colors and shapes and call that design.

Real creativity isn’t as simple as coming up with something that looks pretty and isn’t obviously derivative of something else. Real creativity involves dealing with problems all the way through, and on the Web, that means thinking about markup, about document semantics, multiple presentation paths, accessibility, and behavior. I can’t see how sticking to the rules that define the context could be “limiting,” except of course that it limits the number of truly awful, non-degradable designs out there.

SK: Creativity by nature has some kind of parameters. Standards provide parameters. Many other industries have standards. Take the light bulb as one example. The sockets need to be certain sizes and lamps must use those sockets, too. They also must follow U.S. electricity standards and pass the safety regulations. Do you see creativity stifled because of that?!

Digital Web: Working as volunteers for WaSP on top of your outside lives can be a thankless job. What inspires you when the investment of time and effort seems to bring few results?

SC: Heh. I have a long and varied fondness for thankless jobs—I’ve been a manager, a systems admin, a teacher; you have to take the small triumphs when you can find them, like the guy who wrote in to tell us that after finding our site by accident, he’s become a convert, or the folks who write in to tell us how our site helped them make a successful argument for the use of standards within their organization. The little things keep me motivated.

SK: A strong passion for Web standards is what keeps me motivated and interested. I want to help promote standards and help educate.

Digital Web: Do you foresee a Phase III? Why, or why not?

SC: Of course. What it will look like, who knows? But as long as there is a future, and that future involves publicly-specified Web standards, there will be a Web Standards Project to help.

SK: Sure, I see a Phase III but I have no idea what it will be. We may just need to wait and see how everything evolves to know what’s needed next. I suspect education will keep us busy for awhile, though!

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Web Standards, XHTML, Web Guru