[32] in Software Accessibility Project email archive
Re: comments on the guidelines
daemon@ATHENA.MIT.EDU (Kathleen Cahill)
Tue Feb 13 15:49:25 2001
Message-Id: <3.0.5.32.20010213155222.009cf600@po12.mit.edu>
Date: Tue, 13 Feb 2001 15:52:22 -0500
To: Nina Davis-Millis <ninadm@MIT.EDU>
From: Kathleen Cahill <kcahill@MIT.EDU>
Cc: sw-access@MIT.EDU
In-Reply-To: <4.3.2.7.2.20010213140025.03a6f550@po9.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Nina and team;
Please see my comments below:
At 02:10 PM 2/13/01 -0500, you wrote:
>1. This is getting really exciting!
>
>2. A picky comments about wording. As it now stands, the document divides
>the world into two pieces: web pages and software. The assumption, I
>suppose, is that web pages are things we write ourselves and software is
>any application we buy, lease or build. If these assumptions are shared by
>the rest of you, then it becomes confusing where to place the thousands of
>leased web-based resources the Libraries offer to MIT. As I say, I think
>this is a question of wording more than anything else.
I guess if they are web-based resources, I would regard them as web pages. But, I hear what you are saying. There is a fine line between web front ends and the data (or software) that runs in the background. The IT Accessibility Policy refers to "This commitment ensures that MIT Web pages, software, online documentation, and library resources will be accessible to users with disabilities."
>
>3. A more substantive comment. We had several discussions in which we
>acknowledged that in some cases the world of computing might not have
>developed enough in this area for a particular vendor or product to meet
>our requirements right away. As it now stands, this document could be
>interpreted as unreasonable -- that is, if it were seen as requiring us to
>demand the impossible of third-party vendors. Perhaps we need to define
>further what is meant by "Software ... needs to be reviewed for
>accessibility features" -- in other words, if the review takes place and
>the product fails in one or more aspects, what then?
The hope was that if software packages (or licensed products) did not contain accessibility features, the checklist might spur departments or purchasers to start bugging the vendors about these features so that vendors might eventually add them in. We tried not to get specific about outcomes because we realize that there are products out there that may not meet some or all of the guidelines. But that doesn't mean that MIT shouldn't buy them, especially if there aren't accessible alternatives. Do team members think that we need to include more specific instructions about "What if this product isn't accessible?" ?
Kathy
>
>Nina
>
>
