Accessible xhtml tables 1: scope, id, headers

I haven’t had much call for creating hard core data table in my websites as most of the web work I do is promotional websites for companies in the tourism and leisure industry. However when asked to re-write some xhtml for an online bookings system I found some of the information generated seemed to lend itself to tabular organisation.

So I started to wonder if my limited knowledge of tables and table headers <th> was enough to make my tables accessible. Would I need to use <tbody> for instance. Is it necessary to use the scope attribute in the <th> element? What is the difference between a summary and a caption?

As it happened I decided that using a table for the data in question wasn’t the most semantic choice, but my appetite whetted, I thought I better brush up my table knowledge… just in case!

How do screen readers access tables?

Bim’s article on the RNIB website (Better Connected, Better Results: Table Headers) has got a great description of a screen reader user trying to navigate a table with no table header or <th> elements. Quite a task involving guessing which table cells hold the key heading information then trying to remember where you are the table and probably doing quite a bit of scrolling back and forth to work out what a particular piece of data represents.

She then goes on to explain how much easier it is when key information is coded as <th> instead of as <td>. When scrolling down a column, the row headers are announced together with the data. And to check which column you are in, instead of scrolling back to check, a keystroke will prompt Jaws to announce the column heading information. Although by default Jaws announces the row header and on a key stroke announces the column header, other screen readers may act differently.

So is <th> enough?


Do we need to include the attribute scope? I guess it would depend on the type and complexity of data you had to describe. If your table headers happened to be on the second row or second column for instance, it might be unclear as to which data the header described. With scope you can be certain.

What does the WCAG2 say about scope?

Scope can be an attribute of a table cell <td> or header <th>. Its values ‘row’ and ‘col’ (or ‘rowgroup’ and ‘colgroup’ see below) says whether the cell describes a row or a column.

Because the presence of the scope attribute implies the data in that cell is heading data, WCAG2 says you are allowed to use it in both data cells td or header cells th. However its suggested use is for data cells marked up with td that are actually header cells (although I’m not sure why you don’t just use th in this case … )

WCAG2 link: H63: Using the scope attribute to associate header cells and data cells in data tables

Note: The ‘rowgroup’ or ‘colgroup’ attributes are used to say if the header data describes groups of rows <thead>, <tfoot> and <tbody> element, or groups of columns <colgroup> element. See the w3c sample table, more info on rowgroup and more info on colgroup

Id, axis and header attributes

Scope isn’t consistently supported across screen reader technology apparently. So for more complex tables, a more robust alternative to scope is to use the ‘id’ attribute of a <th> and ‘headers’ attribute of a <td> to directly link a data cell to its header. The ‘axis’ attribute also allows you to give more information about your headers e.g time, location, weight, colour. It also allows you to style the table to make the info easier to understand.

Holistic healing work shop example

Dining Room Morning Room Blue Room The Orangery
Mon Flower arranging Origami Crystal healing Pottery
Tues Egg decorating Water colours Reflexology Yogurt weaving

<th id="dining" axis="venue">
Dining Room </th>
<th id="morning" axis="venue">
Morning Room </th>
<th id="blue" axis="venue">
Blue Room </th>
<th id="orange" axis="venue">
The Orangery </th></tr>
<th id="mon" axis="day">
Mon </th>
<td headers="dining mon">
Flower arranging </td>
<td headers="morning mon">
Origami </td>
<td headers="blue mon">
Crystal healing </td>
<td headers="orange mon">
Pottery </td>
<th id="tues" axis="day">
Tues </th>
<td headers="dining tues">
Egg decorating </td>
<td headers="morning tues">
Water colours </td>
<td headers="blue tues">
Reflexology </td>
<td headers="orange tues">
Yogurt weaving </td></tr>

What does the WCAG2 say?

If a table data cell has more than one header associated with it (e.g a row header and column header), it must have a headers attribute that lists all of the ids of the associated headers. Thus each header cell must have a unique id.

WCAG2 link: H43: Using id and headers attributes to associate data cells with header cells in data tables

Next up Captions and Summaries!

Pobol Peblig website gets accessibility standard

