Re: Call for Consensus (CFC) to move forward the HTML5 Image Description Extension spec for publication (FPWD)

James:

James Craig writes:
> On Nov 20, 2012, at 4:15 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:
> 
> > We are calling for consensus on the HTML5 Image Description Extension specification [1] We have asked for and received feedback on the specification from task force members.
> > 
> > The question we are asking task force members:  Is this specification ready to be put forward by the Task force to the HTML WG and the Protocols and Formats WG for consideration for publication as a first public working draft (FPWD)? Please note: As a Working Draft publication, the document does not need not be complete, to meet all technical requirements, or to have consensus on the contents. Silence will be taken to mean there is no objection, but positive responses are encouraged. If there are no objections by Thursday, November 29th (Close of business, or 23:59 Boston Time), this resolution will carry. 
> > 
> > Other considerations to note: 
> > - As a First Public Working Draft, this publication will trigger patent policy review. 
> > [1] http://dvcs.w3.org/hg/html-proposals/raw-file/4893614e89f2/longdesc1/longdesc.html
> 
> I do not currently plan to make any formal objection, but I need to go on record again as stating that I do not support longdesc, for the following reasons.
> 
> 1. Longdesc uses an approach that is sometimes referred to as "separate but equal," meaning the alternative content is not stored with the media or the linking document, which IMO is a flawed design pattern, as these external resources often become stale and outdated, remaining separate but rarely equal.

"Separate but equal" is a phrase made famous in the racial civil rights
debates of the mid 20th Century in the U.S. It became a term with
strongly negative connotations. May I please request we avoid such
terminology unless it clearly serves the current purpose in some more
obvious way? For instance, are you associating yourself with this view?
Or not?

May I further point out that the currently proposed fpwd would support your preferred
approach in the form of inpage hrefs? Conversely, others have presented
use cases that argue for out of page hrefs. In other words, we have use
cases for both approaches. The proposed fpwd supports both approaches.
So, what's your point here?

Since you ask "why?," I wonder whether you're trying to persuade others
to abandon their use cases? If so, this might be a question best dealt
with in authoring guidance about when to adopt which approach. Perhaps
you could prevail in asserting that there's never a good out of page
use, but it seems that argument has not attracted adherents over the
years these questions have been debated here.

> 
> 2. Longdesc is frequently championed as needed by book publishers despite the lack of evidence that any major publisher implements longdesc in its catalogs. The single request quoted from the publishers association did not actually request retention of longdesc. It requested ~"longdesc or an equivalent feature" and since many of these equivalent features already exist in HTML 5, I'd prefer to leave the poorly-implemented, and IMO poorly-designed, longdesc marked as obsolete. I would be fine having longdesc as "obsolete but conforming" rather than non-conforming, which would result in validators issuing a warning rather than an error.

Why would any publisher catalog mention that its publication uses
longdesc? Or hyperlinks? or paragraph markup, for that matter?If there's
an important point here, it's unclear.

Meanwhile, the assertion that alternative replacement mechanisms are
already provided by HTML 5 was the rationale adopted by the first HTML
decision on longdesc. It is precisely this argument that has been widely
rejected, and has brought the question back for reconsideration.

> 
> 3. Longdesc is under-designed and under-specified with regards to how the URL is accessed in contexts other than standard web browsers. What happens when a longdesc URL is activated in a web view in an app context that does not expect the need for "back" buttons or tabs? What happens when a longdesc URL is activated in the context of a e-book such as EPUB, where the long description content is not available "on the Web" or within the normal reading flow of the book? These questions represent holes in the specification for a feature that was designed as a stop-gap measure more than a decade ago and has not been updated to resolved problems with modern content that are better addressed by other existing features like the IFRAME element, the FIGURE element, an authored Shadow DOM, or embedded accessibility such as SVG+ARIA.

We welcome your proposal of a new, improved mechanism to meet the use
cases. It should be abundantly clear by now that a superior markup
approach would be welcome. There's absolutely no reason the TF cannot
publish several fpwds relating to long text mechanisms. I encourage you
to make your approach concrete in the form of a change proposal.

This is, in fact, the approach adopted by Plan 2014:

"We ask those that oppose instating a longdesc attribute to focus on
producing a better solution, and meanwhile not oppose those that wish to
pursue longdesc via an extension spec or making progress towards
demonstrating that it meets the identified CR exit criteria."

http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#issues

Janina

> 
> Thanks,
> James Craig

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Received on Tuesday, 27 November 2012 16:35:27 UTC