Before being accused of blasphemy, let me explain. It’s my view that some HTML attributes, or techniques designed to improve accessibility, are often over-used or over-helpfully chosen, resulting in content that is less, rather than more, accessible.
Perhaps this over-egging of the pudding stems from web authors being unaware of how disabled users interact with their web sites. Or perhaps they don’t fully understand what the techniques achieve and how they function. Either way, it’s an awful waste to have such good intentions so badly misdirected.
As a user of two different screen readers as well as screen magnification, and being a regular user of keyboard commands for navigation, I’ve a vested interest in casting light on this knotty subject. So let’s point a glaring spotlight on some of the ways that functional inaccessibility can result from misuse of, what should be, accessibility-enhancing techniques.
Each of the culprit techniques or attributes will get it’s own blog article. Choose from:
- ACCESSKEYS.
- TABINDEX.
- FIELDSET LEGENDS.
- Multiple JavaScript event handlers
- TITLE attributes
- Double expanded acronyms
If you’ve got a favourite, or least favourite, technique that needs a little light shed on it, get your torch out and add it to the list.
To originate an article, just e-mail it to:
bim.egan@rnib.org.uk
with “too much accessibility article” as the subject line, and I’ll post it with a link back to you.
patrick h. lauke | 13/09/2006 at 22:38 | Permalink
* completely redundant title attributes on links that just reiterate link text, and even worse put “click here” or “link to” in there
* table summaries that explain how many rows/columns are in the table…this is the job of the AT to expose to the user, i’d say
* well meant, but useless, ALT attributes on those pesky stock photography type images that are nothing but visual fluff; yes, they visually convey a certain mood or whatever…but i’d argue that this mood should also come through in the written copy of a site, thus not seeing the image doesn’t mean that the character (quirky? serious?) is lost
* tabindex where natural control of flow through markup order is far more appropriate
* overuse of fieldset and legend to put around a single form element, rather than a set of checkboxes etc
completely unrelated, but: as with every darned wordpress install, the tab order of your comment form here is quirky…”message” should come after “website”, but doesn’t…
JackP | 14/09/2006 at 9:55 | Permalink
I’m surprised no-one’s yet mentioned that old favourite:
* Text only pages
* target=”_blank” (in general)
* Advising that clicking on an email address may launch an email application ‘in a new window’
* non-link | characters | between | links | when | you | could | just | mark | them | up | as | an | inline | list
Then we’ve got
* Alt attributes that begin “a picture of…”
* Including accesskeys but using display:none so they don’t get in the way
* summary=”layout table”
* not knowing what the difference is between a server and client side image map, and producing redundant text links for virtually everything
And the last two are more attitudes than features, but nonetheless…
* people who don’t realise that certain “until user agents…” clauses have now been met
* anyone that tells me to “upgrade to a new browser” simply because I’ve switched javascript or css off
bruce | 14/09/2006 at 15:44 | Permalink
Can we have a parallel series called “not enough accessibility” which looks at how JAWs and its rivals fail with useful bits of html?
Bim | 15/09/2006 at 9:52 | Permalink
Many thanks to all for useful and valid comments, some of the points raised by Patrick and Jack are already in the plan for the series, including:
* Unnecessary summaries and captions in layout tables
* How TABINDEX can make nonsense of the tab order,
* The craziness that too often results from using TITLE attributes.
The other issues raised can be added to the “to do” list, but if you want to originate an article, just e-mail it to
bim.egan@rnib.org.uk
use “too much accessibility article” as the subject line and I’ll post it with a link back to you.
Bruce’s comment’s could spark another illuminating series, got any examples to start it off please Bruce?
bruce | 15/09/2006 at 11:04 | Permalink
I’m told that the gives “too much information”; and don’t seem terribly well supported by screenreaders …
bruce | 15/09/2006 at 11:05 | Permalink
Ooops - it ate my code examples:
I’m told that
dlgives “too much information”; andinsanddeldon’t seem terribly well supported by screenreaders …Bim | 15/09/2006 at 11:41 | Permalink
Yes, it’s true that DL often gives information overload, not sure about support for INS and DEL, but will check it out. In fact as support for the TITLE attribute is so variable across different browsers and assistive software, it might apply to both “too much” and “too little”.
You’re right, it really would make a good series. It’s on the list. Thanks.
Seb Crump | 19/09/2006 at 12:59 | Permalink
I agree with all thosse suggested above. I’d add:
* Overuse of Accronym/Abbreviation tags - not every instance of an accronym needs to be marked up, but it’s common to see the same accronym marked up several times in consecutive (or even within a single) sentence(s), just adding to clutter.
* ‘Accessibility features’ that are provided in an inaccessible way, e.g. text resize that relies on JavaScript.
Web Access Centre Blog :: Hidden barriers to accessibility | 30/07/2007 at 8:27 | Permalink
[…] Rather like “Too much accessibility“, this series will grow with time, and your suggestions for additional topics is welcome. […]