W3C home > Mailing lists > Public > public-html-comments@w3.org > November 2012

Re: longdesc spec review

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Mon, 12 Nov 2012 06:27:42 -0600
Message-ID: <CAOavpvdGfb8m7JqNHWi3_eU6UgV7zsBUr0v1BFDPhBRyETRxtw@mail.gmail.com>
To: Chaals McCathieNevile <w3b@chaals.com>
Cc: public-html-comments <public-html-comments@w3.org>
Hi Chaals,

On Sat, Nov 10, 2012 at 5:39 AM, Chaals McCathieNevile <w3b@chaals.com> wrote:
> On Fri, 09 Nov 2012 22:34:58 +0100, Laura Carlson
> <laura.lee.carlson@gmail.com> wrote:
>> Hi Chaals,
>> You asked on twitter:
>> accessibility: Please review my longdesc spec
>> http://dvcs.w3.org/hg/html-proposals/raw-file/b63325998cc1/longdesc1/longdesc.html
>> ... - Is it ready to propose it as a Formal draft?
>> https://twitter.com/chaals/status/266954317565673472
>> I am not sure where you want comments to be sent. I couldn't find a
>> Bugzilla component so I am sending this to the HTML comments list. I
>> hope that is okay.
> Works for me. Mind if I forward this to public-html-a11y ?

It would be fine to forward this message to that list.

> And more to the point, thank you very much for the review...

You are welcome.

>> First I want to thank you and say you have done a great job putting
>> this together.
>> https://dvcs.w3.org/hg/html-proposals/raw-file/b63325998cc1/longdesc1/longdesc.html
>> I have just a couple of questions/comments. And I found a few typos
>> and a markup glitch.
>> 1. How soon can your spec be folded into HTML5 proper?
> Dunno. Probably, as soon as we can get it to the point where it is ready for
> Proposed Recommendation. My hope is that we publish it as a First Public
> Working draft within three weeks.

Thanks. Three weeks will land in the middle of a two-week accessible
images unit in a class that I am teaching. It will enable me to say
that although the longdesc attribute is an open issue in HTML5, a
separate spec extension proposes to extend it to be compliant.

>> HTML5 lacking a
>> fully conformant longdesc attribute is a real problem in:
>> * Teaching how to make complex images accessible in a semantic,
>> programmatically determinable way while adhering to design
>> constraints.
>> * Making complex images accessible in a semantic, programmatically
>> determinable way while adhering to design constraints.
>> * Updating legacy HTML4 content to HTML5. Valid HTML4 documents that
>> contain longdesc attributes should be valid HTML5 simply by changing
>> the doctype.
> Agreed. My personal advice is to go for accessibility over validity and use
> longdesc in HTML5.

That may work for some but not for others. When forced to choose
between the two as this case dictates, some authors that I know have
and will choose validity over accessibility. They will leave off
longdesc in order to pass validation even if a longdesc is needed. A
pity but true. And in these cases people with disabilities end up the
losers. So for this case I will be recommending and teaching the use
of HTML4 over HTML5 as the HTML4's longdesc attribute provides a
conforming method AND is an accessible, native, simple, semantic,
programmatically determinable method that adheres to design
constraints. HTML5 is currently deficient. HTML4 is superior in this
circumstance as authors do not have to choose between validity and

>> Lack of longdesc is a gaping hole in HTML5. I urge the HTMLWG to act
>> and not to waste further time. Incorporate your spec into HTML5 proper
>> NOW so that so that everyone can embrace HTML5 rather than finding it
>> an impediment to doing their work.
> That would be great,

Yes, it would be, as the current lack of the longdesc attribute in
HTML5 proper is an impediment to doing real work in an accessible

> but doing it NOW is probably not going to happen.

I understand far too well that may very well be reality. Par for the
course. Typical indeed.

However, it is a complete disgrace for the W3C. In the May 25, 2011
"Responses to Last Call survey objections" email, the HTMLWG Chairs
made a commitment to expedite Issue 30 issue during Last Call [1]. The
issue  was officially raised in the tracker nearly five years ago and
was a known problem even before that. No excuse exists for the HTML
working group to not settle Issue 30 straightaway. The attribute
should have been incorporated into HTML5 proper during the summer of
2011 if not before [3].

> It might even become a Recommendation on its own.

