"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.