Re: Draft note about text alternatives for SVG Native

My answers to questions:

1. Do we only care about providing alt text for the image as a whole? Do we
> only care about the <title>, or do we care about the <desc> too? I think we
> should care about both, but both should be optional.


I prefer title and desc. Both optional. (Recommended by "accessibility
considerations" section)

2. Do we care about the ability to provide alt text for _parts_ of the
> image? (I'm not sure; I think this could be unreasonably onerous because it
> would invite the notion of accessible name calculation, though I am
> inexperienced with SVG, and interested in your views.)


Don't care about parts. This doesn't seem to be a point of parity with
other formats.

3. Do we care about supporting _visual_ text rendering within the image? (I
> think we shouldn't, as this is explicitly removed for everyone [4], whereas
> the lack of alt text is by definition only excluding _some_ users.)


Don't care. Again, not an issue of parity with PNG et. al.

4. Would we _require_ renderers to expose the name and description to the
> platform's accessibility API if it has one? We compare SVG Native to PNG et
> al, but none of those (to my knowledge) require this level of exposure of
> info, and I suspect that would be a big sticking point for SVG Native. But
> if it's not required, it probably won't happen. Would we be happy with a
> "should" rather than a "must"? NOTE: I have not clarified our position on
> this point in the current draft response.


I'm okay with a SHOULD rather than MUST. But again, I'd like to see it
recommended in the "accessibility considerations" section.
*--*
*Paul Grenier*
*[image: github] <https://github.com/AutoSponge>**[image: twitter]
<https://twitter.com/AutoSponge>**[image: linkedin]
<http://www.linkedin.com/in/pgrenier>*

On Fri, Apr 15, 2022 at 10:59 AM Matthew Atkinson <matkinson@tpgi.com>
wrote:

> Hi all,
>
> Here is my draft comment on SVG Native [1] per the GitHub issue [2] we
> discussed [3] on Wednesday. Please let us know your thoughts on it, and the
> following questions.
>
> 1. Do we only care about providing alt text for the image as a whole? Do
> we only care about the <title>, or do we care about the <desc> too? I think
> we should care about both, but both should be optional.
>
> 2. Do we care about the ability to provide alt text for _parts_ of the
> image? (I'm not sure; I think this could be unreasonably onerous because it
> would invite the notion of accessible name calculation, though I am
> inexperienced with SVG, and interested in your views.)
>
> 3. Do we care about supporting _visual_ text rendering within the image?
> (I think we shouldn't, as this is explicitly removed for everyone [4],
> whereas the lack of alt text is by definition only excluding _some_ users.)
>
> 4. Would we _require_ renderers to expose the name and description to the
> platform's accessibility API if it has one? We compare SVG Native to PNG et
> al, but none of those (to my knowledge) require this level of exposure of
> info, and I suspect that would be a big sticking point for SVG Native. But
> if it's not required, it probably won't happen. Would we be happy with a
> "should" rather than a "must"? NOTE: I have not clarified our position on
> this point in the current draft response.
>
> Here's my draft response...
>
> "
> We are concerned that removing the ability to specify an accessible name
> and description for the image (i.e. <title> and <desc>) would present
> accessibility barriers, and would limit the capabilities of SVG Native
> compared to other image formats.
>
> We're concerned about the lack of ability to specify an accessible name
> and description because content authors would have to take extra steps to
> provide that information when working in the native context versus on the
> web. By allowing the use of <title> and <desc> in SVG Native, authors could
> use the same file in both contexts. Many operating environments provide a
> platform accessibility API, and accessibility properties onto which the
> <title> and <desc> values could be mapped.
>
> Other image formats provide for similar metadata: the PNG spec provides
> for various metadata, including an image description [0]; GIF and JPEG
> files provide for metadata and text comment storage.
> "
>
> best regards,
>
>
> Matthew
>
> [0] https://www.w3.org/TR/PNG/#4Concepts.AncillInfo
> [1] https://svgwg.org/specs/svg-native/
> [2] https://github.com/w3c/svgwg/issues/874
> [3] https://www.w3.org/2022/04/13-apa-minutes.html#t05 and
> https://www.w3.org/2022/04/13-apa-minutes.html#t07
> [4] https://svgwg.org/specs/svg-native/#text
> --
> Matthew Tylee Atkinson (he/him)
> --
> Senior Accessibility Engineer
> TPG Interactive
> https://www.tpgi.com
> A Vispero Company
> https://www.vispero.com
> --
> This message is intended to be confidential and may be legally privileged.
> It is intended solely for the addressee. If you are not the intended
> recipient, please delete this message from your system and notify us
> immediately.
> Any disclosure, copying, distribution or action taken or omitted to be
> taken by an unintended recipient in reliance on this message is prohibited
> and may be unlawful.
>
>