Re: Style Sheets for Access

to follow up on what Jutta Treviranus said:

> We encountered a CSS issue related to override which may be best addressed
> in the browser or authoring tool rather than CSS2, but just in case someone
> can think of a creative way of dealing with it in the CSS specs I thought I
> would bring it up here.
> 
> In using CSS in Internet Explorer, through the view/accessibility menu we
> discovered that the CSS chosen (e.g., a large print, high contrast style
> sheet we created) would in fact over ride other embedded, linked or
> imported style sheets as long as we had a style declaration for all the
> specific selectors. However, when we encountered style sheets with
> declarations for selectors for which we had no declarations (i.e.
> contextual selectors or classes we hadn't thought of) the other style
> sheets over rode ours. This is exactly how cascading should work, however
> it makes it difficult to create an accessible stylesheet. How can you
> anticipate every possible permutation of element, class and context in one
> style sheet?
> 

Thanks for reporting on this.  You have hit on a fundamental
problem that we will probably be wrestling with in the long term
as well as trying to optimize the short-term answer.

Note that there are things one can do via authoring style to help
with this problem.  An authoring practice I have used [in print
documents] is to make sure that there is a defined NORMAL style
at the base of everything else and apply large-type constraints
by redefining NORMAL.  That's a very useful form of cascading.

> The easiest way to solve this is probably in the browser, by disregarding
> all but the user selected style declarations made through the accessibility
> menu. 

It could even be a little more subtle than that.  The Browser
could present the pallette of stylesheets that it had identified
as cascading together to form the style environment for this
document for this session.  The browser could present this list
to the user as something he or she can edit.  The user could
add and subtract individual stylesheets to and from this list as
the manual mode of style control which has override powers.

This would retain the ability to compose styles (reject all
others may be harsher than what you want) while reserving
ultimate control to the user.

The CSS vs. browser story is a both-and, in my current
understanding of this situation.  We want to work on the
algorithm as supported by the HTML and CSS specs.  The algorithm
we wind up with may take some author discipline (read markup
guidelines for CSS) to get the best results out of it.  Over and
above that, the browser should still give the user the final word
through manual override capability.

>         Alternatively an authoring tool which generates an
> omnibus style sheet to over ride all other style sheets could
> be created (this would be huge and would defeat the CSS purpose
> of limiting the transfer of redundant information), or a Java
> applet which adjusts the style sheet on the fly in response to
> other declarations....any thoughts?

While we may be able to make incremental improvements in the
scenario you reported by small changes in the stylesheet
selection process, there is an underlying language issue which
means that the current stylesheet concept does not capture the
user's concerns very well.

The style-sheet is really designed from the author perspective.
It works forward from logical classes (of ad-hoc naming) to
physical presentation details.

The user's preferences, on the other hand, are really defined in
terms of physical presentation details, not what the author
thought the logical classes are.  The user wants to be able to
say "don't use italics in sizes under 10 points" and things like
that.  The user's preferences are rules in which the variables
are [patterns, queries, or acceptors -- you pick your favorite
name].  And a lot of the acceptor conditions that fire these
rules need to sense the output of the styles, not the input.

CSS only supports named classes at the moment and for the above
reason it is a weak tool for capturing the user side of the
equation.

The long-term solution is that XML should contain adequate
rule-building capabilities and then XSL can be a good medium for
user preference scripts.

The short-term solution may yet be that there is functionality in
this area that is handled weakly in CSS and remains for browser
code and applets to fill in.

-- Al Gilman

Received on Wednesday, 29 October 1997 13:28:54 UTC