Question - why does font awesome use <title> element in svg sprites?

[kpion]

Toying with SVG Sprites with Font Awesome Free 5.7.1 here.

And I'm trying to understand why do we have the <title> in the SVG sprite files, like this one:

<symbol id="user" viewBox="0 0 448 512">
    <title id="user-title">User</title>
    <path d="M224 256c70.7 0 ......"></path>
</symbol>

When I use i in the recommended way:

<svg class = 'fa-svg-icon'>
    <use xlink:href="icons/font-awesome/sprites/solid.svg#user"></use>
</svg>

I see a tooltip "User" which is not what I want. If I wanted it, I would give it to the parent element.

Here is a test page: https://kpion.github.io/stuff/font-awesome-issue/

I do understand I can use the js version, or write my own js which will remove the <title> but I don't really want to, plus I would really love to hear an answer to why?

I mean, I do know this is w3c's recommendation and is about accessibility, but I have a feeling there is sort of misunderstanding here. Because my guess is that those RFC's are focused on complex svg documents built of many components (the 'use' part), and therefore the suggestion about titles and descriptions applies to the components (in the scenario, where we have many of them in a complex svg).

I can't really find a reason to believe it's about using SVG files as single (non-composite, or composed of only one def) images/icons on a website / app.

IMO, right now the situation, by analogy, is like the PNG creators were adding a <title> tooltip to the files and website creators could not remove / modify them.

I'm pretty sure I do miss something here, just don't know how to identify it o.O

Note that there is also aria-label which seems much much more desired in this context.

p.s.
Although this is a draft, it's pretty clear for me, that the authors focus on the 'components' when they talk about 'title' and 'description': https://w3c.github.io/writing-accessible-svg/accessible-svg.html - I mean the whole <use> thing. For example they say:

Authors should include a desc element for each graphical object defined in the defs that they reference with a use element.

I also asked on SO, without any spectacular success: https://stackoverflow.com/questions/54385153/how-to-get-rid-of-title-on-mouse-hover-on-font-awesome-svg-icon-using-svg-sprit

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community.

Let's see what we can do to answer this

[kpion]

FWIW: I'll just add that this is a part of my "investigation" which started more than a week ago.

During that time I reached out two other icon creators / projects, with similar questions ("why", "what is the purpose, since this is document's creator responsibility imo").

One of the conversations is here: simple-icons/simple-icons#1189

TL;DR; :it seems we had a few misunderstandings there regarding my goals, but eventually the conclusion is that it's worth to consider moving to aria-label

Their currently active issue regarding this: simple-icons/simple-icons#1191

I really like the concept of using SVGs instead of fonts or raster images, for icons. They seem just perfect for this. But it has to be equally simple... that's why I'm bit stubborn here. Because I have a feeling we're very close :)

Ah, and @tagliala - thanks for your interest!

[gtibrett]

SVG has a lot of flexibility on how it can get an accessible name. For our testing engine, the order we check things is aria-labelleddby, aria-label, title (as an element inside the svg), desc and then a title attribute on the svg element itself. All those pass from an accessibility standpoint.

The important part from an a11y standpoint is having alternative text with context for each image. If you define a title in the sprite definition, but then choose to use that sprite with a different meaning somewhere, the alternative text might not be correct. Good example is "pen" vs "edit" for fa-pen.

My opinion is that <i class="fas fa-pen" title="Edit"></i> should be converted to <svg class = 'fa-svg-icon' title="Edit"> <use xlink:href="icons/font-awesome/sprites/solid.svg#pen"></use> </svg>

To the OP's point, I think that both title and aria-label should be supported and carried over as attributes to the SVG, which would allow people to define tooltips and/or screen-reader only aria-labels. (aria-labelledby would be nice to have, too)

[tagliala]

I personally agree with the OP and I think that the SVG sprite should skip accessibility titles and leave them to developers, as in the CSS framework.

It is because you may not need tooltip titles (decorative images) or the title does not meet the action, even in English speaking countries: it is better to set an "Edit" title to an edit action represented by "fa-pencil" instead of "pencil".

I've prepared a demo fiddle here: https://jsfiddle.net/tagliala/8o724syu/13/ but I didn't have time to test this deeply and I'm not an accessibility expert

[scottaohara]

So @gtibrett, just to make sure I'm understanding you correctly, are you suggesting that instances of <title> within an <svg> be converted to <svg title="foo"> ?

