Re: Second Call for Consensus--Reconfirm Longdesc Decision

Hi Janina & Laura,

I've read the change proposal and the suggested text change. I've
still got some (late) feedback, sorry.

===
I am very concerned about the suggested spec text as per
http://www.d.umn.edu/~lcarlson/research/ld-spec-text2.html.
I'm therefore providing comments on it where I have marked the
original text with ">":

First paragraph:
--
> Some images benefit from a long text alternative that is either too long to be
> included in the main flow of the document or requires structured markup that
> cannot be included in an alt attribute. Such a long text alternative of the image,
> if it has one, may be referenced in the longdesc attribute.

This feels like you are arguing for the attribute to exist. A spec is
not the right place to argue for an attribute. Rather, the attribute
should be introduced and then you should provide example situations
for its use. Thus, this paragraph should not be the first one, but
come after the introduction of the attribute, which happens in the
next paragraph.

We can also make it more concise about what the advantage of this attribute is.
For example:
"Web developers are encouraged to use this attribute for images that
contain complex content that is too long to describe in the alt
attribute and where there is no description available in the main flow
of the document. It is particularly useful in situations where a text
description of an image is best described through structured markup,
such as for tables."


Second paragraph:
--
> A longdesc attribute may be present.

s/A/The/ - it's not an indetermined attribute, but the one listed
above under "content attributes".

>  This attribute specifies a link to a long description of the image.

s/specifies/contains/ - there is no specification of a link here, but
the content is a link.

> If present, it must contain a valid URL potentially surrounded by spaces.

s/a valid URL/a valid non-empty URL/ - an empty @longdesc is not of much use.


Third paragraph:
--
> To obtain the corresponding long text alternative link, the value of the attribute
> must be resolved relative to the element. The link must point to either a
> different document from the image or a fragment of the same document that
> does not contain the image.

OK.

> User agents should allow users to access long
> text alternatives in a device independent manner.

I think this could be more prescriptive about exposing it to all
users. For example:

"The user agent should expose the longdesc link to all users in a
device independent manner, but not interfering with the page's normal
rendering. Rendering examples are listed in the <a href="[link to
section 10.6.1]">rendering section</a>."


Last paragrph:
> The longdesc IDL attribute must reflect the element's longdesc content attribute.

OK.


We could also add an additional paragraph that could make it more
interesting for Web developers to add a longdesc page and that is just
a note in green:

"Note: The long description can for example be made available through
a separate Web page that contains the long description of the image
among other information about the image, such as publication date,
license and copyright information, as well as a thumbnail of the image
itself. If such a page is used, the longdesc URL needs to contain a
fragment address to the particular section on that page that contains
the long description. This page would then be reused for all
occurrences of the image on the Website."

===

I've also found some other issues:

1. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation
In the section "Recent research on browsers", the text "Opera,
Firefox, Chromium, and Internet Explorer all support longdesc DOM
reflection." has a dangling pointer.

2. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation
In the section "Recent research on browsers", the text "iCab has
native support for longdesc" could be supplemented with a description
for how the browser exposes it, namely "- the longdesc is exposed by
changing the mouse cursor icon"

3. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
Remove the following quote:
""Authoring tool vendors are likely to find it difficult (or even
impossible) to build user-friendly interfaces that use the
aria-describedby feature. This is likely to result in confusion and
little use of the feature." - Vlad Alexander, XStandard authoring tool
vendor, April, 20, 2011. "
since it is a criticism on aria-describedby and contributes nothing to
the discussion about @longdesc. It indicates that we should remove
@aria-describedby from common use and deprecate it, which is not our
intention with this change proposal.

4. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
Remove the following:
"aria-describedby is not native HTML."
since it is a criticism on aria-describedby and contributes nothing to
the discussion about @longdesc. It just deepens the divide between
accessibility work and the HTML WG.

5. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
Remove the following everywhere where it is copied:
"Protocols and Formats Working Group (PFWG) "likes the idea of having
built in semantics in HTML and in particular would prefer to have
common document elements." "
since it contributes nothing to the discussion about @longdesc and is
a call for authority, that will just make conversation more difficult.
(Also remove it from
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Conclusion
- the statement provides nothing of technical interest)

