[38] in Software Accessibility Project email archive
Re: comments on the guidelines
daemon@ATHENA.MIT.EDU (Kathleen Cahill)
Tue Feb 20 13:24:37 2001
Message-Id: <3.0.5.32.20010220131940.009d9880@po12.mit.edu>
Date: Tue, 20 Feb 2001 13:19:40 -0500
To: sw-access@MIT.EDU
From: Kathleen Cahill <kcahill@MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
>Date: Tue, 20 Feb 2001 09:52:21 -0500
>To: Kathleen Cahill <kcahill@mit.edu>
>From: Ginny Williams <ginnyw@MIT.EDU>
>Subject: Re: comments on the guidelines
>
>Hello Kathy!
>
>I think the web pages look great! My comments below meander from the
>web pages to the project itself. Sorry for the overflow but the
>pages themselves generated much thought. I think that there are one
>or two areas that could use fleshing out as the project progresses.
>Has anyone on the team been in contact with the software buyers in
>purchasing?
>
>On a logistical note, I am again able to make Thursday morning at 10
>meetings and believe that I will have more cycles to help with this
>project as spring approaches.
>
>One overall comment - I would avoid using red or green on the web
>pages, since those who are red/green color blind may not be able to
>see the links (not sure if anyone brought that up).
>
>>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?" ?
>
>My answer to this question is yes. Issuing guidelines and then
>providing lots of support should encourage their acceptance. I would
>include advice on communicating information to the vendor, and on
>composing a justification if there is not a better alternative
>available. This justification should include test results and be
>filed somewhere (perhaps with the purchase order). It would be akin
>to the sole source justification for large purchase orders where only
>one vendor is recommended (I can elaborate if that would help, just
>let me know.).
>
>Speaking of testing, is it possible that we would be able to guide
>someone through testing software? The SWRT has devised several
>testing instructions and checklists to get the information that we
>need when evaluating software. We could develop something like this
>to help guide purchasers not only when they come to the ATIC lab, but
>an additional scenario that they can do from their desks while doing
>preliminary evaluations.
>
>To assist where there's no alternative and the software is not that
>accessible, we may want to consider recommending add-on packages that
>would provide keyboard navigation and other features. For example,
>Macintosh system software is quite limited in providing keyboard
>equivalents right out of the box. Knowing that, we could consider
>licensing a product like Quick Keys that will allow us to provide
>keyboard commands for equivalent functions. This could get quite
>complicated, but would help our users (even those with repetitive
>strain issues) get more use out of software we can't avoid.
>
>Is it possible to provide examples for the display section on the
>purchaser's checklist?
>
>http://web.mit.edu/is/integration/projects/softaccessibility/purchaser.html
>
>
>As I review these guidelines, I am thinking of the people who are
>currently writing installers for the software release team. IS is
>far from being ready to include much of this in our own development.
>Has any of this been run by Mac Dev or the Pismere Team? Do Jim and
>Jeff see these guidelines easy to implement?
>
>ginny
>
>
