This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21566 - User agents must present longdesc through normal interfaces.
Summary: User agents must present longdesc through normal interfaces.
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML Image Description Extension (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Charles McCathieNevile
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11y_text-alt
Depends on: 21564 21565
Blocks: 21778
  Show dependency treegraph
 
Reported: 2013-04-03 11:41 UTC by Charles McCathieNevile
Modified: 2013-05-09 17:55 UTC (History)
3 users (show)

See Also:


Attachments

Description Charles McCathieNevile 2013-04-03 11:41:54 UTC
The requirement for user agents to present longdesc to all users through their standard interface(s) must be a must.

Filing bug for Jonathan Avila - see http://lists.w3.org/Archives/Public/w3c-wai-ig/2013AprJun/0002.html
Comment 1 Charles McCathieNevile 2013-04-03 12:52:55 UTC
I support this proposal. If nobody objects, it will be in the next Editor's draft.
Comment 2 Boris Zbarsky 2013-04-03 16:08:23 UTC
I'm rather strongly opposed to any "must" requirements on user-agent user interfaces.  Especially such a vaguely worded must.  Who exactly decides what "normal" or "standard" means here?  I some sort of "image properties" dialog normal?  Why or why not?
Comment 3 Boris Zbarsky 2013-04-03 16:09:23 UTC
Or is this talking about presenting it via APIs that various accessibility tools talk to?
Comment 4 Charles McCathieNevile 2013-04-03 19:46:19 UTC
Hi Boris, 

To answer your first question, whoever assesses a claim of conformance decides what a "normal interface" is. Since there are functionalities in browsers that work through context menus, others via menu items, etc, I think it would be hard to argue that an image properties dialogue is not part of "the normal interfaces". (I think that would be inconvenient for users, but that's not the same as being non-conformant).

The requirement is vague because I think there is still a lot of room for browsers to differentiate by *how* they make longdesc available. Like with accesskey, the best implementations currently rank as "not very good really" which still distinguishes them from the worst.

There are already plenty of vague requirements about making things work - users are meant to be able to interact with things that have click listeners, user agents are meant to present either the image represented by an img element, if there is one, or the content of the alt attribute, form submit buttons are meant to submit forms, etc. I don't think we are doing anything fundamentally different here.

And no, it is explicitly not about Accessibility APIs - there is a separate requirement for that which is currently at SHOULD rather than MUST. It is here because we received repeated comments (with sound justifications and use cases) that it needed to be really clear that this is for all users, not just those using a screenreader.

NVDA resisted implementing longdesc for *years* because they hoped that browsers would do what this is asking. 

In the end this spec will survive or die based on whether it gets implemented. If we make must requirements and nobody fulfils them, it fails. On the other hand if we make requirements and some particular software doesn't meet them, it isn't as if the world ends.

I'm quite strongly opposed to reducing the level of requirement just so everyone can claim conformance without actually doing what a spec asks - that gives a lot of conformant, implementation but at the expense of any useful interoperability.
Comment 5 Leif Halvard Silli 2013-04-04 12:51:23 UTC
In reply to comment #4:

> it would be hard to argue that an image properties dialogue is not
> part of "the normal interfaces". (I think that would be inconvenient for
> users, but that's not the same as being non-conformant).

and at the end of comment #4:

> I'm quite strongly opposed to reducing the level of requirement just so
> everyone can claim conformance without actually doing what a spec asks -
> that gives a lot of conformant, implementation but at the expense of any
> useful interoperability.

Comment: Nevertheless, if image properties dialog is considered a "normal interface", the bar *would* be so low that "everyone can claim conformance" quite easily. May be the bar should also be so high that it is interesting to implment, though ...

It seems to me that current versions of Opera and iCab, would then meet this bar easily, since the allow access to longdesc via contextual menu. And also, at least iCab, uses the mouse pointer to signal presence of longdesc.

> And no, it is explicitly not about Accessibility APIs - there is a separate
> requirement for that which is currently at SHOULD rather than MUST.

Comment: Keyboard accessible - is that an A11Y API thing? Or an 'normal' interface thing?

Speaking more directly at this bug report, may be the spec should require that vendors that implement this extension make sure to not implement it in such a way that one *MUST* use AT in order to access a longdesc?

>NVDA resisted implementing longdesc for *years* because they
>hoped that browsers would do what this is asking. 

An image properties dialog would hardly be enough for NVDA. What would be enough? Perhaps the only thing that would have helped NVDA would have beeen to have keyboard access to the longdesc?

Just as an idea: Would it be possible to give keyboard access to the @longdesc URL *if* the image has the tabindex attribute set? The image did not need to be clickable. But the longdesc URL could be made accessible via the Enter key provided that the image has focus. Already today, certain aspects behave differently based on whether one uses 'keyboard access' or 'mouse access'. Think of hover ...
Comment 6 Leif Halvard Silli 2013-04-04 13:07:22 UTC
Sorry, I did not mean "that one *MUST* use AT". I mean that one does NOT need to use AT to access it.
Comment 7 Charles McCathieNevile 2013-05-01 10:28:38 UTC
Thinking about this, I am leaning to making the statement apply to valid longdescs, and leaving the error case open for now since I don't think we have enough experience to clearly define a best practice that should be enforced by conformance requirements.
Comment 8 Leif Halvard Silli 2013-05-02 03:16:42 UTC
(In reply to comment #7)
> Thinking about this, I am leaning to making the statement apply to valid
> longdescs, and leaving the error case open for now since I don't think we
> have enough experience to clearly define a best practice that should be
> enforced by conformance requirements.

+1 Strongly support.

   However, I think the conditions for providing access to the longdesc URL should be be more fine grained, like so:

* URL should be non-empty
* And URL should not cause parsing failure
  http://url.spec.whatwg.org/#concept-parsed-url

Thus, if the value is the empty string, or if the URL is so malformed that it causes parsing failure, then it should be hidden. (In the 11th comment of bug 21439, I wrote about this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21439#c11 )

What do you think, Charles? Would you lilke to have even stricter condidtions for making the longdesc accessible to the user? 

One additional reason to go for the variant I propsoe, is that HTML 5.1 and HTML 5.0 have different requirements with regard to what a valid URL is as it seems to me that HTML 5.1/the URL standard (so far) permits spaces inside URLs. At the same time, what browser considers parsable, is probably much less likely to change than what is considered valid.
Comment 9 Leif Halvard Silli 2013-05-02 03:30:47 UTC
And also in support of comment #7: if there would be a clear border with regard to when URLs ware so malformed that it should not be displayed to the user, then this border could also help define when to eventually permit repair.
Comment 10 Charles McCathieNevile 2013-05-04 12:06:39 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Thinking about this, I am leaning to making the statement apply to valid
> > longdescs, and leaving the error case open for now since I don't think we
> > have enough experience to clearly define a best practice that should be
> > enforced by conformance requirements.
> 
> +1 Strongly support.
> 
>    However, I think the conditions for providing access to the longdesc URL
> should be be more fine grained, like so:
> 
> * URL should be non-empty

This is already required in the spec. I already fixed an editorial bug where that wasn't clarified repeatedly in every possible place, but if there is another one, please file it.

> * And URL should not cause parsing failure
>   http://url.spec.whatwg.org/#concept-parsed-url
> 
> Thus, if the value is the empty string, or if the URL is so malformed that
> it causes parsing failure, then it should be hidden. (In the 11th comment of
> bug 21439, I wrote about this:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21439#c11 )
> 
> What do you think, Charles? Would you lilke to have even stricter
> condidtions for making the longdesc accessible to the user? 

No. The agreement of the TF at this stage was to close this bug as suggested. The following points were brought up in the discussion:
1. If user agents do present *everything* as if it were a valid URL, that should conform (although it is recognised as not being the best quality of implementation)
2. We don't know enough about what to do when things are not working out to be prescriptive, so we should leave this open while we learn from implementation experience.
3. Where the URL is valid, it needs to be made available to the user.

We could dig into allowing the UA to test whether the URL resolves to a valid long description, but I think that would be getting a long way ahead of ourselves. I don't know of any UA that does anything nearly as advanced, and I'd rather get basic support. If there is a user agent that wants to do something so good that they ignore conformance, well and good, but lets see that before we start anticipating how it might work.

> One additional reason to go for the variant I propsoe, is that HTML 5.1 and
> HTML 5.0 have different requirements with regard to what a valid URL is as
> it seems to me that HTML 5.1/the URL standard (so far) permits spaces inside
> URLs. At the same time, what browser considers parsable, is probably much
> less likely to change than what is considered valid.

Actually, the Web Apps group has a URL spec as a deliverable, precisely to replace the current fuzzy dependency of HTML on a spec that is incomplete and has no planned completion date. I actually started the work of creating it yesterday, although it will probably take me a few days to get it online (I'm busy dealing with bugs like this instead). In my current thinking (I'm *editing* not "authoring", so the working group may end up resolving otherwise) it will follow a line more like the specs by TimBL, Masinter, Fielding, Dürst, Suignard, McCahill… than the part-spec by Anne, and something with spaces in it will not be a valid URL even if the spec defines a way to work with it.
Comment 11 Leif Halvard Silli 2013-05-05 03:40:19 UTC
(In reply to comment #10)
> (In reply to comment #8)

> > * URL should be non-empty
> 
> This is already required in the spec. 

As this bug blocks bug 21778, the answer is no, it’s not (at least not for the copy of the spec that I hitherto has seen).

Btw, note the difference in our approaches: 
You drew up a condition for when UAs *must* “present longdesc”:

>>> making the statement apply to valid longdescs

Whereas I drew up conditions for when UAs must *not* “present longdesc”:

>> if the value is the empty string, or if the URL is so malformed that
>> it causes parsing failure

It follows that your approach allows an empty longdesc to be presented. (Or to quote what you said below: it “should conform (although it is recognized as not being the best quality of implementation)”.) Whereas my approach would not allow empty longdesc to be presented. (To be accurate, your approach makes it conforming whether the UA hides or presents an empty longdesc - placing the more responsibility on authors, which seems to me to be against the usual priority of constituencies.)

>> What do you think, Charles? Would you lilke to have even stricter
>> condidtions for making the longdesc accessible to the user? 
> 
> No.

I’ll just note that your ‘when longdesc is valid’ condition would permit UAs to hide (or eventually instead ‘repair’) many more URLs than the negative conditions I suggested above would allow.

> The agreement of the TF at this stage was to close this bug as
> suggested. The following points were brought up in the discussion:
>
> 1. If user agents do present *everything* as if it were a valid URL,
> that should conform (although it is recognised as not being the best
> quality of implementation)

Agree, except when it comes to empty longdesc: Please discern - as I tried in comment #8 - between 'valid longdesc (value)' and 'valid URL'. The empty string is an valid URL, but it is an *invalid longdesc*. Should it really be conforming for UAs to present longdesc whenever it is empty? As told in  bug 21778, I don't see why.

> 2. We don't know enough about what to do when things are not working out to
> be prescriptive, so we should leave this open while we learn from
> implementation experience.

Since you use the wording ‘not working out’, and since we can expect a URL that includes a space to be working out (since both the URL standard and UAs have ways to work with them), this definition sounds *pretty* close to what I said (when I referred to URL parsing failure). Because, after all, there is nothing in the above statement which permits UAs to to assume that a URL that contains one or more space, should not be opened/followed/presented by the user agent.

> 3. Where the URL is valid, it needs to be made available to the user.

Again, this means that UAs must present empty longdescs to the user (since empty longdescs would constitute a valid URLs). I suggest adding the condition 'and non-empty'. If it did att the condition 'and non-empty', then it would be an agreeable statement.

> We could dig into allowing the UA to test whether the URL resolves to a
> valid long description,

I agree 100% that it would be best to not dig into that.

> Actually, the Web Apps group has a URL spec as a deliverable,

Thanks for the heads up.

> Fielding, Dürst, Suignard, McCahill… than the part-spec by Anne, and
> something with spaces in it will not be a valid URL even if the spec defines
> a way to work with it.

My apologies to him and to you - as well as to those guys you mention - for having spread *false information* regarding whether spaces are valid in Anne’s URL standard. Anne’s URL standard does *not* allow spaces in URLs - but it does define how to work with them
Comment 12 Charles McCathieNevile 2013-05-06 02:51:29 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> 
> > > * URL should be non-empty
> > 
> > This is already required in the spec. 
> 
> As this bug blocks bug 21778, the answer is no, it’s not (at least not for
> the copy of the spec that I hitherto has seen).

It is in the current editor's draft - <https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html> - and will be in subsequent drafts unless there is a resolution to do otherwise.

"The longdesc attribute must contain a valid non-empty URL potentially surrounded by spaces. The URL is a hyperlink to a description of the image that its parent img element represents." - the second requirement for authors and conformance checkers. That is repeated in the IDL.

> Btw, note the difference in our approaches: 
> You drew up a condition for when UAs *must* “present longdesc”:
> 
> >>> making the statement apply to valid longdescs
> 
> Whereas I drew up conditions for when UAs must *not* “present longdesc”:
> 
> >> if the value is the empty string, or if the URL is so malformed that
> >> it causes parsing failure

Yes, I understand that.
 
> It follows that your approach allows an empty longdesc to be presented.

Yes. It allows any nonsense to be presented. While that is not an optimal implementation strategy, it seems reasonable to allow it to conform to the specification. Indeed, as far as I know nearly all implementations today do this (at least until I add the detect-and-repair heuristic to my extension...)

> (Or to quote what you said below: it “should conform (although it is
> recognized as not being the best quality of implementation)”.) Whereas
> my approach would not allow empty longdesc to be presented. (To be
> accurate, your approach makes it conforming whether the UA hides or
> presents an empty longdesc - placing the more responsibility on
> authors, which seems to me to be against the usual priority of
> constituencies.)
> 
> >> What do you think, Charles? Would you lilke to have even stricter
> >> condidtions for making the longdesc accessible to the user? 
> > 
> > No.
> 
> I’ll just note that your ‘when longdesc is valid’ condition would permit UAs
> to hide (or eventually instead ‘repair’) many more URLs than the negative
> conditions I suggested above would allow.

Probably, but I don't understand whether you think there is an implication in that fact. As I see it, that is a fine thing, since it allows implementations to be smarter and more innovative.

> > The agreement of the TF at this stage was to close this bug as
> > suggested. The following points were brought up in the discussion:
> >
> > 1. If user agents do present *everything* as if it were a valid URL,
> > that should conform (although it is recognised as not being the best
> > quality of implementation)
> 
> Agree, except when it comes to empty longdesc: Please discern - as I tried
> in comment #8 - between 'valid longdesc (value)' and 'valid URL'.

OK. That comes down to the precise wording that I use to try and implement the resolution. I'll attempt to ensure that I get the distinction clear.

> The empty string is an valid URL, but it is an *invalid longdesc*.

Indeed.

> Should it really be conforming for UAs to present longdesc whenever
> it is empty?

Yes.
1. Prescribing error correction is fine when you have a good sense of what the errors are and what the best corection should be, but I don't think we are at that stage yet.
2. This is what implementations *do*, so we are paving cowpaths.
3. Conforming is not the same as good, and there is no reason to imply it is. We can stsate explicitly that it might not be helpful, but I am trying to keep the spec short for now.

> As told in bug 21778, I don't see why.


> > 2. We don't know enough about what to do when things are not working out to
> > be prescriptive, so we should leave this open while we learn from
> > implementation experience.
> 
> Since you use the wording ‘not working out’, and since we can expect a URL
> that includes a space to be working out (since both the URL standard and UAs
> have ways to work with them), this definition sounds *pretty* close to what
> I said (when I referred to URL parsing failure). Because, after all, there
> is nothing in the above statement which permits UAs to to assume that a URL
> that contains one or more space, should not be opened/followed/presented by
> the user agent.

Yes there is. If it has spaces, it is not valid.
 
> > 3. Where the URL is valid, it needs to be made available to the user.
> 
> Again, this means that UAs must present empty longdescs to the user (since
> empty longdescs would constitute a valid URLs). I suggest adding the
> condition 'and non-empty'. If it did att the condition 'and non-empty', then
> it would be an agreeable statement.

Indeed. I agree that I was imprecise, and will be more careful of that (as well as ensuring the spec is).
 
> > We could dig into allowing the UA to test whether the URL resolves to a
> > valid long description,
> 
> I agree 100% that it would be best to not dig into that.
> 
> > Actually, the Web Apps group has a URL spec as a deliverable,
> 
> Thanks for the heads up.
> 
> > Fielding, Dürst, Suignard, McCahill… than the part-spec by Anne, and
> > something with spaces in it will not be a valid URL even if the spec defines
> > a way to work with it.
> 
> My apologies to him and to you - as well as to those guys you mention - for
> having spread *false information* regarding whether spaces are valid in
> Anne’s URL standard. Anne’s URL standard does *not* allow spaces in URLs -
> but it does define how to work with them

Right. I expect to do likewise.
Comment 13 Charles McCathieNevile 2013-05-09 17:55:25 UTC
For valid Longdescs, User Agents have to present them. For invalid longdescs no particular behaviour is prescribed.