UA Guidelines

Hello...

I'd like to offer a couple of small observations about the UA 
Accessibility Guidelines:

First, regarding Guideline 4.18, user control over UA-spawned 
viewports: seems to me that this needs to be a Priority 1 
guideline.  Currently, UA-spawned viewports "break" the 
history mechanism completely, and they provide the user with 
no cue(s) for understanding why basic UA functionality has 
suddenly stopped working.  Further, I can't see how it'd be 
possible to implement Guideline 7.2 (a Priority 1) without 
*also* implementing 4.18; a promotion is clearly in order.

Second, regarding Guideline 8.7, user control over information
regarding links: again, I wonder if a promotion (to a Priority
2) isn't in order.  It's easy to imagine several scenarios in 
which user control over link information would be crucial to 
maintaining the overall "visibility of system status," which,
in turn has been extensively documented as a key element in 
software usability.  For example, consider UAs that do not
support a particular scripting language; a page full of links
that, in turn, rely on that scripting language will be 
utterly unusable, and the user needs the ability to discover 
*why* the page in question is "broken."

I'm sure that my fellow software developers will agree that,
as code requirements go, neither of these is particularly 
hard to implement.  I'm left to wonder why they've been 
relegated to secondary (or tertiary) status.

(Then too, having just spent a summer in the usability lab, 
watching young folks *not* understand "how the Web works" has 
left me particularly sensitive to anything that "breaks" 
basic browser functionality or that obscures the user's view.)

regards,

- Terry Sullivan

(P.S.  Apologies for the tardiness of these comments; I've
found myself a bit preoccupied of late, trying to get my
dissertation results ready for a February defense.)

Received on Sunday, 5 December 1999 20:44:33 UTC