W3C home > Mailing lists > Public > public-aria@w3.org > January 2016

RE: Making Accessible Images available from HTML <img>

From: Fred Esch <fesch@us.ibm.com>
Date: Thu, 28 Jan 2016 14:57:03 -0500
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

z{S}ĝxjǺ
z{mʗ{٥r
z{Ch+bx)<html><body><p>Bryan,<br><br>I think it would be worth while to have an SVG accessibility task force call with folks interested in MathML.  <br><br><br>
<table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="473" colspan="2" valign="middle"><div align="center"><font size="4" face="Verdana">Regards, <br><br>Fred Esch <br>Watson, IBM, W3C Accessibility</font></div></td></tr>
<tr valign="top"><td width="130" valign="middle"><img src="cid:1__=0ABBF5DBDFFED1658f9e8a93df938690918c0AB@" width="163" height="23" alt="IBM Watson" align="bottom"></td><td width="342" valign="middle"><font size="4" face="Verdana">Watson Release Management and Quality </font></td></tr></table><br><br><img width="16" height="16" src="cid:2__=0ABBF5DBDFFED1658f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for Bryan Garaventa ---01/28/2016 02:52:40 PM---Since this involves the HTML taskforce, would there be an"><font color="#424282">Bryan Garaventa ---01/28/2016 02:52:40 PM---Since this involves the HTML taskforce, would there be any benefit in including MathML as part of th</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">Bryan Garaventa &lt;bryan.garaventa@ssbbartgroup.com&gt;</font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">Amelia Bellamy-Royds &lt;amelia.bellamy.royds@gmail.com&gt;, &quot;public-html-a11y@w3.org&quot; &lt;public-html-a11y@w3.org&gt;</font><br><font size="2" color="#5F5F5F">Cc:        </font><font size="2">SVG-A11y TF &lt;public-svg-a11y@w3.org&gt;, ARIA Working Group &lt;public-aria@w3.org&gt;</font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">01/28/2016 02:52 PM</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">RE: Making Accessible Images available from HTML &lt;img&gt;</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font color="#1F497D" face="Calibri">Since this involves the HTML taskforce, would there be any benefit in including MathML as part of this equation?</font><br><font color="#1F497D" face="Calibri"> </font><br><font color="#1F497D" face="Calibri">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.</font><br><font color="#1F497D" face="Calibri"> </font><br><font color="#1F497D" face="Calibri"> </font><br><b><font face="Calibri">From:</font></b><font face="Calibri"> Amelia Bellamy-Royds [</font><font face="Calibri"><a href="mailto:amelia.bellamy.royds@gmail.com">mailto:amelia.bellamy.royds@gmail.com</a></font><font face="Calibri">] </font><b><font face="Calibri"><br>Sent:</font></b><font face="Calibri"> Thursday, January 28, 2016 11:16 AM</font><b><font face="Calibri"><br>To:</font></b><font face="Calibri"> public-html-a11y@w3.org</font><b><font face="Calibri"><br>Cc:</font></b><font face="Calibri"> SVG-A11y TF &lt;public-svg-a11y@w3.org&gt;; ARIA Working Group &lt;public-aria@w3.org&gt;</font><b><font face="Calibri"><br>Subject:</font></b><font face="Calibri"> Making Accessible Images available from HTML &lt;img&gt;</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">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 &lt;img&gt; element.  It came up as a side effect of discussing how to ensure that presentational images are treated consistently, regardless of image format.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">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.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Key email threads from the public-aria mailing list:</font><ul><ul type="disc"><li><font size="4" face="Times New Roman">Should SVG in &lt;img&gt; be treated as a single entity or as an embedded document, with child content? </font><u><font size="4" color="#0000FF" face="Times New Roman"><br></font></u><a href="https://lists.w3.org/Archives/Public/public-aria/2016Jan/0097.html"><u><font size="4" color="#0000FF" face="Times New Roman">https://lists.w3.org/Archives/Public/public-aria/2016Jan/0097.html</font></u></a><li><font size="4" face="Times New Roman">Proposed wording for the ARIA section on role=&quot;presentation&quot; to indicate that a presentational image is completely hidden:</font><u><font size="4" color="#0000FF" face="Times New Roman"><br></font></u><a href="https://lists.w3.org/Archives/Public/public-aria/2016Jan/0127.html"><u><font size="4" color="#0000FF" face="Times New Roman">https://lists.w3.org/Archives/Public/public-aria/2016Jan/0127.html</font></u></a></ul></ul><font size="4" face="Times New Roman">It was also discussed on the 28 January 2016 ARIA WG teleconference.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">For background, when an SVG file is embedded in HTML using &lt;object&gt;, &lt;iframe&gt;, or as inline markup, it's entire document structure is available to assistive technologies. With &lt;object data=&quot;foo.svg&quot; role=&quot;presentation&quot;&gt;, the embedded object becomes transparent and the accessible representation of the document should be the same as for inline SVG code.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">In contrast, for &lt;img src=&quot;foo.svg&quot; alt=&quot;&quot; role=&quot;presentation&quot;&gt;, the SVG document is not used at all, and the presentational image is effectively hidden.  The text proposed for ARIA 1.1 would confirm &amp; emphasize this difference.  Similar text may be appropriate in HTML-AAM.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">The matter has come up, in part, because Safari/WebKit with VoiceOver has (since last year) treated &lt;img&gt; with SVG source as an embedded document.  This causes problems for authors, who expect a consistent behavior for an &lt;img&gt; regardless of the type of image file.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">The motivation for the WebKit behavior is sound, however: make accessible graphical files available to users of assistive technologies.  &quot;Accessible graphical files&quot; currently means SVG, but could conceivably include other image formats (such as PDF used as image, or JPEG with metadata descriptions in EXIF data).</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">I therefore proposed 2 possible other ways in which user agents &amp; assistive tech could make accessible alternatives in image files available to users.  Since they relate to the behavior of the HTML &lt;img&gt; element, they would probably be best specified within HTML-AAM, if the HTML-A11y task force finds them useful:</font><ul>1.        <font size="4" face="Times New Roman">If an author has not provided an accessible name and description for an &lt;img&gt;, 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.</font><br>2.        <font size="4" face="Times New Roman">User agents &amp; 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 &quot;view image in new tab&quot; 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).</font></ul><font size="4" face="Times New Roman">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.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">~Amelia Bellamy-Royds</font><br><BR>
</body></html>

z{mʗ
z{Ch+bx)~)^
z{H
z{S}ĝxjǺPNG

;<vsthef{{{SSS;;;fff   ZWXmƇVLOosj-yL|H<Mt.Goa`ϗQN@Ryh!9eknxq<0ju˦AO:q,I!sg< >\H.d$w
NztESH>>O-]/9UF(Xu"GMlCV0cȍmQ$Jw|ۖIiC-ITB4$.Esb,>Sځn@ir\i3%L3
y(t\n\-fϺ)'N.cq>[ʍ}+u$bѭ5	5@ꁳm;רsh$aLD:aP~c<P+믮#:\2l-Dzf]laSu=p 4qU~釣ližg,)p@uc< Ge;n:a[$yTJtn4
r\K˘ ǘ^Kjk~@VJa%6ê!hژxwVu}~8"$E|24G?hc=c4Veuߙ'+
Oa͊;#rFں:=/ilLB˕8%6G6I(zS)FPG|oHB
z{mʗ
z{Ch+bx)~)^
z{H
z{S}ĝxjǺGIF89aeglHI
Received on Thursday, 28 January 2016 20:04:32 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:18 UTC