For some more info though, consider the following:

<svg focusable="false" width="66" height="66" xmlns="http://www.w3.org/2000/svg" title="svg title">
  <use xlink:href="#ex"></use>
  <!-- referenced #ex has a <title>AccName</title> as a child element -->
</svg>

Hovering over the SVG in Chrome will not display "svg title" as the native tooltip, but will display "AccName" from the <title>.

However, VO + Chrome will announce "svg title" as the accessible name of the SVG (but without role="img" VO will announce it as a "group") on Window Chrome + JAWS 2019, it will announce the SVG as a graphic.

[gtibrett]

@tagliala I ran our testing engine against your fiddle and it did not identify any a11y name calculation issues. Meaning, all of those are considered valid.

Note, the 3rd example could also be written as the following to the same affect.

<button>
  <svg class="fa-svg-icon" aria-label="Modifica">
    <use xlink:href="#pencil"></use>
  </svg>
</button>

@scottaohara I am advocating leaving the <title>AccName</title> out of the referenced sprite. My take is that the sprite file should be hidden from screen readers (as it is for visual users). The title/aria-label/etc should only be implemented in individual instances of a sprite to provide proper context.

The image example that I think is analogous is a picture of the Grand Canyon. The PNG doesn't have a title embedded. When you use that image in a site about National Parks, you would set alt="The Grand Canyon at sunset" but when you use it on a page about a family vacation, you would set alt="Brett and family at the Grand Canyon"

Sorry, that feels excessive. But my point is, the sprites never have context, so I don't think they should ever have titles.

[scottaohara]

Thanks for the clarification @gtibrett.

I've been doing testing on how different screen readers / browser pairings actually parse varoius patterns for svgs and images (both as stand alone content and within the context of links and buttons)

results have been....interesting... unfortunately, more on that later.

[robmadole]

@gtibrett @scottaohara one thing we've tried to do is make Font Awesome "accessible by default". Does removing the <title> from the sprite go against this? If the answer is, "yes", aren't we putting the entire impetus on the developer using the sprite? I might get behind this but we'll need to beef up the documentation.

[gtibrett]

You can maintain "accessible by default" with some conditional logic. If attributes title, aria-label, aria-labelledby aren't present in the <i> shorthand, then the non-sprite <svg> should contain aria-hidden="true". If they are present, that attribute should not be included. The assumption there is that the developer will decide when a title or label is needed but expect the default is that the image will be hidden from screen readers, which is how I use FA now.

[kpion]

If ... I may put my two cents :) "Logic" requires, well, "logic", e.g. javascript, if I understand correctly the concept. IMO if it's possible (and it is possible with SVG images and SVG sprites), then by default no image/icon package should require javascript. Neither should they enforce anything they aren't responsible for. They are... image packages.

I know you know what I mean :) the https://en.wikipedia.org/wiki/Single_responsibility_principle and the "do one thing well" philosophy in unixes - https://hackaday.com/2018/09/10/doing-one-thing-well-the-unix-philosophy/

Image packages should not be responsible for a11y or anything beyond being an .. image package IMO :)

You guys gave those good examples why it is simply bad, the "Grand Canyon", the ""Edit" title", the "it's English only anyway" examples above, it's just wrong... It should be the other way, the 'title' could be available ... somewhere (aria-label?), and then those users who want could use one line of js / whatever to grab it and make browsers to display it. I.e. opt-in, not opt-out.

[robmadole]

@kpion thank you for bringing this up!

@gtibrett has a good point:

the sprites never have context

So during our build step when we are creating these sprite files we simply take the label from the icon's metadata and apply it. This is really short-sighted and ineffectual. And by having a <title> tag in the <symbol> definition we actually make it difficult to make this accessible.

I put together this demo that shows exactly how nasty this becomes: https://github.com/robmadole/svg-sprite-titles

Notice that the second stroopwafel still uses the <title> from the <symbol> even though I've defined a different title and used aria-labelledby

I'm in favor of removing <title> altogether because this is actively preventing anyone who wants to use the sprite to display a tooltip or make this work for screen readers (I think!).

@gtibrett you mentioned "with some conditional logic" we could make this accessible by default. Since SVG sprites are more akin to PNG images we really don't have the option to run any conditional logic on these as far as I can tell.