RE: single browser intranets

At 11:24 AM 10/26/99 -0400, Wayne Crotts wrote:
>The issue is not that clear cut.  Intranet access may not be a vital issue
>(there may be an alternative method of information sharing provided by the
>company).  Or when the issue arises, the company may be able to find a
>browser that is compatible with their one browser policy (dealing with a
>couple of exceptions is much easier than allowing any type of software to be
>used from a computer support stance.
>
>Once again, I think people are not seeing that the issue here is not
>accessibility but allocation of resources.  For an organization to support
>one browser, does not mean necessarily that they are doomed to be
>inaccessible.  We are making huge assumptions to say otherwise.

I don't think Steve painted a black and white picture.  He said the
investment of resources in a carefully thought out and implemented intranet
editorial practice increases the seamless integration of employees with
disabilities and reduces the risk of lawsuits.  There is no question that
there are resources that have to be allocated.  There is no consensus about
the relative magnitude of these resources.

One magnitude that I don't see anyone addressing in business-credible terms
is the curb cut effect for universal design of internal web communications.
 Doing the up-front homework to design the intranet practices for any
browser, or for WAI compliance, will result in intranet content which is
_more_ effective communication with _all_ employees, totalled across the
employee population without regard for disability.  It is not just that you
won't lose effectiveness, you will gain.  Making the words tell the story
independent of the pictures, and the pictures tell the story independent of
the words, will reduce employee time spent and error rate in extracting
information from the intranet.  But I don't know how much.  I would really
love to see Pugh or Arthur Andersen Consulting or somebody with credibility
among the readers of the Wall Street Journal attempt to measure the
cost-benefit curve for this effect.

This gain in communication effectiveness is the major economic incentive
for the employer, not the threat of lawsuits.  Employers can play the law
game very effectively against employees because of the increasing returns
to scale in lawyer-buying.


Businesses implementing intranets need to realize that the Web is an infant
industry, and Best Commercial Practice (a.k.a. what the market will bear)
is not really very good yet.  If they want to play smart and get ahead of
the curve they will use the WCAG in an internal communications quality
program and have a happier, better informed and better bonded workforce.
And business (to read the WSJ) generally understands that that is an
enterprise asset worth investing in.

Al

>
>Wayne
>
>Wayne Crotts
>Information/Systems
>Institute on Human Development and Disability
>A University Affiliated Program
>The University of Georgia
>
>-----Original Message-----
>From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
>Behalf Of Steven McCaffrey
>Sent: Tuesday, October 26, 1999 10:20 AM
>To: W3c-wai-ig@w3.org
>Subject: single browser intranets
>
>
>
>
>As Kynn said,
>
>"...(Caveat, of course, is that the content must still be made
>accessible to people within the company.)"
>
>Precisely.
>
>I don't know why there seems to be a muddling of Intranet policy with
>accessible web page design.
>It is really not hard.
>The issues are clear-cut.
>Fact: If a company has a disabled employee, The ADA employment provisions
>apply.
>Fact: If Intranet access is an essential function for all employees,
>(or, although not required for all employees, is an essential function of
>the position for which the disabled person was hired)
>some accessible means to access the Intranet must be provided.
>Fact: The way this is achieved is open for discussion.  The fact that *some*
>way must be found is not.  (Unless the company wants to be sued under the
>ADA, a company can choose this as an option if they want to take the risk.)
>So:
>If a company
>a. has a disabled employee, and
>b. has an intranet, and
>c. all employees need to access the intranet,
>(or, all employees don't need to but it is an essential function for the
>position for which the disabled individual was hired)and
>d. the disabled employee cannot access the intranet
>then
>  the employer must, by law, find *some*, way to give that employee
>  access to the intranet
>else
>  the whole issue does not even arise.
>If the issue does arise (a. through d. all apply), then the search for a way
>to make the intranet accessible begins.
>This starts by asking the question:
>Why is our   intranet not accessible?
>To answer this, all the internet accessibility barrier issues apply.
>This includes:
>1. Page design issues.
>2. file format issues (e.g. maybe policy statements, required reading for
>all employees, might be available only in PDF or job specific documentation
>is in inaccessible formats)
>3. Software (e.g. the browser)
>4. the available assistive technology.
>a. hardware. (e.g. speech synthesizer - could also be a software
>synthesizer)

