Re: aria-ACTION-2007: Rewrite proposal to take into account that an img with source svg has no children and also to address the required owned elements

(apologies for the premature "send". GMail UI puts the send button
dangerously close to the formatting button.)

I am glad the working group is discussing this issue, as the
Safari/VoiceOver behavior with regards to SVG in HTML <img> has come up a
few times as a complaint from authors.

Some important points to note:

   - Although this discussion primarily focuses on SVG images, it could
   apply to any image format which was itself an accessible document. For
   example, if a browser supported PDF within the <img> tag, or if a browser
   used metadata in other image formats to create accessible alternative text.

   - The appropriate alternative text for a given use of an image, however,
   can only be determined by the context of the web page in which it is used.
   A single image file can have different alternatives in different contexts.
   Alternative text in the image file should not override alternative text
   provided within the context of the web page.

   - Most browsers allow users to "open an image in a new tab" or some
   similar command.  This already provides a way for readers to explore the
   full data of the image, separate from its use in the HTML page.  The
   question is whether that full document should be considered a nested
   document within the main page.

   - Even if an image was treated as a nested document (similar to an
   <object> or <iframe>), the default ARIA role for <img> is "img", and an
   element with role="img" should have all children treated as
   presentational.  The current accepted workaround for the Safari/VoiceOver
   behavior (among web page authors who bother to test in screen readers) is
   to explicitly set role="img" on their <img> elements. This shouldn't be
   necessary, but it currently is required for the screen reader to use the
   author-supplied alternative text instead of the alternative text (if any)
   in the referenced image file.

   - But this brings up the question of what to do if the author specifies
   role="presentation" or "none" on an <img>.  If the image is treated as a
   nested document like <object> or <iframe>, such a role would make the
   nesting transparent and would expose its contents.  This is contrary to all
   author expectations for <img role="presentation"> (or its equivalent, an
   empty alt attribute).

   - The approach proposed by Rich (in the separate email thread [1]) is to
   add special rules for the interpretation of a presentation/none role on an
   <img> element. These special rules are only necessary if you first accept
   the interpretation that an <img> is an embedded document, equivalent to
   <object> or <iframe>.


   - Although an image is defined in a separate document, and the graphical
   rendering of that document is embedded in the page, an <img> is not treated
   as an embedded document in HTML.  It is not a "nested browsing context".
   It is strictly forbidden from including any interactivity (from HTML
   5/WHATWG: "User agents must not allow the resource to act in an interactive
   fashion, but should honor any animation in the resource."[2][3])

   - As already mentioned by other contributors to this thread, there is
   also no standard API to access an image's document object from an HTML
   image element.  Unless and until HTML provides such an API, expecting
   accessibility tools to have access to that document is problematic for many
   implementations.

I would therefore suggest that any extra rules for <img> and
role="presentation" in ARIA merely confuse matters.  What is needed is to
clearly state (probably in the HTML-AAM) that an HTML <img> is not a nested
document, and does not have child content, consistent with the HTML spec.
A variation on Rich's proposed text could be:

Whether the <img> is used to refer to a raster image (e.g. <img
src=“foo.jpg”>) or a vector graphics image <img src=“foo.svg”> it is
treated as a single entity, with no child contents.  An <img> element with
role="presentation" or role="none" therefore is effectively hidden from the
accessibility tree.  If the author intends for the content of the image
document to be accessible to users, it should be embedded using an <object>
, <embed>, or <iframe>, or (for SVG images) included inline in the main
document.

Again, I believe the appropriate place for this normative text would be
HTML-AAM, not ARIA 1.1, though I would not object to an informative note or
example in ARIA.

All that said, to ensure maximum robustness & accessibility, additional
options for exposing alternative text in image files could include:

   - Recommending that, if an author has not provided an accessible name
   and/or 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 alt text.  It's a matter of recommending that they do so more
   intelligently (looking at file contents not just file names), and that they
   also extract long descriptions if provided in metadata or SVG desc content.

   - Recommending that user agents & ATs provide a way for users to open an
   embedded image as its own document.  ATs could in particular 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.

I hope that adds to the discussion (more so than my previous incomplete
email, anyway!),

Amelia Bellamy-Royds

[1]: https://lists.w3.org/Archives/Public/public-aria/2016Jan/0127.html
[2]: https://www.w3.org/TR/html5/embedded-content-0.html#the-img-element
[3]:
https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element