Hi,
J,Av(Brg Hartmann writes:
> recommending the use of a programming language for
> altering CSS on the client (browser) side is a rather bad
> idea, among others for security reasons. (For good reasons
> JavaScript is simply deactivated in many corporate
> environments.)
OK, but we still have an accessibility problem. This isn't
the first time that security and accessibility have been
contradictory goals.
Organisations are GOING to write inaccessible websites.
Maybe they will revise them afterwards in the light of
complaints, but that will take time. People with
disabilities will have to wait before they can use the sites
of such organisations. In a few years' time this could mean
serious exclusion.
By "inaccessible" I mean in this case writing XML + CSS that
cannot be rendered using anything other than the
author-supplied CSS because it does not follow any
publicly-defined syntax. (Mozilla are already at this on
their site, so how long will it be before people copy them?)
To make such things more accessible (at least from the point
of view of users with low vision, dyslexia, or any other
need that implies they can still use the visual display with
suitable alterations) we can look at the author-supplied
rendering and make changes to it (e.g. change italic text
into text of a different colour).
Such a change can be made in several ways, but most of them
have problems of sorts:
1. Get a full-blown screen reader system to do it (very
expensive, lots of development, can't always be
installed, not cross-platform, and would exclude
people in poor economic situations and those whose
disabilities are not severe enough to warrant such an
extreme solution but are still severe enough to make
Web browsing difficult)
2. Use a special Web browser that will do it - but if
that Web browser is not widely-used, developers won't
be considering it when they write their non-standard
scripting and plug-in code that so many sites seem to
depend on these days. Even if your special Web
browser is well-maintained (which is rare), you're
still playing "catch-up" with the widely-used browsers
and you often run into websites that don't work
because they rely on some scripting feature that's not
implemented in what you're using
(NB the above also applies to Web mediators like my
access gateway, which can deal with scripts and
plug-ins a little bit but simply doesn't work when a
site depends on them to the extreme)
3. Get the functionality implemented in widely-used
browsers. I feel this is the best solution.
If the W3C were to recommend having CSS properties being
manipulatable by a programming language (especially
Javascript because it's so widely implemented already), in a
standard fashion, then that would make (3) a lot easier.
Otherwise anything you CAN do will depend on some horribly
browser-specific (and version-specific) code, and you're
still playing "catch-up" when the rest of the world moves on
to another browser or version.
Of course, such a recommendation would have to be done in
such a way that the security people are happy. Something
along the lines of "If you let Javascript manipulate the CSS
properties, you can do it in this way, but note that this
can be switched off". I would try to ask the administrator
to switch it on for disabled people as a special case, or at
least switch on the LOCALLY-SUPPLIED script that manipulates
the CSS (I'm not talking about scripts on authors' websites,
although I suppose you could have that as well if you
want). It would be really nice if you could have a
locally-supplied script (like a user-supplied CSS file) that
does everything, and this can be enabled independently of
scripts "out there" on websites.
Best wishes, Silas
--
Silas S Brown, St John's College Cambridge UK http://www.cus.cam.ac.uk/~ssb22
"Whatever does not make sense can be neither understood nor appraised
and hence cannot be committed to memory." - John Comenius