Two authors, Sri Kurniawan (a treasure trove of citations) and Panayiotis Zaphiris, put a lot of effort into a paper entitled “Research-derived Web design guidelines for older people.” Sadly, I have issues with it, as they say.
- The authors did a literature review of over 100 papers in “HCI and aging.”
- Then they distilled all those papers’ recommendations into 52 guidelines. Then they had grad students card-sort the guidelines.
- Then five HCI experts evaluated the guidelines and merged any repetitive guidelines. After all that work, which is really three research papers’ worth of effort right there, the result was 38 guidelines. This is still way too many for a working Web developer who isn’t a keener, a standardista, and/or a detail freak, but it’s about half the size of WCAG 1.
- Then they tested the usability of the 52 and 38 guidelines themselves.
- And only then did they conduct user testing, with 16 older Web users.
Have you ever heard of so much testing in any Web-related research?
Many of my readers would find the guidelines uncontroversial in the main – mostly things like using clear navigation, don’t use all capital letters, and the like. Then we have the problem cases.
- H1.1. Provide larger targets.
- H1.2. There should be clear confirmation of target capture, which should be visible to older adults who should not be expected to detect small changes.
This seems to refer to the
:activestate of links, which nobody but me seems to bother styling. But it could also apply to Web 2.0–style applications, whereby tiny changes in one part of the page cause other things to happen elsewhere on the page. (I have seen similar events on decidedly-noncompliant pages, including an amazing near-instantaneous stock-lookup site that uses frames.) Also, error messages that appear right on the very form without redrawing the page would seem to be included here.
I think the whole thing can be avoided by making important new additions to a page clearly distinguishable. You’d probably be doing that anyway. Tiny little hover effects? Well, those might not cut the mustard. But they would have to be important hover effects to justify changing them.
- H1.3. Older adults should not be expected to double-click.
How do they run their computers, then? And how often do you have to double-click something on the Web?
If this is a problem, why doesn’t the older person adjust the click delay and/or map double-clicking to another mouse button?
- H2.1. Graphics should be relevant and not for decoration. No animation should be present.
I agree mostly about animation; that would have the pleasant side-effect of eliminating the worst banner ads. But, as written, “raphics… for decoration” essentially makes graphic design illegal on the Web.
Throughout the questionable guidelines, I get the impression that one subject complained about one detail of one badly-made, standards-noncompliant site, which was then generalized into a rule, written in unintentionally overbroad language, that would destroy things that were never originally a problem.
- H3.3. Provide location of the current page.
- H3.5. Do not use a deep hierarchy and group information into meaningful categories.
The former guideline seems to conflict with other claims that breadcrumb navigation is seldom really used. The latter guideline contradicts the former and itself.
- H4.1. Avoid scrollbars.
Come again? Do you mean avoid horizontal scrollbars? Because it is impossible to use the Web without scrollbars at all.
- H5.4. Information should be concentrated mainly in the centre.
Most of the time, it is. This sounds like an ill-phrased complaint. Are the elderly subjects asking for a zoom layout, in effect? (Theofanos and Redish found similar complaints in their study.)
- H6.3. Links should be clearly named and no link with the same name should go to a different page.
I’m really tired of reading variations of this one. “Click here” as a link text usually leads to bad usability. “More…” as a link text on a newspaper front page does not, since you’re reading the hed, dek, lede, or slug for that article when you find that link. You’re not reading them out of context, the entire concept of which is insane.
HTML pages have a tree structure; while CSS may present different components in different places, we do not construct Web pages so you can reorder elements at will. We have a specific, and in many cases mandated, order of elements. There will be times when the right way to link to different resources from within different text will be to use the same word found elsewhere on the page.
Using Jaws? Like its feature to extract links and headings? Great, go to town. But we’re not going to do anything special to make your life easier, because extracting links and headings destroys our pages. Elderly? Skimming a Web page? Is your eye drawn mostly to links, and you see that several of them are the same word? Again we’re not going to do anything special to make your life easier, because you also aren’t reading the page the way we set it up (or the way the underlying HTML requires).
I’d need concrete examples of sites that actually resulted in lower usability for these elderly users before I’d be willing to budge at all on this.
- H6.3. Links should be in a bulleted list and not tightly clustered.
Well, there goes the Web as we know it. I certainly tire of usabilitistas’ and standardistas’ efforts to turn a hypertext medium into a research paper with endnotes.
What seems to be at issue here is the edge case of single-character links placed close together (like the links to subsequent pages of results on a Google search – and that’s an easy-to-use example as these things go). But as written, it bans more than one link inside a paragraph, such as the first paragraph in coauthor Zaphiris’s homepage.
- H7.1. Provide ample time to read information.
It’s pretty hard to find a page that closes by itself these days. The Toronto Public Library search site returns to its homepage, for example, but only after quite a few minutes of inactivity. Unrequested changes of state are a WCAG 1 violation, which may be finessed in WCAG 2 to acknowledge reality and permit auctions and timed tests. Really, where is the actual problem this guideline hopes to solve?
- H8.2. Blue and green tones should be avoided.
There goes the hyperlink. Aren’t they supposed to be blue? (So many guidelines that attempt to bring to extinction the basis of the Web.) Or does this guideline refer to blue or green page backgrounds? Which shades of blue or green, and with which foreground colours?
- H8.3. Background screens should not be pure white or change rapidly in brightness between screens.
I agree that many visual impairments make white backgrounds tiring or outright intolerable, but white backgrounds are not going to go away. Mac and Windows defaults, and centuries of black ink on white paper, condition absolutely everyone to start with dark type on a light ground and work from there. I’ve also read complaints about reverse type. You kind of can’t win on this, except perhaps to provide stylesheet-switchers. (Again, are respondents asking for zoom layouts without knowing it?)
I don’t exactly know how to change brightness rapidly between screens. Are you saying I can’t link from a light page to a dark one? Or that I shouldn’t use scripting to automatically alter the page colours without your consent and at specific intervals? When does this really happen, apart from some rather unpleasant Flash pages?
- H9.2. Text should be left-justified and text lines should be short in length.
How much text on the Web is not left-justified? Five percent? Does this mean we cannot centre a title?
I assume what they’re talking about is full justification, which looks terrible online due to poor authorship (nobody puts in soft hyphens), poor authoring tools (devices make it hard to put in soft hyphens), and poor browsers (which are extremely spotty at supporting soft hyphens, about which there is actually a vast literature). I might see a page with justified text once a month. It isn’t a pervasive problem.
“Short” line lengths cannot be the categorical answer. I assume this is a reference to very wide windows with containers that are not given a
max-width, or containers viewed with IE/Win, which does not understand that property.
- H9.5. Text should have clear large headings.
Text should have heading elements where necesary (
h6). They should be easily identifiable or “clear.” They simply do not have to be “large.”
- H9.6. Use sanserif type font, i.e., Helvetica, Arial of 12–14 point size. Avoid other fancy font types.
There goes this Weblog, then. (At time of writing, I use Zapfino and cursive type for main headings.) What are these “fancy font types,” exactly, and how often does one encounter “fancy fonts”?
Can you really believe they’re suggesting print fonts for use onscreen for elderly people? And grotesk sansserif fonts, with their many confusable characters, at that?
I strongly suspect that subjects were stuck using IE/Win on a crappy monitor under Windows 98 – in other words, not a real browser, not an LCD, and without antialiasing of the ClearType variety. All fonts look like complete shite under those conditions, but even Helvetica and Arial look better when smoothed. (Arial actually tends to have much better screen bitmaps than Helvetica, when it comes to that. Yes, I have just admitted a superiority of Arial.)
Whenever you are offered typographic advice by a nonexpert, be skeptical. Maintain your skepticism even if the nonexperts are elderly people, whom we are not supposed to contradict even if they’re completely wrong, or researchers with doctorates. (Remember, all they can tell us is to “void other fancy font types.” I thought scientists prided themselves on precision of terminology.)
Onscreen typography for Web sites is an issue of ongoing investigation. Telling us to use 12- to 14-point Helvetica or Arial for everything not only contradicts some other guidelines in the same list, it indicates a near-complete ignorance of psychology of reading and the range of fonts that’s actually available. It is, moreover, tacky.
Other than that, though, great paper.