[Bug 21501] Advice to conformance checkers section

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

--- Comment #6 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(In reply to comment #5)

> I am against filling the spec with stuff that is purely meant to answer the
> longdesc lottery article. 

I use that article as source of information. I also assume that answering the
issues it takes up, will be good for the acceptance of the longdesc spec. Are
there other articles that describe the problems longdesc has had any better?

> For most users, that will be unnecessary extra content.

Is this a spec for Web authors? For validation developers? For users? UA and AT
implementors? I suppose that by 'user' you meant 'reader of this spec' But this
particular bug is only about readers that are conformance checker developers.

My question was: Do you consider it valid (sic) that validators check (most) of
the things I have proposed? If so, I could file bugs against the validator.
After all, the validator checks that @usemap=#foo points to a <map name=foo> on
the same page, but it does not check that <a href=#foo> points to anyting on
the current page. So it is clearly a bit up to the validator developers what
they find that it makes sense to check. I agree with the validator devs that it
is obvious to check that <map name=foo> exists for <img usemap=#foo>, but
probably not sensible to check <span id=foo> existt for <a href=#foo>. But if I
would get no support if I asked the conformance checkers to add such checks,
then I should not ask. The best support would be to have a reasonable spec to
point to.

> Another best practice would be to check that the language of the longdesc
> matches the language of the source document. And another would be to check
> if it negotiates to match the users preferred language even if the page
> itself doesn't (this is one of the cool things you can do with external
> longdesc links).

I guess, in theory, then for 

    <img src="image" longdesc="image" alt="alt" />, 

the longdesc could, through content negotation, lead to image.html. That is why
a warning is probably better than an error. Speaking about users - or
simplistic authors, then longdesc has been described as a *simple* solution. I
believe that the *advanced* authors will be able to ignore the warning cause by
longdesc="image". 

As for language, then where would you draw the line? If a Norwegian Bokmål page
points to a NOrwegian Nynorsk page, should it be an error? There are 8000 -
9000 language tags.

> But I am not interested in putting all that into the spec...

The best/optimal shouldn't be the enemy of the good/OK.

> I'm coming to the idea that it would be useful to write a specific best
> practices document. Note that there are validators that linkcheck - I just
> don't know of any free products that do that.

The NU validator checks that @usemap is used correctly - see above. The HTML4
validator does not. Certian things makes sense to have the ordinary validator
check. We should not need to pay for such checks. Etc.

(Btw, the NU validator also have an extra 'image report check' - could of
course be valid to place the warnigns in that report.)


> 3, 4 and 5 have legitimate use cases so should only throw warnings anyway.

Warnings is what I suggest.

> Describing the kind of warning and the use cases is definitely better in a
> Best Practices document IMHO.

The point is to say in the spec that it is allowed to create warnings for
things that are likely errors or useless. 

> 6 is a non-problem. There is a clear difference between having a link
> somewhere on a page, and having an explicitly associated link, in terms of
> allowing user agents (which include things like search engines) to
> unambiguously associate the description with the image.

I suppose that you was that issue described in 6 was exactly equivalent to
this: 

   <a href=longdesc><img longdesc=longdesc src=a alt=alt></a>

With my imperfect experience of how screenreaders work, the longdesc in that
example,  is currently useless, even if the screenreader supports longdesc. It
is even outside what HTML4 envisionaged, as HTML4 talked about longdesc
pointing to a place *different* from where the parent <a href=foo> points.

 If you bring in search engines, then you are also opening up for a new kind of
use of @longdesc - a legitimate use of longdesc in order to affect search
engines, as there obviously many descriptive images that are image links.

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

Received on Wednesday, 3 April 2013 12:22:09 UTC