Accessibility Testing and HTML 5
Abstract
The new “living HTML” standard — HTML 5 — has brought with it some unique challenges for authors of testing tools. Here we’ll examine some of them, look at how siteSifter handles these situations, and discuss how the specification can be improved.
The article assumes that a desire exists to support not only sighted users, but also alternative presentational contexts.
Disclosure
The author is the owner and operator of Greytower Technologies, a company which specialises in automated quality testing of websites.
Introduction
The moment has arrived: you can stay home from work if your temperature is above 41 degrees Celsius. The thermometer is fetched, the measurement begun. And you get a result too. 105.8, to be precise.
And the number is all you get — nothing more, nothing less.
The ability to perform a meaningful test, regardless of field or methodology, hinges on the possibility that the result can be checked against expectations.
If no agreement exists on expectations, or correctness of answer, no test can be performed with any hope of a useful, practical result.
You, the human, will take the above 105.8 and correctly deduce that the thermometer uses the Fahrenheit scale — either that, or you are a remarkably spry corpse. It is a reasonably simple conversion to the hoped–for 41 degrees Celsius.
But a computer can only do this in a very few, very limited contexts. Unless we tell the software that this is a number, and a temperature, there is nothing much that could be done with it. After all, 105.8 could just as well be a radio frequency, a law in Michigan, the weight of a boar in kilos, or acres for sale in Coffeeville, Miss.
To a computer, “105.8” may not even be a number, but a string; a simple sequence of characters with no real numerical value.
Markup languages such as HTML are one way to code such agreement. As long as an author and a browser both accept that the element “P” represent the concept of a “paragraph”, the author can write and the browser can present what is written in a way consistent with the user’s physical realities — be it visual, aural or tactile.
The agreement is written into a specification, which in practise works like a dictionary. As long as both parties can agree what an “egg” is, we have no unfortunate accidents with omelettes …
The Problem
Once definitions change it becomes difficult to agree. We’ll use the well–known and widespread B–element as our example.
B was introduced in HTML 2.0, and explicitly meant to instruct browsers to render a certain piece of text in a bold font, if possible.
5.7.2.1. Bold: B
The <B> element indicates bold text. Where bold typography is unavailable, an alternative representation may be used.
The use of so–called “typographic” elements have, from an accessibility point of view, always been tricky. Let’s have a look at the HTML 2.0 spec again, this time with reference to the I–element:
Typical renderings for idiomatic elements may vary between user agents. If a specific rendering is necessary — for example, when referring to a specific text attribute as in “The italic parts are mandatory” — a typographic element can be used to ensure that the intended typography is used where possible.
If a browser is unable to show “italic”, the warning on mandatory parts is suddenly nonsensical, and information is lost. A speech browser, for example, cannot “read italic” — although it can, of course, read “The following passage is written in an italic font”.
A visually impaired user will, of course, keep in mind the hint from the prose (“the italic parts are mandatory”) and react to the information from the markup (“these words are written in italic”).
However:
As no browser invented today can tell “this italic text” from “that italic text”, no further information can be gleaned. If the I–element is used for other things than mandatory fields, confusion reign.
For this reason — among others — HTML defines semantic elements. Instead of using “I” in the above, we could imagine using a MANDATORY element — which could be styled to italic with CSS, and still be able to present the information in a non–visual context:
<label for="foo"><i>Name</i></label> <input type="text" name="bar" id="foo">
would become:
<label for="foo"><mandatory>Name</mandatory></label> <input type="text" name="bar" id="foo">
or, indeed:
<label for="foo">Name</label> <input type="text" name="bar" id="foo" mandatory="yes">
The visual appearance — the italic font — is the same, while the information, that something was mandatory, would be retained. Our speech browser can now announce: “The ‘name’ field is mandatory”.
In other words: the browser can tell “this” text from “that” text, even if both are visually rendered in an italic font.
The Inconsistency of “B”
Since siteSifter was first launched, we have gathered numerous examples of code from around the ’web for use in testing baselines.
When we today look through our archives for examples of the B–element, it becomes clear that it is not only a popular one, but that it has been used in a number of different ways. Here are a few, with some content and class names rewritten for anonymity. The intended meaning is our best guess based on context.
First, B used as a document header (headline):
<td style="text-align: center"><b>NAME OF<br /> ORGANIZATION</b></td>
As a table header:
<td class=header colspan=2><b>Government</b></td>
As emphasis:
Viewing <b>1</b> to <b><span id="pagingPageResults">1</span></b>
Interestingly, the document from which the above example was taken also use:
<strong>You are here:</strong>
and, finally, to achieve bold text:
Password <span class="red"><b>*</b></span></b>
Of these four examples, only the last matches the specification from HTML 2.0 through HTML 4.01:
The following HTML elements specify font information. Although they are not all deprecated, their use is discouraged in favor of style sheets. …
Rendering of font style elements depends on the user agent. The following is an informative description only. …
B: Renders as bold text style.
The three first examples should be marked up using the H1–H6, TH, and EM elements respectively in order to retain their informational content in a non–visual context.
We have shown that for the last fifteen odd years, the B–element has been misused heavily, often in different ways within the same document.
A Conclusion
We can only conclude that it is not possible to state with any certainty what the B–element represents in the real world.
A non–visual browser is left with two solutions: ignore B, or attempt to make an educated guess based on context. Perhaps such an element inside a table cell is a table header? Or perhaps it is simply a decorative font change.
The pragmatic solution would be to remove style elements from future versions of HTML, and continue to support them in browsers as previously specified: visual browsers will render a bold font, if possible; ATs will be no worse off.
The rationale is as follows: Whenever possible, the non–visual user is best served by an element with only one discrete meaning. If multiple interpretations of content is specified, a user–agent can not programmatically determine which one is suitable.
A graphical browser can apply any style desired to such an element.
Since there is no practical way of mapping B, as used, to any single, easily interpreted semantic structure, redefining it from a font style element would introduce confusion.
And what about HTML 5? It changes the B–element as follows:
The b element represents a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood, such as key words in a document abstract, product names in a review, actionable words in interactive text–driven software, or an article lede.
Reexamining the four real–world examples, we find that none of them fit the “new” definition: three are better served with other semantic elements, and the fourth better rewritten as a mix of HTML and CSS:
Password <span class="required">*</span>
.required {
font-weight : bold ;
color : red ;
background-color : inherit ;
}
Again, in none of the existing sample cases can we find that B applies as HTML 5 defines it.
Worse, a browser is — using the definition from HTML 5 — unable to tell the “product name” from the “key words” or the “article lede”
The Accessibility Angle
First, it is important to note that as standards develop, so too must testing tools. However, not all changes are positive.
In the past, it was possible to say: “You’ve used an element in order to achieve a visual effect — a bold font. Is it not possible that you meant to use a semantic element with the STYLE set to a bold font?”
As of HTML 5, this is no longer possible, despite the assurances of the W3C that:
HTML5 is defined in a way that it is backwards compatible with the way user agents handle deployed content. To keep the authoring language relatively simple for authors, several elements and attributes are not included, as outlined in the other sections of this document, such as presentational elements that are better dealt with using CSS.
First, B has been a presentational element since its inception in 1995. Secondly, it has changed from the way user agents have handled it for over a decade: by rendering its content as bold text.
The siteSifter Solution
In order to get a grip on the problem, siteSifter attempts to detect the correct type and version of each document it process.
If a checkpoint is version–dependent, such as success criterion 1.3.1:
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
and knowing that using B does not meet ‘A’ in HTML 2.0, HTML 3.2, HTML 4.0, HTML 4.01, XHTML 1.0 or XHTML 1.1, siteSifter can flag an error on finding such usage.
Of course, it does meet with SC 1.3.1 in HTML5. Whether it will meet SC 1.3.1 in later versions of HTML is uncertain at this point.
Since versioning has effectively been abandoned, and a precedent has been made for changing a previously well–defined, if ill advised, presentational element into a fuzzy semantic element, there is little to guarantee we won’t see a change back at some point.
Note that the B–element has been redefined without the change reflecting current usage in browsers — since the vast majority of graphical browsers simply handle B as a font change.
Without versioning, such a switch back from semantic to presentational, or even further switches from presentational to semantic, would be nearly impossible to detect.
Another Conclusion
With the changes made to HTML 5, there is no practical way to automatically detect whether a document written in a version–less HTML contains elements breaking with SC 1.3.1.
Further, WCAG 2 require meeting Success Criterion 1.3.1 for the most basic of accessibility levels (“A”).
We recommend that the HTML specification is either (a) changed to contain an explicit versioning syntax, or — preferably — (b) changed to ensure that all structures possible to create are also possible to be programmatically determined.
If an element is needed to meet a semantic use–case for which “B” was intended, introduce a new, more correctly named element.
“B” — like “I” — cannot meet any semantic requirements.
Notes
The code samples used are all from Greytower’s internal collections, and we will not under any circumstance share their origin. However, the same pattern of usage for B can be found by sampling a suitable number of pages from the WWW today.
References
Please note that these references are not necessarily endorsed by Greytower. Links are valid as of the 2nd of July 2012.
HTML is the new HTML5
http://blog.whatwg.org/html-is-the-new-html5
Ian Hickson, 19th of January 2011
1.3.1 Info and Relationships
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#content-structure-separation-programmatic
W3C, 11th of December 2008
RFC 1866: HTML 2.0
http://www.rfc-editor.org/rfc/rfc1866.txt
Berners–Lee, T.; Connolly, D., November 1995
Font style elements
http://www.w3.org/TR/REC-html32#font-style
W3C, 14th of January 1997
15.2.1 Font style elements: the TT, I, B, BIG, SMALL, STRIKE, S, and U elements
http://www.w3.org/TR/html4/present/graphics.html#edef-B
W3C, 24th of December 1999
4.6.18 The b element
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-b-element
WHATWG, 15th of May 2012
4.6.17 The b element
http://www.w3.org/TR/html5/the-b-element.html#the-b-element
W3C, 29th of March 2012
1.2 Backwards Compatible
http://www.w3.org/TR/html5-diff/#backwards-compatible
W3C “HTML5 differences from HTML 4”, 29th of March 2012