Baaaad accessibility
Accessibility is a hotly debated issue. Everybody seems to know, and feel the need to defend with a fiery zealotry, the answers and by answers I mean “myths”. Either it’s the myth that accessibility is expensive or hard to implement, or the particularly insidious myth that it stifles creativity. Those are usually popular amongst clients and managers. (We always wish they’d listen to us, right up to the point that they do. Don’t we?)
Then there’s the myths told and re-told by us; the actual developers and designers.
I spent a delightful few hours using Google to dig up accessibility debates, articles and guidelines. I learned a few things I think are interesting:
We all seem to ‘know our stuff’ but most sources referenced or quoted are, in fact, blogs expounding popular opinion and interpreting the WCAG guidelines with varying degrees of understanding.
The first few pages of results all were the same three articles, reposted or referenced. The names changed, but the third time I saw the exact same phrase in the exact same place it became clear that accessibility advocates are probably the universal masters of plagiarism.
No one cited research or explained research methods, apart from Jacob Nielsen. It should not be surprising that Nielsen sometimes reaches conclusions that are contradictory to what ‘the industry’ holds true.
I am not going to reproduce the ‘myths’ other people so clearly debunked in three pages of Google results. (After which I gave up.) If they are even still myths, I would simply be adding to the deluge of top-ten-lists.
I recently let myself get dragged in a debate about accessibility with a rather uncouth person who employed the age-old method of repetition ad-nauseam to get me to see ‘reason’.
He provided me with seven links to support his opinions. One pointed to the W3C (whose recommendation he had misinterpreted), the rest to ‘authoritative’ blogs, all parroting each other. In the end I had to cut the debate short before I broke my own SNAFU rule.
It got me thinking though; what rules do I know that are blatantly wrong? Which myths have I propagated in the past? Well, I could think of only a few but a very significant few.
So, without further ado, here they are:
I know, because…
The main accessibility myth is the myth of the fabled accessibility expert. There are many companies offering accessibility advice. Most of them suck. The main reason for this is that they are following the trend, badly usually. Most of them simply interpret the basic rules and give websites an once-over with the whitewash of token changes. They do not do research, they barely if at all keep up-to-date and most of them orate from behind their desk without ever seeing an actual disabled user or trying the latest screen reader.
Oh, and they hang around on mailing lists, sometimes even run them, debating with each other about the latest holy commandment of WCAG.
What they do not do is think about the issues and try to solve real world problems. If it isn’t in the WCAG, it doesn’t exist.
The problem with the WCAG, although it is getting better, is that a small sub-set of vocal special interests groups have hijacked the issue. People with less well-represented disabilities often find themselves underrepresented, or ignored. The problem is compounded by the fact that often what is good for one is bad for the other.
Slavishly following the rules means walking on the leash of a very small part of the entire community. I will go so far as to say that most of these ‘experts’ make matters worse rather than better. I don’t know how to remedy this. I just hope common sense will prevail at some point.
The W3C says…
Continuing my train of thought from the station visited above, I arrive at the near sectarian following of the W3C. Don’t misunderstand me; I say my hail-W3C’s every night before I go to bed. It is good to remember, though, that the W3C is a very loose conglomerate of working groups. While the more common specifications are quite good, they do screw up. Even when they don’t screw up, they are human too and need time to adapt to new circumstances and insights. No word is Gospel, but the Gospel. (If you lean that way.) One of my more recent sites, for example, doesn’t validate because I followed a recent accessibility guideline. It’s a W3C recommendation, even. The validator simply doesn’t know about it yet.
Minority report
When debating accessibility, people tend to focus on the well-known minorities; the non-sighted, the reading impaired… as if fixing things for those groups is all there is. Accessibility is for everyone. Pretty near all of us have some issues. Some of us need glasses; others are dyslexic or non-native speakers. Accessibility is about making your website pleasant to use for everybody, not just the blind or the otherwise ‘visibly’ impaired.
Inversely, what accessibility is not about is catering to even the smallest minority. If this were the case we’d have to go out and read, sometimes sign, the content of our sites to each and every visitor. It’s a process of eliminating issues for a progressively smaller number of users until you run out of options, leeway from the client or budget. You can’t please everybody and trying to do so will invariably lead to you not being able to please anybody. At best because someone takes away your computer before you hurt someone with it.
For example: A large number of blind people can’t read Braille. A smaller portion of those is deaf, too. Try to solve that. You’ll wind up spending a portion of your budget inversely great to the size of the minority you are trying to provide for.
At some point you have to quit, decide that some people are simply screwed, and move on. This may sound harsh, but realise that there comes a point where you stop being considerate and start being foolish and condescending. People with multiple and compound disabilities have (or should have) a support system. Save your sanity and job, pragmatism is no sin.
Font size
Here we were, thinking we were slowly getting rid of the major cross-browser issues, and up one pops. And a major one it is.
This brings us back to the debate I mentioned earlier. My opponent was absolutely right in one regard: My website (this site) is ‘broken’ in the sense that I used fixed values for font sizes.
There is some good reasoning behind the WCAG guideline that states that all your text should scale. I agree completely. Users with limited sight need to be able to make text bigger, or smaller. Yet I ‘broke’ this functionality.
Well, for starters I only ‘broke’ this in IE. You can scale my text just fine in any other browser, as far as I’m aware.
I believe the Microsoft take on this issue is completely wrong, and so is that of most designers. (Who either use fixed values because they are trying to emulate print, or use variable values based on the erroneous assumption that the local user knows best.)
I’m still debating with myself whether I should cave to Microsoft’s bad implementation of the standards or stick to my guns.
Here’s the thing; sane browsers scale text when the user wants them to, regardless of how they have been set in the CSS. (Points, pixels, Em, etc.) Microsoft’s IE only scales when the font size has been defined with a “variable” unit. (Em, percentage.)
Here is my standpoint:
Using any variable size on text, barring pixel which, in itself is variable too, is bad accessibility and should be abandoned. A variable unit needs to take its base value from somewhere and there is no way of being sure what this “somewhere” is. Usually this will be some, more or less, arbitrary default font-size imposed by the browser or the OS.
Commonly it will be something like 16 to 18 pixels, but I have seen laptops with really weird settings, Linux installs with ludicrously small default font sizes and don’t get me started on mobile devices.
So, if you base your font size off of that, you have no way of telling what the user will get.
Users have gotten used to, for better or for worse, the website taking care of the font size. When a site does things ‘right’ and on their system this results in unreadable text, they will blame the site, or the computer. They will not fix their settings. As anyone who has worked in support (and I have) can tell you: most don’t even know how or realise there is a setting involved at all. To users, the font size for the computer is text on their desktop. What happens in the browser is ‘external’, is up to the site.
Now, up to this point there is a case to be made for educating the user, even for setting an industry standard, but there is a spanner in the cogs of this theory, a big one.
Impaired users have extra trouble changing settings. At home they will stick with old equipment for far longer than the average because their assistive technology is expensive and hard to set-up. So, not only are they at far greater risk of running into these issues because their equipment is often old and badly supported; they are also loath to change settings. They fear breaking their assistive technology. And even if they are confident, and aware, enough to change settings they still have their handicap to content with.
You try changing settings in windows using JAWS to read the screen to you, rather than your eyes. Or while looking through a piece of rolled up paper.
So much for the home computer. Now, do you travel? Visit friends? Use a computer at work?
Ever found that the computer at your hotel, the library or your friends’ house was really screwed up? I’ll bet you have.
Are we going to trap the disabled in their homes?
In short: Browsers should allow for graceful and useful font scaling by the user, with a simple (keyboard) command. Designers should anticipate problems with local platforms and, as best they can, provide a reasonable starting point for users from which they can customize to their liking.
This equates to:
- A base font size within acceptable margins; no smaller than 9px, no larger than 22px. Body copy always 12px or up.
- A font which is legible and, preferably, designed for use on screens.
- A layout that allows for font resizing, without text getting obscured.
Now, Microsoft may force my hand yet, but this is my opinion on this matter and I think I’ve explained my standpoint. There are other approaches, amongst others using Em values which work just as well, but since we’ve established that to avoid all too common situations where the local platform is not behaving as it should we have to take the true ‘flexibility’ out of the size issue, there is simply no reason, pragmatically, to not make room in your budget and do things the fast and secure way; pixel values.
If only Microsoft would play nice. The jury is out on this one, keep watching this space.
The font sizer
Sticking with fonts, I can’t avoid mentioning the ultimate key-inside-the-locked-chest accessibility gaffe; the resizer, or those little squares with progressively larger ‘T’s” in them to indicate that users can click there to scale text.
Apart from being useless if you did your code right in the first place, because users can scale text or the entire screen at will unless you broke that functionality, they are just silly.
How is a user who can’t read reasonably sized text going to see them?! Even when they are reasonably sized, many visual impairments aren’t about blurry or overall reduced vision. Some people can only see out of the edges, or the very centre of their eye, resulting in a very limited field of view. Again, take that rolled up piece of paper, hold it up to your eye. Have fun hunting down all the functionality you need on most websites.
And they rarely offer the option of scaling text down, while many visually impaired people actually benefit from smaller text.
No, this was a silly mistake, lets not keep making it and bury it with those pictures our mums took of us in the tub when we were kids.
Alt everywhere
The WCAG now recommends using CSS to place images that are purely decorative, a thing I’ve been doing for a long time already. It simply just makes sense. All other images require an alt-descriptor. Right? Wrong!
Alt-descriptors are the trickiest thing facing the accessibility-conscious developer. In short, the alt-descriptor offers an alternative for the contents of a picture, to be read out by the screen reader. If your image contains text (which it almost never should), which is, and here is the tricky part, essential to the information content of the page, there should be an alt-descriptor with an (another tricky one) appropriate, correct and (really hard bit) concise text.
A picture says more than a thousand words. An alt-text should capture those >= 1000 words in a short, to the point, sentence.
You do not, I repeat do not, under any circumstance, please put down the keyboard and back away from your desk, ever describe images which do not offer a benefit to the non-sighted user. On the other hand, even when an image’s informational content cannot be conveyed to a non-sighted user, you should not hide it. Non-sighted users may well share information with others for whom it is useful.
So, when do you leave out the alt descriptor (please do not put in empty alt-descriptors, many screen readers do pause on them, empty or not) and when do you include it?
Simple:
Include:
- When you think you can adequately describe the information content of the picture in terms useful to the non-sighted.
- When you can’t but you can convey what kind of information the picture contains.
- When the picture contains relevant text.
Exclude:
- When an image is decorative or has little informational value.
- When none of the above is possible.
- When it would repeat information already given.
Right, that made everything simple. Let’s be on our merry way, we got it now.
Nah, just kidding. It’s hard. Sometimes the case is simply not clear-cut. To help a bit more some examples:
When selling a book, a bad alt-descriptor would be: “Big book with red title”. A good one would be “A picture of the book [title].” Now, a non-sighted user may not need the book, but they do shop for gifts. To many non-sighted users ‘red’ has no meaning, but even if it does it is non-essential information. The fact that there is a picture of the book may very well be. Why? Well, does ‘Hey bob, here’s a picture of a book, was that the one you couldn’t remember the title of’ help?
Now, if you have a picture of senator McNogood on your page, and in the caption you say: ‘Senator McNogood is seen here taking bribes’ it is not necessary to ad an alt-descriptor to the same effect. If your caption is clearly linked to the image, you do not add an alt-descriptor at all.
If, however, you are a fan of senator McNogood and you want to introduce him to the public, you may want to add an alt-descriptor of ‘Senator McNogood’. But only if there is no caption that does the same.
The point is to make as much of the information available, in a way that does not hinder the user. (So, not twice.) Judge each case on its merits. If you can’t make the information available, make sure all users know it is there so they can find an alternative way to use the information if they really need it. (Ask someone, use a different browser, etc.) For example; a blind reporter may need to verify for a story that the senator is Caucasian. This is not something you’d anticipate having to relay to the audience. In fact, it may be a bit suspicious if you do. If he/she knows there is a picture, at least he/she can ask a colleague to take a peek for him/her.
No one, ever, is going to need to ask his or her colleague to verify that your background image is blue.
Many alternatives
There’s still a school of thought which propagates providing as many alternatives to your content and menu structure as possible. The reality is that you’ll only be confusing your visitors and spending your budget to do so.
The idea is that people want control over how they use your site. Well, it turns out that if you ask people, they will say, sure, yes. But when you observe how people actually use websites of the web 2.0 persuasion, you know with all the ‘flexible’ options and gadgets and doodads you can move around, turn on and off, and so on you will find that the majority will do very little if any at all of all that.
People will gleefully use a ‘bad’ interface they know, rather than learn another. People want clarity, simplicity and predictability.
One of the first things you learn when working in research is that which people say they want, and what they actually will use are two very different things.
What people want is to get to the information they need, or to accomplish the task they came to perform as fast as possible. This means spending as little time with the peripherals as possible. They will learn how to work your interface once and then use set routes through it to accomplish their tasks. If you want to make your visitor happy, make your interface simple, not complex and ‘customisable’.
When there are two routes to the same information, people will assume they lead to different places. Once they have found what they need, they will disregard the other as irrelevant to their needs. If they do try the alternative, they will be confused, annoyed or even assume the site is broken and they somehow landed somewhere they were not intending to go. “I was here before, why am I here again?” is a remark I heard, a lot.
Providing a plain text version of your site is an oft-heard ‘must-do’ too, which I consider harmful. Your site itself should be useable to anyone. Providing an alternative version is not only a cop-out, it invites version differences and mistakes. Besides, just to know there is an alternative version and find the path to it users will have to visit the ‘main’ site at least once. It’s the key-inside-the-locked-chest again. But most of all; to save yourself a one-time effort you are expecting the impaired users to make a continuous, repetitive, effort on your behalf which is not only very bad manners, it is bad business. You see, if a website costs me even the littlest of effort to use more than that of a competitor, I go the competitor. And I’m not (very) impaired; to me it doesn’t even feel personal.
In closing
There is no magic bullet to accessibility. What is good for one user is bad for another. The WCAG is not written in stone. It’s an ever-changing document. The thing about these changes is that they are discovered in the field first, then debated, debated again, written up in concept, debated for another few rounds before finally making it into a recommendation. Blindly following the W3C, the WCAG or what this guy said on that blog is like mailing a letter to your aunt to ask what time it is. Keep your wits about you, use logical thought, ASK users, keep up with the times. You will still make mistakes. That’s unavoidable. But it’s ok to make mistakes. It is not ok to make mistakes, then be arrogant about it and defend them as if they are the only way to do things right.
If the whole world does things differently, you can pout all you like about how it’s wrong. It is the way things are. If you build your site according to standards, and no one finds it easy to use, you have not only overshot your mark, you better duck because that bullet is probably on it’s way ‘round the world and behind you.
With that I will close this article and start work on an alternate set of CSS rules for IE so my site will scale its text in their broken, badly done, browser, too.
The jerks.
Further reading
http://www.webcredible.co.uk/ [...] /web-accessibility/errors.shtml
No Comments yet.