The aim of the HTML Advanced Tutorial is to show how to fully exploit the features of HTML and how to optimise it for accessibility.
Because the HTML Beginner Tutorial and HTML Intermediate Tutorial take the standpoint of using the latest standard of HTML (XHTML 1.0+), some aspects of this guide may be unfamiliar to a lot of people who haven’t read through the Beginner and Intermediate tutorials, which is why there is a Standards Recap page.
In general though, the pages in this section assume that you know the ins and outs of HTML and want to exploit it to its full potential.
This page is for those who know HTML, but might be unaware of the standards involved in future-proof XHTML and the philosophy behind the separation of meaning and presentation.
Separating meaning and presentation
HTML was never meant to be used for presentation, but user-agents incorporated elements that formatted text and developers found ways to manipulate layout.
With the power of CSS it is now no longer necessary to style using HTML and meaning (HTML) can now be completely separated from presentation (CSS).
There are a number of benefits to this – it should greatly decrease file sizes, it has the flexibility of a central style sheet that applies to the entire website rather than an individual page and it should also produce pages of much greater accessibility.
Following this philosophy basically means you shouldn’t style anything within the HTML. Tags such as font or attributes such as bgcolor should not be used. Even the border attribute inside an img tag is no longer valid in XHTML 1.1. This shouldn’t be a problem – there is no styling that can be done in HTML that can’t be done, and done better, with CSS.
It isn’t just about taking away the presentation from HTML, the application of meaning means specific HTML tags should be used when appropriate. For example, h1, h2 etc. should be used for headings – you should not just use CSS to make fonts larger.
A good guide is to see if a visual browser, with its default styling, presents the document well without a style sheet.
Tables should not be used for layout – tables are designed to display tabular data. This is perhaps the most difficult technique for experienced HTMLer’s to get used to as it completely changes the way the HTML has traditionally been structured in the past. This approach greatly reduces the size of the page and, due to the resulting linear code, it becomes much more accessible.
Read the Layout page in the CSS Advanced Tutorial for more on this.
In XHTML all tags should be lowercase and must be closed. For those tags that do not have closing tags (such as br and img), they must close themselves with a ‘/’ at the end (such as <br />). Note that there should be a space before the forward-slash.
The markup must be well formed, with elements properly nested (for example,
<strong><em>this</em></strong>, not <strong><em>this</strong></em>).
All documents must have html, head, title and body elements. They must also start with a document type declaration.
The body of the document should start with p, h1, h2, h3, h4, h5, h6, div, pre, address, ins or del.
All attributes must also be lowercase and their values in quotation marks.
Minimized attributes are not allowed (such as <input type=”checkbox” checked />). Traditionally minimized attributes must be given the value that is the same as the name of the attribute such as:
<input type="checkbox" checked="checked" />
The name attribute is no longer valid (except in form elements) and should be replaced with id.
The target attribute is not a valid attribute. Praise be. It was daft anyway.
The alt attribute in the img tag is compulsory.
The reasons for making web pages accessible to users with disabilities are quite self-evident. Not only is it moralistic, but it will also benefit our future as web users grow older and the acuteness of the senses degenerates. Accessibility isn’t just about accommodating people with severe disabilities, it is about making it easier for a great number of people with minor (predominantly visual) impairments.
There are increasing legal implications such as the introduction of ‘Section 508’ in the US that makes a (half arsed) attempt to enforce certain accessibility initiatives and in the UK, all government websites must reach a specified degree of accessibility. How long until similar legislation is applied to general commercial websites, as it is for buildings?
If you follow the above practices, your HTML should already be highly accessible to users with disabilities. There are further initiatives that can make your web pages even more accessible and it really isn’t that difficult.
This page deals with a number of ways that links can be made more accessible.
Users who do not or cannot use pointing devices can ‘tab’ through links, and as such, links should be in a logical tabbing order. The
tabindex attribute allows you to define this order although if the HTML is linear, as it should be, a logical tabbing order should automatically fall into place.
Accesskeys allow easier navigation by assigning a keyboard shortcut to a link (which will usually gain focus when the user presses ‘Alt’ or ‘Ctrl’ + the accesskey). For users who do not use pointing devices, this is a much quicker and easier way to navigate than tabbing through links.
It isn’t necessary to put accesskeys on all links, but it is a good idea to apply them to primary navigation links.
<a href="somepage.html" accesskey="s">Some page</a>
The trouble with accesskeys is that there is often no way the user can find out what they are (unless they look at the source code). JAWS, the most popular screen reader out there will read these accesskeys out loud, but to take full advantage of them, you will probably want to make them more explicit.
You could apply a method similar to the ‘skip navigation’ link technique (see below), or opt for a separate page explaining the accessibility-related functionality of your site, including the accesskeys. A method that is growing in popularity is to underline a corresponding letter in the link, similar to the method used in the menus of most Windows applications.
See the article in A List Apart for more information.
It is a good idea to add the title attribute, which will pop up a description of where the link will take the user, so improving navigation.
Adjacent links should be separated by more than spaces, so that they can be discerned by screen readers.
This can be done by placing characters in-between links (such as a pipe – ‘link | link’) or surrounding it by characters (such as square brackets – ‘[link] [link]’). It is also a good idea to put navigation links within lists. These can then be styled with CSS to be displayed however you choose, even side-by-side (using display: in-line).
You should give users of screen readers an opportunity to skip the navigation and go straight to the content. This is because if your navigation is consistent (as it should be), a user does not need to go through the same information on every page, especially if there is a lot of it. You can skip the navigation by placing a link before it that skips directly to the content.
It might look something like this:
<div id="header"> <h1>The Heading</h1> <a href="#content" accesskey="n">Skip navigation</a> </div> <div id="navigation"> <!--loads of navigation stuff --> </div> <div id="content"> <!--lovely content --> </div>
Obviously, you do not want this link to be displayed in visual browsers, so you can use CSS to render it invisible.
This is a CSS tip, but is specific to ‘Skipping navigation’. It involves the method to use to render the link invisible.
The most obvious way would be to use display: none, but as some screen readers will pick up on this and not read the link, as intended, the ‘Skip navigation’ link must be displayed.
It still doesn’t have to be visible though – there’s no point in showing it to visually able users. So instead of having a style containing display: none, you can set the width and height of the element to zero (width: 0; height: 0; overflow: hidden;), which has the same visual effect but will be read by screen readers.
There is still much overuse of the br tag when p should be used for paragraphs, but it is generally accepted that p tags should be used to represent paragraphs.
By the same logic, there are a number of tags that should be used to define certain text elements such as quotations, abbreviations and computer code.
It should be kept in mind that although most browsers will render these tags in various ways, the important point to remember is that it isn’t what each element looks like, but rather what meaning it applies.
Abbreviations and acronyms
abbr and acronym are used for abbreviations and acronyms respectively.
An abbreviation is a shortened form of a phrase. Very general. An acronym however is an abbreviation made up of the initial letters (or parts of words) of the phrase it is representing. So CSS is a valid acronym, whereas HTML and XHTML are not (if ‘Hypertext markup language’ was an acronym, it would be ‘HML’. Similarly, XHTML would be EHML).
For optimum accessibility, the phrase that the acronym or abbreviation is representing should be used in the title attribute.
<p>This web site is about <abbr title="HyperText Markup Language">HTML</abbr> and <acronym title="Cascading Style Sheets">CSS</acronym>.</p>
There is a lot of discussion about the use of abbreviation and acronym elements. Lars Holst provides perhaps the most detailed insight.
blockquote, q and cite are used for quotations. blockquote is block-line and used for large citations, whereas q is in-line and used for smaller phrases. cite is also in-line and preferable to q for its semantic nature and possible future deprecation of q.
Again, the title attribute can be used to show where the citation has come from.
Note: q does not usually change the appearance of the enclosed text – you need to use CSS if you want to apply a style.
<p>So I asked Bob about quotations and he said <cite>I know as much about quotations as I do about pigeon fancying</cite>. Luckily, I found HTML Dog and it said...</p> <blockquote title="From HTML Dog, http://www.w3programmers.com/"> <p>blockquote, q and cite are used for quotations. blockquote is block-line and used for large or citations, whereas q is in-line and used for smaller phrases. cite is also in-line and preferable to q for its semantic nature and possible future deprecation of q.</p> </blockquote>
There are a few tags,
var that are specifically for computer code and
samp, which are, in practice, also used mainly for code.
code is used for computer code.
var is used to indicate a variable within code.
<var>ronankeatingisbland</var> = true;
samp is similar to code, but is supposed to be used for a sample of outputted code.
pre is preformatted text and is unusual in HTML tags that is preserves the white space within it. It is most commonly used for blocks of code.
<div id="intro"> <h1>Some heading</h1> <p>Some paragraph paragraph thing thing thingy.</p> </div>
dfn is a definition term and is used to highlight the first use of a term. Like abbr and acronym, the title attribute can be used to describe the term.
<p>Bob's <dfn title="Dog">canine</dfn> mother and <dfn title="Horse">equine</dfn> father sat him down and carefully explained that he was an <dfn title="A mutation that combines two or more sets of chromosomes from different species">allopolyploid</dfn> organism.</p>
address should be used for an address.
<address> HMTL Dog House<br /> HTML Street<br /> Dogsville<br /> HT16 3ML </address>
There are some tags that are worth noting, but are rarely used because of their super specific nature.
bdo can be used to reverse the direction of the text, and can be used to display languages that read right to left. The value of the required attribute dir can be ltr (left to right) or rtl (right to left).
<bdo dir="rtl">god lmth</bdo>
kbd is used to indicate text that should be typed by the user.
<p>Now type <kbd>woo hoo</kbd></p>
ins and del are used to display editorial insertions and deletions of text respectively. It can have the attributes datetime (in the format of YYYYMMDD) and cite (a URL to a description as to why the insertion or the deletion has been made).
The ins element is usually shown underlined and the del element is usually displayed with a strikethrough.
<p>This is some <del datetime="20030522">nonsense</del> <ins cite="http://www.w3programmers.com">very informative stuff</ins> that I've written.</p>
b, i, tt, sub, sup, big and small are all presentational elements and as such, by their very definition, shouldn’t be used when attempting to separate meaning and presentation. b defines a bold element for example, which has no meaning at all – these tags define purely visual characteristics, which should be the job of CSS. Even though they are valid tags, there are others (such as strong and em, which are examples of ‘phrase elements’) that actually add meaning. If you want to solely replic
So you think you know how to make a table. Sure, you know the table, tr, td and th tags, you’ve even got the rowspan and colspan attributes in your pocket. You can make a really cute little plywood coffee table, but don’t you want to know how to make one of those polished solid wood, glass top dining tables that can take the weight of an oversized elephant?
The columns strike back
Table rows tend to make table columns look rather stupid. They do all the work, as the table is built row by row, leaving the columns feeling quite dejected.
Luckily for those eager columns though, the colgroup and col tags have come to their rescue.
These tags allow you to define the table columns and style them as desired, which is particularly useful if you want certain columns aligned or coloured differently, as without this, you need to style individual cells.
Here is an example of these tags in use:
<table> <colgroup> <col /> <col /> <col /> </colgroup> <tr> <td>This</td> <td>That</td> <td>The other</td> </tr> <tr> <td>Ladybird</td> <td>Locust</td> <td>Lunch</td> </tr> </table>
The styles of the class ‘alternate’ will be applied to the second column, or the second cell in every row.
You can also use the span attribute on either colgroup or col, in a similar way to rowspan and colspan.
Using it with the colgroup tag will define the number of rows that the column group will belong to, for example <colgroup span=”2″></colgroup> would group the first two columns. When span is used in colgroup, you shouldn’t then use col tags.
Using span in the col tag is more sensible, and could, for example, be applied to the above example like this:
<table> <colgroup> <col /> <col span="2" /> </colgroup> ...
This would apply ‘alternate’ to the last two columns.
Oh, but there had to be a catch, didn’t there? Here it is: The only styles you can apply to columns are borders, backgrounds, width and visibility.
Internet Explorer appears to behave much better than other browsers because it takes on board pretty much any CSS property, such as color, but, as it turns out, this is only because it acts in a mad wacky way. For a detailed explanation of this peculiar anomaly, let Hixie explain.
Summary and Caption Interlude
A brief and easy accessibility consideration is to always apply a summary and caption to the table.
A summary can be applied to a table using the summary attribute in the opening table tag. This won’t be displayed, but can aid in a non-visual representation of a table.
The caption tag defines the caption straight after the opening table tag. It will appear above the table by default, but can be placed top, right, bottom or left with the caption-side CSS property, although IE won’t take any notice of this.
<table summary=”The mating habits of locust, showing how many use protection and how many have a cigarette afterwards”>
<caption>Locust mating habits</caption>
Headers, footers and the quest for the scrolling table
thead, tfoot and tbody allow you to separate the table into header, footer and body. This is particularly useful for large tables and when printed for example, the header and footer rows should appear on every page.
These elements must be defined in the order thead – tfoot – tbody and would look like this:
<table> <thead> <tr> <td>Header 1</td> <td>Header 2</td> <td>Header 3</td> </tr> </thead> <tfoot> <tr> <td>Footer 1</td> <td>Footer 2</td> <td>Footer 3</td> </tr> </tfoot> <tbody> <tr> <td>Cell 1</td> <td>Cell 2</td> <td>Cell 3</td> </tr> ... </tbody> </table>
You can make the tbody element scroll in Mozilla, by applying the style overflow: auto; max-height: [whatever] to it. You will then see the header and footer kept in place and a vertical scroll bar to the right of the body. You should use the max-height property because IE doesn’t recognise it and so it is safer than using the height property, which IE would apply to every row.
Note: Back to normal browser differences, this time IE doesn’t have a clue when it comes to headers and footers, and although it renders them in the table, they will not appear at the top and bottom of every printed page, let alone deliver the scrolling table.
Be wary of using scrolling tables. Although they serve a very useful purpose, most users aren’t used to them and may believe that the data presented above the line is the only data available.
Forms aren’t the easiest of things to use for people with disabilities. Navigating around a page with written content is one thing, hopping between form fields and inputting information is another. Because of this, it is a good idea to add a number of elements to the form.
Each form field should have its own label. The label tag sorts this out, with a for attribute that associates it to a form element:
<form> <label for="yourName">Your Name</label> <input type="text" name="yourName" id="yourName" /> ...
Field sets and legends
You can group fields, for example name (first, last, middle, title etc.) or address (line 1, line 2, county, country, postal code, country etc.) using the fieldset tag.
Within the field set, you can set a legend with the legend tag.
Note: Visual browsers tend to represent field sets with a border surrounding them and legends breaking the left of the top border.
</pre> </div> <div> <form action="somescript.php" > <fieldset> <legend>Name</legend> <p>First name <input type="text" name="firstName" /></p> <p>Last name <input type="text" name="lastName" /></p> </fieldset> <fieldset> <legend>Address</legend> <p>Address <textarea name="address" ></textarea></p> <p>Postal code <input type="text" name="postcode" /></p> </fieldset> ...
The optgroup tag groups options in a select box. It requires a label attribute, the value of which is displayed as a non-selectable pseudo-heading preceding that group in the drop-down list of visual browsers.
<select name="country"> <optgroup label="Africa"> <option value="gam">Gambia</option> <option value="mad">Madagascar</option> <option value="nam">Namibia</option> </optgroup> <optgroup label="Europe"> <option value="fra">France</option> <option value="rus">Russia</option> <option value="uk">UK</option> </optgroup> <optgroup label="North America"> <option value="can">Canada</option> <option value="mex">Mexico</option> <option value="usa">USA</option> </optgroup> </select>
Like links, form fields (and field sets) need to be navigated to without the use of a pointing device, such as a mouse. The same methods used in links to make this task easier can be used on form elements – tab stops and access keys.
The accesskey and tabindex attribute can be added to the individual form tags such as input and also to legend tags.
<code><input type="text" name="firstName" <strong>accesskey="f" tabindex="1"</strong> />