Note: My Web pages are best viewed with style-sheets enabled.

Unrated

"Professional" Web Developers

Copyright © 2005-2009 by David E. Ross

[On this Web page (and on some of my other pages), I use certain technical terms that appear as links to their definitions. If you select any of those links, my Internet Glossary will appear in a separate browser window so that you will not have to keep going back and forth between pages. Once the window with the Internet Glossary has opened, selecting a link for a different term will reposition the page to that term. However, if that window was in the background when the link was selected, it will remain in the background. In that case, you merely need to bring the Internet Glossary window forward.]

Web developers offer to create and maintain Web sites for a fee. Too many such individuals and companies, while very good in visual design, have no real ability in the technical aspects of creating error-free Web pages. Instead, they rely on tools that might create acceptable Web pages for Internet Explorer (IE) — tools such as FrontPage — but fail to comply with the internationally recognized specifications for HTML (or XHMTL) and CSS. (Of all the tools for creating Web pages, Word may be the worst.)

With the continued erosion of IE's share of the browser market, this is unacceptable. Web pages that can be viewed as intended only with IE ignore 35% to 45% of their potential audience. Worse, non-standard Web pages can also completely exclude any audience that is handicapped, an audience that relies on specialized Web browsers (e.g., audio browsers for the blind).

The Developers

In the following table, the sites of Web developers themselves were evaluated for four criteria:

• The HTML (or XHMTL) was evaluated using the W3C HTML Validation Service.

  Where a plus (+) appears after an HTML error-count, the page could not be initially tested because it lacks an important declaration. The page was tested by forcing the validation tool to assume the existence of that declaration. This is an error not included in the error-count.

• The style-sheet was evaluated using the W3C CSS Validation Service. Where two or more pages for a given developer were evaluated, the error-counts might reflect duplicate errors from the same external style-sheet file. However, a page might also contain an internal style-sheet unique to that page, which means different errors are counted. Thus, error-counts cannot be added to obtain a total for the Web site; but one page's error-count does not necessarily characterize the whole site.

  Where an X appears in the CSS column of the table below, it indicates a page that uses no style-sheet. Given the importance of style-sheets in modern Web page design, this lack may indicate a significant deficiency in the Web developer's capabilities.

• The number of Flash presentations were counted.

The two cited evaluation tools are readily available and free. There is really no excuse for a Web developer not to use them as part of its quality assurance process. This page that you are now viewing was tested. The initial version did have errors, but they were all corrected before this page was released for public viewing.

Only errors are reported, not warnings. Where both error criteria (which excludes Flash) show no errors, the entry is highlighted in bold Italics (except if viewed with style-sheets disabled).

Note: Accessibility used to be evaluated for WCAG-A using Watchfire's WebXACT, but the WebXACT tool is no longer available. Since newly tested sites are not being evaluated for accessibility, fairness required that I delete the reports of that evaluation for those sites previously tested while the tool was available.

Think: If Web developers cannot create error-free Web pages for themselves, what kind of garbage will they create for you?

Any business contracting with an outside service for Web development should specify in the contract that all Web pages comply with the HTML or XHMTL specifications and that any style-sheets comply with the CSS specifications. Final payment for the service should be withheld until compliance is successfully verified. Further, I urge customers of Web developers require compliance with either Section 508 requirements or WAI guidelines for accessibility.

Flash

For vivid graphics that truly help promote a product or service, Flash presentations can be very effective. A number of these developers make extensive use of Flash on their Web pages. However, several of their Web pages use Flash to present links and buttons for site navigation.

Many Web users disable Flash. They do this because the presentation files are quite large. Many individuals who access the Internet at home still do so through dial-up modems. Further, many Web servers cannot consistently deliver content at broad-band speed to those with DSL or cable modems. Thus, the choice is between tying up a computer for a minute or more to download the presentation or simply disabling Flash.