I’m very pleased to announce that the bilingual Pobol Peblig Partnership website has been awarded the RNIB’s (Royal National Institute of the Blind) See It Right standard for web accessibility. For more information on See It Right, other audits and web accessibility visit the RNIB Web Access Centre.

Our experience of the See It Right auditing process was very positive. It challenged our perceived understanding of web accessibility and allowed us to create a fully accessible solution for our client. The following is an overview of our See It Right experience with some examples of issues we faced and how we solved them.


Pobol Peblig Partnership is a Communities First project in Caernarfon North Wales. Communities First is a WAG program to help and support to the most disadvantages areas in the country. Peblig ward lies in the top 10% of the poorest in the country and is eligible for Communities First support. Tai Eryri has been running the project for 7 years.

The main emphasis of the project is capacity building; building skills, experience, knowledge and confidence of the community members, allowing all developments to be community led. The website reflects this dynamic by playing an important role in communication between volunteers, publicity of events, meetings and activities, sharing resources and ideas.

The Pobol Peblig website was built by Chris Slinn of Free Range Developers and Kate Watkiss Interactive Design. More background information on the Pobol Peblig web build.

Choosing See It Right

Having previously undergone staff development training with the RNIB. The Pobol Peblig staff decided that the new website would benefit from RNIB’s web auditing process.

As we were in the relatively early stages of building the site, we were advised to go for the See It Right development audit. This audit guides the web development process to ensure that the finished site is accessible. The development audit also allowed us to continue building the site as normal and once the first check was done and the solutions implemented, we were able to apply the same rationale to the continuing build.

Audit Process

The auditor goes through the site checkpoint by checkpoint. When examples of failures are found, they are reported, together with the URL, code snippets and a clear explanation of why they have failed and the impact on users. The report gives a comprehensive set of instructions, telling you exactly what to do to make the site accessible and why.

The emphasis on how the issues impact on the user makes the report more that just a set of corrections. Not only does it explain how to make the current pages accessible but it also provides a framework to enable the designer to evaluate problems in the future, helping with decisions on how to tackle issues from functionality to design and layout.

We had 2 rechecks after the initial assessment. And at the end of the last recheck we had an informal email exchange with our auditor, Bim Egan, giving us the chance to tie up a few loose ends (thanks Bim!). The rechecks allowed us to address unresolved issues from the first report and assessed new issues that had arisen during the build.

Throughout the process Bim was available to answer questions. The answers were comprehensive and relevant to the site’s specific problems. If we had reasons for not wanting to implement suggested solutions these reasons were listened to and we managed to reach a solution which was agreeable to everyone.

Issues with our CMS

When the first report came back we were well on the way with the construction of the site and had started to populate it with content.

We’d chosen to use Joomla as it has a quick learning curve for the web authors. This was an important consideration as the staff at Ty Peblig would be taking over the website updates and management. And from the development point of view, Joomla also has the added advantage of a variety of open source plugins from the Joomla development community. We chose to extend the basic functionality with plugins such as the calendar and comment modules.

The CMS and plugins generate html code snippets for menus, and other content modules and components, which slot into the site templates. By working on the site templates we were able to make the overall structure of the page accessible. Once the changes to the site templates were made we were ready to look at the generated code.

There is a strong relationship between accessibility and web standard compliance. If your site meets web standards you are well on the way to being accessible. Good quality code means your site is easily transported to different user agents and technologies. The various Joomla plugins on offer deliver a wide range of functionality, however there are also wide differences in the quality of code generated. The failed code had to be identified and then modified according to the See It Right report.

Other issues we faced related to the way Joomla dictated how information was organised. We found some code blocks were generated that didn’t make sense semantically when applied to our content. However Joomla was flexible enough to allow us to ‘shoe horn’ our content into the system and generate semantic and accessible pages that we could easily style up.

Layout and Semantic Content

For various physical and technical reasons a number of people use the keyboard tab key to navigate through web pages. The order of the code and the layout of information on the page should be such that the tab order is logical, and focus moves smoothly across the page without jumping back and forward.

