There is presently no standard for what screen readers should do with inline
SVG islands. We are spearheading an effort by DAISY and the W3C SVG Working
Group to create SVG accessibility standards. One proposal is that screen
readers read the root-level <title> and <desc>. This is most elegantly
accomplished by having those two properties appear separately in the
accessible DOM elements exposed to screen readers. Presently IE9 does this
but also exposes <title> and <desc> of all graphical objects - which we
believe is overkill and annoying. We have asked Microsoft to change this.
Other browsers seem to expose nothing in SVG to screen readers while
traversing a document linearly. We are requesting that all browsers be
updated to include this feature, and we hope that Safari can be updated to
do this.

(In reply to comment #0)
> There is presently no standard for what screen readers should do with inline
> SVG islands.
The W3C Note 'Accessibility Features of SVG' [1], from 2000, does discuss SVG accessibility, but as mentioned, it does not normatively define precisely what screen readers should do.
Also, there are some specific suggestions in the SVG Tiny 1.2 spec [2] for both authoring content and screen readers, but it could use more precise and normative instructions. The SVG WG plans to do this in an upcoming SVG Accessibility specification, and as part of SVG 2.
> We are spearheading an effort by DAISY and the W3C SVG Working
> Group to create SVG accessibility standards. One proposal is that screen
> readers read the root-level <title> and <desc>.
This is suggested in SVG, most recently in SVG Tiny 1.2 [3].
> This is most elegantly
> accomplished by having those two properties appear separately in the
> accessible DOM elements exposed to screen readers. Presently IE9 does this
> but also exposes <title> and <desc> of all graphical objects - which we
> believe is overkill and annoying. We have asked Microsoft to change this.
If all the elements are exposed at once, this is indeed overkill, but if they are exposed as discrete elements when the immediate parent is in focus, then it is appropriate, just as progressively exposing any structure text content (e.g. in HTML) is useful.
The key is in defining the navigation behavior so users can explore the content, or skip over it, at their own discretion. This will take coordination between the author of the content structure and the screen reader software, though a well-defined algorithm.
> Other browsers seem to expose nothing in SVG to screen readers while
> traversing a document linearly. We are requesting that all browsers be
> updated to include this feature, and we hope that Safari can be updated to
> do this.
We also need to consider the order in which text content is made available (presumably document order should be the default, with possible overrides), and when labels should be used instead of 'title' and 'desc' elements.
This should all be discussed on the public SVG mailing list, www-svg@w3.org, and standardized as part of SVG.
[1] http://www.w3.org/TR/SVG-access/
[2] http://www.w3.org/TR/SVGTiny12/access.html
[3] http://www.w3.org/TR/SVGTiny12/struct.html#uiTitleDescBehavior

(In reply to comment #3)
> Related to bug 120709, which also includes the Radar link.
>
> https://svgwg.org/svg2-draft/single-page.html#chapter-access
I agree with Doug that the desc and title elements should not just be ignored. They are meant to describe aspects of certain groups of presentations.
I don't know if they all should be read at once though. I agree that they can provide noise if the SVG is just a graphic which might not be part of the paragraph and main text content.
To allow navigation and a general structure that can be detected by the screen reader would be great.

Here is a very minimal example to demonstrate that the title *could* make sense.
<svg xmlns="http://www.w3.org/2000/svg">
<title>This is a title</title>
<circle cx="50" cy="50" r="50">
<title>This is a very round circle.</title>
</circle>
</svg>
I think many title elements in the first attached example are misused. People often use <title> for on mouse hover text.