[Bug 21403] New: HTML 5 spec should address how alt text is copied to a plain text pasteboard

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21403

            Bug ID: 21403
           Summary: HTML 5 spec should address how alt text is copied to a
                    plain text pasteboard
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: jcraig@apple.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 26 March 2013 18:37:07 UTC