Validation

Validation means verifying that the site you produce meets and complies with published guidelines to ensure a quality experience for all users. Some validation (like HTML and CSS validation) can be done automatically, however full accessibility validation requires a large amount of human interaction.

• Markup validation
  • Choose a DTD: XHTML 1 Strict or HTML 4 Strict
    • Currently no practical difference (for accessibility).

      With the current set of assistive technology devices, there is no practical difference between HTML 4 and XHTML 1. You can make one just as accessible as the other.

      Some SGML enthusiasts complain the the XHTML syntax can cause problems in SGML-capable browsers. Though the problems are fairly insignificant, they do not arise in HTML.

    • XHTML has more theoretical benefits (future-proof your site).

      Because XHTML is a form of XML, the theoretical benefits are vast. Any XML parser can read and translate XHTML into other forms to reuse the data. XHTML also alleviates any possible abiguities in rendering because of ommitted closing tags.

      The current generation of web browsers contain XML parsers capable of transforming documents with scripting or with an add-on extension. Future versions may include more parsing utilities.

    • Strict DTD versus Transitional DTD.

      Use of a strict DTD can enforce more separation of content from style than a transtitional DTD. Also, although it doesn’t require it, a strict DTD also encourages the use of semantic markup. Almost any validating document can be made accessible, but XHTML 1 Strict or HTML 4 Strict are the recommended choices.

  • Benefits of markup validation
    • Catch easy errors

      Just like it says, the W3C markup validator will catch markup errors, tell you where they are, and tell you why they are incorrect. The new beta version of the markup validator gives slightly better instructions and even has “fussy parsing” mode, which will flag non-errors that are known to cause problems. Is that a Freudian slip waiting to happen?

    • Consistency across all user-agentss

      A browser or other UA cannot be expected to consistently render your page unless your code complies to the same rules it understands. All browsers follow the same specifications, so by following the standards instead of the browser bugs, you can ensure consistent rendering on all standards-compliant browsers: past, present, and future.

      Base your design on standards, and then make small adjustments where needed. If you base it on a buggy implementation, you have trouble getting it to work correctly in compliant browsers.

    • More reading.

      Why say more when these authors have already done a fantastic job?

      • The Business Benefits of Web Standards by Tristan Nitot (March 21, 2003)
      • The Business Value of Web Standards by Jeffrey Veen (September 18, 2003)
• CSS validation
  • Errors versus Warnings

    The W3C CSS Validator will alert you to any errors or warnings in your CSS. Keep in mind that warnings are not errors, but they are there to help you avoid problems. Pay attention and consider fixing each warning unless you have a good reason not to.

  • CSS selector differentiation and comment hacks

    You should leave markup clean and free of presentational code, however, each browser’s implementation of the CSS model is slightly different. When these differences arise, it is common practice to exploit browser bugs (comment hacks) or known limitations (selector differentiation) in order to serve conditional CSS to each user-agent. While a “hack” like this would be considered laughable in any other software field, it is a regretable necessity of modern client-side coding.

    However, in order to ensure consistency across all present and future implementations, There are some rules to using CSS comment hacks and selector differentiation.

    • Must be valid CSS.

      In order to not cause unpredicatble rendering bugs, you must not use invalid CSS. An example of an invalid CSS hack follows:

      /* incorrect */
.nav {
  width:250px;
  width:200;
  }

      All browsers render the width as 250 pixels, however the second line is invalid. Fully-standards-compliant browsers ignore it, but Microsoft Internet Explorer (MSIE) incorrectly assumes a unit value of pixels. Because all CSS size values must contain a unit or a keyword, this is invalid and could potentially cause problems with other browsers and future releases.

      An example that acheives the same thing in a valid way follows:

      /* correct */
.nav { width:200px; }
html>body .nav { width:250px; }

      The first rule is recognized by all standards-compliant browsers (including MSIE) and the second rule is recognized by browsers correctly implementing CSS level 2: Gecko (Mozilla, Firebird, Netscape 7, Camino), Safari, Opera, and many more.

    • Always leave default value complying to specification.

      We assume that future releases of web browsers will follow web standards, so make sure the last overriding rule you include in a style sheet follows the recommended standards. When a new browser is released, your code should be presented in the manner expected. If you follow web standards, your web site will probably require little or no modification to support new browsers as they are released.

    For more information on CSS comment hacks and selector differentiation, consult the CSS-Discuss Wiki.

    • CSS Hacks
    • Avoiding Hacks
    • Rendering Mode
• Accessibility validation
  • WCAG Checklist

    If you know all the code on your web site you can go through this list and verify accessibility. The following tools can help speed the process, but they are know substitute for human verification (user checks).

  • Tools

    There are validation tools that will help you recognize certain accessibility problems, however, these are only a supplement and should not be used without full user checks.

    • Bobby

      The first of its kind and a fantastic tool for catching many common accessibility errors, Bobby received much praise and now receives more criticism than it deserves. The criticism is mainly due to the fact that Bobby is often misused. People see the “Bobby Approved” graphic and assume they are finished. Too many ignorant developers out there claim a completely accessible site, without performing one user check.

    • Cynthia Says

      Another web-based validation tool that’s slightly different (better?) than Bobby. You be the judge. Note: Cynthia is still misused just like Bobby. Many people see no error and assume full validation.

    • WaiZilla

      An open-source accessibility validation tool started by Tim Roberts that integrates with the Mozilla web browser. Read Ian Lloyd’s review of WaiZilla for more information and a few links to other accessibility testing tools.

    • Lift

      Lift was created by UsableNet and is available as a stand-alone version or as plugin utilities for Macromedia Dreamwever and Microsoft Frontpage.

    • A-Prompt Project

      A-Prompt is developed and made available by the Adaptive Technology Resource Centre of the University of Toronto and is available in English and French.

  • User checks are essential!

    In case we didn’t mention it before, user checks are essential! Don’t just use the automatic tools for accessibility testing. User checks are essential!

• Shortcomings of Validation
  • Automated validation can’t do everything.

    That’s right. There’s no magic pill for web development.

  • Valid does not mean accessible.

    Valid HTML and CSS is important, but it does not mean your site is accessible. Full accessibility validation does mean accessible, but that level of validation cannot be provided by automated tools. (If you noticed we keep repeating this, you’re paying attention. Thanks.)

  • Valid does not mean semantic.

    A site can use completely valid XHTML 1.1 Strict markup and still be semantic trash. More information on semantics is contained on the next page.