RE: Making Accessible Images available from HTML <img>

Since this involves the HTML taskforce, would there be any benefit in including MathML as part of this equation?

I’m not sure if this is applicable or being addressed separately, but there looks to be a lot of overlap with the ability to provide accessible information consistently within complex mathematical formulas via the ‘math’ element.


From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com]
Sent: Thursday, January 28, 2016 11:16 AM
To: public-html-a11y@w3.org
Cc: SVG-A11y TF <public-svg-a11y@w3.org>; ARIA Working Group <public-aria@w3.org>
Subject: 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