Use structural and semantic markup properly and validate code

Markup such as headings, paragraphs, lists, definitions and quotations add useful semantic (inherently meaningful) information. Markup used solely for presentation purposes incorrectly communicates meaning. You should make full use of structural and semantic coding wherever possible and never use semantic markup solely for decorative reasons.

Valid code ensures the widest possible acceptance by the multitude of devices and a clearer upgrade path to new standards.

On this page

Techniques

Use native HTML structural and semantic markup to add meaning to elements

HTML is rich in native, semantic markup, to help convey the type of information – image, main heading, sub-heading, ordered list, table column header – to users, even when they are not able to see it.

Native HTML elements also carry many built-in behaviours that allow users to interact with them appropriately, such as hyperlinks and input fields.

You have to do a lot of work to get a generic element, like a span, to behave as well as look like, for example, a link – this generally requires JavaScript, CSS, ARIA and extra HTML attributes – and even then there is no guarantee that your new element will be recognised by all browsers and assistive technologies.

Always use semantic markup and rely on CSS to finesse the appearance of your HTML elements as required.

Do not misuse semantic / structural markup for presentation effects

See DEV 1.5 – Do not misuse semantic markup

Validate your code to help eliminate errors

Many code validators will help weed out deprecated tags and syntax problems, and assist you to code to standards, for example use the following free resources:

In particular, look out for invalid markup that can significantly impact on accessibility, such as the presence of duplicate IDs, or the absence of programmatically assigned form field labels and image alt attributes.

Do not use deprecated features of HTML

For example, <dir>, <font>, <frame> or <frameset> tags (see the further reading section)

Use CSS to control all formatting and layout

Cascading style sheets (CSS) are powerful when used properly. They allow separation of content and style, allowing users to easily change your site’s appearance – for example, changing text size, colour or font family by applying their own CSS – to make it easier for them to navigate and read.

Using CSS helps to ensure consistency across all pages of your site, and reduces download times as all of the styling information will be downloaded once then cached.

There are also organisational efficiencies to this approach, for example, design specifications will only need to be updated in one place and can therefore be done so quickly and easily.

Do not apply styles directly to text containers such as paragraphs, divs, spans and table cells – doing so will remove all of the advantages of using CSS.

Write HTML and CSS according to the specified standards

Ensure that all code is validated against the appropriate standard, for example by using W3C validators.

Specify a valid Document Type Definition (DTD)

You should use the most up-to-date web technology - see the list of valid W3C DTDs

Links or buttons?

Links should take users to other pages (for example, the next page in a sequence; a page on another site); buttons should perform operations on the same page (for example, ‘print’; open a modal dialogue) – make your links look like links and your buttons look like buttons, this will help users predict what will happen next.

A button which has been styled to look like a link

See dates

<button>See dates</button>

Users will expect this to take them to another page. They may attempt to right-click it to open it in a new window. If this is the intended behaviour then this should be coded as a link; if this is not the intended behaviour then the button should not be styled to look like a link.

A button which has been styled to look like a button

Button with the text "See Dates" — Figure 1

<button>See dates</button>

Users will expect this to show them the dates without taking them to another page. If this is not the intended behaviour then a link should be used instead.

Links which have been styled to look like buttons

There are occasions where links can be appropriately styled like buttons, this is generally when users will be able to accurately predict that they will take them to another page (for example, “Log in”, “Search”, submitting a form)

Note: although these may be styled as buttons they must be coded as links so that their nature can be correctly conveyed to screen reader users.

Button with the text "Search" — Figure 2

<a href="...">Search</a>

Users will expect this link to perform a search and present them with a list of search results on a different page.

Where semantic elements are not available, assign appropriate ARIA roles

It is always best to use native HTML for buttons and links, rather than creating custom elements, as there is no need to add event handlers to native HTML elements. If it is not possible to use native HTML, ensure you assign the appropriate ARIA roles as well as specifying event handlers. See DEV 8 – Use ARIA to create rich internet applications

Be aware of semantic text information not conveyed to screen reader users

Some widely used screen readers do not convey <strong> or <em> to users. Whilst these will make a difference to the text visually, those sentiments may not be conveyed to screen reader users.

VoiceOver on Apple devices will read the three following sentences in the same way, with no change in intonation:

<p>This is the best line</p>
<p>This is the <strong>best</strong> line</p>
<p>This is the <em>best</em> line</p>

Videos

Examples of good practice

Examples of bad practice

WCAG Failure F68: A user interface control not having a programmatically determined name