W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2007

Re: simultaneous rendering of image and its descriptor

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Fri, 26 Oct 2007 19:23:13 +0100
To: Jan Richards <jan.richards@utoronto.ca>
Cc: w3c-wai-ua@w3.org
Message-Id: <20071026181020.M67935@hicom.net>

aloha, jan!

perhaps the difference between a short/terse descriptor and a 
long descriptor exists only in my head -- from a programmatic 
point-of-view, the long description, if it is to be displayed
in place of the image or simultaneously with the image, needs
to be pulled into the document from another document, which 
strikes me as somewhat different than reusing a text-string 
associated with an image to create a visual caption...

one consideration is the use of ARIA widgets (such as the tree 
view and accordion views) to provide long descriptions of complex
diagrams, flow charts and family trees -- that way, an individual
could expand/collapse all, or choose which branches to expand, 
so as to follow a particular tree and its subtrees, so as to 
provide an equivalent to the "ah-hah!" moment that such complex 
diagrams, flow charts, and family trees provide for the user who 
can visually and cognitively process them...  this isn't a problem
in the HTML world, whose mime-type is text/html, but may be more 
tricky when integrating a section whose mime-type is 
application/xhtml xml into a document instance whose mime-type 
is text/html

i suppose i'm just trying to cover all of the possibilities, so 
if what i've written applies equally to both sorts of descriptors,
then the better it is from a spec-writing point of view -- treat 
images and alternate content in a consistent manner...

i hope that helps, if not, i'll be sitting here at my laptop for
the foreseeable future, so just ping me again,

gregory.
------------------------------------------------------------
The more things are forbidden, the more popular they become.
                                               -- Mark Twain
------------------------------------------------------------
Gregory J. Rosmaita: oedipus@hicom.net
     Camera Obscura: http://www.hicom.net/~oedipus/
        Oedipus' Online Complex: http://my.opera.com/oedipus
------------------------------------------------------------

---------- Original Message -----------
From: Jan Richards <jan.richards@utoronto.ca>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>
Cc: w3c-wai-ua@w3.org
Sent: Fri, 26 Oct 2007 14:06:30 -0400
Subject: 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?][WINDOWS-1252?]— in the case of a user with an 
extremely small 
> > viewport [WINDOWS-1252?][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
------- End of Original Message -------
Received on Friday, 26 October 2007 18:23:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:50 GMT