The Information and Relationships Success Criterion is a very complex requirement. Unlike other success criterion, it is not sufficient to comply with only one or two of the listed techniques – it is important to comply with all the relevant techniques. This means that this success criterion covers a wide range of requirements – in fact it covers many WCAG1 checkpoints, such as table headers, headings, coding lists etc.
Headings
Headings are a valuable way for people to navigate through content – either visually or through audio feedback via a screen reader. When dealing with a hundred page PDF, it is absolutely essential that a user can navigate via headings. Screen readers can pull out a list of headings, and this is a standard way for screen reader users to determine the content of a particular page without having to read through the entire text. Lack of support for this requirement in Adobe Reader was one of the reasons the Australian Government Information Management Office decided that PDFs were not accessible – because the two most common screen readers (JAWS and WindowEyes) did not identify headings consistently (for more information see my blog post on the results of the enquiry).
There is some controversy over headings. Some accessibility specialists say there should be only one H1 per page, others say multiple H1s are acceptable. In my opinion, it doesn’t really matter, as long as you are consistent across the site. However I do believe that each page should start with an H1, although there are some that believe the use of hidden headings in navigation (to indicate the start of a sub-section for instance) automatically preclude the use of an H1 at the beginning of the page.
Hidden headings in navigation are a very important issue and one I will be covering in a future article on Skip links.
Field Labels
Another important technique under Information and Relationships is the requirement for field labels. There are many clauses when it comes to fields and field labels, and I have consistently seen this technique implemented incorrectly. Time and time again I see fields without field labels. Often people refer to Technique H65, which allows for the use of the TITLE element but only when the label element cannot be used. Information and relationships does allow for the label to be hidden, however there is another Level A Success Criterion: Labels or instructions that requires the label to be visible. There are some exceptions to this rule which I will talk about in a future article on WCAG2 and forms.
Fieldsets
The requirement to use the FIELDSET element was a WCAG1 Level AA checkpoint. In WCAG2 this is now a Level A requirement. Assistive technologies have improved greatly in their interpretation of the FIELDSET element and it can now be relied on consistently to provide certain information – where previously headings were the preferred method of grouping field elements.
The FIELDSET element should always be used for radio buttons and checkboxes, where each item only makes sense in relation to an over-arching question, for example:
What is your favourite colour?
- Blue
- Green
- Purple
Each particular radio button field label (“Green”, “Blue” or “Purple”) does not make sense unless read out with the over-arching question which is “What is your favourite colour?” In this instance the three radio buttons should be contained within a FIELDSET element and this element should have a LEGEND of “What is your favourite colour?” And remember, if you use FIELDSET, you must always have an appropriate LEGEND.
Structural markup for tables
When I first started in the accessibility industry in 1998 there wasn’t a screen reader around that could read table headers. This was the reason for requiring that content made sense when read in a linear fashion in WCAG1. Screen readers have improved since then, and as result the need to code data tables is now mandatory. All data tables must use TH to identify table headers and TD to identify data cells. It is then a personal decision whether you want to use SCOPE or TH ID / TD HEADERS. For a simple data table it is often sufficient to just use the TH and TD elements.
WCAG2, however, goes beyond table headers. WCAG2 also requires the use of the SUMMARY and CAPTION element for data tables. Often these two elements are used interchangeably, but they actually mean very different things. The CAPTION element should only be a few words and is essentially the heading of the table, for example “Number of accessible web sites by industry”. The SUMMARY element provides a very high-level overview of the content and can be several lines, for example “Government web sites are most often accessible with 54% of web sites tested being accessible. Small business web sites are the least often accessible with only 3% of web sites tested being found accessible”. These figures are educated estimates, but I would say that in my experience these percentages are about right.
Lists of links
When on the W3C Working Group we did strive to replicate the accessibility techniques that people were using out in the real world. We knew that WCAG1 was past its use-by-date and that many accessibility specialists were coming up with their own requirements, and we included these techniques in WCAG2 when we thought they were valuable. Coding a set of links – such as navigation – using either OL, UL or DL was one of those techniques.
Q and BLOCKQUOTE
Hidden away in Technique G115: Using semantic elements to mark up structure, and Technique H49: Using semantic markup to mark emphasized or special text, is the requirement to use both the Q and BLOCKQUOTE elements to code speech. In WCAG1 this was a Level AA requirement. Techniques G115 and H49 are Level A techniques. I’m finding a lot of clients struggle with this requirement as there is often a lot of speech in their site, and finding and coding it can be time-consuming. Another problem is how the browser renders the Q element – sometimes a browser will add quotation marks and sometimes not, so it really requires some fancy CSS footwork.
And of course the WCAG1 requirement not to use BLOCKQUOTE to indent text still stands. Surprisingly I still come across this problem quite often.
What else?
With the Information and Relationships Success Criterion you need to be careful not to go overboard. For example, a very specific failure of this success criterion is using structural markup (TH, CAPTION, SUMMARY etc) for layout tables.
Another failure to keep aware of is the use of JavaScript to emulate a link. The use of ONCLICK is allowed (although I’ll be writing a future article on JavaScript and accessibility), but only in conjunction with the A HREF and AREA elements.
These are my interpretations of the Information and Relationships Success Criterion, but I’d be happy to hear your own!
Gian WildGian Wild has been working in accessibility since 1998. She worked on the very first Australian accessible web site and was the accessibility consultant for the Melbourne 2006 Commonwealth Games. For six years she was actively involved in the W3C Web Content Accessibility Guidelines Working Group. Gian Wild is the Director of AccessibilityOz.
