Accessites.org
Specifications, Standards, Guidelines and Recommendations

Don’t be a slave to a standard.

By now, web standards should be something we are all used to. We can validate page markup against the Extensible HyperText Markup Language (XHTML) and HyperText Markup Language (HTML) specification documents. We can check style sheets against the Cascading Style Sheet (CSS) specifications.

Then there are guidelines…

There are international guidelines such as the Web Content Accessibility Guidelines 1.0 (WCAG 1.0), for example, (and WCAG 2.0 is due shortly). There are also national/regional guidelines — such as the UK Government’s Illustrated Handbook for Web Management Teams.

Then there are Best Practice Recommendations — techniques or approaches that are considered to be superior to other known methods of achieving a given end. We’ve posted a few suggestions on Accessites ourselves.

• Keyboard-Friendly Link Focus
• Making a Font Selector
• Dealing with Acronyms & Abbreviations

…to name but a few.

So there’s certainly plenty of documentation around to support anyone who is new to accessible web design — provided all of the standards, guidelines and best practice recommendations agree with one another. But, as you may probably have noticed, they don’t. Nor should we really be too surprised by this. This doesn’t imply any failure on the part of the the standards. Or the guideline authors. It simply reflects that we are working in a very rapidly evolving technology and that documentation can sometimes struggle to keep up with emerging trends and new developments.

The Standards

When was the last time you noticed just how old some of the specification documents are? The HTML 4.01 Specification celebrates it’s 9th birthday later this year whilst the revised edition of the XHTML 1.0 Specification is 8 years old having been originally published in January 2000. In “web years,” both of those documents are pretty long in the tooth. For the most part, however, they are still highly relevant today and, if followed, still represent the best method of ensuring effective markup performance across the greatest number of user agents. But, on very rare occasions, they do seem to run contrary to reality.

Now, before you throw your hands up in horror at the very idea that the specification documents could be “wrong,” let me explain using an example: embedding video clips in a page.

The correct method of achieving this, according to the specification documents is to use object. However, in practice, support for the object element is patchy and unreliable across the different browsers — most importantly in Internet Explorer (IE). The only reliable approach (and the current best practice recommendation) is to use embed which as Joe Clark rightly points out, isn’t “real HTML” at all as it was never ratified by inclusion in any formal World Wide Web Consortium (W3C) specification.

So what do you do? Follow the specifications come what may, use object and decide it’s a browser problem? Or do you use embed on the grounds that it offers the most accessible solution but on the understanding that you just invalidated your page?

Cue the Guidelines…

WCAG 1.0 doesn’t mention the embed element itself but does state that embedded objects must be accessible. Given that support for object is patchy, that seems to be one vote for embed. However, the supporting document HTML Techniques for Web Content Accessibility Guidelines 1.0 only mentions object when providing examples of accessible markup, so it would seem that WCAG 1.0 is adopting the same stance as the standards and ignoring embed completely.

So now we seem to have a consensus — except we don’t…

The current (and probably the final) draft of WCAG 2.0 specifically authorises the use of the embed element — even though it also mentions that embed is not a valid part of HTML.

So what is the current score with regard to embedding objects in pages?

• W3C Specification: Use object
• WCAG 2.0: Use embed
• Best practice recommendations: Use embed

Confused yet?

Best Practice Recommendations

This type of contradiction isn’t an isolated event either. Let’s look at another guideline: the UK Government’s Illustrated Handbook for Web Management Teams and the advice it gives with regard to setting access keys. In attempt to introduce some conformity into an area where the W3C has not previously given any clear advice, the Handbook states:

When a user visits your department’s website for the first time they bring their collective experience gained from all other sites. It is, therefore, important that UK Government Websites adopt a constant accesskeys standard. Variations from this will make it more difficult for users as they have to learn new navigational skills each time.

Listed below is the recommended UK Government accesskeys standard:

• S - Skip navigation
• 1 - Home page
• 2 - What’s new
• 3 - Site map
• 4 - Search
• 5 - Frequently Asked Questions (FAQ)
• 6 - Help
• 7 - Complaints procedure
• 8 - Terms and conditions
• 9 - Feedback form
• 0 - Access key details

— UK Government’s Illustrated Handbook for Web Management Teams

Spot the problem? Using S could create significant shortcut conflicts for some users.

The Shaw Trust — who have an experienced team of pan-disability testers — issue the following advice:

When using accesses keys there may be an issue with using letters as shortcuts instead of numbers – this may override a native feature of some browsers and assistive technologies. We advise that only numerical keys are used. — Shaw Trust

The Royal National Institute of Blind People (RNIB) who are long time advocates of web accessibility state:

Only use numbers if access keys are to be used. — RNIB

The problem we have here is that a published national standard (insofar as the Illustrated Handbook is a standard) differs from the best practice recommendations made by organisations in the same country. So that leaves us in a position of having to choose between a national standard or best practice advice.

What is a developer to do in the midst of all of this potentially conflicting information?

Personally, I’d argue that best practice recommendations should take priority — especially in a situation where a “standard” or specification is older or hasn’t been updated for a while. Best practice solutions are based on experience in the real world and, whilst I’d agree that we should be very wary of pandering to browser shortcomings, we do, presumably, want to extend accessibility to as many users as possible. So it makes sense to take serious note of any approach that has been tested in the wild.

By now, it probably sounds as if we’re playing some sort of Top Trumps game here and my Best Practice beats your Standard but I think that these are situations where developers do need to make their own judgment calls. However you do need to take care where you look for best practice recommendations. There’s as much bad advice out there as there is good.

• Don’t rely on a single source for advice (not even Accessites).
• Seek out differing opinions using resources such as the Accessify forum.
• Compare and contrast different approaches.
• Play Devil’s Advocate and look for potential problems in any so-called ideal solution.
• Accept that there may be no single Right Way.

Finally, make up your own mind. By now, if you’ve looked at and considered all of the options, you’ll almost certainly have arrived at the best solution for you. Don’t be a slave to a standard. Following a standard simply because it is a standard isn’t enough. That kind of single-minded approach can create more problems than it cures.

Filed under Our Articles — Subscribe, Trackback,

Bookmarking Links » del.icio.us | Digg | blogmarks | Ma.gnolia | StumbleUpon | Technorati | Help |

These posts may be related:

Introducing the PWAG »

Under Construction »

Does Accessibility Cost More? »