The idea of shirking off HTML5 accessibility into a separate spec is
retrograde. Keeping longdesc core to the language keeps accessibility
core to the language.

When accessibility is not relegated to a separate spec but integrated
into the host language, it is viewed as a mainstay rather than as an
afterthought or add-on. Educators have a hard enough time teaching
HTML, and an even harder time teaching the need for accessibility (and
the means to address those needs). Pile on yet another layer and the
difficulties increase exponentially.

Most basic authors/content creators are not going to check two specs
to make images accessible. They should not be forced to read another
spec besides HTML5 to make complex images accessible. These authors
may get to know basic HTML and be willing to put in longdesc for
complex images but the majority will not delve into two specs to do

HTML5 proper has a responsibility to provide mechanisms for
accessibility [2]. I urge the HTMLWG and accessibility task force to
act inclusively by ensuring accessibility is integrated into HTML5
proper and not to segregate and ghettoize accessibility into separate

HTML5 presents opportunities. It has significant buzz and is
considered to be "cool". Reinstating longdesc into HTML5 proper would

A.) Educators the opportunity use HTML5's appeal when teaching longdesc.
B.) Authors the opportunity "to be cool" by using HTML5's longdesc.
C.) User agents the opportunity be part of the buzz when implementing longdesc.

This would all advance accessibility in a mainstream way.

>> 2. I am not sure what you mean here:
>> "Authoring requirement: the link is to part of a document, the
>> description should be contained within an element, which is the target
>> of the link."
>> Are you talking about fragments?
> Yep. And there is a fragment missing from my sentence. I'll fix it or take
> something from what you said.

Great. Thanks.

>> If so maybe it may be clearer to say
>> something like:
>> "The link must point to either a description identified by a fragment
>> [*] in a different document or a description identified by a fragment
>> [*] in the same document."
>> [* fragment ref]
>> http://dev.w3.org/html5/spec/history.html#the-indicated-part-of-the-document

I neglected to mention this in my previous email:

3. Something that seems to be missing from your spec is that providing
 longdesc enables users of assistive technology such as JAWS to
separate the activation of the longdesc for exposure from a user
agent's universal link activation action (which is usually activated
with the ENTER key, the Space Bar, or by mouse click), so that the
linked image retains the expected behavior in response to user
interaction while a discrete mechanism is used by screen readers to
retrieve the long description.

HTML4 said it this way:
"Since an IMG element may be within the content of an A element, the
user agent's mechanism in the user interface for accessing the
'longdesc' resource of the former must be different than the mechanism
for accessing the href resource of the latter."

The way the accessibility task force had it speced (Ben's originally
penned this text in the spring of 2011):
"Where elements exposing long text alternative resources are also
descendants of controls such as hyperlinks or buttons, user agents are
expected to ensure users can access both the resource and activate the
ancestor control."

Please add spec text such as this as it will allow the creation of
accessible logos and light boxes, and photo albums.

> Thanks. I'll fix these.

You are welcome. Thank you.
>> 1. "This specification defines a longdesc attribute to extended
>> descriptions to images in HTML5-based content"
>> Missing a period at the end of the sentence.
>> 2. "Requires: Discoverability,"
>> The comma is unneeded.
>> 3. "Many well-known images are already described by other sources. The
>> copyright on those sources is not necessarily compatible with
>> repeating the description, but there is little value in making a new
>> one, and "
>> Missing a period at the end of the sentence. The last comma and the
>> word "and" should be deleted.
>> 4. "It must be possible to associate a description in the body of a
>> page with an image in that page"
>> Missing a period at the end of the sentence.
>> 5. "It must be possible to re-use a single description for multiple
>> occurrences of an image"
>> Missing a period at the end of the sentence.
>> 6. "A user must be able to return from the description to the image"
>> Missing a period at the end of the sentence.
>> 7. "It should be possible to use existing tools and techniques to
>> associate an image with its description"
>> Missing a period at the end of the sentence.
>> 8. "Any proposed mechanism MUST include a means of accessing content
>> added by authors using the HTML4 and XHTML1 attribute longdesc"
>> Missing a period at the end of the sentence.
>> 1. In the last "Backwards Compatibility" section <dd>'s are messed up.
>> Should be:
>> <dd>It should be possible to use existing tools and techniques to
>> associate an image with its description.</dd>
>> <dd>The longer description mechanism MUST be easy to author, easy to
>> maintain and have authoring support in terms of tools and educational
>> material to accommodate authors of differing skill sets.</dd>
>> <dd>Any proposed mechanism MUST include a means of accessing content
>> added by authors using the HTML4 and XHTML1 attribute longdesc.</dd>
>> The last two <dd>s are currently outside of the definition list. And
>> there are some extra <br>'s and <p>'s.
>> That's about it.
>> Deep thanks Chaals for your work.
> Laura,
> many many thanks are due to you for the work you've put into this. As far as
> I can tell it is far more than I ever did, and it has been truly important.
> We're not there yet, but without you we would be nowhere near where we are
> now.

