- From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
- Date: Mon, 29 Nov 2004 15:51:57 +0000
- To: "Jim Ley" <jim@jibbering.com>
- Cc: <www-svg@w3.org>
Jim, "it can't be done by the user" What can your reason be for asserting this? it's not as easy as asserting black background, but with good authoring tools it is possible. In particular the example given demonstrates how, for the simple example of 'border' the user could. authors need to understand how to enable users to make choices for themselves. Style sheets provide an appropriate mediation. However this does rely on conscientious authors making that step. This is particularly relevant to mobile phone users, who have very limited screen size, which is almost certain not to change. many users will benefit from a sophisticated contrast control. It seems almost impossible that this wont arrive promptly. Style sheets are the clearly obvious and currently available solution. 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. As I originally asked, if you have examples that demonstrate how users can choose high or low contrast, please let's see them. alternatively, some other accessibility style solution would be great*. Hypothetical future realities are much harder to determine. regards Jonathan Chetwynd http://www.peepo.co.uk "It's easy to use" irc://freenode/accessibility * "link to another version of the page" A good reason for keeping it all in a single document, is ease of maintenance. I'm surprised you mention this, as it's a regular WCAG issue. Furthermore, by understanding the design issues and incorporating them into a single document, one makes small coherent steps towards graphical accessibility, whereas creating alternatives merely leaves the understanding disparate. On 29 Nov 2004, at 14:50, Jim Ley wrote: "Jonathan Chetwynd" <j.chetwynd@btinternet.com> > 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.
Received on Monday, 29 November 2004 15:52:30 UTC