[Accessibility] Re: [Accessibility-atspi] Two diffferent ATK implementations for HTML document structures

Wed Mar 1 11:59:55 PST 2006

On Wed, 2006-03-01 at 18:45, Catherine Laws wrote:
> Bill Haneman <Bill.Haneman at Sun.COM> wrote on 03/01/2006 10:49:32 AM:
> 
> >
> > I strongly believe that the Hypertext interface should continue to be
> > used for embedded links (i.e. the links should not be children), in
> > accordance with our published documentation.  It makes sense to use
> > containership for other kinds of embedded objects.  Hypertext will also
> > be necessary in order to provide for programmatic activation of links.
> >
> > Client-side image maps are one of the primary design cases which
> > Hypertext was intended to manage.  Why would we not use Hypertext as
> > intended, for this purpose?  Note that the Hypertext interface
> > explicitly allows for multiple anchors within a link.
> >
> > I don't see the value in failing to
> > use Hypertext as intended for image maps, links within text elements,
> > and activation of links.
> 
> One major problem we can't figure out is how to specify relationships for
> hyperlink objects and map areas. Hyperlink implements the Action interface

Hyperlink should not implement Action, according to the spec.

> but not the Relation interface, so how do you implement tabindex (taborder)
> if you can't specify a FLOWS_TO relationship, indicate that hypertext is a
> label for a control if you can't implement LABEL_FOR, or indicate the
> activation of a link controls content changing in an iframe or some other
> control? And can you specify an accessible name and description for each
> Hyperlink object to match the alt/title attributes for each area of a map?

Hyperlink:getObject(i) should get you a queryable object corresponding
to the 'ith' anchor in the map.  Such objects provide name, description,
and may also implement Image, Action, Component, or Text, depending on
the way they are exposed to the end user.  Each map area would be a
separate anchor in the Hyperlink object.

Tabindex/taborder aren't well served by the current APIs - I would not
use FLOWS relationships to infer tab order, as FLOWS is for 'content
flow', i.e. normally text flow within documents.

For this example client-side image map (living in a document at
file:///home/bill/foo.html):

1) element "<img>" implements AtkImage, AtkComponent, and AtkHypertext.
[We'll call its AtkObject "img", and its corresponding other interface
instances 
"img_img", "img_component", "img_hypertext" for purposes of this
example.]

2) img::getName() returns the 'title' attribute, "example client side
image map"
   img::getDescription() returns the longdesc;
   img_img::getDescription() returns the alt-text;
   img_img::getImageExtents() returns a bounding box containing the
image, i.e.
	[0,0,190,260]
   img_img::getImageLocale() returns "en_UK"

3) img_hypertext::getNLinks () returns 1.
   img_hypertext::getLinkIndex (0) returns 0;
img_hypertext::getLinkIndex(n) returns -1 for all other values of n,
since this hypertext object has zero-length text content.
   img_hypertext::getLink (0) returns an instance of Hyperlink,
'img_link'.

3) The 'img_link' Hyperlink instance is the thing that represents the
imagemap.
   Provided the <map> element can be identified, and the contained hrefs
   are valid, img_link::isValid() returns TRUE.

4) Because the <img> map has four anchors, img_link::getNAnchors()
returns 4.
	img_link::getURI(0) returns "file:///home/bill/page1.html",etc.
	img_link::getObject(2) returns and Accessible which we'll call
'anchor_2'.

5) 'anchor_2' implements Component (because it maps to an onscreen
position), 
	and Action (because hrefs should all be actionable).   With the new
AT-SPI
	Accessible::getAttributes() API, it can also expose its "shape"
attributes,
	i.e. it has the "shape=rect" name-value pair.  
	anchor_2_component::getExtents() returns [21,158,170,211].
	Note: Since Component only
	exposes rectangular bounding boxes, the circle,       
        anchor_1_component::getExtents() 
	would return [100,84,158,142].

6) 'anchor_2' can be programmatically activated via the Action API
(where 
	actions such as 'activate', 'open in new window', 'bookmark', etc. 
        would be anticipated).  

7) To answer Cathy's question about 'title' and 'alt', the anchor
objects (i.e. anchor_2) expose name and description just as the
containing <img> element did.  We only need to decide a
recommendation/policy on which attributes (title, alt, etc.) map to
Accessible::name versus Accessible:description in these cases.  I think
we've suggested that "alt" usually maps to Image::description for
images, but for <area/> we may prefer to map "alt" to Accessible::name
or Accessible::description.

>From the assistive technology's point of view, this looks just the same
as any other image link (i.e. any <img/> within an <a/>) until the
Hyperlink returned from the Hypertext interface is queried deeper.  This
seems right to me; in this respect, client-side imagemaps look
superficially like any other kind of link, until you poke at them.  

The above may look complicated, but in fact it isn't, considering that
we've just attempted to enumerate pretty much the whole range of API for
a client-side image map.  I think breaking it into a parent/child
hierarchy wouldn't result in a simpler structure, the only difference is
that the img_hyperlink::getAnchor()::getObject() calls would be replaced
by img::getChild(), and we would need additional roles or relations to
convey the hyperlink/image-map semantics in the latter case.

Bill

> Cathy Laws
> 
> IBM Accessibility Center, WW Strategic Platform Enablement
> 11501 Burnet Road,  Bldg 904 Office 5F017, Austin, Texas 78758
> Phone: (512) 838-4595 or (512)838-2308, FAX: (512) 246-8502
> E-mail: claws at us.ibm.com, Web: http://www.ibm.com/able
> 
> Vision without action is merely a dream, action without vision is merely
> passing time, but action with vision can change the world.” Nelson Mandela