Research e-Labs

We report on the process of achieving compliance with the New Zealand Government Web Standards for this site, including reports from the openWolf validator.

In working to achieve compliance for this site with the NZ Government Web Standards, we made extensive use of the open source validator openWolf and its New Zealand implementation at accessware.co.nz maintained by Geoff Munn. openWolf reports on the NZ Government Web Standards point by point and includes a wrapper to the W3C validator for grammatical testing.

To date, the research.elabs home page has achieved extremely good reported compliance in comparison to mainstream government sites’ home pages.

Website	Failures	Warnings	View openWolf report
research.elabs	25 (2*)	9 (3*)	openWolf on research.elabs
Department of Labour	72 (12*)	8 (4*)	openWolf on Department of Labour
Inland Revenue Dept	111 (11*)	25 (7*)	openWolf on IRD
Ministry of Education	171 (15*)	21 (8*)	openWolf on Minedu
NewZealand.govt	126 (13*)	26 (5*)	openWolf on NewZealand.govt

<sup>The table above is for comparison of openWolf reports only and does not represent an in depth analysis of the web sites mentioned.
* The number of distinct standards reported as not met</sup>

Compliance report for research.elabs

View the real-time openWolf report for research.elabs home page.

Let’s examine the openWolf compliance report for research.elabs. As above, the home page produces 25 Failures against 2 Web Standards and 9 Warnings against 3 Web Standards.

openWolf “Warnings” for research.elabs

13.1 Pages usable when scripts, applets and other programmatic objects turned off (1)
13.2 Alternative event handlers and device dependence (4)
15.2 Unique interfacing and device-independence (4)

These points are all related - this is how openWolf flags javascript files, which are not possible to test for their compliance impact. OpenWolf generates such “Warnings” whenever a javascript file exists, regardless of implementation and any alternate handling including graceful degradation or progressive enhancement techniques.

My view is that “Warning” is not the most useful labeling for untestable javascript instances, as it results in a “Warnings” list that is a mix of possible issues from untestable javascripts and other “Warnings” from testable issues.

In the case of research.elabs home page, the javascripts do not cause non-compliance. In fact, the javascripts are ‘inert’ - not active in any way (they are lying in wait until we implement a demonstration of a progressive enhancement technique - which will still be compliant). So for research.elabs home page, the reported Warnings are not compliance issues.

Because of the untestable nature of javascript implementations, I have suggested that openWolf should consider a separate category labeled “Javascript.”

openWolf “Failures” for research.elabs

3.4 Relative rather than absolute units (19)
8.1 Identify the target of each link (6)

Web Standard 8.1 states: “Clearly identify the target of each link. It must be clear to the user where that link will take them. Everything that is a link is obvious as a link.”

openWolf interprets this by requiring that each new link destination must have unique link text. In the case of research.elabs there are multiple links labeled “No Comments”. However, as well as the page context and structure of a single “Comments” link within a <div> per blog-post, the links are built with descriptive and unique title tags which I believe satisfies Standard 8.1.

This is important because it is a common design situation. The alternative is to fully expand the text links and while that would be possible in this blog situation without overloading the layout with text, there are many other situations when such a change would not be the desirable design, for example this NZ Web Standards MediaWiki discussion where expanding the ..→ link would cause undesirable text clutter.

My view is that openWolf should report such points in the “Warnings” or “User Checks” section. I am posting more detail in Comments on Standard 8.1. on the Web Standards wiki for discussion.

Web Standard 3.4 states: “Use relative rather than absolute units in mark-up language attribute values and style sheet property values”

Interestingly, the subsequent “Guide to this Standard” section then provides examples only relating to fonts:

Avoid fonts with sizing based on absolute units such as points (pt), pixels (px), centimeters (cm), millimeters (mm) and inches (in). Font sizes expressed as percentages (%) and “ems” (em) are preferred.
A base size font across the whole web site (for consistency) is recommended.

research.elabs complies with these guide points, using only “ems” for all font sizes. The compliance problems arise where other (non-font) elements are defined in absolute units.

This non-compliance issue appears to be common across all NZ Government web sites - we have not seen a compliant example. Moreover, the rare examples globally (here is an example) of fully scaling layouts still have accessibility issues such as scaling beyond the screen.

The complexities of accessing web pages on modern screen sizes from say 176 pixels wide (a common phone) to 2500 pixels and beyond, together with scaling functions in modern browsers require a more sophisticated Standard than the existing 3.4.

As always, your comments are welcome.

This entry was posted on Friday, January 25th, 2008 at 1:11 am under Standards & Compliance. You can leave a response, or trackback from your site.