Re: longdesc requirements review (from Rich)

You are welcome Gregory.

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	"Gregory J. Rosmaita" <oedipus@hicom.net>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS, public-html-a11y@w3.org
Cc:	jbrewer@w3.org
Date:	04/19/2011 09:29 AM
Subject:	Re: longdesc requirements review (from Rich)



aloha, rich!

thank you VERY much for your comprehensive review of the verbose
descriptor requirements -- your input is extremely valuable, and i
have mounted your comments in their entirety to the discussion
page for the verbose desc reqs wiki page:

http://www.w3.org/WAI/PF/HTML/wiki/Talk:Verbose_desc_reqs

i did make the suggested change to Requirement 1 on the requirements
document:

PRIOR
1. A programmatic mechanism to reference a specific set of structured
content, either internal or external to the document containing the
described image.

CURRENT
1. A programmatic mechanism to reference a specific set of structured
host language content, either internal or external to the document
containing the described image.

RATIONALE
Change structured content to structured host language content. We don't
want to use PDF to describe HTML or vice versa

thanks again for your review -- more comments and discussion to follow,
and thanks for the excellent suggestion to clarify requirement 1,

gregory.
----------------------------------------------------------
He that will not apply new remedies must expect new evils;
for time is the great innovator.      -- Sir Francis Bacon
----------------------------------------------------------
            Gregory J. Rosmaita: oedipus@hicom.net
        Camera Obscura: http://www.hicom.net/~oedipus/
    Oedipus' Online Complex: http://my.opera.com/oedipus/
----------------------------------------------------------

---------- Original Message -----------
From: Richard Schwerdtfeger <schwer@us.ibm.com>
To: public-html-a11y@w3.org
Cc: jbrewer@w3.org
Sent: Mon, 18 Apr 2011 16:47:07 -0500
Subject: longdesc requirements review (from Rich)

>
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Requirements_for_HTML5

>
>    1.		 A programmatic mechanism to reference a specific set of
structured
>       content, either internal or external to the document
> containing the      described image.      <rss>Change structured
> content to structured host language content.      We don't want
> to use PDF to describe HTML or vice versa </rss>
>    2.		 A way to inform users and authors that a description is

>   present/available.      <rss>comment: This is a change to
> longdesc in that it provides      additional functionality. This
> can be achieved by a plug-in for      example. If they are
> trying to delete longdesc this may be a hard      sell.
> This may best be addressed by user agent requirements for ARIA
> if we      can get the browser vendors to agree. At least it
> could be consistent      across browsers. Is this a UAAG
requirement?</rss>
>    3.		 A device independent way to access the descriptive
content.
>         <rss>comment: This is a change to longdesc in that it provides
>       additional functionality. This can be achieved by a plug-
> in for      example or by web applications themselves. If they
> are trying to      delete longdesc this may be a hard sell.
> This may best be addressed by user agent requirements for ARIA
> if we      can get the browser vendors to agree. At least it
> could be consistent      across browsers. Is this a UAAG
requirement?</rss>
>
>    4.		 An explicit provision that accessing descriptive
content, whether
>       internal or external to the document containing the image,
> does NOT      take the user away from the user's position in the
> document      containing the image where the verbose descriptor
> was invoked;        <rss>For a blind user to read the long
> description you will      temporarily need to take the user away
> from the position. Note: this      is another reason to not
> limit ourselves to native host language      properties as part
> of the strategy. We might instead focus on a      single way to
> do short (labels) and long descriptions consistently      across
> elements such as through the use of ARIA properties         I
> suggest some rewording, something like:         An explicit
> provision that accessing descriptive content, whether
> internal or external to the document containing the image, does NOT
>       take the user away from the user's position in the document
>       containing the image where the verbose descriptor was
> invoked when      the has completed reading the description and
> wishes to quickly      return back to the element to which the
> description is applied.   </rss>
>    5.		 A way to provide user control over exposition of the
> descriptor so      that rendering of the image and its
> description is not an either/or      proposition. (A visual
> indicator of the description should NOT be a      forced visual
> encumbrance on sighted users by default).        <rss>comment:
> this is an additional requirement for a property that      they
> are trying to remove. </rss>
>    6.		 A method to reference a longer description of an image,
without
>       including the content in the main flow of a page.
>    <rss>comment: this is an additional requirement for a
> property that they      are trying to remove. </rss>
>    7.		 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      verbose descriptor resource of the former
> must be different than the      mechanism for accessing the href
> resource of the latter.
>    8.		 A means of accessing content added by authors using the
HTML4
>       attribute longdesc (backwards-compatibility for "legacy"
> content)      <rss>should it get removed.</rss>
>    9.		 Ease of use.      <rss>comment: What aspect is ease of
> use? It would appear you      addressed ease of use above.
> </rss>   <rss>
>       10. Should longdesc be targeted for removal, HTML must
> deprecated the      attribute with an acceptable time frame to
> allow for industry to      produce an accepted alternative. </rss>
>
>    Should we use ARIA as the replacement strategy long term we
> must be      clear that ARIA implementations (post 1.0) must
> require that user      agents support these interactive
> features. This could be a user agent      conformance behavior
> for UAAG or the host language.
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
------- End of Original Message -------