Efficient Web Accessibility Testing — Tingtun eGovMon

Version

Versions tested: PageCheck 2.0

Mode of operation

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.

Error reporting

Testing results are presented on the same page as the form control of the service. All content is accessible with JavaScript off (which is not the case for their FAQ, due to fly-outs obscuring text), divided into logical sections, which are folded by default if JavaScript is on. It is clear that a lot of thought went into the results presentation, and it is very easy to ascertain what the problem is, where it occurs, and what the justification for the eventual fail was, even though source code of the validated page is not displayed in relevant fragments with inline injection of marks. Only the offending tag and the immediate surroundings are provided, so having the source of the given document open in an editor is still necessary.

Scope

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.

CSS and SVG

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.

Inline SVG

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.

XHTML and self-closing tags

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.

Mixed XML: XHTML (+ SVG (+ MathML))

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.

Server headers — language

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 Firefox/Pentadactyl:

server response, Norwegian version server response, English version
Server responses in a graphical browser

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.

Using the 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 Content-Script-Type and Content-Style-Type.

Server headers — links

Stylesheets can be added to documents via link elements, 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.

Server headers — site navigation links

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.

Multiple caption elements

eGovMon does not flag multiple caption elements as erroneous:

<table>
<caption>sufficient description here</caption>
<caption>invalid caption element</caption>

Summary

The major issues with eGovMon are:

The benefits of using eGovMon are: