[Bug 21778] New: Define a user experience for when the @longdesc is the empty string

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

            Bug ID: 21778
           Summary: Define a user experience for when the @longdesc is the
                    empty string
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
               URL: https://dvcs.w3.org/hg/html-proposals/raw-file/720b89a
                    ac76f/longdesc1/longdesc.html
                OS: All
            Status: NEW
          Keywords: a11y, a11y_text-alt
          Severity: normal
          Priority: P2
         Component: HTML Image Description Extension
          Assignee: chaals@yandex-team.ru
          Reporter: xn--mlform-iua@xn--mlform-iua.no
        QA Contact: public-html-bugzilla@w3.org
                CC: public-html-admin@w3.org,
                    xn--mlform-iua@xn--mlform-iua.no

In the discussion regarding invalid content of @longdesc, we sometimes seem to
assume that user agents somehow hide the longdesc link if the longdesc content
is invalid. For example, if the longdesc URL is the empty string.

However, this does not seem to match reality.

For instance, in iCab, the mouse pointer will change to indicate presence of
longdesc even when the @longdesc URL is the empty string. And, if one tries to
open such an invalid longdesc URL (using the contextual menu), then - as the
URL is the empty string, the only result is that the current page is opened in
a new window (or in a new tab). Such an experience can be quite confusing -
e.g. for someone that doesn't know what @longdesc is good for.

PROPOSAL:

When the longdesc is the empty string, then let the spec encourage user agents
to inform the user that the longdesc is invalid. This could be done for
instance by announcing "invalid longdesc link". Or it could be done by
presenting some kind of dummy text: "Sorry. This URL was invalid." Anything
that can help the user understand that this did not work as intended. This
could be done e.g. by defining a default data URI. This data URI - or some
equivalent that the vendor picks - will then, when the user atempts to follow
the empty longdesc URL, be rendered in place of today’s behavior.

ANALOGY/PRESEDENCE:

If the @src URL of an img element is empty, then (at least some) user agents
render a special icon (usually containing a question markj) that informs the
user that the image is lacking.

1. CONTRA ANALOGY/PRESEDENCE:

 a) If one control-clicks on an image, the user agents usually offers to open
the link in a new window/tab. This is very similar to how longdesc URLs often
open in a new window/tab. But, if the @src URL is the empty string, then  all
that happens is that the current page opens in a new window/tab. And so: Why
not handle an emtpy @longdesc URL the same way as such an empty @src URL?
 b) to render dummy content when @longdesc is empty, would not reflect the tru
URL that the empty string reflects. It would instead be like some kind of
filter that is applied when opening longdesc URLs wher the longdesc value is
the empty string.

2. PRO ANALOGY/PRESEDENCE:

To this is could be replied that
 a) why not implement the same behavior for empty @src URL as well?
 b) for empty @src, users know in advance that image is lacking.
    It is harder to to know that @longdesc is empty.
 c) what's wrong with applying a filter?
 c) we should create the best user experience
 d) in the case of images, then the user knows what he expectes to see - the
image, and no being able to see it should not confuse the user if the user
already didn't see it since the URL was empty. Besides, an empty @src URL is an
edge case. Sure, an empty @longdesc is also an edge case, in a way. But unlike
@src, it suffers from the problem that users, including authors, often don't
know what to expect.

As a final argument, if the empsty string caused such a default data URI with
some explainative stuff to be opened, then it would become very simple for
authors to test how longdesc works.

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

Received on Tuesday, 23 April 2013 04:31:37 UTC