WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: HTML Validator Software?

for

From: Terence de Giere
Date: Nov 3, 2003 7:16AM

The Windows-based 'A Real Validator' (http://www.arealvalidator.com/)
duplicates most of the features of the its online counterpart (at
http://www.htmlhelp.com/ a validator based on the same code base as the
W3C validator) and is a real SGML parser, and can run batches of files,
but it cannot check online files. DTD's can be added to extend its
capabilities. This is a very basic program, without much in the way of
extras, easy to use. On-drive alternatives could be the use of an SGML
or XML editor to create web pages -- these are rather expensive tools,
but they force you to write valid HTML, because that is what they were
designed to do. A downside for graphical design is CSS and visual
presentation of HTML needs to be checked in the browsers, as
What-You-See-Is-What-You-Get tends not to be a feature fully implemented
in the internal display of pages in these editors. That is not
necessarily a fatal drawback because even sophisticated graphical
editors have trouble correctly rendering complicated CSS embedded with
the STYLE element or linked CSS files. SGML type editors also provide a
good environment for learning HTML in a way useful for dealing with the
problems of accessibility, because the document structure properties of
a page are always evident.

Karl Groves hit the nail on the head with his comments about valid HTML
being a quality control issue. It is much more difficult to
trouble-shoot pages when the HTML is undefined, and validation provides
the equivalent of error checking that a compiler provides for
programming languages. I have always found that valid HTML creates far
less presentation problems if one tests a page in a wide variety of
browsers. Although most browsers do not follow web standards fully, they
all have core rendering based on basic HTML rules, so those established
rules are the safest bet on getting a good page cross-browser page
('cross browser' here means _all_ browsers not just Internet Explorer
and Netscape). Then if a particular browser has some peculiar problem,
one has a better shot at finding a successful work-around that does not
interfere with accessibility or valid HTML and does not create problems
for the other browsers.

The CSE Validator, and some similar ones that come with HTML editing
applications like HomeSite are useful for certain things in a production
environment, but they are not, as mentioned, SGML parsers, and do not
correctly evaluate whether the HTML is valid according to the SGML
standard, from which HTML is derived. The CSE validator (and similar
tools) may produce better quality invalid HTML, in that it will help the
developer to correct invalidly quoted attributes and certain improper
nestings etc, and make useful suggestions, but not valid HTML according
to the SGML or XML standard except as a matter of chance. Because it is
fast and so forth, I know some production people like CSE a lot, but for
accessibility it lacks correct compliance with guidelines that require
valid HTML. In other words, in a production environment, a CSE
'validator' can act as a quality control test for a non-standard HTML
environment, but a non-standard HTML environment is not what we are
looking for with accessibility because we are trying to maximize the
success of the page rendering across as many browsers and user
situations as possible, rather than customize the visual rendering for
just a few graphical browsers.

The process of SGML validation has been established for 17 years as an
international standard, longer than the World Wide Web has been around,
and is the basis for correctness for all SGML and XML document types. I
don't know why programmers have such resistance to writing quality HTML.
It is as if hand written HTML, however sloppy, is a mark of excellence
because one can do it. But one can just as easily hand code HTML and
check it with a real SGML parser and this provides a real test of one's
knowledge of HTML as it was originally conceived. The HTML error
correction in the major browsers has made it too easy to write sloppy
HTML. The situation of browser error correction, and hard-wired coding
of HTML in graphical we page editors has disassociated HTML from its
intended validation processing model. While a page certainly has to
display correctly in these graphical browsers, we can't really
independently test HTML quality in these browsers because we don't know
exactly how they are rewriting the code for display, and in my
experience, correction routines are not identical across the browsers.

Another point of resistance is the development environment, some tools
make it difficult if not impossible to produce valid HTML. This is
something that also needs to be addressed -- unless highly motivated,
users of editing and development software won't want to jump through
hoops to get good code if it requires a substantial effort to work
around obstacles in the software for valid HTML. Macromedia Dreamweaver
can produce valid HTML, but it will also insert a lot of non-standard
HTML when using its menus etc., and it is designed in fact to open and
display just about any kind of HTML page, rather than restrict the code
to a specific DTD, such as HTML 4.01. And while Dreamweaver inserts
doctype declarations, it is really not paying any attention to them. As
a tool, this flexibility is a blessing and a curse. One can open a bad
HTML page and can work on it, where an SGML editor might choke, but for
valid HTML, the user of Dreamweaver has to know how to produce valid
HTML, since the editor cannot inform the user he or she is making a
mistake.

When attempting, in an organization, to enforce a policy that tends to
be outside designers' and developers' experience, such as usability,
accessibility, and valid HTML, it is best to have support from the top
management - if they do not buy into it, it may never be possible to
enforce it. Some sort of approval process is needed before a page goes
online, and accessibility checks, validity checks and so on can be made
a part of that process. With an outside contractor, it should be made a
contractual condition for payment.

Terence de Giere
<EMAIL REMOVED>



----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/