Where a Flash presentation is necessary for site navigation, the utility of the Web site for promoting a business is destroyed when a user disables Flash. Web users who have disabled Flash are more likely to go elsewhere on the Web rather than enable Flash to navigate a site. Also, Flash presentations are often inaccessible by the handicapped.

Customers of Web developers should carefully question any plans to use Flash, to ensure that visitors to their Web sites are not driven away by gratuitous graphics or by graphics that are required for site navigation. Otherwise, you might be paying for a feature that might be counter-productive.

However, Flash itself should not be considered a bad feature of a Web page without considering the context in which it is used. For example, Flash can be quite effective for displaying a product in action. Thus, the column showing the count of Flash presentations in the table above is separate from the columns showing errors.

Why Validate Web Pages?

Just before the list of developers, I indicate that I validated the HTML and style-sheets (CSS) of their Web pages. Why is this important?

When I was a software test engineer, one of the first questions we would ask before starting to test a software package was: "Were there any compilation errors?" We would refuse to test it until it compiled error-free. We would not test garbage.

Validating both the HTML (or XHMTL) and CSS of a Web page is very similar to compiling computer software. And the consequences of errors is also similar: A Web page with HTML and CSS errors will display unpredictably.

No truly professional Web developer should deliver a Web page that cannot validate error-free. This is something clients of Web developers must demand. After all, would you purchase software that fails to compile correctly?

Yes, some browsers are tolerant of HTML errors, often unintentionally as the result of bugs. Some Web developers try to take advantage of that tolerance, intentionally making use of those bugs. However, are you trying to reach an audience that only has buggy browsers; or are you trying to maximize your audience? And what will you do when your audience upgrades their browsers to newer versions in which the bugs have been corrected or (worse) behave differently?

Note, however, that validating a Web page merely checks to determine if the HTML and CSS syntax comply with the World Wide Web Consortium (W3C) specifications. The spelling, grammar, and punctuation of text are not checked. The aesthetic appearance of the page is not checked. A Web page that has been validated should be merely presumed to comply with standards, the next topic.

Standards: Why and How

Light bulbs and lamp sockets are manufactured according to compatible standards. This is necessary because the several companies that make bulbs need to ensure their products can be screwed into the sockets made by several other, unrelated companies. Similarly, Web pages are written by individuals not associated with the companies that create Web browsers. Thus, the files that constitute Web pages must meet standards compatible with those used to create browsers.

Contrary to popular belief, Microsoft does not produce the only Web browser and thus does not dictate the standards for Web pages. The standards are developed and documented by the W3C, a non-profit organization. In its mission statement, first among W3C's long term goals for the Web is

Strictly speaking, W3C does not create standards. It provides specifications. Lacking any competing specifications that are not proprietary and tailored to a particular manufacturer's product, however, the W3C specifications may be considered as standards. Alan Richmond presents an excellent argument for why standards are important when developing Web pages. Karl Groves has two blog entries that focus on why businesses in particular should be concerned about standards: The Top 20 Web Mistakes Small Businesses Make and The importants [sic] of standards compliance and the process of validation; his other blog entries address some of the same issues presented here.

For a business contracting with a Web developer service, the key issue is maximizing the audience for the business's Web site. This requires maximizing the variety of browsers that will display the site properly. This also requires being found by search engines, several of which correctly index only those Web pages that comply with standards. A business that ties its marketing and public image on the Web only to Internet Explorer (with its declining market share) — using proprietary, non-standard Web page features supported only by Internet Explorer — is headed for trouble. Without adhering to the W3C specifications, that business says:

Cartoonist Dan Piraro vividly illustrates the importance of standards. A browser can only do what we tell it to do. What a Web developer wants must be expressed according to the standards. Only then will tell = want without regard for what brand of browser is used. Otherwise, there may be significant differences between how the developer wants a Web page to appear and what his page tells my browser to display.

In the end, the issue is clear:

