Re: SVGAccessibilityWG: has-been-clicked or a:visited

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