Introduction· Standard· Validation· Tools·
QA Homepage· Latest News· QA Resources· QA IG· QA WG· QA Calendar·
This article has been produced as part of the W3C Quality Assurance Interest Group work. Please send any public feedback on it to the publicly archived mailing list public-evangelist@w3.org or for a private feedback to karl@w3.org. The author acknowledges people who have given time for reviews and ideas.
This article has been translated in several languages.
Here you will find easy, painless techniques and ideas to improve your Web site quality and make your Web site valid. This document is intended for HTML users, developers working on Web applications, and Web masters.
Most of the Web sites on the Web are not valid. We may assume that this is the case for 99% of the Web pages, but there are no statistics to support this. It would be interesting to run a survey to prove that this case is indeed true.
Why?
I have heard many comments and rants on this topic. Most of them are often due to a lack of knowledge and understanding of what HTML validation is. The following are some examples:
Steve, CEO, said: If my Web site is made with the standards, it will be unexciting and I will lose customers.
With W3C standards, you'll be able to have very exciting Web sites. Creating a Web site which respects the standards has nothing to do with generating text-only Web pages.
The W3C is currently proposing a set of very cool integrated technologies. You can experience a full multimedia Web site with existing W3C interoperable technologies using XHTML (Structured XML markup), CSS (Style sheets), SVG (2D vector animated graphics), and SMIL (Synchronized Multimedia). These technologies have been built on a consensus by the different players of the Web market.
Alan, Technical Director, said: I don't have the finances to care about standards in my Web site. It will cost too much!
Designing with standards will simplify Web site code maintenance because you will not have multiple versions for different browsers. Your pages will have a longer life and will not be dependant upon vaporous technologies. So designing with Web standards will cost you less in fact.
Dean, Artistic Director, said: if I respect the standards, it will infringe upon my creativity.
Technical constraints exist with any artistic medium, whether you are drawing, sculpting, or designing Web pages. Watercolors or oil paintings have their own constraints, but these techniques do not to block creativity, rather they provide structure for creative expression.
Creating with Web standards will open a new world with techniques particular to the media, the technology, and the audience. There is still a lot to explore in this domain. We are only beginning to explore the benefits of standards-based multimedia experiences.
Claudia, Graphic Designer, said: I don't care about accessibility. People with disabilities are not in my target audience.
You'll benefit by designing with respect to accessibility. People with disabilities represents 8% to 10% of the total population. It's easier to maintain a Web site that follows accessibility guidelines (and therefore Web standards). Your Web site traffic will increase, and a wider variety of browsers will have access to site content.
Some countries require accessibility by law such as Australia (Disability Discrimination Act Advisory Notes Version 3.1 May 1999) or USA (Section 508 - Web-based Intranet and Internet Information and Applications) or Europe which is working on a similar plan (e-accessibility).
Aminata, Web Programmer, said: Why I should respect standards? The Web is a free place.
The Web is a free place shared by many users whose needs you don't necessarily know. The standards have been designed to keep in mind all potential audiences. There's a challenge to the Web community to create with Web standards. You will not be attached to any company or proprietary technology. You can use technologies that are independent of platforms requirements.
Karl, Web Developer, said: I have simply followed instructions in books.
Unfortunately, many books do not teach good Web programming. When you are creating a Web site, you should check the correctness of your markup. If you are a Web developer, be careful using books to develop your application and read the particular specifications which you are trying to implement.
Some Web sites are gathering good materials to help people design in accordance with W3C standards. On the W3C Web site, you will find a growing list of tutorials promoting good practices.
Some people at W3C have developed freely accessible software for your own use. We encourage you to use them when it's possible. These software packages implement W3C technologies.
Tim, Accountant, said: My Web editor generates non-valid markup.
Many authoring tools do not generate valid markup. Some have syntax checkers embedded into them, others do the right thing, and many do not generate valid markup. As an intermediate solution, you have to check your Web page with an HTML validator. At the same time, contact the software manufacturer (by mail, phone, letter) and let them know. Companies will do the right thing if you ask them to.
Valérie, Web Content Developer, said: It's not my fault. It's the way the engine for templates has been designed. (Often a system with a Web-based interface).
You're right. It's often not your fault. If it's a simple form where you never write HTML by hand, write the developer of your interface or your site maintainer until the problem is solved. If you are not sure if the produced content respects W3C standards, validate the content with the HTML validator, and submit the report to your Web master, or the person in charge of the content management system.
Ning, Software Developer, said: There is no information to help me. All of the materials I have found are in English.
Some people have translated documents and specifications to other languages. The W3C maintains a list of translations.
HTML has evolved during its development, and is available as several versions. All of these versions are standards, and you can select one that suits your needs. Most of the time, the latest version will be the best choice, unless you target a very specific audience, or older, broken browsers. The version you choose defines the elements and attributes you can use.
For instance, in HTML 4.01, you will find the list of elements and the list of attributes you are allowed to use in your pages. You can edit your pages manually, a means usually referred to as "hand-coding" or "writing the source."
HTML 4.01 allows you to write a paragraph and an anchor identifier to this paragraph, like this:
<p id="ref">This is a paragraph</p>
Pay attention to the way you nest your elements. Some elements cannot be included in others, and some attributes belong only to certain elements.
The elements that you can write in your document or implement in your software depends on the HTML version. This table contains a list of HTML definitions, or document types (DOCTYPEs), that you can use:
| Version | DTD list | DOCTYPE Declaration in documents |
|---|---|---|
| HTML 2.0 | DTD |
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> |
| HTML 3.2 | DTD |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
| HTML 4.01 | Strict, Transitional, Frameset |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> |
| XHTML 1.0 | Strict, Transitional, Frameset |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"> |
| XHTML 1.1 | DTD |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> |
You cannot validate your document if you don't use one of these DOCTYPEs at the beginning of your document. Don't forget it if you write your documents by hand.
Here, you have an example of an XHTML 1.0 Strict document template.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>An XHTML 1.0 Strict standard template</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
</head>
<body>
... Your HTML content here ...
</body>
</html>
An XHTML Strict template is very simple to achieve. Document modification and validation is easy and straightforward.
An HTML validator simply checks the correctness of your document against the declared DOCTYPE.
If you want to verify the validity of your final document when it's displayed by the user-agent (for example, a Web browser), you can use the W3C HTML validator. The HTML validator will return a list of errors according to the chosen HTML DOCTYPE. If your document has no errors, it will return a No errors found!
message.
If you edit your Web site with the help of forms (and you don't write HTML tags in your form), you can report the errors to the Webmaster of your site and requests that the HTML markup generator be fixed.
If you create your Web site by hand or directly compose the markup code, and the validator returns errors for your page, simply fix your markup. The HTML validator gives you the line number where the error is.
The HTML validator provides the line number where the error occurs, so it should help you locate the problem in your document. It checks the file line by line, starting from the first line. This means an error which is at the beginning of your document might result in more errors further along your page. A good way to work through the errors is to correct the first displayed error, and then revalidate your page. Often you will find that fixing a problem early in the document resolves a few errors at a time. Continue doing this until all errors are fixed, and the resulting document will be valid
If you are using an HTML authoring tool and your pages are not valid after editing, please report to the software developer or company. You should be able to contact the company's technical support people.
If you are a developer of a template engine, authoring tool, or content management system, use the HTML validator to fix problems in your implementation. You can also incorporate the HTML validator in your software or back-end. The source code of the HTML validator is freely available. The validator is being enhanced every day and you can participate to its development.
Note: Some documents are valid with regards to the DTD and still incorrect with regards to the HTML specification. In the near future, we will present a list of possible errors not detected by the HTML validator.
List of HTML validators
Another important issue with many Web sites is URI persistence. When you add links to other Web sites in your documents, you are expecting that those links will remain stable and persistent. It means that the information you want to point out will still be here when someone reading your Web site clicks on one of the links, you gave. You want also verify and guarantee that the links you have given to other Web pages or to other sections of your Web site are also without any mistakes. A tool has been developed for this purpose: W3C Link Checker.
Checklink generates a report of links. The report length depends upon on the time it takes to fetch and verify all the links contained in your page. To verify the link, the program handles an HEAD HTTP request of the document. If the server is misconfigured, you can have a wrong report even if the link is good, but just because the server is not able to give the HEAD. In this case, you should write to the Web master of the Web site to ask him to fix the server configuration.
Checking link http://webstandards.org/ HEAD http://webstandards.org/ fetched in 0.1s
Above is an example of the list. It gives the taken time to fetch the link.
After the list of links, you'll have a report of the links which are broken or redirected, which will help you fix incorrect links.
If you want to have more information about the importance of links, we invite you to read the document Cool URIs don't change
written by Tim Berners-Lee.
If you, as a Web master, wish to install a program on your Web site to help people to check their Web pages, the source code of the W3C Link Checker is freely available.
Since 1996, Cascading Style Sheets (CSS) have provided a way of separating the structure from the style in a elegant and effective manner. In the last year (2001), many user agents (browsers) have implemented support for CSS 1 and CSS 2. Using style sheets helps you maintain all the information about the style of your documents in a single place.
At the date of writing this article, you can choose between CSS 1 and CSS 2 to put style in your documents.
Designing with style sheets has many benefits, like reducing the design cost of your Web site and increasing its interoperability (readability of your Web site on many different user agents). Designing your Web site for multiple versions of user agents with tables and JavaScript increases the cost of initial building by 30%.
Do not use the FONT element with the FACE attribute. It's considered harmful from an internationalization standpoint. If you want to learn how to get rid of your font element and adopt style sheets, we encourage you to read the tutorial by Todd Fahrner Beyond the FONT tag:
Practical HTML text styling
As with the W3C HTML Validation Service and W3C CSS Validation Service, you'll can check the validity of your style sheet. You can check the validity of external style sheets called by your document. If you wish to install your own flavor on your Web site, the source code of the CSS validator is freely available.
Making a Web site is not enough. Most of the time you don't know the audience. People accessing your Web site have different materials, browsers and/or specific disabilities. There are a lot of business benefits to doing accessible Web design. Unfortunately, it's less straightforward to validate your documents for accessibility. Some tools, like Bobby, can help you, but they are not the final answer to your accessibility concerns. You will need to do a human-checking of your content. The Web Accessibility Initiative is maintaining a list of resources that will help you design accessible Web sites.
Often people are discouraged to make Web sites valid because of the number of invalid pages they have or because they don't know where to start. It's quite simple, be SMART: Small, Meticulous, Accessible, Regular, Template. Taking small steps will help you to have a valid Web site without pain and discouragement. So, think progressively and find solutions that will make your work easier, like using a template engine.
Here are a list of tools that will help you have a better Web site.
Tidy was initially developed by Dave Raggett. It will help you make a Web page valid. Sometimes Tidy is unable to fix all the errors. Tidy is not an editing tool—it will only help you solve things.
It's very difficult sometimes to know which pages of your Web sites are invalid. If you run a script that will crawl all your pages, you will have a huge list of invalid pages.
So what's the solution?
At W3C, Gerald Oskoboiny has developed a QA progressive tool for Web sites that doesn't overload the Web master of a site. It sends a report of the top ten of most accessed invalid documents, providing notification so they can be corrected. Each week, the Web master will receive a new report listing 10 more invalid documents. This tool has been released to the public. You can adapt it for your own needs.
Olivier Théreaux, W3C, has developed a more portable and pluggable version of this tool: LogValidator
This tool takes a Web server's last logs and processes it through validation modules. Those validation modules check the most popular documents' validity for a certain technology. The default module is HTML validation, but there will be others available.
So you'll be able to fix the spelling of your Web pages, if you have included metadata, if the links are still valid, etc. An API documentation will help you to create new modules depending on your needs.
Thanks to people who have reviewed this article: Ian Jacobs, Susan Lesch, Olivier Théreaux, Stephanie Troeth, Jeffrey Zeldman and people on the public-evangelist mailing-list.
This article would have not been possible without the participation of Kim Nylander, Technical writer, who has reviewed and helped.
