Making Accessible Images available from HTML <img>

The ARIA WG has been discussing the proper way to expose accessible SVG
graphics (and theoretically, other accessible image types) embedded in a
webpage using HTML <img> element.  It came up as a side effect of
discussing how to ensure that presentational images are treated
consistently, regardless of image format.

Any normative recommendations on this matter are probably best put in the
HTML-AAM, so we wanted to bring it to the attention of the full HTML
Accessibility task force.  It is also likely of interest to SVG
Accessibility task force members.

Key email threads from the public-aria mailing list:

   - Should SVG in <img> be treated as a single entity or as an embedded
   document, with child content?
   https://lists.w3.org/Archives/Public/public-aria/2016Jan/0097.html
   - Proposed wording for the ARIA section on role="presentation" to
   indicate that a presentational image is completely hidden:
   https://lists.w3.org/Archives/Public/public-aria/2016Jan/0127.html

It was also discussed on the 28 January 2016 ARIA WG teleconference.

For background, when an SVG file is embedded in HTML using <object>,
<iframe>, or as inline markup, it's entire document structure is available
to assistive technologies. With <object data="foo.svg"
role="presentation">, the embedded object becomes transparent and the
accessible representation of the document should be the same as for inline
SVG code.

In contrast, for <img src="foo.svg" alt="" role="presentation">, the SVG
document is not used at all, and the presentational image is effectively
hidden.  The text proposed for ARIA 1.1 would confirm & emphasize this
difference.  Similar text may be appropriate in HTML-AAM.

The matter has come up, in part, because Safari/WebKit with VoiceOver has
(since last year) treated <img> with SVG source as an embedded document.
This causes problems for authors, who expect a consistent behavior for an
<img> regardless of the type of image file.

The motivation for the WebKit behavior is sound, however: make accessible
graphical files available to users of assistive technologies.  "Accessible
graphical files" currently means SVG, but could conceivably include other
image formats (such as PDF used as image, or JPEG with metadata
descriptions in EXIF data).

I therefore proposed 2 possible other ways in which user agents & assistive
tech could make accessible alternatives in image files available to users.
Since they relate to the behavior of the HTML <img> element, they would
probably be best specified within HTML-AAM, if the HTML-A11y task force
finds them useful:

   1. If an author has not provided an accessible name and description for
   an <img>, the user agent should attempt to extract one from the referenced
   image file.  This is already done, sort of, for synthesizing
   bare-minimum alt text.  It's a matter of recommending that browsers do it
   more intelligently (looking at file contents not just file names), and that
   they do so not only for a missing accessible name, but also to provide
   users with long descriptions when available from image metadata or SVG
   content.
   2. User agents & ATs should provide a way for users to open an embedded
   image as its own document.  Most user agents already provide a context-menu
   option to "view image in new tab" or similar.  However, this would be more
   useful if non-visual ATs would indicate to users if the image document
   included browse-able alternative text content (since screen reader users
   would not by default expect to get additional content from an image file).

Both of these options make alternative text in the image file available to
interested users, but ensure that it is secondary to any text alternatives
provided by the web page author, and that it does not distract from the
overall structure of the main document.


~Amelia Bellamy-Royds