W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

Re: longdesc (was Re: minutes: HTML Accessibility Task Force Weekly Call 2011-03-31 [draft])

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 5 Apr 2011 19:29:12 +0200
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, "Gregory J. Rosmaita" <oedipus@hicom.net>, Janina Sajka <janina@rednote.net>, Judy Brewer <jbrewer@w3.org>, Charles McCathieNevile <chaals@opera.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20110405192912884531.bf54bd27@xn--mlform-iua.no>
Steve Faulkner, Tue, 5 Apr 2011 16:11:20 +0100:

> my understanding and thoughts:
> 
> 1.the html task force seek to have an agreed  position on longdesc in 
> a short time frame

The A11Y Task for also presented an 'agreed position' on @summary: 
http://www.w3.org/mid/4D9B24E2.5020006@intertwingly.net


> 2. continuing to refine/change/update the extremely detailed change 
> proposal Laura has developed means that it is difficult to achieve 
> agreement as nobody is sure what they are agreeing to

There is no doubt that it is long. But it could probably easily be made 
shorter by moving use cases and other such "evidence like" stuff into 
separate documents.

> 3. What the HTML wg chairs require when they reconsider this issue is [1]:
> 	•	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.

It seems to me that these things are what Laura's CP is concentrating 
on.

> 4. due to the  requirements above any change proposal should 
> concentrate on providing such evidence. the proposal should be 
> succinct as is possible so as not to drown out the new evidence.

Providing evidence is not something which makes a CP short (unless one 
places the evidence in form of links to separate docs). There is lots 
of evidence in Laura's CP.
 
> 5. we should not seek at this time to expand the scope of what is 
> required which is i believe:
> 
> A feature that provides an explicit and unambiguous method of 
> associating an image with a description of the image.

This scope description IMHO fits ARIA-describedby too well.

> 6. From discussions at the San Diego face 2 face we should attempt to 
> achieve consensus on it NOT being a requirement that  longdesc only 
> be available to users of AT. In discussions with the developers of 
> NVDA, what they do not want is to implement an AT only method of 
> access, they want the browsers to provide the functionality.
> 7. in regards to the above i would suggest that recommending browsers 
> to implement longdesc in a way that can be available to any user will 
> solve many of the problems that are perceived as being part of 
> longdesc, while not taking away the essential capability of longdesc 
> to be an "unambiguous method of associating an image with a 
> description of the image"

So, the way @longdesc should differ from ARIA is that it should be 
available to all? That's perhaps a possible distinction.

But @longdesc  - or can already be - available to users of IE, Webkit 
(iCab), Firefox (add-on). Should we read the above to mean that 
"available in a contextual menu" isn't enough? More precisely, should 
it have to be visible on the page, as John suggested: 

> JF: The most important take away from the F2F was a relaxing of the
>    stand on whether the presence of a longer description mechanism
>    should be visible to sighted people. In listening to a lot of
>    feedback and discussing it, there was agreement that having a visual
>    indicator was useful though.

If this is how it should be read, then I find it hard to not come back 
to the much cited misuse and erroneous use of @longdesc: If a visual 
longdesc representation simply becomes a way to activate a larger 
version of the image, then we have succeeded in nothing.

I have low hopes for a CP which fails to address "the misuse cases" - 
the chairs claim that this is not the most important thing not 
withstandin. 

The way I have suggested to address the misuse cases is by having 

 a) stricter rules & validation, 
 b) a clear long description format (how to write it & link to it

For a) then requiring that the link is a #fragment URL, as such URL as 
seldom misused. For b) saying that the long description should be a 
<figure> or <article> (or another text piece element) with an @id 
attribute (so that it is possible to link to it.) 

> If we can agree on the points above I think a change proposal that 
> encapsulates the above could be produced in short order.

Having said the above, I want to thank you for providing the spec text 
example in public-html - it was helpful to the discussion and good to 
see in live what we are talking about. So, nice if you can "do it 
again".
-- 
leif halvard silli
Received on Tuesday, 5 April 2011 17:29:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:19 UTC