W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: ISSUE-30 (Longdesc) Change Proposal

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 17 Dec 2009 09:27:18 -0800
Cc: "public-html@w3.org" <public-html@w3.org>
Message-id: <05CB1C5F-8964-4752-9472-EB31C2E10AEB@apple.com>
To: Charles McCathieNevile <chaals@opera.com>

Your edited version looks good in terms of meeting the requirements,  
would you mind sending a flat copy without the varying quoting levels,  
or else put it in the Wiki, so I can have a nice readable copy to link  
in the status list? (I'll link this version in the meantime.)

On Dec 17, 2009, at 9:19 AM, Charles McCathieNevile wrote:

> On Tue, 08 Dec 2009 20:39:11 +0100, Maciej Stachowiak <mjs@apple.com>
> wrote:
>> Thanks for providing a Change Proposal for this issue! The chairs  
>> are reviewing Change Proposals to ensure that they meet the  
>> required structure. Here is our feedback on this Change Proposal:
>> (1) This Change Proposal lacks a clearly marked Summary section  
>> (perhaps some of the introductory text is a summary, but that is  
>> not clear).
>> (2) This Change Proposal lacks a clearly marked Details section,  
>> and does not provide sufficient detail to identify a specific  
>> change. It's mentioned that many sections may change, but does not  
>> identify explicitly which changes are required by the Change  
>> Proposal.
>> (3) This Change Proposal lacks an Impact section.
>> On Oct 26, 2009, at 10:53 AM, Charles McCathieNevile wrote:
>>> Hello,
>>> I would like to propose that the longdesc attribute from HTML 4 be  
>>> retained in HTML 5 as an allowed attribute on images.
>>> This implies the following changes to the spec:
> [I assume these are reasonably clear, and provide sufficient  
> information
> for the editor to incorporate the relevant changes into his  
> workflow. Is
> that assumption valid, and if not, can you please clarify what I  
> should be
> providing?]
>>> at
> Section 4.8.2
>>> http://dev.w3.org/html5/spec/text-level-semantics.html#the-img-element 
>>>  img would also become interactive content with longdesc present.
> i.e. add "or longdesc" after "usemap" in the phrase "If the element  
> has a
> usemap attribute" under the 'Categories' item.
>>> The longdesc attribute would be listed as an attribute for the  
>>> element.
> i.e. Add "longdesc" to the list of content attributes, and
> "attribute DOMString longdesc;" to the attributes listed in the DOM
> Interface for the img element.
>>> The attribute is described already in HTML 4 [1] and the  
>>> description can be re-used although it should be made clear that  
>>> the URI to which longdesc refers can be a relative reference to  
>>> some part of the same page (in order to be explicit about which  
>>> content is associated with the image), or a different page.
> I.e. in the first sentence at [1], add text such as "which may refer  
> to a point within the current page or to a different page" after the  
> work "link".
>>> The example, which references an image but appears to provide  
>>> useless alt text should not be copied from HTML 4.
>>> Other sections that may change:
>>>,, should all mention that a longdesc  
>>> *may* be provided to provide a detailed *description* of the  
>>> image, e.g. to help a person who cannot see it to find it from a  
>>> description.
>>> should mention it as a way to make the association  
>>> between an image and the relevant text explicit.
>>> should mention it as the preferred way to point to a  
>>> description of the image if this is desired, rather than mis-using  
>>> the alt attribute for this purpose.
>>> should mention that where an image is a key part of the  
>>> content, it should have sufficient text in the alt attribute to  
>>> replace the image, and using the longdesc attribute for critical  
>>> information is a mistake. However, it can be used for additional  
>>> information if desired.
>>> This has been a controversial topic. It is clear that longdesc is  
>>> relevant only to a fraction of images on the Web, and that it is  
>>> only provided in a few of the cases where it is actually relevant.  
>>> It is also clearly subject to bogus values to a large extent  
>>> (perhaps the majority of the time). And its use is relatively  
>>> limited, even by those who might be expected to appreciate it.
>>> However, it has been implemented multiple times successfully. The  
>>> fact that there is bad data associated might account for low  
>>> overall usage, but has relatively little impact on  
>>> implementations, which can readily choose to simply ignore values  
>>> which are not URIs, or even to present the value to the user, and  
>>> relatively little impact on the user, who can still benefit from a  
>>> *good* usage.
>>> This would require conformance checking to accept the attribute as  
>>> valid, and would imply maintaining the existing requirement on  
>>> Authoring Tools[2] to allow the author to use this functionality.  
>>> It would maintain conformance of HTML-4 tools and content, rather  
>>> than the current expected change leaving them non-conforming.
> This has no impact on existing HTML-4 browsers, many of which fail  
> to make
> longdesc accessible other than via the DOM. Failure to make this  
> change
> will have an impact on assistive technologies such as screen readers,
> which use the longdesc attribute to find descriptions of images.
>>> [1] http://www.w3.org/TR/REC-html40/struct/objects.html#adef-longdesc-IMG
>>> [2] http://www.w3.org/TR/ATAG-10/ makes several relevant requiremnts
>>> cheers
>>> Chaals
>>> --Charles McCathieNevile  Opera Software, Standards Group
>>>   je parle franšais -- hablo espa˝ol -- jeg lŠrer norsk
>>> http://my.opera.com/chaals       Try Opera: http://www.opera.com
> -- 
> Charles McCathieNevile  Opera Software, Standards Group
>      je parle franšais -- hablo espa˝ol -- jeg lŠrer norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Thursday, 17 December 2009 17:28:22 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:55 UTC