RE: single browser intranets

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.

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 11:50:24 UTC