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

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

From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
Date: Tue, 9 Nov 2004 09:32:30 +0000
Message-Id: <46E9E303-3232-11D9-AEF9-000A95C7D298@btinternet.com>
Cc: "'Chris Lilley'" <chris@w3.org>, <www-svg@w3.org>, "'Jim Ley'" <jim@jibbering.com>
To: "Doug Schepers" <doug@schepers.cc>


thanks once again for taking the time to try to understand my 
description of accessibility issues, which can appear to be off-topic.

W3C publishes a broad range of documents including specifications, 
there are for instance accessible authoring tools guidelines 
http://www.w3.org/TR/ATAG10/ though these primarily refer to html 
tools, they also include such diverse items as quick tips 
http://www.w3.org/WAI/References/QuickTips/ training 
http://www.w3.org/WAI/training/ accessibility features of SVG 
http://www.w3.org/TR/SVG-access/ the test suite and of course all the 
other useful documents already linked to from the SVG website.

I would expect that Aaron was referring to mozilla viewer, however 
unless we can identify a more accessible viewer or authoring tool, and 
believe he was aware of this, the generalisation would still hold true, 
though I accept it is unlikely he was referring to the spec itself. 
However in true W3 fashion the spec is not accessible to a wide 
Aaron has expressed interest in the proposed accessibility 
documentation, "Especially if it gets down to practical details"

the problem of link highlights being similar to their backgrounds 
applies equally to html, and can be found in the wild. this issues is 
many magnitudes of order less frequent than the default, which as we 
know barely exists for SVG.

let's hope we can start creating these essential SVG accessibility 
documents sooner rather than later, and let's ensure these documents 
are truly accessible to a wider audience.


Jonathan Chetwynd
http://www.peepo.co.uk     "It's easy to use"
On 9 Nov 2004, at 01:42, Doug Schepers wrote:

Hi, Jonathan-

Sorry about the last post... An errant slip of the finger sent it 
merrily away before I'd managed to type anything.

I agree that every effort should be made to make SVG as accessible as
possible, and I'm glad that you're bringing up these issues.

I think that specific issues should be raised and addressed, however. 
speak more about this toward the end.

Jonathan Chetwynd wrote:
<snip />
| The Mozilla accessibility expert Aaron Leventhal was recently quoted:
| "SVG is not accessible yet at all"

I'm not sure that you're putting that in the right context, Jonathan. 
actual quote is:

"ML: How accessible should we expect new applications developed on 
technologies to be? Like for example the Mozilla Amazon Browser. Do
programmers have to take care of anything special to insure their 
accessibility? To what extent? I would guess that keyboard support is 
good with the core technologies, but what about screen reader support?

"AL: [...] The answer for web content is easy. Alas, SVG and MathML are 
accessible yet at all. Static HTML is fine as long as gudelines and 
sense are followed (disclaimer: some assistive technologies still don't
support Mozilla well, such as the JAWS screen reader). Dynamic web 
is still a problem that we're working on." [1]

I took that to mean that Mozilla's SVG implementation is not accessible 
This could be because, as you know, Mozilla does not yet support 
'title' or
'desc' elements.

I think it would be worthwhile contacting him to clarify why he believes
this to be so, in order to address his concerns.

| 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.

Macromedia is a company; the W3C is a standards consortium; you're 
apples and oranges. Macromedia has taken hits in the past regarding
accessibility, and I suspect that this is in large part a PR ploy.

You speak of people with learning disabilities using Flash and not SVG, 
I don't think they are hand-coding the Flash. I think that they are 
using a
tool to do it. There is a paucity of well-distributed SVG authoring 
(though some fine ones exist). With the right authoring tool, these same
user-authors could just as easily create SVG as Flash, but the W3C 
make authoring tools, they make language specifications.

| 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?

Yes, there is evidence, and it's called SVG1.2. There are numerous
enhancements that will aid in accessibility. One of them is Vector 
as Jim rightly mentions. Another is the addition of tooltips and the 
element, which preserves 'title' and 'desc' from being misused and will
provide the user with instructions on how to use an element or control 
like the 'alt' attribute, but better). Another is the navigation
considerations, including navindex, directional navigation, and 
elements. Another is improved keyboard and mouse support (for instance, 
think some people would have an easier time using the wheel). Another is
sXBL, which will allow for the visual rendering of XML, while retaining
access to the semantics of the model.

You brought up an interesting point on svg-dev. Should SVG1.2 allow 
users to
provide their own sXBL components, much as alternate CSS stylesheets 
can be
used for HTML pages? It's up to the UA implementors to do this, but I 
it's worth mentioning in the Spec. A user could provide their own sXBL
templates for known XML ontologies and models (like XForms or MathML or
whatever), which would help them render it in a manner more suitable for
their own needs. The authoring community could work to provide alternate
accessible sXBL; perhaps the Spec could talk abou how even the primary
author can provide several different components, each applicable to a
different need. This is a good feature from CSS that shouldn't be 

| *<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."

On the very page you're talking about are the answers to your questions
about how this is to be done. [2] At the end of the page, there are 2
examples that would be applicable. One example creates a double-stroke, 
the other uses "vector effects to produce shared borders on paths". 
these two, and you have a distinctive double-outline that surrounds all 
each of) the elements in the shape. Vector Effects are simpler to create
than filters, and once one author makes them, other authors can use 
With a good authoring tool, this too would be a snap.

| 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.

Again, the fault lies with the authors. How often do authors remove the
underlines and coloration from links? It's terrible practice, but all 
common. You can't control authors.

| 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.

With the 'title', 'desc', 'hint', and 'metadata' elements all separate, 
available on almost all elements, I think that their purpose is much 
clear than an 'alt' attibute.

| 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.

I don't find fault with this, but what should the defaults be?

A border or outline of a certain color is not always appropriate for 
SVG document or application, nor for each particular type of disability.
Consider these use cases:
* A picture of a bird flying in a blue sky; clicking on the bird takes 
to a page about flying. If the default color of the surrounding outline 
is blue, it won't be visible against the blue sky (especially to people 
poor eyesight); it won't be visible at all to a person without any 
* An organization chart visualized as a set of interconnected boxes vs. 
same org chart represented in a set of dropdown menus that pull up 
lists of people connected to the person chosen. In the first case, 
a colored outline around the box and the interconnects might be good, 
for the second you'd want to highlight the text behind the person 
chosen on
the dropdown while you're chosing it, then transfer the name to the
associated textbox and close the menu. These are very different 
and the same visual cues would not suffice for both.

| 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.

Nobody is arguing that SVG shouldn't have links, and as you know, the
':active', ':visited', and ':hover' pseudoclasses are mandated in SVG; 
only MozSVG implements them, and only in a rather buggy fashion, is the
fault of the implementors.

I think that you have a good suggestion in trying to organize a Best
Practices group, and I applaud your work toward making accessible GUI
standards. I think you should continue your efforts along those lines. 
can only go so far; it's up to authors and implementors to make the 

I intend on making an sXBL widget set, and I will make it as 
rich and accessible as possible.


[1] http://nostalsong.com/mozillalinks/html/links23_full.html#community
[2] http://www.w3.org/TR/SVG12/vectoreffects.html#vectorEffect-examples
Received on Tuesday, 9 November 2004 09:33:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:29:24 UTC