In our original design we put a search and contact link on the top right of the page. We’d positioned them here partly to conform to convention and partly in order to visually balance the page elements. Since we had implemented a logical code order in our page, positioning the tools to match our conventional layout moved the tools out of the flow of the document. This caused problems with the tab order.

The expected tab order would be to tab left to right through the section links at the top and then through the tools (search, contact etc) at the top right. BUT we also had a context menu down the left. Logically, the context menu came after the section menu in the code. So after tabbing through the top section menu and down the context menu on the left, the focus jumped back up to the top to get to the tools.

Following the advice given, we repositioned the tools to fit under the contextual menu allowing the tab order to move logically across the page. Moving the tools down also provided extra space across the top of the page so the user could increase section link text size without the text overlapping.

Bilingual Content

The Pobol Peblig Partnership website is a fully bilingual website complying with Welsh Assembly Guideline: Publically funded projects in Wales must provide all public communications in both English and Welsh. Because the first language of most of the Peblig residents is Welsh this is a very real, practical requirement.

Coding language changes

Language implementation has a particular impact on screen reader users. When the language of a page changes, it must be coded so the screen reader software can select the appropriate language with which to read the page. It is the ‘lang’ attribute that tells the screen reader what language to use.

The language of an entire page is coded in the ‘lang’ attribute of the html element which surrounds the entire page content and meta information. This means if lang=’cy’ every text string that will be read by a human must be in Welsh, and conversely, if lang=’en’, human read text must be in English. If text occurs in this page of a different language to the page overall language, it must be coded.

We used a language switcher, so there is both an English version and a Welsh version of each page. As the site is dynamic and regularly updated we needed to make sure all articles were translated, if no translation was available there would be a line of text explaining a translation was on its way. As it happens the staff have been entering Welsh and English text at the same time so this hasn’t really been a problem.

How to code everyday Welsh

The main problematic issue was the implementation of ‘bilingual’ project titles and organisation names.

The way the Welsh language is developing, as those living in Wales will know, means that words are being incorporated in everyday Welsh (and English) that are hybrids of Welsh and English. Some of the projects use regional slang Welsh for the project names and these names are used whether the residents are speaking Welsh or English.

An example is the walking project ‘Miglo’. Miglo is a ‘cofi’ word which means escape (or ‘dianc’ in Welsh). Miglo is used in both Welsh and English conversations. Another example is the sex education project ‘Jiwsi’ run by the FPA (Family Planning Association). The name ‘Jiwsi’ is a welsh spelling of the English word juicy.

In both these examples the title can be considered bilingual and can be used in both the English and Welsh pages. In other instances, because our residents only used the welsh project names anyway it was harder to establish if these were really bilingual names.

We approached Bim with this problem who returned with this very practical advice: Ask the question ‘would English speakers refer to the project or organisation with its English name?’, if not, use an English translation followed by the Welsh name, if they would, just use the English name.

Training and Accessibility

As our website is a communication tool for Pobol Peblig and they are in the process of taking over the management it was very important that the staff also understand about web accessibility, the impact it has on users and how to make sure new content they put in is accessible.

The clear explanations and solutions given in the audit have allowed us to easily create training material and give practical advice during the handover period. The staff now have a broad understanding of why websites need to be accessible and the types of usability issues that need to be addressed. We have also covered how to make sure the Pobol Peblig website remains accessible. Ongoing website update training will reinforce the specific accessibility issues as they come up.

Building an Accessible Website: RNIB See it Right

A website I’ve just been working on (Pobol Peblig Partnership) is currently being audited by the RNIB under the RNIB See it Right accessibility standard. This article covers some of the things we learned through the audit process, with background information to help understand how to approach building accessible sites and then gives some practical tips and things to remember.

Who are your visitors?

Your website visitors are likely to be a diverse group of individuals with different levels of experience, using a variety of different web browsing technologies as well as having a range of needs and preferences. Someone who is partially sighted, for example, may have difficulty viewing a particular webpage but increasing the text size will allow them to read it. A visitor with a slow internet connection may decide to turn off the images to make download times quicker.

