- From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
- Date: Mon, 8 Nov 2004 20:59:56 +0000
- To: Chris Lilley <chris@w3.org>
- Cc: www-svg@w3.org, "Jim Ley" <jim@jibbering.com>
Chris, my response to Jim and your replies, I've tried to keep this brief, so please excuse, but feel free to comment on, any errors. SVG offers the opportunity for authors to refine and provide an interface they desire, however it has long been recognised that users benefit from relatively standardised interfaces, and if the specs are not the place to provide guidance on this standardisation, then perhaps the place might be Authoring Tools techniques, as well as accessibility and authoring guidelines. Current versions aren't to my knowledge available**. While all this is made to work well one might expect users to also have some control of these parameters, but that relies on all the above together with excellent viewers and ATs. (Flash is used by people with mild to severe learning difficulties to author graphics including animations, I'm not aware of the same user group creating SVG files.) I agree, that Jim has provided much excellent feedback on this topic, not that I agree with all he says*, a few comments and further details. >>If your issue is in reality that links are not identifable as links in a consistment manner between SVG documents, and there's not a component of this that is stylable, then you should >>raise this issue. Neilsen and others have identified that the majority of users benefit from and expect standard interfaces, such as text fonts changing colour on having been visited. The comparable standard in SVG does not appear to have been agreed (or discussed?) In particular no description is given of how groups which have links might use pseudo classes. >>It gives authors the ability to change the rendering of content dependant on the link being visited or not. Ian Hixie created a demonstration for mozSVG yesterday, something similar is here: http://www.peepo.co.uk/temp/visited.svg afaik these are the first working examples on the web. It doesn't work in ASV6 or amaya8.6 hardly evidence of universal adoption, and yet this is a really well known and agreed to be useful standard. >> if your issue is that adding a border to an SVG graphic, as you demonstrate on your site, is too complicated currently, then you should raise this. yup that too! arranging a border for a group is a complex process, (by hand...) it certainly would be helpful to have a group 'border' with style in SVG. (rectangular borders for graphics that aren't rectangular are indeed very ugly, whether in html or svg.) These are both important issues that need to be addressed. >>It's not the job of a specification to say how an author should use it, how it's used is down to what the author wants to achieve, you seem to be confusing a particular rendering - the default non-CSS ones from HTML images where an image as a link gets a border, with the ability to change a whole range of properties which the CSS pseudo class provides. see first paragraph regarding need for further and current SVG documents I don't know enough about specs, but do know that in 3 years or so I have yet to see a linked SVGs that indicates that it is a link, by using hover, visited, etc I could be mistaken, but it must be evident that at least there hasn't arisen a standard. Are these two issues raised in the W3C/SVG accessibility documents? I can't remember, yet this is a very basic accessibility standard. A default action would be great! It would raise the issue with authors (and users), who currently seem sublimely ignorant of it. >>There's nothing inherently wrong with the accessibility of this in this particular area (there could be some authoring guidelines about consistent use, but I can't see anything wrong with the specification) We do need authoring guidelines, see first paragraph. however there is a problem in this particular area, there isn't a standard. compare: http://www.w3.org/TR/CSS1#anchor-pseudo-classes which gives a description of use that explores the possibilities for html in reasonable depth, and contrast with http://www.w3.org/TR/SVG11/styling.html#StylingWithCSS where no description is provided, the linked pseudo classes refer to CSS and not the specifics of SVG. The fact that there isn't a standard or default method for indicating what are links, those that have been visited, etc is a problem. HTML doesn't have this fault. SVG offers a whole range of possibilities, particularly as border isn't at present supported. see http://www.peepo.co.uk/launch/index.svg in asv for our guess at a possible standard. This is far too difficult to implement for groups, so one cannot imagine many authors bothering, compare with the html version which requires perhaps 3 words or so. Apart from the rather facile, or ridiculous option of providing a rect with stroke-width as a border to a graphic, it is really hard to imagine what was intended in respect of groups. perhaps the whole graphic changes, not impossible with stylesheets. but again I've yet to see this in the wild. and would it be simple to implement? The fact is that this is an extremely open option, there are plenty of possibilities, and it would be great to have some working examples or prototypes. Always remembering that they should be easy to implement, at least in the near future :-) To raise another issue, It isn't clear why alt isn't included as well as title, they have different functions perhaps one describing the image, and the other the linked resource, surely essential accessibility for SVG? regards Jonathan Chetwynd http://www.peepo.co.uk "It's easy to use" irc://freenode/accessibility *>>The basic ability is provided for in SVG 1.1 currently - I agree it would be nice to have this in non-CSS SVG User Agents, and I would like the WG too consider this for future versions >>(along with the other suggestions we've seen in the past related to CSS like features in the non CSS UA's). it's not clear to me that I was suggesting this, and don't believe I was. **JC> It is time there was an SVG Accessibility WG with a focus on Authoring JC> Tools. I was puzzled to work out how that followed on from the previous comment (and Jim's excellent response). Is it a new comment that merely reused the same subject line?
Received on Monday, 8 November 2004 21:00:29 UTC