• If my Web page complies with the W3C specifications and was checked by viewing it with a standards-compliant browser, any problem you have with viewing it as I intended is the fault of your browser. You can upgrade your browser or change to the product of a different company. If you are using a current browser version, you should notify the company that developed it that it has a bug.
• If your page does not comply with the specifications — or worse uses proprietary capabilities found in only one company's browser — any problem that I have with viewing it as you intended may easily be the fault of your Web page. You need to fix your page before pointing an accusing finger at my browser. If you don't care, then I don't choose to view your page.

Note that there are other standards involved in Web page creation. For example, there is RFC 3986 (actually a request for comments on a proposed standard) for the format of Web page addresses and the addresses of other entities on the Internet. These addresses are Uniform Resource Identifiers (URIs, commonly called Uniform Resource Locators or URLs). A common violation of RFC 3986 is the presence of blanks within a URI. Thus, we see

<http://www.abc.com/my  page.html>,

<http://www.abc.com/my_page.html>.

<http://www.abc.com/my%20page.html>,

RFC 3986 also specifies that, when quoting a URI, it should be bracketed within < and > (as seen above).

Terminology

A non-technical overview of Web terminology might be helpful, not only for understanding the table above but also to help when choosing a Web developer or discussing your needs with a developer.

A Web page is what a user sees in the browser window. Primitive pages consist entirely of unformatted text, such as the page for RFC 3986 cited above. However, most people think of formatted pages when discussing the Web.

A formatted Web page consists of three major parts, each in their own files: HTML, style-sheets, and images.

HTML stands for "hypertext markup language", an annotation used to format a Web page. The term "hypertext" refers to the use of links in a page to reach other pages. HTML is used to describe the language used in the page (e.g., English, Russian, Chinese), the characters used for text in that language (e.g., Roman, Cyrillic, Greek), the layout of text into paragraphs and tables, and the placement of graphics. HTML also creates the links to other Web pages. Most important, the actual text of a Web page is contained in the HTML file. To view a Web page, the user generally requests the HTML file for that page (thus the extension htm or html in a link). Some pages — especially pages displayed as frames — use multiple HTML files.

For this discussion, HTML also includes XHMTL and other markup languages, each of which has a formal specification under the control of the W3C. It also includes dynamically-generated PHP files.

Style-sheets define the margins, fonts, colors, spacing and other attributes that characterize a formatted Web page as different from an unformatted page. While much of this formatting can be specified using HTML in an HTML file, current practices indicate that cascading style-sheets (CSSs) should be used instead. CSSs are found in three forms:

• Separate, external CSS files linked to HTML files,
• A CSS section within the beginning of an HTML file, and
• Embedded style specifications at the place within an HTML file where the formatting applies.

This allows a hierarchy of styles — the cascade — where embedded specifications override a CSS section, which overrides an external CSS file. The hierarchy also allows multiple CSS files, with rules describing how one overrides another. The use of external CSS files is important because they permit changes in the formatting of a collection of Web pages without requiring each HTML file to be changed, the changes being made in only one or two CSS files. (I once changed the font for an entire Web site of over 30 pages by changing only one line of a CSS file.)

Style-sheets also have a formal specification under the control of W3C.

Images are the graphics seen on a Web page. They can serve merely as decoration or to illustrate a point. Images can also be the primary purpose of a Web page, such as a display of photographs. Images are generally either GIF (Graphical Interchange Format) or JPEG (Joint Photographic Experts Group) files. The former is a patented format of Compuserve freely used in the computer industry with Compuserve's permission; the latter is an international standard. BMP (Bit Map) and PNG (Portable Network Graphics) image files are also seen; both of these are international standards.

Besides HTML, style-sheets, and images, Web pages might contain other features such as audio, streaming video, and Flash.

For more Internet-related terms, see my Internet Glossary.

Accessibility

We often think of accessibility in terms of physical barriers: stairs confronting those in wheelchairs, door knobs impossible to work for those with arthritic hands, and distant parking spaces creating excessively long walks for those with heart disease. With the Web, there are communication barriers. The deaf cannot hear streaming audio and arthritic hands might not be able to grasp a mouse or work a track-ball.

