Re: disposition of ISSUE 30 cited in bug 10967 insufficient

I agree with Sam, particularly with respect to the following points:

1) The Chairs will decide whether new information is sufficient to reopen an issue after that information has been presented to and discussed by the HTML WG. Other WG members may have different standards of what they consider sufficient to reconsider the issue, or may have different interpretations of the data. We will not precommit to a quantitative threshold of information that is definitely enough to reopen the issue, since it is in part a matter of how HTML WG members view the information provided.

2) The information gathered so far seems reasonable to present to the WG now, should the parties collecting it deem it appropriate to do so.

3) If this batch of information does not turn out to be sufficient to reopen the issue, or is sufficient to reopen, but after full consideration the decision is the same, then the threshold next time to even discuss potential new information on this issue will be significantly higher. One goal of the decision process is to achieve closure on issues, and not have the same issues crop up over and over again. So it would be wise to be very confident of the new information to be presented before proceeding, because it is not likely there will be another chance.

Regards,
Maciej

On Nov 30, 2010, at 6:45 PM, Sam Ruby wrote:

> Short answer: I feel that there is enough here to merit consideration by the wider working group.  My co-chairs will also need to have an opportunity to weigh in on this.
> 
> Now for a longer answer: the primary role of the Chairs is to ensure that groups consider all legitimate views and objections, and endeavor to resolve them.  You ask a number of legitimate questions below, but are directing them at the wrong parties.
> 
> Put another way: under no circumstances will the Chairs allow the Working Group to be factored out of Working Group decisions.
> 
> I will state that I expect every bit of evidence presented below to be challenged, and I expect that evidence and suggestions will be provided which leads to a different conclusion.  Without hearing that evidence, I will not commit to an answer.
> 
> I will also repeat my concern that should the evidence provided end up falling short, the chairs will likely be looking for something substantially more evidence to be provided before we even consider reopening the discussion yet again.  That's why I counsel patience.
> 
> Given these factors, I encourage those on this list to coordinate in order to determine when they would like to proceed with a discussion on public-html.
> 
> - Sam Ruby
> 
> On 11/30/2010 06:51 PM, John Foliot wrote:
>> Sam Ruby wrote:
>>> 
>>> Revisiting this Issue
>>> 
>>> This issue can be reopened if new information come up. Examples of
>>> possible relevant new information include:
>>> 
>>>      * use cases that specifically require longdesc,
>>>      * evidence that correct usage is growing rapidly and that that
>>>        growth is expected to continue, or
>>>      * widespread interoperable implementation.
>>> 
>>> I believe that Laura is collecting this information.  The advice that
>>> both I and Maciej gave in September on this topic is still relevant
>>> today:
>>> 
>>> http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0495.html
>>> 
>>> - Sam Ruby
>> 
>> Sam,
>> 
>> On August 12th, I wrote to the Chairs and asked for clarification on these
>> three points
>> (http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0045.html,
>> http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0047.html)
>> without getting much of a quantitive response back. The questions are/were:
>> 
>>>      * use cases that specifically require longdesc,
>> 
>> 1) How many use cases are required?
>> 
>> 
>> Sam, your response then was:
>> 
>> "The assumption of metrics was something you inferred.
>> 
>> My suggestion on the way forward is to start with a single step.  Such
>> as a widespread implementation.  I've heard second hand that Oracle is
>> such a user.  If they could be encouraged to present their use case
>> directly, and preferably with samples of web pages (sanitized snapshots
>> would be fine if we are talking about intranet applications), then the
>> members of the working group can discuss whether the pros and cons of
>> that usage."
>> - http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0054.html
>> 
>> That proof has been collected and submitted:
>> http://www.w3.org/html/wg/wiki/LongdescRetention#Examples_with_Redundant_Link_Text
>> 
>> 
>> Does this meet your criteria for use-cases "that specifically require
>> longdesc"? If not, why not?
>> (It must certainly meet the first-step recommendation of gathering and
>> sharing the Oracle data)
>> 
>> 
>>>      * evidence that correct usage is growing rapidly and that that
>>>        growth is expected to continue,
>> 
>> 2) Define "rapid", define "growth" in the context of satisfying this
>> requirement.
>> 
>> 
>> * Since the decision of August, a plug-in for WordPress was developed to
>> allow authors to insert longdesc
>> (2010-9-26 http://wordpress.org/extend/plugins/tags/longdesc).
>> 
>> * Drupal 7 will be officially released December 7th with support for
>> authoring and storing longdesc data in that CMS:
>> "Has been added to D7, no plans to backport for now."
>> http://drupal.org/node/801584
>> http://drupal7releasedate.com/
>> 
>> 
>> Does this meet your criteria for both "rapid" and "growth"?  If not, why
>> not?
>> 
>> 
>> 
>>>      * widespread interoperable implementation.
>> 
>> 3) Define "widespread"
>> 
>> This has always been the fox in the hen-house, as for the most part the
>> GUI-based browser vendors have shown little appetite (or outright refusal)
>> in doing anything for "all their users". However, since HTML is DOM based,
>> should an author use the longdesc attribute today, that attribute and its
>> value *are* in the DOM, and thus can be accessed by any user-agent that
>> chooses to do so.
>> 
>> An incomplete list of *user-agents* that do something useful with @longdesc
>> today include:
>> 
>> * JAWS Version 4.01 and up -
>> http://www.freedomscientific.com/fs_products/software_jaws401newfea.asp
>> * LookOUT in combination with WebbIE. - http://www.screenreader.co.uk/
>> * Sense Reader Professional Edition v1.1.0.6 (Korean Screen Reader) -
>> http://www.haeppa.kr/?page=10
>> * SuperNova/Hal - http://www.yourdolphin.com/
>> * Thunder in combination with WebbIE. -
>> http://www.screenreader.co.uk/product.php?shopprodid=1
>> * Window-Eyes -
>> http://www.gwmicro.com/Window-Eyes/Manual/HTML/index.html?19_10longdesc.htm
>> 
>> Does this meet your criteria for "widespread"? If not, why not?
>> 
>> All of the afore mentioned Assistive Technology informs users that an image
>> has a long description, at which point the user has the *option* of reading
>> the description or skipping it. (Emphasis on the OPTION part, as this unique
>> feature also feeds back to the question of use-case: proposed solutions such
>> as aria-describedby currently does not allow for the toggling of 'proceed or
>> skip', and was never designed to do so)
>> 
>> Since all of these tools essentially perform the same function when
>> encountering @longdesc, does this meet your criteria for "interoperable"? If
>> not, why not?
>> 
>> 
>> I continue to ask these questions, as I wish to ensure that I "...Make every
>> effort to ensure that this information is complete before doing so, as it
>> will have the effect of raising the bar as to what constitutes new
>> information in the event that it turns out to be incomplete."
>> 
>> 
>> JF
>> 
>> "Never give in--never, never, never, never, in nothing great or small, large
>> or petty, never give in except to convictions of honour and good sense.
>> Never yield to force; never yield to the apparently overwhelming might of
>> the enemy." - Winston Churchill
>> 
> 
> 

Received on Wednesday, 1 December 2010 03:16:13 UTC