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 10:33:49 UTC