6.  http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
Remove the following quote:
"It is unlikely that many content creators or developers will learn
ARIA (something not native HTML). They already feel like they've
learned far more than they should have to know under their job
description. And in many cases, their supervisors agree. (reference
Cliff Tyllick) "
since we are not trying to remove ARIA from HTML, but are just trying
to re-instate @longdesc. Don't make life for ARIA even more difficult
by contributing to its criticism.

7. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
Remove the following:
"aria-describedat is not native HTML. "
since this statement has no technical value and sheds again a bad light on ARIA.

8. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
Remove the following:
"It is unlikely that many content creators or developers will learn
anything with an ARIA prefix. They already feel like they've learned
far more than they should have to know under their job description.
And in many cases, their supervisors agree. (reference Cliff Tyllick)
"
since again this is a criticism of ARIA that is not called for when
discussing the technical merits of @longdesc.

9. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
Remove the following:
"The <canvas src> proposal implies that the problem with longdesc is
copy/paste errors. It is not. Some browser vendors have a problem in
not affording users the option of accessing longdesc content. This
could be corrected if they followed User Agent Accessibility
Guidelines. "
since there is no technical argument and since slashing out at browser
vendors is not constructive.

10. http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
You could add to the argument against image maps that:
* overloading the mechanism of image maps with that of providing long
text alternatives clashes in the case that you need both, image maps
and a long text alternative
* for a long text alternative provided through a link in an image map
to be exposed to AT programmatically would require a special marking
on one area, such as a @longdesc boolean attribute

11.  http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/AlternativesAreNotViableSolutions
Remove the following from the image map section:
"Obsolescing longdesc breaks backwards compatibility for numerous
company, organizational, governmental, educational, and personal sites
throughout the world.
Obsolescing longdesc would cause confusion and result in mixed
messages between existing Guidelines, Laws, Policy, and Standards and
HTML5. "
since these arguments have nothing to contribute against the choice of
image maps, but are general issues with making longdesc obsolete.
These arguments are already used in the section on a new attribute and
are ok there.

12.http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Conclusion
Remove the following:
"A HTML attribute is easier to teach. Many content creators and
developers will not learn ARIA. "
since again this is a criticism of ARIA that is not called for when
discussing the technical merits of @longdesc.

Removing those arguments will make the case stronger, not weaker -
it's not quantity that counts, but quality of the argument.

==

Hope this helps.

Cheers,
Silvia.


On Wed, May 18, 2011 at 8:49 AM, Janina Sajka <janina@rednote.net> wrote:
> Colleagues:
>
> We have been requested to confirm the consensus on longdesc reached at
> the Text Subteam teleconference this past Monday, 17 May.
>
> http://www.w3.org/2011/05/16-text-minutes.html
>
> We are further requested to confirm the Task Force consensus according
> to the published Consensus Procedures document at:
>
> http://www.w3.org/WAI/PF/HTML/consensus-procedures.html
>
> Therefore, we will test for consensus on both resolutions approved by
> the Text Subteam during our regular Task Force teleconference this
> coming Thursday, 19 May.
>
> If the consensus reached at the Text Subteam is confirmed during the
> Thursday meeting, we will further open a WBS survey for three working
> days beginning Thursday as provided for in the Consensus Procedures
> document.
>
> We will vote on each resolution separately, just as was done in the Text
> Subteam, so that it is possible to approve either, neither, or both. The
> two resolutions are:
>
> RESOLUTION:
>        The Task Force supports the Issue 30 Change Proposal at:
>        http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc
>
> RESOLUTION:
>        The Task Force supports a Formal Objection escalation should it
> appear that HTML last call is to be published without the longdesc as
> in our supported proposal
>
> Regards,
>
> --
>
> Janina Sajka,   Phone:  +1.443.300.2200
>                sip:janina@asterisk.rednote.net
>
> Chair, Open Accessibility       janina@a11y.org
> Linux Foundation                http://a11y.org
>
> Chair, Protocols & Formats
> Web Accessibility Initiative    http://www.w3.org/wai/pf
> World Wide Web Consortium (W3C)
>
>
>

Received on Wednesday, 18 May 2011 04:57:50 UTC