skip to content W3C SVG

19. Valid Markup & Spelling

Use properly nested markup tags and correct spelling

When using markup languages (e.g. HTML, XHTML, SMIL) follow the specifications for the language and test for errors using a validator. When using human languages (e.g. English, Hindi, Japanese) test for spelling errors using a spell checker.
Note: The intent of this guideline is to avoid typing errors, tagging errors and accidentally invalid markup. Occasionally, developers will have valid reasons for markup that will not validate in a tool. Such conscious decisions are acceptable and can simply be noted in your accessibility documentation.

Rationale

Testing in supported visual browsers can help find some errors in markup. However, browsers often display Web pages rather well even when the pages do not follow the specifications for the markup.

The errors that some browsers are able to overlook can cause issues when other tools (particularly screen readers) attempt to work with the markup.

For example, screen reader users use special keystrokes to navigate data tables cell by cell. They listen to the data and to the relevant headers along the way. Occasionally a data table with a missing closing </th> tag will look fine on many browsers. However, when a screen reader interprets the table, the missing tag can cause the wrong header to be associated with a particular data cell.

Additional Benefit: Valid markup is less likely to break in new browser versions. It is also easier and less expensive to maintain than non-standard markup which often depends on browser quirks mode, reflecting legacy browser-specific behaviors.

Misspellings that can are overlooked visually can make a big difference when a screenreader tries to pronounce the words. During recent accessibility reviews, we found that misspellings were greatly reducing the quality of the experience for screenreader users, even when the issues were minor for visual users.

General Techniques

If you find that specific elements of your markup do not validate, but you have valid reason for this markup, pay special attention to how those elements play in screen readers.

Testing HTML

Valid Markup
Testing technique Description
Tools

In the HTML Check menu of the Web Accessibility Toolbar use the W3C HTML Validator function.

Or, in the Tools menu of the Web Developer Toolbar use Validate HTML.
Output Each of these tools will indicate whether or not the page validates. If there are any problems on the page, a list of validation errors and warnings is shown.
Analysis Clearly, fully valid documents are ideal in general. To meet accessibility guidelines, we require only that tags are properly nested and that id values are unique . So, at least report any errors or warnings regarding mismatched, improperly nested tags or duplicated id values.

Technology Specifics

HTML | XHTML | CSS

Planning
  1. Decide in advance what version and flavor of HTML/XHTML will be used: http://www.w3.org/MarkUp/#recommendations
  2. Let all developers know which version/flavor to work toward.

Development
  1. Follow the specifications for the chosen version.
  2. Indicate the appropriate character encoding: http://www.w3.org/International/O-charset
  3. Include a valid document type definition: http://www.w3.org/QA/2002/04/valid-dtd-list.html#DTD

Validate during Development
  1. Use a tool to validate your markup, such as: http://validator.w3.org/
  2. Test your validator to be sure that you understand whether markup that is hidden through CSS will be tested. The W3C validator is able to test markup hidden through display:none and throughor visibility:hidden.

JavaScript

Development
  1. When adding HTML/XHTML elements or text content, manipulate the document object module (DOM), rather than using document.write or innerHTML. innerHTML is non-standard. Both document.write and innerHTML do not always write proper nodes to the Document Object Model tree. This may become an issue for custom and future assistive technologies, so DOM manipulation is best for future-compatibility. (Legacy content that is expected to be retired in the next year or two, may use these without significantly degrading the experience for users with disabilities.)
  2. When manipulating the DOM, ensure that the markup generated meets validation standards. For example, if using JavaScript to create new nodes with ids ensure that the ids are unique.

Validate during Development

  1. Test your validator to be sure you understand which JavaScript-generated markup it tests. For example, the W3C validator (http://validator.w3.org/) checks markup that is written into the page using JavaScript while the page is loaded. But, it does not check any markup that is written based on choices the user makes onscreen. In order to test this markup:

    OR

  2. indicate user choice through a query string so that each choice has a URL which can be validated
  3. include a testing mode in your script which allows you to temporarily hard-code user choices during validation

Related Guidelines

WCAG 2.0 Level A – SC 4.1.1 Parsing

In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.