Re: single browser intranets

add to this the cost of training and the steepnes of the learning
curve and the free help available for those wishing to effectively
design and you come up with a financially plausable reason for
implimentation of an accessible design.
"Gregory J. Rosmaita" wrote:
> 
> aloha, claude!
> 
> the logical flaw in your rebuttal to al gilman's contribution to this thread is
> revealed in the (supposedly) rhetorical question you posed:
> 
> quote
>   Is it realistic to expect small companies to expend
>   a large percentage of its resources on a solution for
>   which there isn't an existing problem?
> unquote
> 
> who says that an incredible outlay is necessary to achieve an interoperable and
> accessible intranet?  simply because only one browser is used to access it and
> the company currently has no disabled employees doesn't reduce the overall
> importance of designing to maximize interoperability -- the time that is spent
> up front will be considered time well spent once (a) the company moves to
> another platform, browser, and/or integrated application suite and (b) if one
> of the company's current employees becomes disabled....
> 
> the type of thinking that leads to blanket assertions such as quote behind our
> firewall we -- who currently have no disabled employees -- can do anything we
> damn well please unquote is the same sort of short-sighted logic that brought
> us the Y2K problem...  and, as the Y2K mania in which our society  is currently
> indulging amply illustrates, the yeah, we'll address that when it becomes a
> quote real unquote issue mode of thinking leads, ultimately, to a greater
> outlay and loss of time, effort, and resources than does a bit of forethought
> and planning...
> 
> sure, as a former I.T. professional and intranet architect slash administrator,
> i can understand the urge for uniformity, but i also know its stifling
> limitations...  i also know, from practical experience the limitations of the
> cookie cutter approach to accessibility...  the combination of illnesses that
> caused my blindness also caused a severe loss of tactile sensitivity that
> prevents me from reading braille with any efficacy...  the end result is, that,
> were it not for synthesized speech, i would be functionally illiterate...
> thus, as one who is now umbilically connected to a computer device of some sort
> in order to accomplish even the most basic of tasks (looking up a phone number,
> leaving myself notes, keeping track of which album in which milk crate is
> which, etc.) i also know that simply by switching from screen reader X to
> screen reader Y while running the same mainstream application can cause a world
> of difference, as well as dramatically increasing or decreasing the
> functionality and usability of the mainstream application...
> 
> achieving accessibility isn't as easy as it has been portrayed on this list by
> some during the long, torturous history of this thread -- one can't simply slap
> JFW or HPR on a workstation and say to the employee here you go, now stop your
> whining since (amongst other reasons which could be cited):
> 
> 1) the I.S./I.T. department of the company or entity in question has no
> experience with adaptive/assistive technology, and hence are unaware of the
> very real possibility that upgrading or applying a patch to a single piece of
> software -- even one which the disabled employee never actually uses -- can
> negatively affect (or even bring to a crashing halt) the performance of the
> assistive technology being used by the disabled employee to perform even the
> most prosaic of tasks
> 
> 2) most people who rely on assistive technology are trained on a specific brand
> of software, and making a drastic switch to another brand of assistive
> technology not only means another steep learning curve, but that many of the
> functionalities that the user took for granted when using adaptive technology X
> no longer apply when using adaptive technology Y...  this is particularly true
> of screen reader users in the windows environment...  most screen readers have
> a set of mouse emulation keystrokes and scripted events (minimize all windows,
> etc.) that the user learns by rote, never knowing that there are OS equivalents
> to many of the emulated and scripted events (such as shift+F10 to simulate a
> right-mouse-click, or WindowsKey+M to minimize all applications), with the
> consequence that -- when the user is forced to migrate from the A.T. which has
> hitherto been their life-line in the GUI environment to a different A.T. for
> compatibility's sake -- or, to a piece of specialized software, such as HPR,
> just so that they can access information on the company's intranet -- their
> productivity will most likely slip dramatically...  this leads not only to
> decreased output by the person with a disability, but to the reinforcement of
> negative stereotypes, as well -- the quote well, what more does he want unquote
> syndrome, which is born of the type of ignorance that has been flagrantly
> flaunted on this list, to wit, the quote just slap screen reader X on the
> workstation and the accessibility issue has been addressed unquote...
> 
> when it comes to accessibility, the cookie cutter approach of using adaptive
> technology A in conjunction with application C does not, and cannot be allowed
> to, suffice...
> 
> i'll close with a brief illustration of my point...  although i personally find
> IBM's HomePage Reader (HPR) to be quite an incredible and impressive bit of
> engineering, i have had innumerable members of the Visually Impaired Computer
> Users' Group of New York City (for whom i serve as webmaster, minister of
> propaganda, and president emeritus) tell me, after being exposed to HPR
> firsthand, quote i'd love to be able to navigate tables and surf the web in
> general like that, but i'll never remember all those keystrokes and commands --
> it's bad enough that i have to switch between 2 or 3 screen readers during the
> course of a day in order to get my work done; the last thing i need is a whole
> new set of commands to memorize unquote
> 
> gregory
> --------------------------------------------------------
> He that lives on Hope, dies farting
>      -- Benjamin Franklin, Poor Richard's Almanack, 1763
> --------------------------------------------------------
> Gregory J. Rosmaita <unagi69@concentric.net>
>    WebMaster and Minister of Propaganda, VICUG NYC
>         <http://www.hicom.net/~oedipus/vicug/index.html>
> --------------------------------------------------------

-- 
Hands-On Technolog(eye)s
Touching The Internet:
mailto:poehlman@clark.net
Voice: 301.949.7599
ftp://ftp.clark.net/pub/poehlman
http://poehlman.clark.net
Dynamic Solutions Inc.
Best of service
for your small business
network needs!
http://www.dnsolutions.com

---sig off---

Received on Tuesday, 26 October 1999 17:45:51 UTC