It’s a good day when you can verify an accessibility bug has been resolved.

In this case I’m referring to a long standing Webkit bug that had been filed concerning image elements (<img>) which referred to a .svg source.

For instance,

<img src="my-image.svg" alt="i mean something!">

In mid-2018 this bug was filed with WebKit as the above markup would result in VoiceOver announcing the image as a “group”. Unexpected, but not as bad as the iOS experience where the <img> was entirely ignored by VoiceOver, regardless of the alt containing a text string or not.

The workaround (hack) here was to declare a role=img on the <img> element.

<!-- redundant roles are redundant -->
<img src="my-image.svg" role="img" alt="i mean something!">

This generally would not be recommended, as it would be an unnecessary use of ARIA to explicitly declare the element’s implicit role. But, fortunately this mismatch of what’s generally recommended vs this specific use case can start to be put to rest.

In early 2021, an update was made (see comments in above linked Webkit bug) to address this issue, though this update was not immediately available due to Safari’s release schedule.

As of September 2021, the update has been confirmed with Safari 14.1.2 on macOS 11.5.2, and iOS 14.7.1. An <img> with a .svg source now announces as an ‘image’ with the alt providing its accessible name. It is not ignored by iOS Safari and VoiceOver. If an alt or alt="" is specified on the image, it is ignored by VoiceOver as would be the general expectation for declaring a graphic, rendered as an <img>, as decorative.

See the Pen img src=.svg by Scott (@scottohara) on CodePen.

Viewing the ‘bug’ in a different light

It is worth mentioning that there are some legitimate reasons as to why Webkit may have exposed such an image with an .svg source in this way, as it’s not always fair to assume that all unexpected behaviors are 100% “bugs”. Sometimes, there can be a bit of nuance. For instance, SVGs are unlike raster images, both because of their scalable nature, but also because they have their own DOM which can include content which may need to be accessible.

While there was a significant issue with the iOS VoiceOver behavior, with the context of how an SVG would otherwise need to be exposed, if not a source of an <img> element, it is not entirely outside of the realm of reason as to ‘why’ such images were exposed as ‘groups’.

However, the underlying issue here being that an <img> was not specified by HTML to expose descendant elements of any sort. But, had the DOM of the .svg been exposed to the accessibility tree while being a source of an <img>, then this issue might have been closed outright as by design. And truly, that would have made sense so long as the SVG and its contents could have been fully accessible.

In the end though, as this behavior is not possible with an <img>, it’s great to see an inconsistency of behavior for users (primary goal) and developers (secondary) be addressed.