Re: CSS style sheets in SVG enable high and low contrast

"Jonathan Chetwynd" <j.chetwynd@btinternet.com> wrote in message 
news:9987A006-421E-11D9-86AF-000A95C7D298@btinternet.com...
> "it can't be done by the user"
> What can your reason be for asserting this?

because to author a user stylesheet changing the contrast of an image, one 
needs to know what the current contrast of the document is, and what 
elements need to change - it's not simply a mechanical process of changing 
different colours to increase contrast.  So to be able to create a user 
stylesheet for the image, they need to understand the image.  Obviously if 
they need a new stylesheet to do that, then they cannot.

> In particular the example given demonstrates how, for the simple example 
> of 'border' the user could.

Yes, yours is an excellent example of how an Author can achieve a high 
contrast version, it does nothing to show how a user could create a user 
stylesheet to create a high contrast version of another site (take foafnaut 
fore example, how can you create a high-contrast CSS version of that?

> authors need to understand how to enable users to make choices for 
> themselves. Style sheets provide an appropriate mediation.

Not in SVG they do not, you can't change the size of text in SVG, it changes 
the semantics of the content, you can't change the colour of individual 
elements in SVG, it changes the semantics (you could change all green things 
to red perhaps, but even that has problems if it's a traffic light, but at 
least works if it's a graph - that's impossible in user stylesheets though) 
User stylesheets simply cannot achieve what you want, rather than 
continously challenging me to produce examples, take something like simple 
like http://www.glitchnyc.com/images/ArdvarkTheAardvark/VervetThree.svg or 
http://jibbering.com/2002/8/img-desc.svg and show me how a user stylesheet 
could be used to increase the contrast of those, then when you've done that, 
look at how you might be able to do the same with Jan's map.   Authoring 
user stylesheets is difficult enough for users in HTML, it's completely 
impossible where the semantics are the presentation, you can't change the 
presentation without changing the semantics unless you actually know what 
the semantics are.

> However this does rely on conscientious authors making that step.

What step?  That's what's missing, there's nothing defined that authors can 
do which will suddenly make user stylesheets work.

> This is particularly relevant to mobile phone users, who have very limited 
> screen size, which is almost certain not to change.

CSS is not on the mobile browsers, none of them have it, and none of them 
are likely to get it, it's not required by the spec.

> many users will benefit from a sophisticated contrast control. It seems 
> almost impossible that this wont arrive promptly.

CSS does not give you contrast control, to do that you eed to be able to 
change everything that is one colour into another colour, CSS can't do that.

> Whatever eventual solution is adopted the user will effectively create a 
> description of their preferred style, and compliant authors will supply 
> data that fits this requirement's sheet, and does so in an excellent and 
> appropriate fashion.

Which is completely different to CSS, and user stylesheets will not work to 
do that, you'll need something to parse the representation of your 
information and then it can be something that can have the style included. 
CSS at most is only part of that.

> As I originally asked, if you have examples that demonstrate how users can 
> choose high or low contrast, please let's see them.

How users can choose between contrast is a button saying "high/low contrast" 
there's nothing to show, technically it can be done in lots of ways, none of 
them interesting and all of them require authors to do all the work.  I have 
no interest in accessibility solutions that require authors to do all the 
work, authors simply cannot be interested (me included, and I do care about 
accessibility)

> * "link to another version of the page"
> A good reason for keeping it all in a single document, is ease of 
> maintenance.

Having multiple colours in a single document and multiple translations in a 
single document increase complexity hugely.  WCAG has never advocated having 
multiple translated content in the same document, the English and the French 
version do not go in the same document (if I'm wrong, please provide a 
citation)

If you wish to bring the other stuff back to WCAG, then we can disqualify 
your approach because it's reliance on script.  Your approach isn't "making 
small coherent steps" it's requiring authors to fully author documents 
accessible to every special case, authoring to special cases is important in 
graphics, the final rendering is what matters, you cannot have semantics 
that the user can understand or style in a way which is accessible to them 
like you do with HTML.  It's the final rendering that matters, to change 
that rendering you must understand the semantics, that means the author (or 
someone who understands it) has to be the person to do it.

The lack of non-graphical semantics in SVG is a problem, and we've just seen 
at the SVG LUG Henry Rezpa discussing the importance of RDF, and we've got 
Ivan Hermann's and Chaals's previous RDF based accessibilty work - this is 
how you make SVG graphics accessible to all, by getting the semantics into 
the document.  Any other graphical changes need to be done by the author or 
at the very least someone who understands the content.

You do a good job evangelising Accessibility in the SVG community, but I 
think you're missing a great many of the wider problems outside your own use 
cases of SVG within your community.  As we know your community has huge 
barriers to content, and the graphical nature of SVG is great for them, but 
we're not going to make random SVG content accessible to them without author 
co-operation, it's simply not possible.

User CSS does not help, and is actively harmful.

Cheers,

Jim.

Received on Monday, 29 November 2004 16:29:19 UTC