DEV 7.1 – Use structural and semantic markup properly and validate code
Why is this important?
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.
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.
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
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
<button>I am actually a button</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>I am actually a button</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.
<a href="...">I am actually a link</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>
Examples of good practice
Examples of bad practice
EN 301 549 v 2.1.2
- 18.104.22.168: Info and Relationships
- 22.214.171.124: Headings and Labels
- 126.96.36.199: Parsing
- 188.8.131.52: Name, Role, Value