Note: Mark Pilgrim introduces us to a diverse bunch of internet users who use the net in a variety of ways in his excellent download Dive into Accessiblity.

What are they using to view your site?

There are different assistive technologies out there to help you if you have particular browsing needs such as screen readers, brail displays or alternative user input devices. Many of these work along side a visual browser. Alternatively you may prefer not to use additional assistive technologies but instead, tailor your visual browser to meet your particular requirements. Or do a bit of both.

The key thing to remember is that users have found their own way to do things based on the technology they use, practical necessity and personal preference. As web designers, who are we to tell our users what to do? An interesting piece anecdotal evidence that illustrates this, relates to website keyboard shortcuts or “access keys”. Although aimed at users with motor difficulties, apparently the majority of users who use access keys are actually web developers who routinely use keyboard commands in their day to day jobs.

Although including access keys is necessary for WAI priority 3 compliance, there are issues with its use and it is not required for See It Right. For more info read the RNIB’s article on access keys.

Anyway, to give your visitors the potential to have the best experience possible, whatever their browsing needs or preferences, your web design must be as robust as possible, allowing for text and colour change and able to be viewed with images turned off both with or without css styles. You should also be able to use your website without scripting or plugins. This is known as graceful degradation which means the same thing today as it did in 2002 when Peter-Paul Koch suggested:

The first step in adapting [graceful degradation] successfully is fluid thinking: accepting the unpredictability that rules the user interface of the Web.

See It Right

Although our design ticked quite a few of the accessibility boxes, we missed the mark on a number of points. Although we were thinking about accessibility from the beginning of the build, our main error was to follow our perceived wisdom as web developers/designers rather than thinking first and foremost about how the site would be used.

Bim Egan who did the audit for us was extremely helpful and her explanations were clear, and solutions offered, logical and practical. The common thread through all the different solutions we implemented was “empathise with your users”. Read more about how See It Right can benefit your visitors.

The following tips are not a how to or check list but just a few of the key issues we tackled during the audit.

Text size and positioning

You should be able to increase and decrease text size by 3 times without any text being obscured. This can be a challenge when absolute positioning has been employed and elements have been pulled out of the flow of the document.

However, by using a combination of relative (em) and absolute (px) units for position, dimensions, margin and padding, most layout designs can display at 3x decrease and 3x increase. If it isn’t possible you may need to rethink the way you’ve implemented your layout. That’s the last thing you want to do at the end of a build so its a good idea therefore to test that 3x text size increase and decrease (in different browsers) from the beginning.

Alt text

Alt text can do more harm than good. Badly written alt text can be confusing and make a passage of text difficult to understand. Use an empty alt attribute on purely decorative images.

How do I decide if an image is purely decorative? Well, ask your self if the meaning of a document can be fully understood by reading the text. If so, the image could be considered decorative as the text provides enough explanation for the meaning to be expressed. For users with images turned on in their browsers the meaning may be enhanced by a decorative image. But for a user browsing without images, the use of an ill considered piece of alt text can be very confusing. We were given the following advice in the audit

It might be pertinent to consider all content images decorative, unless they are linked images, images of text, or convey real information that helps to make sense of adjacent text.

You may decide that alt text is needed to give your page equal meaning to those browsing without images or those who find it difficult to see images. If you do, check how the alt text ‘reads’ in the context of the rest of the copy.

The key is to ensure that ALT text is given to images that convey content or bring meaning to a page. Using null ALT text for other images prevents the user experience becoming cluttered with redundant information for a screen reader user. Web Access Centre


The following examples from the audit show how alt text can be confusing for screen reader users:

… the image “Ty-Cymunedol.jpg” immediately below the question “What is the Pobol Peblig Partnership?”, audibly follows with the information from the ALT attribute “outside Tyˆ Peblig”.

In another example on the same page, the question, ” Who is the Partnership?, the image ALT appears to answer “2 Peblig Pensioners”

The Audit goes on to say:

Ideally, ALT attribute text should not appear to be a change of subject, interrupt reading flow, nor be misleading

When images are used as links

