W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

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

From: Jim Ley <jim@jibbering.com>
Date: Tue, 9 Nov 2004 01:25:39 -0000
Message-ID: <002a01c4c5fb$06068410$418f9bd9@Snufkin>
To: "Jonathan Chetwynd" <j.chetwynd@btinternet.com>
Cc: <www-svg@w3.org>

"Jonathan Chetwynd" <j.chetwynd@btinternet.com>
> thanks for your consistently timely and helpful responses.
> I am not trying to dictate or impose anything, please stop insinuating 
> this.

I certainly don't think you are, sorry if my own lack of language skills 
leaves you thinking this.

> I'd like to see the mission statement in the charter include the word 
> 'accessibility', and describe meeting the needs of people, the disabled as 
> well as the general public,
> rather than emphasising the technological aspects, as it currently does.

I don't, unfortunately technical groups in industry consortia are rarely 
going to be able to keep accessibility experts on board the whole time, the 
W3c WAI PF does a good job reviewing specifications, and I'm sure they won't 
miss SVG 1.2, but I don't think it's realistic to expect the limited 
accessibility resources to devote full time on a specification, nor do I 
think it's very necessary.  All W3c specs have

Most of your comments have been about implementation, not specification 
problems, I don't think the specification is bad, sure it doesn't highlight 
accessibility issues, but none of the W3c's technical specs do - the 
audience for them is implementors.  The W3c's Web Accessibility groups have 
done, and are doing lots of work raising the sort of issues you want raised, 
I'm not trying to say they're not important, just that the problems aren't 
in the spec, so you're focusing on the wrong groups.

> Are members of the WG keen to encourage anyone to author SVG? flash has 
> managed this, and people with mild to severe learning difficulties have 
> used the tools available to create graphics and animations in flash, but 
> not to my knowledge in SVG.

I can't see anything at all missing in the specification to prevent this, 
it's an authoring tool problem for authoring content for those with learning 
difficulties, I don't see anything in the spec that's a problem here.

> Do you consider that this has been done, between 1.1 and 1.2? is there any 
> evidence?

I am sure that the WG have considered Accessibility - I believe I have a 
still open issue about accessibility which is not addressed, but they've 
accepted another proposal of mine, but I'm sure that's an oversight rather 
than deliberate avoidance (there are other ones which aren't accessibility 
related which I believe are open)

> just a short example. the new WWAAC browser reads all html alt, title and 
> desc data it finds, and isn't configurable in this respect.

That's a flaw in that tool, we can't complain in a forum for specification 
discussion about flaws in tools.

> Imagine that they are expected to navigate thru masses of metadata, to 
> find the alt content, that may not even be present.

Obviously metadata has to be in a standard format, as I'm sure you're aware 
there's ongoing work at standardising this, if the tool doesn't know 
anything about metadata, then there's title and description which already 
provide more than alt (it's more like alt and longdesc on an HTML image) 
metadata just shows that SVG unlike HTML has extension mechanisms much more 
built in.

> if you can honestly say "I don't use links in SVG documents," then you 
> really don't have a good reason for commenting on this aspect.

No, because I'm a user of SVG, and I use A elements to provide navigation 
between SVG documents, they're just not links (in the hypertext sense), the 
visited state of them isn't something that's relevant to how they're used by 
the user, that's why default presentation of links would be bad for me, 
which is why I want the status quo, where those of us who want to identify 
links, can very easily do so (by specification, admittedly there's failures 
in the implementations) and those of us who don't, don't have to.

feedback on SVG accessibility is I'm sure very welcome, but we need to 
ensure we don't claim that SVG is inaccessible to the Working Group, when 
it's their fault, they've addressed it, they're doing things right.  If we 
keep telling them they're wrong, they're going to think they completely 
haven't understood the issues, and get turned off the whole idea, or doubt 
there own concepts of what they need to do, that we end up with something 


Received on Tuesday, 9 November 2004 01:26:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC