RE: Making Accessible Images available from HTML <img>

Bryan,

I think it would be worth while to have an SVG accessibility task force
call with folks interested in MathML.

                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>,
            "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Cc: SVG-A11y TF <public-svg-a11y@w3.org>, ARIA Working Group
            <public-aria@w3.org>
Date: 01/28/2016 02:52 PM
Subject: 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