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

Jim,

thanks for your consistently timely and helpful responses.
I am not trying to dictate or impose anything, please stop insinuating 
this.

I am raising the issue of accessibility, and the need for updated 
documentation on this essential concept.

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.

The Mozilla accessibility expert Aaron Leventhal was recently quoted: 
"SVG is not accessible yet at all"

The Macromedia accessibility expert Bob Regan is a partner with a UK 
web based project and The Rix Centre, and intimately concerned with the 
needs of people with learning disabilities.
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.

It may be that SVG is in danger of becoming a technology for industry, 
but not for people.
The potential is undoubtedly there, but is the feedback? This isn't 
just theory, it means paying attention to users.
It has to be done asap, so that the delay in updating specs, guidelines 
etc is minimal.
Do you consider that this has been done, between 1.1 and 1.2? is there 
any evidence?

I've replied to your other comments below*.

regards

Jonathan Chetwynd
http://www.peepo.co.uk     "It's easy to use"
irc://freenode/accessibility

*<g border="grey"> is simple, most people don't want to know the 
details of how this might be implemented.
http://www.w3.org/TR/SVG12/vectoreffects.html seems complex rather than 
simple. Frankly I have to say, i haven't got a clue what this document 
is about. The description at the beginning lacks clarity imho, i didn't 
understand the categories, and there are a  number of typos. I am at a 
total loss to understand your suggestion "it's much simpler in the 
future."

you say " However alt is much better provided for with both 
description, and metadata giving the ability to describe the image in 
considerable detail"
however this is typical of a 'bloat mentality' (no offence intended), 
more doesn't of necessity mean better.
Even use of alt, title and desc isn't systematic by html authors, which 
leads to endless confusion for users.

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.
try to imagine someone trying to comprehend all this, even if authored 
sensitively. now try imagining someone trying to configure a suitable 
viewer. how would they navigate thru this lot?
so if the SVG desc and metadata are also completely non-standardised, 
users wont find it easy to use.
Imagine that they are expected to navigate thru masses of metadata, to 
find the alt content, that may not even be present.
ok well maybe they're also on a mobile phone, sounds like a disaster 
area to me :-(

We need not just good but great defaults.

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.
An SVG portal of necessity needs links. One wants not just theoretical, 
but a practical understanding of the issues.
The benefit of feedback is that, it doesn't provide hindsight, but does 
provide dead-reckoning.
If on the other hand you don't think SVG should include links, that is 
a different matter.

Received on Tuesday, 9 November 2004 00:17:38 UTC