Hackish Accessibility Techniques (10th April 2008)
In Accessible CMS Project, someone who evidently has some knowledge of the subject asks for review of the system they’ve created.
I notice lots of small issues. It strikes me that I see these issues a lot on websites by newcomers to accessibility. Then I realise it’s due to the culture of accessibility experts.
In Tables with form fields: am I crazy? Stephen Lang suggests using a correct and semantically rich data table with form controls in it. The table headers get associated with the table cells, as is normal. The idea is these associations are passed on to the controls when you’re filling them in with ATs.
This is obvious, isn’t it? After all, if you use a
<ul> or an
<img> in the cell you expect the table headers to work.
Steve Faulkner points out major screen readers don’t do this. He goes on to say this isn’t the AT vendor’s problem; it is the problem of every author. For each
<input> he proposes hiding a
<label> offscreen or adding a
This is met with cheers of approval from two other experts.
But I say it’s the AT at fault:
If a website provides good markup but a device doesn’t support it, the problem is in that device.
Steve disagrees. I provide code samples to make it clearer and explain how the structure is available from each. Steve accepts one of them which has complete table header markup and full-fat form labelling. He rejects the other two.
To a casual observer or someone new to accessibility, the certainty of stevefaulkner, brucelawson and dotjay probably makes me look like a crank. You leave with the impression that accessibility requires loads of complicated markup and repetitive information.
Anyone with a clue about accessiblity will realise this is exactly the wrong impression. These hackish accessibility techniques confuse people starting out with accessibility, resulting in less accessible websites.
Correct markup and calls for AT vendors to fix their bugs are drowned out or even snidely bashed. Super-duper markup tricks are what beginners leave each of these discussions with. Tricks so complicated only their inventor stands a chance of getting them right.
It leads to more broken markup and more repetitive text.
Hype Wins Again
Simply linking table header association with control labelling in ATs is dismissed as too much for anyone to implement. Yet ARIA is portrayed as the unquestionable and urgent solution.
ARIA requires complicated implementations of complicated specifications (which duplicate features already present in basic HTML4) into both UAs and ATs. How can that be the way forwards if simple improvements to form labelling aren’t?
I know for a fact that everyone involved is trying to do the right thing. But tabular forms using reams of
title without a
<th> in sight seem inevitable.
It’s just so sad that good ideas get drowned out by hype.