Clean up language re <title>/<desc> and tooltips

[nikosandronikos]

https://svgwg.org/svg2-draft/struct.html#issue20

I don't think there's anything important in Tiny 1.2 that isn't in SVG 2. Particularly, with the resolution of issue #100.
I'll open the issue in case anyone else has differing views and we can review in London.

[AmeliaBR]

(and clean-up re SVG accessibility issues for empty title/desc and multilingual)

[nikosandronikos]

Removed issue from the spec relating to taking text from SVG Tiny 1.2 in commit 41fa130

[AmeliaBR]

Also need to clean up re which elements can have a title/desc child. Currently the prose says "container" and "graphics" elements can have title & desc, but I think other elements allow descriptive elements in their content models, while switch elements now explicitly exclude them (see discussion in SVG Accessibility mailing list).

[nikosandronikos]

This is editorial, but needs to be rewritten in sync with the accessibility specs.

[AmeliaBR]

Cleaning up which elements can have title/desc extends to the FXTF specs, see w3c/fxtf-drafts#9

[jarek-foksa]

Besides container elements (excluding switch) and graphics elements, are you planning to allow descriptive elements as children of anything else? I'm not sure why pattern should be allowed to have a title, while linearGradient not.

[AmeliaBR]

My instinct is to allow them generously, except for where there is a direct logical conflict (like switch). We would need to be clear that a non-rendered element is not exposed to assistive tech simply because it has a description. However, you could use the description of the graphical effect element to generate a full description of the graphics:

<pattern id="dots"... >
  <title>blue and white polka dot pattern</title>
  ...
</pattern>

<path d="..." fill="url(#dots)" aria-describedby="dots">
  <title>Bow tie</title>
</path>

The phrase "blue and white polka dot pattern" would be available as an extra description on the shape because of the aria-describedby attribute. It could also be used simply as metadata in authoring tools to describe the pattern itself. But there would not be a pattern object in the accessibility tree when you view the graphic in a browser.

The alternative approach would be to forbid <title> and <desc> on all never-rendered elements. As @jarek-foksa notes, the current haphazard & inconsitent approach doesn't make sense.

[jarek-foksa]

@AmeliaBR thanks for clarification. I also think the first approach makes more sense now, though if further unification of SVG and HTML is going to happen, I would opt for limiting the places where <title> is allowed so that it would be easier be deprecate and replace it with the title attribute in future.

[AmeliaBR]

@jarek-foksa Switching to attributes would have the downside of removing the option to create multilingual titles. And besides, we've only finally got the browsers to start treating <title> correctly for accessibility purposes, why turn back now?

As @Tavmjong noted on the FXTF thread, we resolved today to "title and desc can be a child of any svg namespaced element except switch". After the fact, I thought of a few additional exceptions, however:

• <title> and <desc> can't have child <title> and/or <desc> because that would excessively complicate attempts to figure out which alternative text is intended.
• <script> and <style> don't have meaningful child content. The SVG spec currently allows them to have any child elements, but I'm pretty sure an HTML parser will treat it as character data.

Lots of other elements are unlikely to particularly benefit from descriptive content, but they wouldn't break so there's no reason to forbid it.

[AmeliaBR]

Leaving this issue open until we clean up the content model of all other elements to correctly include or exclude title & desc.

[AmeliaBR]

For the content model, it looks like there's no easy way to say "any possible child element except other title/desc" for the title/desc, so we'll just leave that as is. It doesn't really change anything, since we're already clear that markup inside title & desc is ignored. The rest of the content model (for other elements) has been cleared up: title & desc are allowed anywhere except script, style, & as a direct child of switch.