Currently, if a page has an <img src="blah.svg" alt="blah"> (with an SVG as the src), Safari/VoiceOver completely skips the image and doesn't announce the alt attribute text. Only low-impact solution I found was explicitly adding role="img" - this then makes VO behave correctly <img src="blah.svg" alt="blah" role="img"> Expected: regardless of whether it's an SVG, PNG, or whatever, the <img> should not be skipped/ignored by VO and the alt should be announced, even without role="img"
<rdar://problem/21055846>
Basic test: http://codepen.io/patrickhlauke/full/XbjYGZ/
VO iOS and VO OSX do not behave exactly the same. on an img without role="img" VO iOS do not announce the alt value when you use svg as a source but when you use an accessible svg with a role img and aria-label on it, it announce the value used for aria-label of the svg file with VO osX if you use an accessible svg with role img and aria-label on it, it announce correctly the alt value used on the img element
This behavior was chosen to allow access to accessible contents of SVG. We need a few test cases that include inaccessible SVG contents (as reported) and other variants so no behavior represses.
The workaround Patrick mentions removes access to the descendant contents of the SVG.
Another test case from Deque. http://a11yideas.com/testcode/mwp/iOSsvg.html
I'm not entirely convinced this is a bug. Here's a summary of the issues at play. 1. By default, we expose SVG images as an AXGroup so that VoiceOver can navigate the descendants of accessible SVG images. (This is something of a workaround because VO on macOS assumes AXImages are leaf nodes. e.g. It assumes they contain no accessible descendants and does not interact with them. Existing VOenhancement request is pending.) 2. On these accessible SVG DOM trees, you can specify the title in contents of the SVG image, which should be spoken by VoiceOver. 3. Regardless of the role, you should be able to use the @aria-label attribute to specify the label. 4. If you use an explicit role="img" (as noted by Patrick Lauke), WebKit will expose the @alt value, but flattens the sub-DOM tree, thereby making the contents of the image non-navigable. I think #2, #3, and #4 represent reasonable workarounds in the short term, if the authors desire is to prevent access to the sub-DOM. If the bug report is that @alt should be used instead of the title of the src SVG, I'm not convinced it's the right thing to do, and I request more explanation.
Actually, I'm filing Deque's bug separately. Their example uses an entirely inaccessible SVG, so in that case, we should probably fall back to the behavior of a flattened bitmap image. bug 160705 AX: @alt and bounds ignored when using img[src] points to an inaccessible SVG
Seems this has been fixed. Testing with latest iOS11/Safari using http://codepen.io/patrickhlauke/full/XbjYGZ/, VO announces the first image correctly (using the alt)
Tested in both Safari/iOS 14 and Safari 14 on macOS Catalina, and this bug / behaviour still exists. Tested using the above Codepen http://codepen.io/patrickhlauke/full/XbjYGZ/ and on macOS the first image is announced "empty group", on iOS the image is skipped.
Just recently updated my original codepen (as it broke since it referenced an external SVG that disappeared since). Still seeing odd results and inconsistencies between macOS/Safari/VO and iOS/Safari/VO, which seem related to presence/absence of <title> inside the SVG worth reopening, or opening a new bug?
and apologies, i missed out re-linking the codepen https://codepen.io/patrickhlauke/pen/XbjYGZ
A similar demo (based on Patrick's) that shows the issue affects whether external SVGs or data: SVG images are used and also whether alt or aria-labelledby is used: https://www.tunetheweb.com/experiments/svg-images/ Also note comment about Image Rotor on MacOS which oddly seems to follow iOS's broken logic rather than MacOS's broken logic!