This sound interesting but quite off topic. "SVG is a language for describing two-dimensional graphics" [1], so requiring it to have a functionality to disable image rendering would be both counter intuitive and hard to understand: what is an "image" in SVG? a basic shape or a path? all that is not text? what if basic shapes/paths are used to draw text? many more questions like these can be posed...

In Batik's context, I'd personally label this as "wontfix" or "invalid" as this is a somehow transcendental question which seems to largely surpass the scope of Batik, but this is not enough clear to me to mark this myself - I'd prefer that either the reported or a project leader would recognize this and close this issue and/or post more information supporting this within Batik's context.

This may also slightly relate to bug 45486 [2], although in that scope what is being recommended is to show alternate content when a given resource is not available (but the specification points towards the use of a checkerboard in those cases).

[1] http://www.w3.org/TR/SVG/intro.html#AboutSVG
[2] https://issues.apache.org/bugzilla/show_bug.cgi?id=45486

#1 Helder, fixing this bug is part of the specification.

NB: parity Opera, already provides this facility

whilst it may be true that "SVG is a language for describing
two-dimensional graphics" that is only a small part of the story, and one that is taken out of context. SVG is text, may have text embedded, and certainly should have text metadata such as title content.

Blind users may not wish to have images renedered, unless to aid someone with them...

please read:

http://www.w3.org/TR/SVG/struct.html#DescriptionAndTitleElements

eg:

"User agents may, however, for example, display the 'title' element as a tooltip, as the pointing device moves over particular elements. Alternate presentations are possible, both visual and aural, which display the 'desc' and 'title' elements but do not display 'path' elements or other graphics elements."

"Authors should always provide a 'title' child element to the outermost 'svg' element within a stand-alone SVG document. The 'title' child element to an 'svg' element serves the purposes of identifying the content of the given SVG document fragment. Since users often consult documents out of context, authors should provide context-rich titles."

Google currently does not provide search by graphic, so relies on the text. and one easy historical way for the author to check on their alt content is to use lynx browser, or switch off images in other browsers. this applies equally to SVG files. 

this is my opinion, and of course I welcome further input, leaving as needinfo

it may be of interest that when using minefield/mozilla to view html pages, with images switched off, gifs and jpgs are not displayed, but svgs are, which is at best confusing.
I recognise that batik does not display html pages currently, however users expect consistency, and it is possible to embed many types of other content in svg, such as html, audio, video, etc....