Functional images such as links use a combination of plain text and alt attribute to make the meaning of these non-text elements clear to text only browsers and screen readers. Read the link text plus alt attribute to check they make sense. Remember screen readers can’t just ignore links, and will announce the file path to the image, when there is no text available.

Our helper links to ‘print page”, “download pdf’ or ‘email to a friend’ used the following images pdf, print, email, with respective alt attributes: PDF, Print, E-mail. The problem with this code was that users without a mouse wouldn’t get a tool tip and, if they hadn’t seen the icons before or couldn’t see very well, the purpose of the links would be unclear.

The solution was to include link text (PDF, Print, E-mail) next to the image then add the following alt attributes

  • “pdf_button.gif”: ” version of this page: (new window).”
  • “printButton.gif”: ” of this page : (new window).”
  • “emailButton.gif: ” to a friend: (new window).”.

The end result will be three links, announced by screen readers as:

  • “PDF version of this page: (new window).”
  • “Print version of this page: (new window).”
  • “E-mail to a friend: (new window).”

pdf, print, email

The right tool for the job (or the riddle of the nested lists)

Inspired by Andy Clark’s book Transcending CSS I tried to make sure my site template had a meaningful order underlying the page organisation and attempted to make the most of the xhml elements available. During this process I decided to use unordered lists to create a structure within my document. For example I created a list to hold supplementary information which highlighted features in the rest of the site. I used css to display the list as a colourful side bar. This is the xhtml I used:

<ul> <li class="supp1"> <h3>Next Meeting</h3><p><a href="">18.06.2007 Ty Pobl Peblig</p></li>
<li class="supp2">
<h3>Get Organised</h3><p><a href="">Resources pages</a></p></li>

<li class="supp3">
<h3>Reports</h3><p>The partnership is drawing up reports</p></li>


Unfortunately I hadn’t taken into account the complexity of the content of each box. Some of the feature boxes contained lists of events or related projects, some contained archive links or project summaries. So my sidebar list items were expanding as the website was populated

Lists are used to describe a group of objects or bits of information that are similar in some way. It might also be useful to have a preceding header to describe the list. . A website user will use bullet points and the header to quickly get information about a list and the items within it. A screen reader user will receive the same information, but by listening to the information being read out.

Here is an example of a simple list of events being read out by a screen reader:

  • What’s on?
  • List of 4 items
  • bullet SBARC!
  • bullet Arts & Craft
  • bullet SBARC!
  • bullet Storm O Stori Calan Gaeaf
  • list end

Unfortunately this simple list was nested inside my supplementary list, so if you are listening to a screen reader to access this page you will hear:

  • What’s on?
  • List of 4 items nesting level 1 (contains 4 nested lists)
  • bullet List of 1 items nesting level 2
  • bullet SBARC!list end nesting level 2
  • bullet List of 1 items nesting level 2
  • bullet Arts & Craftlist end nesting level 2
  • bullet List of 1 items nesting level 2
  • bullet SBARC!list end nesting level 2
  • bullet List of 1 items nesting level 2
  • bullet Storm O Stori Calan Gaeaflist end nesting level 2
  • list end nesting level 1

It may sometimes be useful to code headings inside lists item content. However it is worth remembering headings also provides extra wordage in a screen reader which can add to confusion rather than enhance meaning. As it would probably be stretching the useage of a list to use it as a structural element, I will be using it in the future with more caution!

Semantic Flow and Tab Index

It’s important that the content in a document makes sense without css style information to guide the user around the page.

Equally when style information is being used to position elements on the page the order should still be logical. In other words the focus should move in a consistent, regular manner and not hop back and forward when tabbing through the document.

Although we’d carefully planned the semantic flow throughout the document, the way we’d positioned some of the elements on the page meant a jump across the page while tabbing through. When we fixed this by repositioning some of the elements, the page actually worked better visually, as well as allowing a logical tab order through tabbed elements on the page.

Remember if your page content is organised logically there is no need to use tab index and often, if tab index is used inconsistently resulting in an illogical tab order, it can be confusing and obstructive.

Validation, validation, validation!

… And finally if you validate your code, both xhtml and css, you are probably well on the way to being accessible without even trying!