Re: Second Call for Consensus--Reconfirm Longdesc Decision

Silvia, Laura, and All:

I wonder if there's some misunderstanding? The "Second Call" that is the
Subject in this thread is to confirm (or not) the resolutions from
Monday's Text teleconference. Specifically ...

Silvia Pfeiffer writes:
> 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.

That is not the proposal on agenda for Thursday. The URI cited in
Monday's resolution, which is on the agenda for Thursday's call and a
possible WBS is at:

http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc


It is, of course, fine to continue to develop and refine a proposal.
Certainly, there was no expectation that no more tweaks would be made to
the proposal considered by the Text Subteam. However, we cannot follow a
complex consensus process while the proposal under consideration is
being revised, even if the revisions being contemplated are believed to be no more than minor refinements.


In any case, I do need to point out that you've taken this thread very
much in a different direction, and I need to try and keep things as
clear as we can. Please feel free to continue to discuss the proposal at
the U. of Minnesota site, but on its own subject thread, please--not on
this one.

Janina





> 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)
> >
> >
> >

-- 

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 14:41:21 UTC