[37] in Software Accessibility Project email archive
Comments on draft documents
daemon@ATHENA.MIT.EDU (James Repa)
Tue Feb 20 01:16:51 2001
Message-Id: <200102200616.BAA14233@fort-point-station.mit.edu>
Date: Tue, 20 Feb 01 01:14:42 EST
From: James Repa <REPA@MITVMA.MIT.EDU>
To: SW-ACCESS@MIT.EDU
Hi,
Here are my comments on the accessibility documents:
checklist.html
* Link color
Why was the color for links changed from the default (or user-set color)
to red? This may not directly violate our recommendations, but it seems
like this document should set a good example and avoid arbitrarily changing
default colors.
* Object Information, 1st bullet
I presume that Note 1 was going to say something about focus (or the
lack thereof) on the Macintosh, but I don't see Note 1.
* Sounds
The functions recommended in the first and third bullets (visual cue for
audio events, and changing the volume, respectively) are automatically
provided by the operating system under the Mac and Windows, aren't they?
(The only one I'm not sure about is visual cue for audio events under
Windows.) We ought to word these something like this:
There should be an option to provide a visual cue for audio alerts;
this function should be supported by the operating system (not sure
about Windows, again) as long as the developer uses appropriate
development tools for audio alerts.
* Display, "Provide a function that allows the user to increase
magnification of client area content."
Again, the developer shouldn't have to actually write any code to
support this, as long as he/she uses appropriate development methods
and does not interfere with existing tools for visually impaired users.
* Timing, response times
I would leave this out; I don't think it's going to help anyone.
Most developers do not build limited response times into their applications.
If we really need to keep it, let's reword it to say,
"If there are timed instructions or responses, provide an option to
adjust the timing."
* Flash rate
Developers don't generally mess around with the flash rate, and frankly,
I think any developer or web designer who insists on flashing instructions
or messages in your face should be shot for the good of humanity.
(Alright, I'm just kidding - a life sentence would be sufficient.)
Anyway, I would leave out this bullet entirely. If
we must leave it in, we might consider being more specific:
"Flashing instructions or messages are considered annoying by many
individuals, and screen objects flashing faster than 2 Hz are expressly
forbidden because of the possibility of triggering seizures in
people with certain neurological conditions."
waccess.html
* Cascading Style Sheets and older browsers
Under web accessibility principles, the first bullet says you should use
HTML 4.0's Cascading Style Sheets, but the "Check your work" bullet says
you should check your work with various browsers, including Netscape 3,
which does not seem to support CSS. (It doesn't "break";
it just ignores some tags.) In my work, I have avoided using CSS so far
because of Netscape 3.
Since Netscape 3 is aging and becoming less and less viable, I don't
think we will need to support Netscape 3 much longer. But, we should
say something about CSS and Netscape 3 if we're going to mention both of
them in our document. Should we add the following statement?
"Note that Netscape 3 does not fully support CSS; we still recommend
using CSS, since Netscape 3 is expected to be desupported soon at MIT,
and verifying that when CSS-related tags are ignored by Netscape 3,
the documents are still readable."
* Internet Explorer
The "Check Your Work" bullet also mentions Internet Explorer.
Currently, web designers and developers at MIT are not required to
worry about IE because it does not support user certificates, and therefore
is not a viable browser for many web sites or web-based applications.
There is work in progress to support MIT-issued user certificates under
recent releases of IE under Windows, but not on the Macintosh.
IE under Windows supports user certificates in theory, but work is
required to find a practical way of getting it to handle MIT-issued
certificates. IE under the Macintosh does not support user certificates
at all, and Microsoft has shown no interest in adding this support.
A related issue is that Netscape does not run natively under Mac OS X,
so we're not sure how we're going to support certificates at all under
Mac OS X, but that's not an issue for our committee.
Anyway, we should add some sort of note about IE and its limited support
under MIT.
General comments:
As Nina mentioned, there are cases where available vendor software just
doesn't meet our guidelines. There may also be cases where the vendor
that comes closest to meeting accessibility guidelines must be rejected
because of serious shortcomings in functionality or business model, and
we should not be forced to choose such a product. Can we discuss this
issue at our next meeting and draft some wording to address it?
Jim