The largest problems confront those with visual handicaps. Some of these problems even affect the rest of us.

• A color-blind person cannot read red text against a green background. Even without color-blindness, red text against a patterned yellow and orange background may be difficult to read for all of us.
• Highly stylized fonts can confuse a person with dyslexia. Unusual fonts might exist on the computer of the person creating the Web page but not on the computer of a person reading it.
• A partially blind person needs large type to read, but fixed font-sizes prevent changing the size. The rest of us may also have problems with small type as we age. This is a special problem if "text" is actually a graphic image of text (e.g., the labels on navigation buttons) with no real text available as an alternative.
• Information contained only in an image is unavailable to a blind person using an audio browser.

This last only touches a much more serious problem. Audio browsers function poorly — or fail entirely — when Web pages do not comply with published HTML specifications. This is the most important consideration for making Web sites accessible to the handicapped: the pages need to comply with the W3C specifications. Other considerations relate to design characteristics that maximize the user's options (e.g., allowing the user to change fonts and font sizes, override colors). For audio browsers, pages merely have to be coherent if displayed as plain text, without images or formatting. Such a display might not be aesthetic, but it should be understandable.

Two different accessibility guidelines exist:

• The Web Accessibility Initiative (WAI) — a program of W3C — has three levels of rigor in its Web Content Accessibility Guidelines (WCAG).
• Section 508 of the U.S. Rehabilitation Act of 1986 (as amended in 1998) contains the mandate for government Web sites to be accessible.

See also Policies Relating to Web Accessibility.

"Sniffing"

In an attempt to create Web sites for all browsers, some Web developers create a separate set of Web pages for each major browser. They then try to take advantage of non-standard peculiarities of each browser to enhance those pages.

To detect which browser is accessing a Web site, the Web server is programmed to "sniff" the browser's user agent (UA) string. The UA string is an identifier sent by each browser when requesting a Web page.

There are several problems with sniffing for browsers:

• After sniffing for the most popular browsers, other browsers should not be ignored. If a Web site sniffs for Internet Explorer, Firefox, Chrome, and Safari, it must also provide for displaying pages for Opera, Konqueror, SeaMonkey, Camino, Chrome, and others.
• The site must sniff for the correct portion of the UA string. Mozilla browsers — Firefox, SeaMonkey, Camino, Netscape, and others — all use the same Gecko engine. These browsers differ merely in their user interfaces (menus and toolbars) and the hosts on which they operate. It is the Gecko engine that interfaces with Web servers, negotiates security, and displays Web pages. Thus, a server should be sniffing for Gecko and not Firefox. Approximately 120 commercial Web sites are known to violate this rule; the Mozilla organization is attempting to convince the site owners to take corrective action. (For more information, see Gecko is Gecko.)
• Sniffing for a particular version of a browser must not ignore other versions and must provide for future versions. There are far more users of Internet Explorer 7 than there are of Internet Explorer 8. Do you sniff for Gecko 1.8.1.17 or for all sub-versions of Gecko 1.8? And will you update your Web site when Gecko 1.9 goes into use?
• Many browsers have options that easily allow users to spoof other browsers by sending fake UA strings. Using SeaMonkey, I can spoof Opera, Netscape, Firefox, and Internet Explorer (including IE 5.0 on a Mac). This completely defeats the purpose of sniffing.

Obviously, there is something wrong if I cannot properly view your Web page from a browser that identifies itself as

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12, NOT Firefox/2.0.0.17

Clients of Web developers should ask whether there will be any browser sniffing. If there is, question how the four points above are addressed. More important, question why there is sniffing at all. Generally, Web sites that require sniffing also require more frequent maintenance to adapt to new browser versions; there is usually a cost associated with such maintenance. In any case, a Web site that adheres to the W3C HTML and CSS specifications should not require any sniffing at all.

Problems with sniffing can be avoided by having Web pages that comply with the HTML and CSS specifications and following the guidelines of the Viewable With Any Browser Campaign. That makes sniffing unnecessary.

