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

Reiterating that I am not planning to file a formal objection, but I could not remain silent because, as Steve's original email stated:

>>> Silence will be taken to mean there is no objection


On Nov 27, 2012, at 8:34 AM, Janina Sajka <janina@rednote.net> wrote:

> James Craig writes:
>> 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? 

I am aware of the etymology, and if anyone find the phrase offensive, I apologize, but I thought my use of it was both clear and obvious. The term "separate but equal" is used to refer to things that are never truly equal. As racially segregated schools became dilapidated during the civil era of the mid-20th Century due to lack of funding, effort, and awareness; "segregated" accessibility efforts such as separate "accessible" sites (Example: <http://www.amazon.com/gp/aw>) or off-page long descriptions (e.g. longdesc) often become dilapidated due to lack of funding, development effort, and awareness.

I'm certainly not implying that longdesc represents some form of institutional hatred or undermining of a particular group of people, but I think it clearly serves the purpose to demonstrate that a "separate but equal" approach, even one with the best of intentions, never lives up to being truly equal.

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

I am aware that longdesc can link to an in-page id, but if it's in page (as to a footnote detailing the table data of a rendered chart), I believe it should use a standard link accessible by anyone. If it's not something like a footnote intended for everyone, but it's truly at alternate of the content displayed in the image, then linking to something in-page would be redundant, and instead the embedded content should maintain its own accessible alternative, as demonstrated in the SVG+ARIA example.

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

The point was that proponents of longdesc have repeatedly stated that the attribute is "used by book publishers" or "needed by book publishers" without providing any evidence that these statements are true.

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

I can agree to disagree on this on this point.

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

I don't believe any change proposal is needed. Links, iframes, and figures are already in the spec and supported by all browsers, an the spec has detailed additions for newer but less-well-supported features like embedded SVG, and Shadow DOM content.

> 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."


As I mentioned, I am not planning to file a formal objection, but I could not remain silent because, as Steve's original email stated:

>>> Silence will be taken to mean there is no objection

Please consider this my informal objection, as well as a partial answer to Steve's other question:

>> Is this specification ready to be put forward by the Task Force…?


I think no, but if I'm in the minority, I'll accept the task force's non-unanimous decision to publish.

James

Received on Tuesday, 27 November 2012 22:44:02 UTC