Short Note on HTML conformance checking

Posted on Monday, 10 August 2015 by Steve Faulkner

When you check a HTML document, using the W3C HTML conformance checker, to find out whether its code conforms to the rules defined in the HTML specification (and other referenced specifications). It’s useful to understand what the output means.

W3C Nu Markup checker

Errors

Errors are instances where the code you are checking does not conform to MUST level requirements defined in the HTML specification.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT  This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

For example, the following code snippet breaks the rule:

Content model for element ol: Zero or more li and script-supporting elements.

<body>
<ol>
<div></div>
</ol>
</body>

In other words, an ol element must only contain li, script or template elements as child elements.

<body>
<ol>
<template></template>
<script></script>
<li><div></div></li>
</ol>
</body>

MUST level requirements and the errors they produce are there to stop you doing stuff that can cause problems or remind you to do stuff that you need to do to avoid problems.

W3C Old Skool W3C validator

Warnings

Warnings are instances where the code you are checking does not conform to SHOULD level requirements defined in the HTML specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

For example, the following code snippet breaks the rule:

Default Implicit ARIA semantics – SHOULD NOT be used

<body>
<ol role="list">
<li>item 1
</ol>
</body>

In other words, ol has a an implicit role of list, which is conveyed by browsers automatically, so there is no neeed to add the explicit role as an attribute.

<body>
<ol>
<li>list item
</ol>
</body>

SHOULD level requirements and the warnings they produce are there to stop you doing stuff that is unecessary or harmful in general or as a reminder to do stuff that it is useful or helpful to do, in general.

Where do these requirement terms come from?

An ancient (1997) text handed down by our ancestors: Key words for use in RFCs to Indicate Requirement Levels. Which you will find referenced by many (all?) W3C specifications that define what are known as normative requirements. Requirements are defined in HTML, for user agent implementers, conformance tool implementers or web developers (AKA authors).

Further Reading

About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including HTML 5.1, ARIA in HTML, Notes on Using ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility.

Comments

Comments for this post are closed.