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

Doug,

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

regards

Jonathan Chetwynd
http://www.peepo.co.uk     "It's easy to use"
irc://freenode/accessibility
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 
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 09:33:06 UTC