Subject: Re: CSS style sheets in SVG enable high and low contrast - msg#00578

Previous Message by Date: click to view message preview

Re: CSS WG comments on SVG 1.2

On 29 Nov 2004, at 21:18, Ian Hickson wrote: On Mon, 29 Nov 2004, Antoine Quint wrote: Several properties in SVG 1.2 (including 'enable-background', 'overlay', 'cache', 'static', 'snap', 'focusable', 'tooltip') have names that are likely to clash with future CSS extensions. Since the SVG-introduced properties apply only to specific SVG cases, whereas the CSS properties are generic, we request that the SVG property names be made more specific to avoid future clashes. Although you are probably aware, the reason for this type of issue is that CSS doesn't offer any way to "package" property names and ensure avoiding clashes with other vocabularies. Prefixing every property with "svg-" would do that. So would prefixing the majority of the CSS properties with "html-". Half :) One way to solve the CSS WG issue is that these new attributes could remain XML attributes and not be made available too via CSS mechanisms. Personally, for many of the above properties I think that would be much better. For example, the 'focusable' property doesn't seem like something you'd want to change from a stylesheet. Yeah, it seems like something we should consider. We'd still have to resolve how to style such content. Dean

Next Message by Date: click to view message preview

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

"Jonathan Chetwynd" <j.chetwynd@xxxxxxxxxxxxxx> wrote in message news:9987A006-421E-11D9-86AF-000A95C7D298@xxxxxxxxxxxxxxxxx > "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.

Previous Message by Thread: click to view message preview

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

"Jonathan Chetwynd" <j.chetwynd@xxxxxxxxxxxxxx> I dont agree at all, the style sheets referred to can be applied by the user, they could more usefully be applied across a greater variety of sites if another semantic layer were available that more fully described GUIs. You cannot change the colour of graphical elements unless you _know_ that the colour isn't relevant (consider the key to a simple graph, you need the polyline and the text both to remain the same colour, this isn't possible in CSS) If we develop some description language that can define these sort of elements, then that would as you say be a great benefit, however it would not be usable with user CSS stylesheets alone. So even with this advance that doesn't exist, or even being worked on, user stylesheets wouldn't help any. User stylesheets as a repair for specific SVG sites, perhaps that's useful, but it's an incredibly expensive activity, and applies to such a small number of cases and is achievable by using DOM methods to inject styles. afaik the common user agents do support stylesheets, it is the changing of stylesheets that remains problematical. Which means they only support a subset, and especially once you move to the mobile focussed UA's there's nothing more than style="..." as an alternative to attributes (why they did that I don't know, I particularly dislike this deliberate partial implementation of specifications, but I can understand the motivation. Please provide any evidence that supports your statement: "the exact same can be achieved in other ways" at it's simplest, simply link to another version of the page, there's no reason to have all that mess - like we discussed on #svg with the systemLanguage detection (with Vincent), there's actually little reason to do all the changes in a single document, alterernate representations make a lot of sense, a lack of reliance on javascript is certainly one well worth considering. It is also possible using SMIL animation, again which avoids script, with its attendant advantages, but instead requires SMIL, or if you wish you can use other javascript. none of it's interesting though, it's all simple to author, and has to be done by the author, it can't be done by the user. In the case of contrast there is research into automated methods to achieve it, however as you've noted they're not very good, they're also not achievable with CSS user stylesheets, so will need a new Access Technology (I believe some of it can be achieved with filters, but am waiting on hearing back from some accessibility people I've asked.) - if it can a bookmarklet could do it in ASV+IE, or MozSVG when it gets filters. Please note that WAI have recently also published draft documents, but they dont refer to SVG. Even I know of work on the SVG Accessibility document, it's as mature as the scripting one, which is currently too simplistic to really be useful. Jim.

Next Message by Thread: click to view message preview

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

"Jonathan Chetwynd" <j.chetwynd@xxxxxxxxxxxxxx> wrote in message news:9987A006-421E-11D9-86AF-000A95C7D298@xxxxxxxxxxxxxxxxx > "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.