You are welcome, Chaals.

Thank you for not only picking up where I left off but also for
enduring the politics, nonsense, and stall tactics [3]. I wish you
swift progress and the best of luck.

Best Regards,

[1] http://lists.w3.org/Archives/Public/public-html/2011May/0347.html
[2] http://www.w3.org/TR/html-design-principles/#accessibility
[3] Timeline:

I became involved in HTML Issue 30 longdesc after the Chairs August
2010 decision to obsolete it.

The decision said, "This issue can be reopened if new information come
up. Examples of possible relevant new information include: 1) use
cases that specifically require longdesc"

>From August to December 2010 we gathered evidence and wrote use cases
in anticipation of reopening the issue.

December 1, 2010, Paul Cotton, * "...there is no rush to make this
(reopen issue 30) request."

August 21, 2010 Sam "...If you have new facts to bring forward, you
may do so at any time."

November 30, 2010, Sam:
"Our position has always been that we are seeking a description of
what problems longdesc solves, and a description of how longdesc makes
things better."

November 30, 2010, I asked Sam:
"I have been gathering documentation. It is just a matter of if it
will be productive to try to reopen ISSUE-30 or more efficient go
straight to a Formal Objection. Your advice?"

November 30, 2010, Sam Ruby replied,
"I do not recommend that you proceed directly with that information
directly to the Director.  My advice is that that information, when it
is deemed to be complete, be presented to the HTML WG on public-html."

They kept saying that there was no rush to ask for longdesc to be
reopened PRE-Last Call. So I took my time in asking for the issue to
be reopened PRE-Last Call.

February 21, 2011, instead of filing a Formal Objection I asked for
Issue 30 to be reopened because of Sam's November 30 response.

The Chairs subsequently denied the request to decide the issue before
Last Call postponing it and publically committed to "expedite" it
during Last Call because WG members voted NO on the LC survey. i.e.
Daniel Glazman:
"The longdesc discussion is not reflected in this document. The lack
of longdesc itself it enough for me to refuse this document to move to
LCWD. FWIW, there's is proposal from the HTML-A11Y Task Force dated
16-may... Longdesc should be in. I don't think this is reasonable to
move to LC before this is resolved and fixed."

May 25, 2011, in the "Responses to Last Call survey objections" the
Chairs promised to expedite the processing of Issue 30 issue during
Last Call.

November 29, 2011, Paul said that the Chairs estimated that they would
be finished reviewing Change Proposals

December 15, 2011, Maciej said, "we've reviewed one of the change
proposals... review of jonas' proposal is almost ready to go... we
hope the final review will be out before the holiday break".

January 19, 2012, longdesc Issue 30 deserves to be resolved

January 24, 2012, Re: longdesc Issue 30 deserves to be resolved

Initially there were 3 change proposals for Issue 30.
February 7, 2012: Sam asks: Split Issue 30?

February 14, 2012: The Chairs decided to spilt Jonas' Change proposal
off into Issue 204.

February 20, 2012, The question: "What is the timeline for ISSUE-30?"
remains unanswered.

March 17, 2012, RE: hypothetical question on longdesc

July 12, 2012, ISSUE-204, ISSUE-30 and ISSUE-203 processing order

July 12, 2012, RE: ISSUE-204, ISSUE-30 and ISSUE-203 processing order

August 23, 2012, Formal Objection on HTML Issue-204 Decision

September 19, 2012, Process change that halts any longdesc survey and
voids the longdesc Change Proposal.

September 21, 2012, longdesc document for the record:

September 21, 2012, I notify Sam: "The HTML5 leadership has lost all
credibility to me. I have been led up the garden path too many times
before. I want no further part of this endeavor."

Laura L. Carlson
Received on Monday, 12 November 2012 12:30:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC