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

Will,

I'm completely with you in respect of the need for good examples, and 
would welcome contributions.
Do you have any? would you be willing to create some for discussion?

I'd welcome techniques for creating accessible SVG1.1 content, so don't 
think that is a valid reason for delay*.
Any techniques document will take a considerable time to author, 
comment on, reach a consensus, draft and publish.
almost certainly years rather than months. There's always a ready 
excuse for delay.

Please don't delay instead of verbally describing an issue, which you 
have done well, why not create, or point to a specific example?
I have no doubt that this will greatly enhance everyone's understanding 
of this issue.

regards

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

*furthermore there is a significant body of 1.1 which remains in 1.2.
It also seems quite possible that 1.3 will be RC before we have a fully 
1.2 compliant viewer, and accessible authoring tools maybe some years 
away.

On 9 Nov 2004, at 15:09, Will Pearson wrote:


Hi Jonathan;

I think you raise a valid point about the availability, or at least
publicity, of techniques for creating accessible SVG content.  However, 
I
think this needs to be done after the spec has been finalised, as if
implementers and content providers were to work to one set of 
guidelines,
which were then to be changed, I don't think there'd be a happy bunch of
people, it may even lead to them giving accessibility a lower 
importance in
the future due to past problems.  It's something I'm really keen to see
happen, but would caution waiting until the spec is at least at RC 
stage.

However, I don't know whether SVG is truely accessible to some users.  
The
problem comes down to how the semantic meaning encoded within diagrams 
is
visually extracted.  It isn't a problem unique to SVG, but a problem 
with
diagrams in general.  The technique of providing a textual equivalent 
for
elements of a drawing is fine up to a point, but problems arise due to 
other
semantic encoding techniques being used within diagrams.  Spatial
relationships between diagram elements, colors, etc. can provide as much
meaning as the lines themselves do, and this is often either not 
conveyed or
not conveyed with any clarity by textual descriptions for a single 
diagram
element without the context of other diagram elements.  Therefore, 
having
things like LongDesc assigned to a <LINE> tag really don't make a 
drawing
100% accessible to someone who has no means of extracting the meaning
visually.  Techniques do exist to make drawings accessible, such as
displaying the diagram to the user using sound (Evreinov G., 2001; Van 
Den
Dohl K. et al, 2004), or extracting the semantic meaning conveyed by the
lines, their spatial relationships and other semantic encoding channels
(Pearson W. and Polovina S., 2005).  Thus, all hope is not lost, but 
whilst
SVG affords some accessibility to some users at the moment, it doesn't
afford accessibility to all users.  This isn't a problem with the specs,
rather it's something that needs to be dealt with by the viewers and
authoring tools.  It's not a problem with the content, just how that 
content
is conveyed to users.

Will

Evreinov G., (2001), Spotty: Imaging Sonification Based On Spot-Mapping 
Aand
Tonal Volume, In proceedings of the seventh International Conference on
Auditory Display (ICAD 2001, Espoo, Finlad

Pearson W. and Polovina S., (2005),
Transforming Vector Based SVGDiagrams into Auditory Descriptions Through
Semantic Based Translation, To appear in the proceedings of the ACM W4A
workshop on web accessibility, Japan, 2005

Van Den Dohl K. et al (2004), Geometric SHAPE Detection With Soundview, 
In
proceedings of the tenth International Conference on Auditory Display 
(ICAD
2004), Sydney, Australia
----- Original Message -----
From: "Jonathan Chetwynd" <j.chetwynd@btinternet.com>
To: "Jim Ley" <jim@jibbering.com>
Cc: <www-svg@w3.org>; "Chris Lilley" <chris@w3.org>
Sent: Tuesday, November 09, 2004 12:17 AM
Subject: 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 20:09:03 UTC