There is another form of sniffing. Secure Web sites (e.g., those where you access your bank account) sometimes sniff for your IP address. The intent is to determine if you are using the same computer that you used before; the computer is being authenticated, not the user. If a site finds an IP address different from the one you had when you previously logged-on, you are required to go through additional steps before you are allowed to logon.

The problem is that, if you access the Internet through a dial-up modem (as do almost 20% of the Internet users in the U.S.), your IP address changes every time you connect. Even with a broadband connection, your IP address might change if you reboot your computer (e.g., after a power failure, after a shutdown for a vacation, after installing a Windows patch).

There are better ways — less annoying ways — to authenticate a user's computer than sniffing an IP address. One way would be to set a cookie on the user's computer with some random string of characters, also saving that string in a database on the Web server. The logon process could then compare the two strings. If they match, the computer is likely the same as the one you used previously.

Authenticating by checking IP addresses is actually not very secure. When you disconnect from the Internet, your IP address might then be reassigned to another user who connects through the same ISP.

If you are having a secure Web site developed (e.g., for E-commerce), you should ask the developer how customers will be authenticated when they logon. Unless you want to annoy some 20% of your customer base, be sure that authentication does not involve sniffing for IP addresses.

Do-It-Yourself Web Development

Some larger businesses and many government agencies have internal organizations for Web development. Non-profit organizations often rely on unpaid volunteers. This avoids any problems caused by using incompetent outside Web developer firms, but it does not excuse them from HTML and CSS errors or from having pages that are inaccessible to the handicapped.

Two major factors lead to problems with internally developed Web sites:

• There are no generally accepted qualifications required when a person presents himself or herself as a Webmaster. Often, internal organizations tasked with creating Web sites are staffed with personnel who do not even know that the W3C exists, let alone that there are internationally accepted specifications for HTML and CSS. In federal agencies, such personnel might not know that there is a law mandating accessibility let alone what guidelines should be followed.
• Too many managers lack technical experience. Far too readily, they accept the concept that, if Micro$oft says "It's okay", then it must indeed be okay. They provide Micro$oft's FrontPage to their staff as the tool for generating Web pages. They believe that, if a Web page looks as intended with Internet Explorer, it looks okay to the entire world. They do not realize that they have tied their Internet presence to a browser with a steadily declining market share, to a "fading star".

When Web sites are developed internally, management must still be concerned about reaching the broadest possible audience. Thus, they should require a quality assurance process that subjects each Web page to the same two error tests that I performed for the chart on this page. While this testing might not be necessary for each minor update to a page that was already tested, it should be repeated occasionally when a section is added to or deleted from a page. If a Webmaster has any pride in the work she or he performs, this testing should be done even if not required by managers.

In any case, managers responsible for how a company or agency presents itself to the public should be concerned about how Flash is used, about adherence to standards, and whether that presentation is accessible not only to the handicapped but also to any of the 35% to 45% of the public that use non-Micro$oft products to view the Web.

Text Content

Even if you retain an outside Web developer, you should supply all text content for your Web site. In the end, you — not the developer — will be held accountable by others for your site's content.

Whether you use an outside Web developer or create your Web site in-house, be careful when creating your text content. If the content libels a competitor or plagiarizes someone else's copyrighted work, you can be the target of a lawsuit. Actually, plagiarism can even be a criminal offense. Some Web hosting services will immediately shut down a Web site against which a copyright complaint has been filed. How would you react if the site for which you paid a significant amount to develop was suddenly terminated?

On the other hand, if you create good, original content, be sure that you retain publication rights (e.g., a copyright). Do not surrender your rights to an outside Web developer who might then collect a fee for supplying your content to another customer. After all, you either put your own effort into creating the content, or else you paid someone to create it for you. Only you should be allowed to profit from that work.

Updated 9 June 2009

This page has been visited 7130 times.

"Internet" Table of Contents

David Ross home

E-mail