Ministry of Agriculture & Lands
WEB STANDARDS
HTML VALIDATION
Version 1.2
This page outlines the process for validating HTML code, for delivering validated code to the Ministry and also defines the process for the testing and delivery of HTML code based products.
1. INTRODUCTION
1.1 Audience
1.2 Purpose
1.3 Assumptions
2.1 Mandatory Validation
2.2 Optional Validation
2.3 Visual Validation
4. CONCLUSION
APPENDIX A - Common W3C Errors
This section of the document records the various versions or releases of this document.
Version |
Details/Description |
Distribution |
Date |
Author |
Org. |
0.1 |
First Draft |
Whole Document |
09-Aug-00 |
Diana Von Ratenberg |
ISB |
1.0 |
Final of first draft | Whole Document | 18-Aug-00 | Diana Von Ratenberg | ISB |
1.1 |
Editorial changes after web transition to WLAP/SRM |
Whole Document |
04-Mar-02 |
Keith Langley |
IMB |
1.2 |
Editorial changes after implementation of Chief Information Office web standards |
Whole Document |
Oct 15, 2003 |
Joe Carr |
IMB |
This Standard outlines the process for validating HTML code and for delivering validated code to the Ministry. These standards are mandatory for all HTML and also describe some tools which can be used and checks which can be made to further ensure the quality of the code.
This document is directed at anyone who produces HTML code for the Ministry, including contractors as well as Ministry staff. It is also relevant to anyone managing or directing projects involving the delivery of HTML code to the Ministry.
This document describes the standards for validating HTML code prior to its delivery to the Ministry. Its purpose is to provide contractors and Ministry staff with information on standard tools which are to be used for validating HTML and the resulting deliverables from the validation process. It also provides a description of the test and delivery process of HTML code.
1.3 Assumptions
For the purposes of this standard the term 'author' will be used to identify the individual(s) writing the HTML code. Except where otherwise specified, it is assumed that this individual may be either a Ministry employee or a contractor.
HTML code delivered to the Ministry must conform to certain standards. This is necessary to ensure there is some level of consistency in Ministry pages as a whole and to provide a certain level of confidence that a variety of browsers will be able to read and interpret the HTML code. It is also necessary to ensure that other agents, such as Wireless Application Protocol (WAP), can be used to read Ministry pages.
While the standards provided here are a Ministry requirement, it should be pointed out that there may be a 'cost' associated with following these standards. The cost is related to the time and effort required by the author to validate pages and to fix any errors generated. The benefit is a potential reduced cost in page maintenance. It is up to each Web Administrator, within the branch and region to define the level of compliance required. This level of compliance may vary within a branch (i.e. a 'transitory' page may not require the same rigorous compliance as a page which has a long life and will continue to be updated and used).
All contractors delivering HTML to the Ministry must follow these standards, unless otherwise instructed, in writing, by their Ministry Contract Administrator.
The following sections describe the mandatory and suggested requirements for validating HTML code prior to publishing in a production environment at the Ministry.
W3C Validator
The Chief Infomation Office (CIO) is the designated agency established to manage the government's Internet web presence. The CIO has mandated that the W3C Validation program be run against all HTML code within Government prior to publication. The Ministry will comply with this requirement by mandating that all HTML code being published to either an Internet or Intranet production server be run through the W3C validator and that all errors be resolved. The version of HTML that must be validated against will be as specified in the User Experience and Internet Standards.
Note : Some previous versions of the standard web templates used by the Ministry were, at one point, not compliant with the W3C validator. Therefore putting any pages through this validator, which were developed using the templates prior to an approximate timeframe of April 2000 will not pass the W3C validation. There is no intention to revisit these pages in order to bring them up to current standard unless a website redevelopment project includes out-of-date web pages.
Link Checks
All links must be checked and validated before delivery to the production server. Authors may use any tool of their choice for this purpose, including manual validation (i.e. testing by clicking on all links). The suggested tool to check for valid links is the W3C Link Checker.
There are a number of other tools and methods available, whose use, although not mandatory, could assist authors in their development efforts:
Bobby Compliance
BCIS is also in the process of deciding whether or not all code must be compliant with Bobby, a web based tool which analyzes pages for their accessibility to people with disabilities. Until such time as this decision is made, Bobby compliance will not be mandatory for the Ministry, although it may become part of the standard should BCIS deem this necessary in the future.
HTML Kit
HTML Kit-tidy is a lint checking kit. It's benefit is that not only does it locate the errors in the code but it also resolves them for the author. It does not locate all errors reported by the W3C Validator, but is a good cleanup program to use before putting code through the validator as it catches 80-90% of the errors and fixes them, making subsequent use of the W3C Validator easier.
Spell Check
The Ministry does not mandate the use of spellcheckers by authors since in most cases content will be the responsibility of content owners. As well, there are certain constraints on spell checking (i.e. use of technical jargon, English vs. US Dictionary) which make the standardization of spell checking difficult. It is recommended, however, that a spell checker be used by content owners during some level of the development.
Image Size
Although some validator programs check and provide information on image size, the Ministry does not mandate use of these.
Load Time
Although some validator programs check and provide information on page load time, the Ministry does not mandate use of these. However, load time requirements should be defined by the client and in the case of outside consultants, contracts should include information on load time requirement.
In addition to performing the validations and checks described above, the author must visually review every page or form and check for proper layout, consistency and adherence to Ministry Standards for web development. Visual checks must be performed using the Ministry standard browser as well as any other market leading browsers for pages intended for the public (i.e. Internet)
When performing a visual check the author must turn off the graphics and view the pages as text only. The pages must be checked for the existence of alternate text and also to ensure that the content is not dependent on the graphics for comprehension.
The validation tests above must be performed at the author's site, in their development environment. This includes the visual validation. When the author is ready for delivery, he/she must feel confident that the code will run on the platform(s) defined, by the Ministry, as the target platform(s).
Figure 1. illustrates the Test and Delivery cycle for web pages and applications. This is only a high level view of the test cycle and should be used in conjunction with other relevant test standards if the delivery involves a data application.
The steps in the Test and Delivery Process (as related to Figure 1.) are described below. These steps are the same whether the author is a Ministry employee or a contractor. The steps identified as being "Ministry" responsibility will be performed by the party accepting delivery of the code. This could be the IMB in some cases (i.e. delivery of a web application) or the Program/Region responsible for acceptance.
-
Author validates the code on the Development Environment using the programs described earlier in this document, including visual validation
-
Author performs a visual check on the Development Environment as described above
-
Author delivers code to a Test Environment at the Ministry. The Test Environment will match the Production Environment
-
Author performs random visual checks in the Test environment to ensure the move to a new environment has not impacted the code
-
The Ministry performs random validation checks using the standard programs described above in the Test Environment
-
The Ministry performs a random visual QA check in the Test Environment
-
A description of any errors found are sent back to the author
-
Upon Ministry acceptance the code is moved to the Production Environment and a random visual QA is also completed there by the Ministry
This document is to be used by all HTML authors (vendors or Ministry staff) to ensure HTML code delivered to the Ministry and running in a production environment is consistent and compliant with the BCIS HTML standards. It describes the mandatory validation tests and it also recommends some other useful tools for authors to consider. And, finally, a high level test and delivery process is outlined so that authors understand the steps for successful delivery of HTML pages and/or applications.
Appendix A - Common W3C Errors
The following are some common errors which may be encountered when running HTML code through the W3C Validator, and some guidelines on how to resolve these. In particular some of these errors may be encountered from the validation of a page which used an older version of the BCIS template.
Error
message |
Explanation |
Line 34, column 81: ... align="RIGHT" valign="TOP" width="7" bordercolor="#339966"> ^ Error: there is no attribute "BORDERCOLOR" |
Bordercolor is a propritary tag and is not read by all browsers. Same with BORDERCOLOR, BORDERWIDTH, BORDERHEIGHT, TOPMARGIN. See http://www.idocs.com/tags/tables/_TR_BORDERCOLOR.html |
Line 116, column 93: ... ellspacing="0" cellpadding="0" width="149" height="193"> ^ Error: there is no attribute "HEIGHT" |
TABLE does not have a height attribute in HTML 4.01, see http://www.w3.org/TR/html401/struct/tables.html#h-11.2.1 |
Line 51, column 91: ... CCCC"> ^ Error: required attribute "ALT" not specified |
Supply aternative text information for the image, eg: ......alt="Groundwater Logo"> |
| Line
11, column 15: TABLE BGCOLOR="#FFFFFF" WIDTH="100%">
Error: there is no attribute "BGCOLOR" |
This page was written in HTML 3.2. HTML 4.01 allows it but it is a deprecated (will eventually be discarded in favour of Cascading Style Sheets) attribute. |
Line 1, column 1: ^ Error: Missing DOCTYPE declaration at start of document (explanation...) |
The ministry is using the following HTML 4.01 transitional DOCTYPE shown at: |
Line 12, column 12: ^ meta name="Microsoft Theme" content="gdbc 011, default"> Error: value of attribute "NAME" must be a single token |
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). No spaces allowed. |
Line 41, column 11: coords=11,0,105,11 href="http://www.elp.gov.bc.ca/" ^ Error: an attribute value must be a literal unless it contains only name characters |
Quotes are required for attributes. |
Line 77, column 29: script language="JavaScript"> Error: required attribute "TYPE" not specified |
Requires the following: <script language="JavaScript" type="text/javascript"> |
Line 77, column 11: --mstheme--><font face="Trebuchet MS, Arial, Helvetica" ... Error: document type does not allow element "H5" here; missing one of "APPLET", "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag |
Other
errors that are in the same category (instead of H5) include P,Table,
Address, Div and all the other block elements. The error is probably
due to having FONT tags overlapping these. eg:<font face="arial"><p>Example </p>Example</font> |
Line 801, column 7: Error: start tag for "LI" omitted, but its declaration does not permit this |
A
nested list must be within an LI and not having the following: <ul> <ul> |
Line 857, column 46: ... ttp://www.env.gov.bc.ca/main/stock">http://www.env. ... ^ Error: document type does not allow element "A" here |
In this case, the LI tag was not closed |
