Introduction· Decide· Analyze· Organize· Improve· Review· Maintain·
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 private feedback to Karl Dubost karl@w3.org.
The author acknowledges people who have given time for reviews and ideas.
Translation of this document is welcome. However, before starting a translation of this document, please be sure to read the information on translations, in our Copyright FAQ, and check the list of existing translations of this document (available at http://www.w3.org/QA/translations#switch).
Whether you are a manager, a Web developer, a Marketing or Communications team member, or perhaps an individual Web master, you have read about the interest in Web standards from many sources. You have understood that standards are beneficial for your Web site in terms of cost savings, ease of management and profitability, and so you have decided to switch - and employ standards within your Web site.
Unfortunately, you haven't found a guide which explains the processes of where to begin and how to organise this transition of your Web site to being standards-compliant. You might think that having a large Web site makes this objective unattainable. If you are unsure about what Web standards are, we encourage you to read about what Web standards really mean [WEB-QUALITY], how to purchase and develop a quality Web site [REQ-WEBAGENCY], and why an accessible Web site [WAI-PROFIT] is profitable.
The method that we propose in this document is valid for Web sites of any size; it will suit your needs whether you are managing an individual, small business or a large corporate Web site.
We will guide you through the individual steps - all of which you will be able to fulfill individually - from the analysis of your existing Web site to the organization of your new Web site. Each of these steps have been designed to be separate, and can be undertaken at various times, different levels, by different persons regardless of their skill level, but in accordance to a workflow.
Large or small, your Website has to be initially evaluated against the standards; there is probably a sizable number of pages which do not meet the criteria you have established for the quality of your Web site.
Get your communication, technical, marketing and management teams together to create a list of all the things you would like to evaluate on your Web site. At this stage, there is no need to prioritize what you would like to fix, but we encourage you to at least check the validity (HTML and CSS), the accessibility and the internationalization of your website. You will find some explanations for techniques later on in this article.
This article outlines a method to improve your Web site in accordance to W3C standards, but you may also use this strategy for other requirements by which your Web site should comply. We propose a non-exhaustive list here:
Sometimes, you or your team may not have the skills nor the understanding about the issues involving your Website; if this is the case — ask for help. Invite a person who is a specialist in accessibility or internationalization to take part in your team. For example, with regards to accessibility (how well people with disabilities can access your Website), you can ask a local association to help you, such as the Association for the Blind — in most cases, they will be more than happy to assist you. If you are part of a large organization, it might be very likely that you have people with disabilities in your company. Ask your human resources department and suggest their participation in this project.
Now that you know what you want to test, you have to determine what the current problems are on your Web site. A good way to do this is to create a full list of URIs that belong to your site first. To do so is not a complicated process — a simple spider which follows page links, and add them to a plain text file (e.g. a URI on one line) is sufficient.
It might be that the technologies used on your Website are not accessible by a spider's engine; this itself might be a way to identify the number of your Web pages which are inaccessible. Basically, this exercise will show you which pages are not able to be indexed by search engines. meaning that you are effectively blocking out traffic coming to your site.
Once you have made the list, you can use it with the LogValidator [LOG-VALIDATOR], which is a program designed specifically to aid your testing process. The LogValidator takes a list of URIs and analyzes them according to the module you have chosen to load when you begin your testing. (It will be part of the job of your technical team, discuss with them how to implement it for your own site configuration.) For each URI, it will apply a series of tests and will give you the corresponding result.
After this first analysis, you will have a map of your Website's health, and you will be able to adopt a strategy for organizing the necessary work and fix the pages which have faults. You may have a huge number of pages which don't comply to your criteria. For example, all your Web pages might be HTML or XHTML invalid. But don't worry — this is in fact great news! Why? Because if you are using a templating engine or a content management system to generate your Website, it means that you certainly have mistakes in your templates.
The solution is simple; just fix your template and run the whole test again; you might have less errors, perhaps even none at all. If you are not the developer of the templating engine, ask the person or persons who have created the CMS for your Web site to fix it accordingly. In the future, when the time comes to re-design your Web site, follow the recommendations in the document Buy standards compliant Web sites [REQ-WEBAGENCY].
If you still have errors in your Web pages after this first pass, don't worry — this guide is here to help you fix them.
An additional benefit of this first step is that it gives you a concrete idea of all the Web pages within your site, which means that if you want to move a page, or delete a section of your Website, you will have a better idea of how to redirect your visitors to the new pages and hence not lose traffic coming from external links (such as those from other Web sites and search engines). Remember, cool URIs don't break.
You now have a list of all the Web pages which do not validate, or have other problems or mistakes. It doesn't matter whether this list is long or short, it will not change the method that is explained here. The first principle is simple: "Don't fix! Improve - organize your work"
It's not at all necessary to fix all your Web site in one shot, for two main reasons:
Additionally, don't try to fix one particular category of problems on its own, whilst leaving the other problems until this has been finished. For example, you want to make your html pages valid, and also make them accessible — do both of these at the same time. If you do them one after another, within a later fix cycle, you may introduce problems and adversely affect the good outcomes of an earlier one.
Therefore: do not fix in one shot, do not fix problems by cycles — improve your process.
The key to success of this method is to remain realistic when it comes to making choices, and ensure that these choices will yield effective results. If you would like to improve your Web pages, you have to determine how much time it takes per page to solve all the problems which have been identified. Try with a current sample of Web pages which has common problems on your Web site, and consider the appropriately skilled people and resources within the workflow of your Web site.
Once you have determined the amount of time needed for a few pages, you will be able to more accurately decide how much resources and persons to allocate to this task, as well as how many pages you can realistically fix each day.
We encourage you to fix on a daily basis more so than a weekly/monthly basis. It will be easier for a person responsible for this task to schedule the time for this process, and it will take less time per day than per week. It is easier and less of a burden to fix 5 pages a day than 25 pages one day in a week.
Have regular meetings with the team who is in charge of undertaking these tasks; collect their opinions, arguments and their experiences. This will help you to determine if recurring problems come from the CMS, or the process used to edit your Web pages. You will be able to improve your process and the quality of the tools you use at the same time.
After some time, and with the experience gained from the implementation of this method, you will be able to set milestones. For example, 50% of the traffic coming to your Web site reach pages which comply with the quality criteria you have decided. When this goal has been fulfilled, you can leverage it to 60% and so on. Whatever you decide to test or to achieve, keep it reasonable and small; this method is about making continual, but achievable progress and improvement.
To be a truly successful project, you have to integrate everyone who is part of the publishing process into this task. Understanding the tools, the methods which are currently being used will help you establish where the problems are arising — is it a problem with the tool, or is it a problem with the person using the tool? When an authoring tool is introducing mistakes into your pages, it will help to collect comments, and to negotiate with the creators of the tools so that they will improve their software. This is particularly true in the context of a large company where you have a lot of users; this is a smarter way to ensure that improvements can be made.
Publish the improvements — at least within the team, if not publicly. It will show your progress and encourage everyone to continue. If you have identified the problems which exist in your publishing system, you can only improve from here.
The LogValidator [LOG-VALIDATOR], which has already been cited in this article will help you to improve your site by identifying the parts of your Web site which are faulty. In its default mode, this tool has been designed to check progressively the HTML validity of documents. Its basic principle is quite straightforward: from a Web server log file, it compiles the results to order the most accessed pages daily, and takes the first n pages of this resultant sort (where n is a number you specify), and send them to the W3C Markup Validator. After which, it will send you back the results of this validation.
What are the benefits? This way, you fix the most accessed pages first and you evaluate the quality of your Web site in this regard — not in terms of the absolute number of pages.
The LogValidator has an open and modular architecture written in Perl, and you can develop the modules you want to add for your own purposes. For example, you can develop a spell checker, or a module which checks if the logo and the footer information is correct within your pages, or perhaps you could have a module which checks for broken links within your site. It is also a tool which is easy to install and is part of the CPAN archive.
The number of possibilities is endless, so it is best to remain realistic in terms of your goals.
Having adopted the use of the LogValidator, there are different ways to proceed and analyze the results returned by the LogValidator. For example, you could set up an internal mailing-list where your new Web site quality assurance team receive a list of URIs which need attention every morning, and your team will have to either amend the content, or report if the source of the problem is elsewhere.
This step by step method helps you to maintain the quality of your Web site, but you still have to verify on a regular basis if problems are still recurring.
Once in a while (every 3 months, for example), re-run the full analysis, and it will help you to know if you have made progress on the overall quality of your Website, and also determine what the problems related to your templating engines are. It will also help you to meet your objectives that you have established in the beginning. If the quality of your website is not increasing, you have something to fix within your process.
Lastly, it will reward the work of your team, the people involved in this effort, by showing them the progress you have made. Little by little, you will gain experience that will be beneficial to your organization. At the same time that you conduct this review, compile a list of everything that has been done and publish it. This will become the updated manual on the quality of your Web site.
Often, you have a style guide within your company which defines the policy for the company's colors, and its logo. Add to this guide the simple techniques that will help people to improve the Web site when an error is detected.
The method described in this guide is dynamic and not sealed in concrete; it has to evolve with your needs. If your publishing process have requirements which are no longer relevant, or new requirements have been added, it will be necessary to adjust your publishing process, and therefore your quality assurance process.
The solution for evaluating and improving quality that we have proposed here is divided into components which do not affect one another, therefore you can remove the components you no longer need, and add new components where necessary.
You might have the case where a problem doesn't have a practical immediate solution because it is impossible to remedy it by yourself. For example, you maybe be using a publishing tool, an authoring tool which does not produce valid code. You have tried many methods, you have tried workaround, but nothing worked. It is absolutely necessary to collect this information and to send it to the company which has made the product, not as an individual, but with the signature of your company. You represent a segment of the market, and so the authoring tool company will listen to you.
To maintain the quality of your site, you will have to reward good internal authors and to help the ones who have more difficulties. There will be no success if your users do not see the benefits of the method you have chosen. Invite them, encourage them to report any problems with the process, with the tools, etc. it will improve the whole organization.
This method is simple and has been applied for years inside W3C only for the HTML part, it has helped us to maintain the validity of all Web pages. This method can be very powerful if you use it inside your own company or Team.
Thanks to people who have reviewed this article: Olivier Théreaux, Stephanie Troeth, Denis Boudreau and people on the public-evangelist mailing-list.