W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > January to March 2014

Re: EOWG Comments on longdesc

From: Shawn Henry <shawn@w3.org>
Date: Tue, 21 Jan 2014 17:14:56 -0600
Message-ID: <52DEFF70.2060308@w3.org>
To: Charles McCathie Nevile <chaals@yandex-team.ru>, public-html-a11y@w3.org, "EOWG (E-mail)" <w3c-wai-eo@w3.org>
CC: Mark Sadecki <mark@w3.org>
Dear Chaals and TF,

Thank you for your response. Here are replies on a few points:

>> * Introduction: Provide a little context at the beginning, briefly
>> explaining what long descriptions are. For suggested wording, see
>> the Image concepts page <http://www.w3.org/WAI/tutorials/images/>
>> (note the lower sections have "Why is this important" and "How to
>> make images accessible") and Complex
>> images<http://www.w3.org/WAI/tutorials/images/complex>.
>
> We will add more information in the introduction as suggested.
> However the pages you suggested do not appear stable enough to be a
> reference in this document, so we will not link specifically to
> them.

Correct, the pages are not stable enough to be referenced in the document -- indeed we will be editing them soon. We did not intend to suggest that they be referenced; we only pointed to them for ideas for wording in the Introduction.

On 21 January we checked again for new Introduction wording at <https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html> and do not see it yet. Please inform us when the Introduction wording is ready for us to review in reply to this comment.

>> *Suggested edit to the paragraph under Use Cases and Requirements
>> <http://www.w3.org/TR/html-longdesc/#UCnR>: "Text alternatives are
>> required so that users can successfully understand and interact
>> with images even if they cannot see, or see well. The alt attribute
>> is designed to contain a short description. This is sufficient for
>> most images, and should provide enough information to ensure that
>> users understand the image's purpose. Some images contain more
>> information than can effectively be provided in a short
>> description. The longdesc attribute is designed for longer
>> descriptions to meet use cases such as the following." — although,
>> some of this information may be better in the Introduction per
>> previous comment...
>
> Whether an image needs a long description can depend on context as
> well as the image itself. Alt is designed to provide a functional
> replacement text, not a short description. In many cases text
> alternatives are not necessary to support interaction. We therefore
> do not propose to adopt this edit.

EOWG is uncomfortable with the first paragraph at <http://www.w3.org/TR/html-longdesc/#UCnR>. For example, "everyday work" seems to make light of the importance of text equivalents in all cases; "information to replace an image" may not be understood; "often this is more helpful than a detailed description of every image" seems a tangential comment rather than a key point.

We provided a suggested edit to show the flavor of what we think the paragraph should say; however, we are fine with you changing our suggested edit. Here is another suggestion that hopefully addresses your concerns:
"Text alternatives for images enable people who cannot see to get the information that is provided in images. The alt attribute is designed to contain short functionally equivalent text, either the function of the image or a short description, based on the context. For many images, short alt is sufficient for users to get the information they need about the image. For some images and contexts, users need more detailed information from the image. The longdesc attribute is designed as a means to provide this detailed information, such as in the following use cases."

We hope that between the two suggestions you can see what we think are the importance points to get across here and how it has a very different flavor than what is in the draft -- and we *welcome for you to edit our suggestions*.

Also note the related comment about the Introduction -- Probably this information is best in the Introduction and then the Use Cases section needs only a simple sentence to introduce it.

>
>> * Current wording: "This document does not define the term
>> "accessible" nor accessibility, but uses them with the sense they
>> have in [WCAG]" Change reference from WCAG to Introduction to Web
>> Accessibility <http://www.w3.org/WAI/intro/accessibility> then can
>> say more directly: "This document does not define the terms
>> "accessible" or "accessibility"; it uses them as explained in
>> Introduction to Web Accessibility.
>
> That document referenced has no apparent stability or persistence
> policy. For a reference we prefer to use a W3C Recommendation which
> has both.

WCAG 2.0 does not define or explain accessibility, and thus it seems a weak reference for your point. WAI Resources such as "Introduction to Web Accessibility" are commonly referred to in W3C specs -- WCAG itself refers to <http://www.w3.org/WAI/intro/wcag.php>. WAI Resources follow the W3C URI Persistence Policy (<http://www.w3.org/Consortium/Persistence.html>). While we provide a changelog for many WAI Resources, we do not provide a public archive of all previous versions of most WAI Resources.

Please reconsider the best reference in this case, and let us know how we can provide specific, documented assurances with regard to the stability and persistence of "Introduction to Web Accessibility" to meet your needs.

We look forward to your further reply.

Regards,
~Shawn Henry for EOWG



On 12/11/2013 4:15 AM, Charles McCathie Nevile wrote:
> Dear EOWG,
>
> Thank you for your feedback on the spec. I am sorry it has taken so
> long to provide an official response, but here it is.
>
> We found the vast majority of your suggestions very helpful and will
> incorporate them into the specification. Below are replies to
> individual suggestions where we feel it is important to clarify, or
> where we will not be incorporating your suggestions.
>
>> * Add "This section is non-normative." to main non-normative
>> sections. (We see a sentence about this later, but are concerned
>> it's not clear enough. For example, the first section under 3. The
>> longdesc attribute <http://www.w3.org/TR/html-longdesc/#longdesc>
>> starts with a sentence that is not clearly a "Note" (e.g., not
>> offset, marked up, and preceded with "Note:"...")
>>
>
> In the specific example, that statement is not normative, so instead
> we will remove the words "Note that" at the beginning. We believe
> that all other non-normative sections are identified as such, but
> will double-check.
>
>> * Introduction: Provide a little context at the beginning, briefly
>> explaining what long descriptions are. For suggested wording, see
>> the Image concepts page <http://www.w3.org/WAI/tutorials/images/>
>> (note the lower sections have "Why is this important" and "How to
>> make images accessible") and Complex
>> images<http://www.w3.org/WAI/tutorials/images/complex>.
>
> We will add more information in the introduction as suggested.
> However the pages you suggested do not appear stable enough to be a
> reference in this document, so we will not link specifically to
> them.
>
>> *Suggested edit to the paragraph under Use Cases and Requirements
>> <http://www.w3.org/TR/html-longdesc/#UCnR>: "Text alternatives are
>> required so that users can successfully understand and interact
>> with images even if they cannot see, or see well. The alt attribute
>> is designed to contain a short description. This is sufficient for
>> most images, and should provide enough information to ensure that
>> users understand the image's purpose. Some images contain more
>> information than can effectively be provided in a short
>> description. The longdesc attribute is designed for longer
>> descriptions to meet use cases such as the following." — although,
>> some of this information may be better in the Introduction per
>> previous comment...
>
> Whether an image needs a long description can depend on context as
> well as the image itself. Alt is designed to provide a functional
> replacement text, not a short description. In many cases text
> alternatives are not necessary to support interaction. We therefore
> do not propose to adopt this edit.
>
>> * Current wording: "This document does not define the term
>> "accessible" nor accessibility, but uses them with the sense they
>> have in [WCAG]" Change reference from WCAG to Introduction to Web
>> Accessibility <http://www.w3.org/WAI/intro/accessibility> then can
>> say more directly: "This document does not define the terms
>> "accessible" or "accessibility"; it uses them as explained in
>> Introduction to Web Accessibility.
>
> That document referenced has no apparent stability or persistence
> policy. For a reference we prefer to use a W3C Recommendation which
> has both.
>
>> * The Abstract says "Note that by allowing a hyperlink inside
>> another one, this document explicitly redefines the HTML concept of
>> hyperlink in a limited set of circumstances." Is this point clearly
>> addressed in the main document?
>
> Yes. It is in the section mentioned in your first comment above
> (Section 3). Note that we propose to remove the confusing lead-in
> "Note that" in the relevant paragraph.
>
> Please let us know if you are satisfied with our response.
>
> cheers
>
> Chaals TF co-coordinator
>
>
> On Tue, 17 Sep 2013 01:13:44 +0400, Shawn Henry <shawn@w3.org>
> wrote:
>
>> Dear HTML Accessibility Task Force,
>>
>> Thank you for the opportunity to review HTML5 Image Description
>> Extension (longdesc) W3C Last Call Working Draft 16 July 2013
>> <http://www.w3.org/TR/2013/WD-html-longdesc-20130716/>.
>>
>> EOWG has several suggestions from an education and outreach
>> perspective, below.
>>
>> * Add "This section is non-normative." to main non-normative
>> sections. (We see a sentence about this later, but are concerned
>> it's not clear enough. For example, the first section under 3. The
>> longdesc attribute <http://www.w3.org/TR/html-longdesc/#longdesc>
>> starts with a sentence that is not clearly a "Note" (e.g., not
>> offset, marked up, and preceded with "Note:"...")
>>
>> * Introduction: Provide a little context at the beginning, briefly
>> explaining what long descriptions are. For suggested wording, see
>> the Image concepts page <http://www.w3.org/WAI/tutorials/images/>
>> (note the lower sections have "Why is this important" and "How to
>> make images accessible") and Complex
>> images<http://www.w3.org/WAI/tutorials/images/complex>. Consider
>> pointing to these pages for more information (although will need to
>> check timing if it's still a draft and if Shadi & Bim are
>> comfortable).
>>
>> *Suggested edit to the paragraph under Use Cases and Requirements
>> <http://www.w3.org/TR/html-longdesc/#UCnR>: "Text alternatives are
>> required so that users can successfully understand and interact
>> with images even if they cannot see, or see well. The alt attribute
>> is designed to contain a short description. This is sufficient for
>> most images, and should provide enough information to ensure that
>> users understand the image's purpose. Some images contain more
>> information than can effectively be provided in a short
>> description. The longdesc attribute is designed for longer
>> descriptions to meet use cases such as the following." — although,
>> some of this information may be better in the Introduction per
>> previous comment...
>>
>> *Remove title from examples. (rationale: Using a title attribute in
>> examples, even non-normative examples, could lead to proliferation
>> of this technique via copy and paste. Use of title attributes is
>> specifically ruled out in the 'HTML5: Techniques for providing
>> useful text alternatives' draft
>> <http://dev.w3.org/html5/alt-techniques/#secm7>.)
>>
>> *Flow of Use Cases and Requirements: When reading the doc top to
>> bottom, the "Requires:..." and "Helped by:..." under Use Cases do
>> not make sense. It's only when you get to the next section that
>> they make sense. Consider switching the sections around or
>> explaining it.
>>
>> *The items under "Requirements for an Image Description
>> functionality" seem in random order. Is there a way to provide some
>> structure or flow to them? (If there's nothing else, at least
>> alphabetical order would help people reading the use cases and
>> jumping down to the requirements to see the description of the
>> things after Requires & Helped by.)
>>
>> * Current wording: "This document does not define the term
>> "accessible" nor accessibility, but uses them with the sense they
>> have in [WCAG]" Change reference from WCAG to Introduction to Web
>> Accessibility <http://www.w3.org/WAI/intro/accessibility> then can
>> say more directly: "This document does not define the terms
>> "accessible" or "accessibility"; it uses them as explained in
>> Introduction to Web Accessibility.
>>
>> * "Localizing" is not as well understood as "Translating";
>> therefore for the last use case, we suggest changing "Localizing"
>> to "Translating". (also, could simply to "When content is
>> translated to different languages"
>>
>> * The Abstract says "Note that by allowing a hyperlink inside
>> another one, this document explicitly redefines the HTML concept of
>> hyperlink in a limited set of circumstances." Is this point clearly
>> addressed in the main document? (Generally, the abstract is a
>> summary and shouldn't have info that is not elsewhere.)
>>
>> * copyediting:
>>
>> - Suggest change "As well as sections marked as non-normative, all
>> authoring guidelines, diagrams, examples, and notes in this
>> specification are non-normative. Everything else in this
>> specification is normative." to "All authoring guidelines,
>> diagrams, examples, notes, and sections marked non-normative in
>> this specification are non-normative. Everything else in this
>> specification is normative.
>>
>> -Write out IDL on first reference.
>>
>> -Quote terms as follows: The key words "must", "should", and "may"
>> in this specification are to be interpreted as described in
>> [RFC2119]. This document does not define the terms "accessible" or
>> "accessibility" (and change 'term' to "terms" and 'nor' to 'or'.)
>>
>> -Use consistent capitalization in the headings.
>>
>> - Under Use Case, last one has "it is important that metadata
>> intended for human consumption". That seemed a bit awkward to some.
>> Consider changing it to "it is important that metadata intended for
>> people to read" or "it is important that metadata intended for
>> humans" or such.
>>
>> - "Authors should put descriptions within an element which is the
>> target of a fragment link (e.g.
>> longdesc="example.html#description") if a description is only part
>> of the target document." is a bit hard to understand. Can you flip
>> it around and say something like: "'When a description is only part
>> of the target document, authors should include the [fragment link]
>> in the element (e.g., longdesc="example.html#description")."
>>
>> ###
>>
>> (Note: These comments do not necessarily represent consensus among
>> all of EOWG, because not all participants were available to review
>> the comments before we submitted them.)
>>
>> Regards, ~Shawn Henry for EOWG
>> <http://www.w3.org/WAI/EO/EOWG-members.html>
>>
>>
>>
>> ----- Shawn Lawton Henry W3C Web Accessibility Initiative (WAI)
>> Massachusetts Institute of Technology (MIT) e-mail: shawn@w3.org
>> phone: +1.617.395.7664 about: http://www.w3.org/People/Shawn/
>>
>>
>>
>
>
Received on Tuesday, 21 January 2014 23:15:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 21 January 2014 23:15:04 UTC