This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
HTML 5 spec should address how alt text is copied to a plain text pasteboard. Starting discussion based on debate from WebKit issue: https://bugs.webkit.org/show_bug.cgi?id=11200 My opinion is that including alternative text in the plain text pasteboard is useful, but it would need to be clearly identified as image text rather than rendered text, because without that context, information is lost to the user, and plain text concatenation may result in unexpected or undesirable results. I'd suggest that, by default, some inline delineation of where the previously non-rendered text started and ended: // alt text <p>Foo <img src="bar.png" alt="Bar"> Baz</p> "Foo [Image: 'Bar'] Baz" // alt text with ARIA 1.1 text role (overrides image semantic for accessibility) <p>Foo <img role="text" src="bar.png" alt="Bar"> Baz</p> "Foo Bar Baz" SOME IMAGE CASES TO CONSIDER: - Inline images used as text, such as "I ♥ you", or custom emoji. - Images with long alt text (from a single clause to several sentences) - Images with bad alt text, such as the file name. - Gaiji images used as inline characters. - Images with a missing alt attr. - Images with an empty alt attr. SOME USE CASES TO CONSIDER: - General plain text rendering (for sighted users and assistive technology users alike). When a user copies a rich text format and pastes into a plain text format, do they expect image alternative text at all? Some would. Some would not. - Speak Selection (an assistive technology on iOS and OS X) uses the plain text pasteboard to "voice" the users current selection. There are some cases listed above where including the alt text (without clearly indicating its image context) would result in a negative user experience. NOTES: It's worth noting that Gecko has inserted unmodified alt text into the pasteboard for some time. Trident and WebKit have recently been updated to insert unmodified alt text, but this is behind a setting in WebKit that remains off due to the potential negative affect for Speak Selection users. I'd like to request the Working Group's and Accessibility Task Force's deliberation to standardize what should be the default, given the cases above, and any others that arise. Thanks.
It already does. The plain-text portion of the text on the clipboard is a rendering. Renderers are expected to follow CSS and the rules in the rendering section if they want to be considered "as supporting the suggested default rendering". The rendering section of the spec says: "In the absence of style-layer rules to the contrary (e.g. author style sheets), user agents are expected to render an element so that it conveys to the user the meaning that the element represents, as described by this specification." The rendering section also has an explicit subsection that goes into some detail about this for <img> element specifically: http://www.whatwg.org/specs/web-apps/current-work/#images-0 Additionally, the <img> section itself has a long part that covers what the element represents; search for "What an img element represents depends on the src attribute and the alt attribute". The key parts for the case here are: "the element represents the text given by the alt attribute. User agents may provide the user with a notification that an image is present but has been omitted from the rendering" and "When an img element represents some text and the user agent does not expect this to change, the element is expected to be treated as a non-replaced phrasing element whose content is the text, optionally with an icon indicating that an image is missing".
(In reply to comment #1) > It already does. The plain-text portion of the text on the clipboard is a > rendering. Renderers are expected to follow CSS and the rules in the > rendering section if they want to be considered "as supporting the suggested > default rendering". > > The rendering section of the spec says: "In the absence of style-layer rules > to the contrary (e.g. author style sheets), user agents are expected to > render an element so that it conveys to the user the meaning that the > element represents, as described by this specification." > > The rendering section also has an explicit subsection that goes into some > detail about this for <img> element specifically: > http://www.whatwg.org/specs/web-apps/current-work/#images-0 > > Additionally, the <img> section itself has a long part that covers what the > element represents; search for "What an img element represents depends on > the src attribute and the alt attribute". > > The key parts for the case here are: "the element represents the text given > by the alt attribute. User agents may provide the user with a notification > that an image is present but has been omitted from the rendering" and "When > an img element represents some text and the user agent does not expect this > to change, the element is expected to be treated as a non-replaced phrasing > element whose content is the text, optionally with an icon indicating that > an image is missing". thanks for the background info Ian. here is a more user friendly link to the relevant HTML 5.1 spec section http://www.w3.org/html/wg/drafts/html/master/rendering.html#images-0
(In reply to comment #1) > "optionally with an icon indicating that an image is missing." This is the part that needs clarification wrt plain text. There is no way to include an optional "icon" in plain text, so information can be lost. The delineated text would accomplish the same purpose as the optional icon, or it could be standardized to include unicode delimiters, perhaps even non-visible replacement characters matching the beginning and end of the text alternative.
It's optional; it's only real purpose is to provide access to the content menu for cases where a sighted user wants to see the image after all. That doesn't apply in the copy/paste case, so I think it's fine to drop the icon entirely.
But it's not optional if there is no specified way to do this in plain text. The spec should either expressly state that nothing besides the text alternative should be included, or expressly state how an "optional icon" is represented in plain text.
Checked in as WHATWG revision r7855. Check-in comment: Make it clearer that the optional icon doesn't make sense in plain text http://html5.org/tools/web-apps-tracker?from=7854&to=7855
There's room for improvement with the replacement characters idea, but okay. Relating WebKit bug 115283. https://bugs.webkit.org/show_bug.cgi?id=115283
Yeah, the replacement characters idea is interesting. I don't know what characters one could use, though. The obvious ones all render as weird glyphs.
How about these? U+FFF9 interlinear annotation anchor U+FFFB interlinear annotation terminator Or perhaps: U+FFFC object replacement character
U+FFF9 and U+FFFB are meant for internal use, as I understand it. U+FFFC is the obvious choice but renders as a weird glyph. I dunno. Invisible characters are rather confusing to users and cause all kinds of weird problems. What problem are we really trying to solve here?
See the related bug. The "Speak Selection" accessibility feature on iOS uses the plain-text pasteboard. Without a delineation, there is no way for this to give the context to low vision users (data loss) when speaking alternative text versus real text. If some delineation existed, it could (as an example) speak "Image" or change the pitch of the alternative text speech.
"related bug" refers to bug 11200
Sorry. Right number, wrong tracker. https://bugs.webkit.org/show_bug.cgi?id=11200
Raising priority after reviewing implementer feedback.
Noting this simply editorial.
HTML5.1 Bugzilla Bug Triage: Works for me. W3C spec now has the change done in https://github.com/whatwg/html/commit/b1f0747c60797aead9b56adf4f7d6ddbab537f0f There may be further issues (as noted with the replacement character idea)... please open additional requests as noted below. If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!