Versions tested: PageCheck 2.0
eGovMon is available exclusively as a web service, in two modes:
The latter mode is available only on request, through email, and as such is not appropriate for commercial purposes, or indeed any projects apart from a site with cat pictures:
This check is resource intensive and may take several hours. Enter your email address, and we will let you know when the results are available.
In the past, an option to validate sites three levels deep was available, but has since disappeared. The single-page mode is very fast, and therefore it is reasonable to assume that the above justification regarding resource utilization is just an excuse to prevent the tool from being used for large projects. That stands in contrast to the alleged motivation for this project, i.e. compliance with the Anti-Discrimination and Accessibility Act (Diskriminerings- og tilgjengelighetsloven (LOV-2008-06-20-42 § 11).
The service uses a web crawler to fetch the document for processing: Python-urllib/3.3. There is no way to override this, and due to the fact that such bots are universally banned by system administrators due to widespread abuse, this bot might have to be temporarily white-listed before any checks are performed.
eGovMon is a promising project, or would have been if its scope was not severely limited. First, it is first and foremost an HTML validator, while references to WCAG are presented only as a rationale background. A well-formed and valid document is unlikely to be flagged by eGovMon as inaccessible, unless it contains form controls, for which some minimal checks are performed (labels, legends, etc). The following are the tests used by eGovMon:
They are grouped in the following criteria:
Little has been implemented thus far, but what has is very decent — i.e. there are very few false positives apart from server headers, of which more in the following sections. For a full-featured validator which is strictly in sync with the rolling HTML5 specification, we point to the Living Validator maintained by the specification community.
eGovMon does not parse standalone stylesheets (CSS) or vector graphics (SVG) at all:
The document is not a web page.
Inline styles are ignored, while there are problems with parsing of inline SVG, of which in the next section.
eGovMon does not really have a concept of SVG, as
mentioned above. Within HTML5, SVG can be
freely mixed within HTML documents, inline, and not as an
external resource, referenced for example by an
img or an
object element. This is a major problem, on several levels,
particularly in light of the fact that HTML parsers for
SVG are under development in modern browsers. In other
words, vector graphics will no longer be parsed as XML,
unless the parent document of an inline is served as
application/xhtml+xml, or the object is external, also
served as XML:
image/svg+xml. Since new
parsers are under development, that may change yet, and fast.
<div>this is <svg width="500" height="600"> <rect x="0" y="0" width="500" height="600"/> <text x="10" y="10">sample text</text> </svg> </div>
Still, even now islands of XML may be freely used, namespace-free, within HTML documents, even though permissive parsing has not yet been implemented, and self-closing elements must be properly closed, as in XML, eGovMon will complain about self-closing tags in documents with SVG islands served both as HTML and as XHTML:
There is an error in the tag structure. Opening and closing tags that are not used according to specification.
A similar error as above is thrown for self-closing script tags in
XHTML documents served as
application/xhtml+xml — an
example of the Apache server configuration:
AddType 'application/xhtml+xml; charset=utf-8' .html
The above results in the following cryptic error message issued by eGovMon:
Unexpected EOF (when parsing in state "in text"), expected </script>. Code extract: value not set.
For documents sent as an application, a doctype is spurious, and is best omitted. This is especially true in this case:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN" "http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd">
eGovMon will complain about a missing doctype.
This false positive, in conjunction with the failure to process server headers (see next section) and most online documents elaborated on in the previous section severely limits the software's usefulness with respect to XHTML 1.x and 5.x documents, even moderately complex XHTML/XML and SVG mixed documents, as well as MathML documents. While these documents are not nearly as ubiquitous as they were a decade ago due to the rise of the HTML5 specification, XML is still used widely enough to make this a big issue.
The most prodigious source of false positives in eGovMon is due to its failure to check and process server headers, which are the most efficient way to declare encoding, language, content type, navigation structure of auxiliary documents, and even stylesheets. An example of the Apache server configuration to achieve this is:
AddLanguage no .html
This can be overridden anywhere down in the URL hierarchy,
or from the top configuration file, for example through the
<Files> directive. Server headers are trivially
checked from within the graphical browser — examples from
The same information can be trivially obtained from the command line, using a text browser:
% lynx -head -dump //unicus.no/ | grep Language Content-Language: no % lynx -head -dump //unicus.no/en/ | grep Language Content-Language: en
eGovMon does not check and process server headers, and thus will complain that the language is not set for the document, with the following error:
No main language specified for the page. The language attributes are missing on the html element.
lang attribute is the only way to avoid the
false positive (note that
xml:lang should not be used in
HTML pages, and eGovMon cannot parse documents delivered as
XML — see the previous section). This attribute makes sense
for standalone documents (such as testcases), and even then only for
those which are shared through other means. Recommending this attribute
is poor advice even for small servers, let alone huge sites with
thousands of pages. Documents servers with a valid server header should
never fail validation.
Failure to check and parse server headers is a critical flaw in automated accessibility checkers:
eGovMon does not check, parse, or process server headers, but at
least it doesn't issue bogus content type error warnings for other
server headers, such as
Stylesheets can be added to documents via
but links need not reside within the documents themselves — they can be
set on the server. An example of the Apache server configuration:
<Files ~ "index\.(html)$"> Header add Link '</css/define.css>; rel="stylesheet"' </Files>
This directive injects a stylesheet link to all documents with the html extension. It may be used as a global stylesheet for the entire site, as a base stylesheet to be overridden by document-specific stylesheets, or as a way to neatly define CSS Variables, on its own a useful accessibility feature of cascading stylesheets. It is unfortunately not mentioned in the WCAG 2.0 standard, which it post-dates.
eGovMon is be unaware of such links. Non-sensical or otherwise erroneous headers sent by misconfigured server will also not be caught. The same applies to color contrast errors which may be present in such stylesheets.
Other link types can also be specified on the server, such as the site map, copyright notice, newsfeed, and many more:
<Files ~ "index\.(html)$"> Header add Link '</index/>; rel=index' Header add Link '</legal/>; rel=copyright' Header add Link '</atom.xml>; rel=alternate; type=application/atom+xml; title="site updates newsfeed"' </Files>
These links affect accessibility in more ways than one. Some applications populate a separate navigation bar with these links, where they may appear as text and/or icon buttons. Others may add it to the text menu. Some more advanced search engine robots process server headers and may present information extracted thus in the site overview. It is also recommended that newsfeeds are appended to the documents through such a link.
eGovMon is unaware of such links. Non-sensical or otherwise erroneous headers sent by misconfigured server will also not be caught. Documents linking to newsfeeds within the body of the document, but neither through a head link nor a server header link, will not be flagged.
eGovMon does not flag multiple
caption elements as
<table> <caption>sufficient description here</caption> <caption>invalid caption element</caption>
The major issues with eGovMon are:
The benefits of using eGovMon are: