Tags : Web Development
31Oct2016

Junior Developer Focus: HTML Validity

Tags : Web Development

There are a lot of rules to follow when creating valid HTML. Every developer knows what it’s like to paste code into the w3c validator and have it spit out error after error, some of which are a bit ambiguous. This article will help you to avoid common pitfalls and be more confident in how to mark up your content.

HTML Skeleton

Your code editor of choice may have a HTML skeleton that it produces by default. If not, the Emmet plugin can create an HTML 5 skeleton for you: 

<!DOCTYPE html>
 <html lang="en">
 <head>
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width, initial-scale=1.0">
     <meta http-equiv="X-UA-Compatible" content="ie=edge">
     <title>Document</title>
 </head>
 <body>
 </body>
 </html>

The important parts here are the doctype and the title tag. These must be present.

The doctype is required for HTML 5 pages. Browsers support HTML features independently of doctype, but omitting this tag can affect the way that the browser renders HTML. You may experience some weird behaviour without it.

The HTML language attribute isn’t required, but it’s good practice to have it here. It’s beneficial for disabled users and it can be used in style sheets to change fonts and text direction.

The meta charset tag isn’t required if your server specifies the encoding, which most do. However, it is usually good practice to include it anyway. If the server and the meta tag specify different charsets, then the server will take precedence.

The meta viewport tag will ensure that the page works well on mobile devices. Without it, a mobile browser can render the page in a zoomed out state and require the user to zoom in.

The X-UA meta tag is not required and is usually only added to sites that were coded for older versions of IE.

Opening and closing tags

You’ve probably come across tags that have no content before, such as <br> and <hr>. These are examples of void elements. In XHTML, these elements are closed using a shortcut syntax. EG: <br />. In HTML 5, you don’t need to use the forward slash or provide a closing tag at all. Here is the full HTML 5 list:

area, base, br, col, command, embed, hr, img, input, keygen, link, meta, param, source, track, wbr

Also remember that script tags always need to be <script></script>. Using the shortcut will break the page.

Content models

Each element has a set of rules that state what other elements are allowed to be placed inside it. In the past, a ‘block-level’ element was not allowed to sit inside an element that was ‘inline-level’. For example, you couldn’t put a DIV inside of an anchor.

With HTML 5, the terminology has changed and it is a bit more complex. Each element has a ‘content model’, which lists what the element can contain. Now with HTML 5, placing a DIV inside of an anchor is valid.

It’s very difficult to absorb this information, and I wouldn’t expect a junior developer to memorise all of these rules. Instead, this will be a gradual accumulation of knowledge through experience. Don’t worry if you don’t get it all correct straight away, it’s not the end of the world. Just remember to validate your HTML with the W3C validator and you’ll fix whatever is incorrect.

See: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories

Semantic markup and elements

When writing HTML around content, you should use tags that are appropriate. For example:

  • Each section should be wrapped in a section tag.
  • A heading should use a heading tag.
  • A paragraph should use a paragraph tag.
  • A quote should use a blockquote tag.
  • Lists should use OL (ordered list) or UL (unordered list) + LI (list item) tags.

Don’t use DIVs or SPANs for anything except styling. When using a span, ask yourself if there is a more semantic tag that you could use. EG: strong, em, small.

Correctly nested heading levels

When using a header tag, be sure to use the appropriate level. Examine the content and determine if the heading is related to the previous one. If so, it needs to move down a level. Otherwise it’s a new train of thought and should be the same level as the previous heading.

There should only be one H1 and there shouldn’t be any ‘gaps’ between headings. EG: H1, then H3 but no H2.

Images

If an image is a part of the content and requires alt text or a caption, then it should be an image tag. Otherwise, if it is used for decoration purposes only, it should be a background image.

Forms and labels

Every form control (except hidden inputs) need to have an associated label. The ‘for’ attribute of the label should point to the ID of the control. Placeholders do not replace the need for labels.

Accessibility

You may have heard of WAI-ARIA and WCAG before ( https://www.youtube.com/watch?v=gtuna2AWvqk ) These are guidelines and techniques that can be used to make your website easier to use for disabled users.

Aria attributes are one of the main techniques that you can implement to achieve ease-of-use. These attributes can be used instead of classes in many cases. For example:

  • Instead of using an active class on a tab panel heading, you can use aria-selected=”true”.
  • Instead of using an active class on tab content, you can use aria-hidden=”false”.
  • Instead of using an error class, you can use aria-invalid (with multiple values.)
  • Buttons can have aria-pressed=”true”,.
  • Accordions can have aria-expanded.

Aria attributes can also help disabled users to understand the context of form elements. A good example would be an ‘I agree’ checkbox. In this instance you can user aria-describedby to connect a paragraph of text to the form control: 

<p id="i-agree-terms">Terms and conditions etc...</p>
 <input type="checkbox" id="i-agree" aria-describedby="i-agree-terms">
 <label for="i-agree">I agree</a>

Aria attributes can also be used to indicate that one element ‘controls’ another with aria-controls. This attribute can then be used by Javascript to fetch the IDs of the elements to be toggled when the controlling element is clicked.

Aria roles can be used to specify that a particular set of elements is meant to be a particular type of ‘widget’, such as the previously mentioned tab panel / tab content widget.

See:

http://heydonworks.com/practical_aria_examples/

http://accessibleculture.org/research-files/WDCNZ-25July2013/make-your-widgets-sing-with-aria.html#/

Conclusion

HTML is just a mark-up language, but there is a lot to learn. Especially when you take Aria / WCAG into account. Government websites need to be at least WCAG 2.0 AA compatible and most bigger websites, legally, need to be accessible too, so don’t discount this information. You’ll be making life easier for a lot of disabled people. If you want a job with a big company or a government contract, you will need to have knowledge in accessibility. The sooner you employ WCAG guidelines, the sooner you will be comfortable with them.