(In reply to comment #2)
> #1 Helder, fixing this bug is part of the specification.

   Where does the SVG specification say that user agents
must allow images to be turned off and replaced with any
available title/desc element?

   I should say that it's not at all clear to me how you
would 'replace the image' with title and desc.  In a
tool tip you are free to overflow, but I wouldn't think
that would be a good option for an image.

> please read:
> http://www.w3.org/TR/SVG/struct.html#DescriptionAndTitleElements
> eg:
> "User agents may, however, for example, display the 'title' element as a
> tooltip, as the pointing device moves over particular elements.

   Batik already does this of course.

> Alternate presentations are possible, both visual and aural, which 
> display the 'desc' and title' elements but do not display 'path' 
> elements or other graphics elements."

   Also I should mention that these lines use the words 'may' and 
'possible' rather than 'must' or 'required'.

> "Authors should always provide a 'title' child element to the outermost 'svg'
> element within a stand-alone SVG document. The 'title' child element to an
> 'svg' element serves the purposes of identifying the content of the given SVG
> document fragment. Since users often consult documents out of context, authors
> should provide context-rich titles."

   Sure I agree that authors should provide title and desc elements.
Batik will display them (in fact quite a bit of work has gone into
displaying them in the face of dynamic modifications etc).

> Google currently does not provide search by graphic, so relies on the text. 
> and one easy historical way for the author to check on their alt content 
> is to use lynx browser, or switch off images in other browsers. this 
> applies equally to SVG files. 

> this is my opinion, and of course I welcome further input, leaving as 
> needinfo

   If there is really a spec requirment please provide it.

#4

Thomas,

it is the resaponsibility of developers to be aware and implelement the user agent guidelines, not bug filers to point to those W3C specification files.

 I have already stopped responding to, or filing mozilla bugs because of the unacceptable - to me - tone of responses.

I have also dramatically reduced my contributions to Opera, and Safari development, because of lack of progress.

the fact you do not know where to find the evidence, puts you in a weak not a strong position, however in this instance, you prefaced your request with a 'please'.

http://www.w3.org/TR/SVGMobile12/access.html#SVGUAAccessibilityGuidelines

"Provide a text-only view
SVG user Agents should provide mechanisms that allow assistive technologies to achieve a useful text-only view. Examples include a DOM explorer, a synchronized text only view, or an XSLT style sheet to convert the textual content to XHTML."

for SVG1.1 the UA guidelines were less developed:

http://www.w3.org/TR/SVG/access.html

" To conform to the SVG specification, an SVG user agent should conform to UAAG. "

uaag: http://www.w3.org/TR/UAAG10/guidelines.html#gl-feature-on-off

"Guideline 3. Allow configuration not to render some content that may reduce accessibility"


I'm frequently wrong, but do have over 10 years bug filing experience.
I'm unlikely to file further bugs, if I am expected to provide all the supporting evidence, as I already have literally hundreds of bugs filed across many applications, and simply don't have the time.

regards

(In reply to comment #5)
>  I have already stopped responding to, or filing mozilla bugs because
> of the unacceptable - to me - tone of responses.

IMHO your tone is pretty acerbic too, generally much more than the tone used to (usually constructively) criticize some of your out-of-topic or offending statements. Nevertheless, this is way off topic - I seriously believe that tone should be neutral and would prefer not to turn this thread into an opinion war. Please don't. :-|



> http://www.w3.org/TR/SVGMobile12/access.html#SVGUAAccessibilityGuidelines
> 
> "Provide a text-only view
> SVG user Agents should provide mechanisms that allow assistive technologies to
> achieve a useful text-only view. Examples include a DOM explorer, a
> synchronized text only view, or an XSLT style sheet to convert the textual
> content to XHTML."
> 
> for SVG1.1 the UA guidelines were less developed:
> 
> http://www.w3.org/TR/SVG/access.html
> 
> " To conform to the SVG specification, an SVG user agent should conform to
> UAAG. "
> 
> uaag: http://www.w3.org/TR/UAAG10/guidelines.html#gl-feature-on-off
> 
> "Guideline 3. Allow configuration not to render some content that may reduce
> accessibility"


There, wasn't too hard, was it? ;-p

It seems that there is now enough information to work with. :-)



> I'm frequently wrong, but do have over 10 years bug filing experience.
> I'm unlikely to file further bugs, if I am expected to provide all the
> supporting evidence, as I already have literally hundreds of bugs filed across
> many applications, and simply don't have the time.

I do believe that one should always invest time providing links to relevant parts of specifications. It's worth the effort, specially if it helps towards the issue being fixed (which is usually the case).

Often developers are more focused into solving problems than into reading the specs (although, in this particular case, Thomas is IMO one of the persons I know which have a better knowledge of the SVG specification, what can and cannot be done and how, as well as on its relation with the Batik implementation - not at all meant to sound flattering).



Hope you continue to contribute (not only within Batik but in general) with your accessibility background and knowledge, although I'd personally suggest a small amount of moderation. ;-)

Created attachment 22882 [details]
Test case

Instead of using an URL to a test case, which can be broken at anytime, it is (generally) a good practice creating a reduced test case and attaching it into the issue. I took the liberty of using the one available in the provided URL, although I recognize it much simpler - just a few shapes, text and title/desc elements.

(In reply to comment #5)
> #4
> it is the resaponsibility of developers to be aware and implelement the user
> agent guidelines, not bug filers to point to those W3C specification files.

   I'm sorry but I 100% disagree with this point.  If you claim that fixing
a bug is a requirement of a specification then I think that you have a
responability to point to the part of the specification you think requires
it.  At the very least you will be able to find that section
faster than the developer, since you are the one referencing it.

  If you are not willing to do this then what is the developer to do?
How long does a developer search (for SVG there are quite a number of 
multi-hundred page specs involved) before giving up?   How does a developer
'prove a negative'?  As you say you are sometime wrong...

> http://www.w3.org/TR/SVGMobile12/access.html#SVGUAAccessibilityGuidelines

   Thanks a lot!

> "Provide a text-only view
> SVG user Agents should provide mechanisms that allow assistive technologies to
> achieve a useful text-only view. Examples include a DOM explorer, a
> synchronized text only view, or an XSLT style sheet to convert the textual
> content to XHTML."

   So Batik includes a DOM explorer which honestly I would think would
be more useful for this.   Batik also supports (IIRC) XSLT style sheets
(I forget the details) although one to do the above transformation isn't 
built in.

   Finally, I want to comment that I never would have connected that 
spec section with "block images and display desc (and title?) as text." 
So it's very good that you provided the specification reference.

   Given we provide a DOM viewer do you think we meet this Accessibility
guideline?

> for SVG1.1 the UA guidelines were less developed:
> http://www.w3.org/TR/SVG/access.html
> " To conform to the SVG specification, an SVG user agent should conform to
> UAAG. "
> uaag: http://www.w3.org/TR/UAAG10/guidelines.html#gl-feature-on-off
> "Guideline 3. Allow configuration not to render some content that may reduce
> accessibility"

   This I think we are a bit sketchier on, but reading the Toggle images
point which is much closer to your request, it occurs to me that we
do support User Style sheets so turning off all images is pretty easy.
We can't easily replace the images with title/desc text, although the 
tool tips would still be active as long as you only set 'visiblity' to 
hidden (instead of 'display' to 'none').

   I can't promise when it might get implemented as right now none
of the comitters has much time to do new development on Batik. 

> I'm frequently wrong, but do have over 10 years bug filing experience.
> I'm unlikely to file further bugs, if I am expected to provide all the
> supporting evidence, as I already have literally hundreds of bugs filed 
> across many applications, and simply don't have the time.

   That is of course your perogative.  Might I suggest that simply 
providing the links and moving on would save you a lot of time over 
indulging in belittling the developers?  In the long run you might
even feel better.

   Thanks.

#678,

Thomas & Helder,

I am unlikely to respond to further bug requests.

you may feel it is simple and easier for me to find evidence in the spec. It isn't.

and when the response is generally "oh yes, accessibility, we wont be impleementing that any time soon." or similarly

" I can't promise when it might get implemented as right now none
of the comitters has much time to do new development on Batik."

This is generally known as 'taking the piss' in English.

hence I am relinquishing my interest in contributing further.

regards