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

Hi, Jonathan-

Sorry about the last post... An errant slip of the finger sent it sailing
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. I'll
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. The
actual quote is:

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

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

I took that to mean that Mozilla's SVG implementation is not accessible yet.
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 mixing
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, but
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 tools
(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 doesn't
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 Effects,
as Jim rightly mentions. Another is the addition of tooltips and the 'hint'
element, which preserves 'title' and 'desc' from being misused and will
provide the user with instructions on how to use an element or control (much
like the 'alt' attribute, but better). Another is the navigation
considerations, including navindex, directional navigation, and focusable
elements. Another is improved keyboard and mouse support (for instance, I
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 thin
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 discarded.

 
| *<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, and
the other uses "vector effects to produce shared borders on paths". Combine
these two, and you have a distinctive double-outline that surrounds all (not
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 them.
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 too
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, and
available on almost all elements, I think that their purpose is much more
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 each
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 you
to a page about flying. If the default color of the surrounding outline link
is blue, it won't be visible against the blue sky (especially to people with
poor eyesight); it won't be visible at all to a person without any vision,
obviously.
* An organization chart visualized as a set of interconnected boxes vs. that
same org chart represented in a set of dropdown menus that pull up vertical
lists of people connected to the person chosen. In the first case, creating
a colored outline around the box and the interconnects might be good, while
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 behaviors,
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; that
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. SVG
can only go so far; it's up to authors and implementors to make the content
accessible.

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


Regards-
Doug

[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 01:42:12 UTC