Coding for intranets (was RE: [thelist] Color Chooser Review -- c orrection)

[aardvark]

> From: Eric Maag <emaag at infohazard.net>
>
> >> Are there cases where the rules can legitimately be ignored?
> >
> > did you want specific examples?
>
> Yes pls.

i'll give a couple of mine own...

a call center application deployed through a browser as HTML,
which we inherited when we started working for this client...

without losing any more screen real estate, and without confusing
operators, we were to create a method to allow the phone rep to
enter credit card numbers or check information or another two
types of payment information...

we found using DHTML attached to a radio button (with a <label>)
worked best and had greatest comprehension by users... the users
selects the payment type, and immediately below that all the
appropriate fields are displayed...

in another case...

an internal tasking system where we used an ActiveX calendar
control because we knew the exact configuration of every
browser... resulted in increased accuracy and increased speed for
users...

another case...

internal e-commerce testing application named MonkeyButler... i
hooked it up so if it threw errors, it made a different monkey
screech for each error... it also used non-standard HTML as part of
the testing process (to make sure target application wouldn't poop
the bed)...

i have others, but i think you can see a pattern:

- they're internal applications where i control the audience...

- even if i don't control the entire audience, i know the audience...

- accessibility was less of a concern in all of these because the
jobs are done either by people who cannot be disabled in a certain
way to do their regular job or because accessible back-ups that are
in place already cover for it (like a paper-based system, in one
case)...



--
Read the evolt.org case study
Usability: The Site Speaks for Itself
http://www.amazon.com/exec/obidos/ASIN/1904151035/evoltorg
ISBN: 1904151035