W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: example spec text for longdesc

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sun, 27 Mar 2011 23:19:07 +0200
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: Henri Sivonen <hsivonen@iki.fi>, HTMLWG WG <public-html@w3.org>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Message-ID: <20110327231907980718.1b5c6dbc@xn--mlform-iua.no>
Laura Carlson, Sun, 27 Mar 2011 06:43:45 -0500:
>>> Instead of suffixes, we could require the @longesc URL to point to a
>>> #fragment ID.

> I have been thinking about this a bit.

Great to hear!

> Leif's idea does have merits. The biggest one is that it would
> be a consistent rule for authors and tools.

There are benefits for users too. See (5) below.

> But only a very small portion of the longdesc use in the wild 
> use on-page anchors. We have just four examples out of all of
> them in the research [1].  So it is not consistent in that 
> respect. Existing content correctly using longdesc without an
> #anchor would be invalid.

Understand. But 

(1) if is a good thing to do, then shouldn't users be put higher than 
(those) authors? Authors would tackle a "sorry, but HTML5 has raised 
the bar" message in validators, no? It simply raises the bar. That's 
all.

(2) Your page has 26 (and not just 4) examples of fragments 
identifiers. (Seems you counted only longdesc=#foo but not 
longdesc=somePage#foo.)

(3) If the entire page is meant as one description, the empty fragment 
should be possible: longdesc=anotherpage#. 

(4) Current URLs will *work* even if they aren't valid. John's citation 
of Jonas: [1] """it's not going to have a big effect because people 
simply doesn't consult validators to a large degree"""   

(5) A quality check of some of your longdesc research page's examples 
shows that while a fragment identifier wouldn't improved user 
experience when accessing the simplest long description pages, there 
are several examples of the opposite. For a look at 6 examples, see 
[footnote].

 (6) Validity: HTML5-wise, those pages will have other errors. How 
important is it that all the currently correctly uses of @longdesc get 
a valid stamp by the HTML5 validator, when this as well would stamp as 
valid the 75% to 99% misused/rotten/etc examples too? 

Finally, for you and Henri, two examples of what validators could say:

 Example 1: (description situated on the same page as the image)
   """
   Error: The fragment identifier in attribute longdesc referred
   to foo, but there is no element with that id attribute value.
   From line 7, column 4; to line 7, column 30
   <body><img longdesc=#foo src=bar alt=Lorem. >
   """

 Example 2: (description situated on another page than the image)
   """
   Error: Bad value for attribute longdesc on element img:
   The URL of the @longdesc attribute must end with a fragment 
   identifier referring to the container element for (or at least
   the start of) the designated description.
   From line 7, column 4; to line 7, column 30
   <body><p><img longdesc=anotherpage src=a alt=b ></p>
   A hash-name reference must start with #
   """

And @cite could be evaluated the same way.

[footnote] Analysis of 6 examples in Laura's collecton:

* Then longdesc page [ld1] has lots of text before description. This 
text is visible if CSS doesn't hide it (e.g. Opera Mini doesn't hide 
it). VoiceOver jumps over it, but for a sighted user with CSS disabled, 
the text fuss disturbs. A fragment identifier should jump over it for 
everyone.
* Longdesc page [ld2] has navigation stuff before the description, 
though  the 'skip to content' link helps. But why not make the 
skip-to-#content fragment part of the longdesc URL? 
* Longdesc page [ld3]: same remark as for [ld2].
* The longdesc URL of [ld4] has no fragment. And the skip-to-content 
link on the longdesc page [ld45] does not locate the description
* A description page were the skip-to-fragment is sucessfully used. 
[ld6].
* The @longdesc URL [ld7] to longdesc page [ld8] *could* have included 
a #text fragment, but didn't ...
* The IBM examples such as [ld9] points to a frame page. [ld10] Frame 
pages are not legal in HTML5. But it shows how much work it probably 
can take to locate a the long description (Works fine if I disable 
javascript ...)

[1] http://www.w3.org/mid/03f201cbec3d$e2652230$a72f6690$@edu
[ld1] http://www.stcsig.org/sn/siglogo.shtml
[ld2] http://www.anblik.com/page/logo-long-description.html
[ld3] 
http://tours.daytonartinstitute.org/accessart/object.cfm?TT=gt&TN=mh&ID=50&COM=IM
[ld4] http://www.lexdis.org.uk/
[ld5] http://www.lexdis.org.uk/sitemapdesc
[ld6] 
http://barrierfree.nict.go.jp/nict/develop/research4/detail/longdesc.html#sec-a
[ld7] http://www.nald.ca/literacybasics/marketng/sr-markt/02.htm#mocpie
[ld8] 
http://www.nald.ca/literacybasics/marketng/sr-markt/moc-pie.htm#text
[ld9] 
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzahh/mngcon.htm
[ld10] 
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzahh/rzahh549.htm
-- 
leif halvard silli
Received on Sunday, 27 March 2011 21:19:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:26 GMT