Re: simultaneous rendering of image and its descriptor

Hi Gregory,

I'm still not sure I see why "long descriptor" is a special case. Both 
short and long labels (and medium of a technology had them) need to be 
made available both explicitly and implicitly.

Good point about "locked down" systems. We should remember this when we 
think about configuration settings.

Cheers,
Jan



Gregory J. Rosmaita wrote:
> aloha, jan!
> 
> i concentrated on a "long descriptor" because it usually (currently)
> takes the form of an external resource that can be pulled into an 
> IFRAME, rendered in a UA's sidebar, rendered in place of graphic,
> etc.
> 
> for short descriptors, a UA would reuse the value of the "alt"
> attribute to create a visible caption -- of course, the user must 
> have control over the rendering of the caption -- respect user's 
> pre-set colors, fonts, etc., allow for exposure above or below the 
> object being described, encase the image and short descriptor in a 
> DIV so that a style rule can be applied that visually binds together
> the image and the descriptor using the CSS box model (basically, the
> text and the image in a CSS-defined visual box) so as to provide a 
> caption/terse description of the object being described, and an 
> explicit (programmatically) as well as implicit (that is, visual) 
> container for the pair (image/descriptor) ...
> 
> short descriptors are a bit different, in that their "alt" text 
> (or whatever form a short descriptor takes) must be available to 
> the end user whether or not the image itself is rendered -- in a 
> locked-down or multi-use terminal scenario, it may not be possible
> for an individual to turn image rendering off, or it may be dis-
> advantageous to a colleague to do so, so whether or not an image 
> is rendered, the "alt" text must be available to the user, either
> on demand (onFocus announcement, onMouseOver, through a dedicated 
> keystroke sequence, etc.) or by default, which means that the UA
> has to carry the "alt" value into the DOM when images are rendered,
> so that the "alt" text is available for exposition either natively 
> by the UA or through the passing of information from the UA to the
> AT via the DOM...
> 
> did i clarify things, or just further muddy the waters?
> gregory.
> 
> PS: i can do much better on "doing more" through use of ARIA -- an 
> example of the necessary markup will be forthcoming (as soon as i 
> can get to it)
>   ------------------------------------------------------------------
>   "Let me save you from drowning," said the monkey as he placed the 
>   fish into a tree.                                 -- Hindu proverb
>   ------------------------------------------------------------------
>                 Gregory J. Rosmaita <oedipus@hicom.net>
>       Camera Obscura: http://www.hicom.net/~oedipus/index.html
>   ------------------------------------------------------------------
> 
> ---------- Original Message -----------
> From: Jan Richards <jan.richards@utoronto.ca>
> To: "Gregory J. Rosmaita" <oedipus@hicom.net>
> Cc: w3c-wai-ua@w3.org
> Sent: Thu, 25 Oct 2007 22:50:51 -0400
> Subject: Re: simultaneous rendering of image and its descriptor
> 
>> Hi Gregory,
>>
>> Why just the "long descriptor"? What about short descriptors? 
>> Would providing these via an image properties dialog be sufficient?
>>
>> -Jan
>>
>> Gregory J. Rosmaita wrote:
>>> aloha!
>>>
>>> i'm not sure whether the following falls under 3.6 or 3.7 or in a 
>>> checkpoint of its own:
>>>
>>> 1. Allow configuration to allow simultaneous rendering of an image 
> and 
>>> its long descriptor
>>>
>>> use cases:
>>> 1. user with severely restricted viewport needs guidance through the 
> flow 
>>> of the image; 
>>>
>>> 2. are users with cognitive processing issues who will require 
> guidance 
>>> through the detailed description
>>>
>>> (more use cases at:
>>> http://esw.w3.org/topic/HTML/LongdescRetention
>>> the page name is misleading, as the actual title of the page is 
>>> "Image Equivalent Content", the "Requirement" of which is recorded 
> thus:
>>> "In situations where images are not available to the user (because of 
>>> disability, choice, or UA limitation) there is a need for a mechanism 
>>> that presents equivalent content to the user, either as an 
> alternative to 
>>> the image or in a side-by-side exposition. Equivalent content is not, 
> nor 
>>> should it be, and either/or proposition, and its method of exposition 
>>> should be subject to user control, as some user groups may need both 
> the 
>>> image and its detailed description in order to make sense of the 
> image 
>>> or [WINDOWS-1252?]— in the case of a user with an extremely small 
> viewport [WINDOWS-1252?]— to follow 
>>> the image's flow."
>>>
>>> and, yes, if that sounds familiar, its because i wrote it)
>>>
>>> as for the "doing more" portion, here is what i verbally proposed at 
>>> today's telecon:
>>>
>>> --- DOING MORE ---
>>> Support for ARIA concept of "context menus" for objects/elements:
>>>
>>> 1. expose entire range of possibilities available to the user via a 
>>> context menu
>>>
>>> 2. limit range of possibilities to user-defined pre-selection (via 
>>> preferences)
>>>
>>> 3. exclude/include content-types/formats through UA's user preferences
>>>
>>> No matter which setting the user sets as the default, there must be a 
>>> mechanism that enables the exposure of the full range of 
> possibilities -- 
>>> even when a user has pre-set what content-types to include, as the 
> author 
>>> may not have provided any conditional/alternative content that meets 
> the 
>>> user's pre-set criterion.  It is for this reason that support for 
> ARIA 
>>> context menus is strongly encouraged, as they can display the entire 
>>> range of controls and options available to the end user.
>>> --- END DOING MORE ---
>>>
>>> RESOURCE NOTE FOR UAWG:
>>>
>>> Note: the first instances of the string "context menus" should link 
> to 
>>> the ARIA document or the ARIA Best Practices document (which 
> currently 
>>> exists only on the ESW wiki, but which is being pulled together into 
> a 
>>> W3C note)
>>>
>>> Relevant ARIA Properties:
>>>
>>> 1. latest PF Editor's draft (member-confidential)
>>>     http://www.w3.org/WAI/PF/Group/adaptable/#haspopup
>>>     http://www.w3.org/WAI/PF/Group/adaptable/#controls
>>>     http://www.w3.org/WAI/PF/Group/adaptable/#owns
>>>
>>> 2. latest public draft
>>>     http://www.w3.org/TR/2007/WD-aria-state-20071019/#haspopup
>>>     http://www.w3.org/TR/2007/WD-aria-state-20071019/#controls
>>>     http://www.w3.org/TR/2007/WD-aria-state-20071019/#owns
>>>
>>>   ------------------------------------------------------------------
>>>   "Kill the rattlesnake that gives no warning; spare the one that 
>>>    does."                                    -- Lenni Lenape proverb
>>>   ------------------------------------------------------------------
>>>                 Gregory J. Rosmaita <oedipus@hicom.net>
>>>   Camera Obscura:           http://www.hicom.net/~oedipus/index.html
>>>   Oedipus' Online Complex:  http://my.opera.com/oedipus/
>>>   UBATS - United Blind Advocates for Talking Signs: http://ubats.org
>>>   ------------------------------------------------------------------
>>>
>>>
>>>
>> -- 
>> Jan Richards, M.Sc.
>> User Interface Design Specialist
>> Adaptive Technology Resource Centre (ATRC)
>> Faculty of Information Studies
>> University of Toronto
>>
>>    Email: jan.richards@utoronto.ca
>>    Web:   http://jan.atrc.utoronto.ca
>>    Phone: 416-946-7060
>>    Fax:   416-971-2896
> ------- End of Original Message -------
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Friday, 26 October 2007 18:06:26 UTC