>b. software. (e.g. a screen reading program, and/or a self-voicing browser)
>If some way is found to make the intranet accessible without changing the
>browser specific design, then that method can be used.
>No portion of the  ADA, nor any related law, nor the WCAG guidelines
>mandates the use of any specific browser.
>Lynx is *suggested* as a validation tool.  Nowhere does it say Lynx must be
>supported.  Why is Lynx suggested as a tool?  Simple, in general (not *in
>all* cases), if the pages are rendered well in Lynx, it is *more likely* to
>be accessible to a wider range of browsers (e.g. graphical browsers with
>images turned off) and assistive technologies.  The key phrases here are
>*more likely* (*not guaranteed*) and *wider range* (not the entire range*).
>
>But,
>*if no way can be found to make the intranet accessible without using Lynx*,
>by changing the other variables, then, and only then, the pages must be
>designed so Lynx can be used.
>
>Anyone familiar with accesible web page design for the *internet* already
>should have a good understanding on how all these factors interact.  The
>fact that the pages or files are on an intranet as opposed to the internet
>does not change the fact that the employee has the right to access the
>information on the intranet.
>
>Again, *if there is no disabled employeee*, then, obviously, the whole issue
>does not arise.  The company is free to pick any browser to support, design
>specifically for the browser chosen, and  use inaccessible design if they
>want to.
>
>Similar comments apply to disabled students accessing university intranets
>except that, of course, public accommodation and education provisions apply
>instead of employment provisions.
>
>
>
>It was my understanding that, according to the Web Content Accessibility
>Guidelines, designing for browser, and deed even device (e.g. screen
>reader), independence, is one accessibility issue.
>Why?  Simple.  If browser spcific design is used, is just happens to be the
>case that it is *more likekly* to cause accessibility difficulties(not
>necessarily though, see Myths (2) below).
>
>
>Summing up.
>If you are an employer with a disabled employee or will have a disabled
>employee (which, if you are not practcing an outright policy of
>discriminating against people with disabilities in your hiring practices,
>has some chance) it is *likely* (*not guaranteed*) that browser spcific page
>design will become an issue, else it is not likely to become an issue.
>That is, you can reduce the chance of this occuring  by:
>a. Never hiring a disabled employee (hopefully, you won't choose this
>option!) or
>b. Not designing for a specific browser, that is, designing for browser
>independence or
>c. If you do design for a specific browser, do it in such a way that any
>proprietary features you use will degrade gracefully in browsers that don't
>support those features.
>
>
>Parenthetically, I think someone raised the issue of Email access.  if
>electronic mail is an "essential function" some means of doing this must be
>provided.
>Exactly which method to use is, as I understand it, open to negotiations.

>first, try to select and adapt assistive technology to the existing Email
>software.  If this fails, for whatever reason, the employeer must allow some
>alternative email program to be used.
>
>I agree with Gregory in that if your first question in designing an Intranet
>site is which browser you should design for, you are starting with the wrong
>question.  It is wrong not just from an accessibility standpoint, but from a
>general information systems design standpoint.
>First, decide on content.  Then design the page using accessible design
>guidelines, including browser independence.  It is a myth that this is
>either limiting or difficult.  In fact, it benefits everyone.
>
>
>Myths.
>(1)
>"In general, accessible Web sites don't need to be designed
>to be very different. They just need to be designed to be flexible; flexible
>so
>that users can operate them in different ways (with keyboard and mouse), and
>flexible so that they transform gracefully into intelligible and useful
>pages if
>particular technologies are not supported, or cannot be used by particular
>users or browsers."
>(Number 7. from Fact Sheet for "Web Content Accessibility Guidelines 1.0"
>http://www.w3.org/1999/05/WCAG-REC-fact)
>
>(2)
>"
>    Myth #1: Accessible pages must be written in HTML 2.0
>    False. Authors can use HTML 2.0, HTML 3.0, HTML 3.2, HTML 4.0, and
>    proprietary extensions and still maintain accessibility. The key is to
>use
>    features so that they degrade gracefully in non-supporting browsers, and
>to
>    avoid dependence on poorly supported features. In some cases, such as
>HTML
>    tables, this can require some extra work and thought, but most new
>features
>    in HTML 4.0 were designed with an eye on backwards compatibility.
>    Style sheets are an excellent example of a feature that degrades
>gracefully.
>    The proper use of style sheets can significantly enhance the
>presentation of
>    a site while not deterring from the site's accessibility at all in
>    non-supporting browsers.
>(The Web Design Group
>Accessibility Myths
> http://www.htmlhelp.com/design/accessibility/myths.html)
>
>-Steve
>
>
>
>
>
>------
>Steven McCaffrey
>Information Technology Services
>NYSED
>(518)-473-3453
>

Received on Tuesday, 26 October 1999 12:31:39 UTC