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

Bill Haneman Bill.Haneman at Sun.COM
Wed Mar 1 08:49:32 PST 2006


On Tue, 2006-02-28 at 17:30, Catherine Laws wrote:
> Here is a document that discusses 2 different ways that HTML document
> structure and elements could be exposed in Firefox using ATK. The first
> approach exposes a structure that more closely matches the HTML DOM, with
> all text exposed at deeper leaf/child levels with more empty content
> containers showing the hierarchy of the document structure. The second
> approach takes greater advantage of the Hypertext interface by exposing
> plain text at higher container levels with UNICODE characters representing
> embedded child objects, both non-text and textual, that require additional
> ATK interface implementations, such as images and relationships.
> 
> http://www.mozilla.org/access/unix/new-atk.html


I am surprised to see suggestion #2 below for new roles, since this
proposal was already aired and explicitly rejected by consensus during
the 'Accessible Doc' discussions last year.  The main reason for this
was that the "roles" proposed don't map well onto the ATK role
semantics, but rather are primarily attributes of the relevant objects.
Instead, a number of new roles have been added to ATK already, in order
to handle more HTML element types.  Most readers of this email will be
probably be aware of this; including for instance (pasting from the ATK
inline documentation):

 *@ATK_ROLE_EMBEDDED: The object is an embedded container within a
document or panel.  This role is a grouping "hint" indicating that the
contained objects share a context.
 *@ATK_ROLE_ENTRY: The object is a component whose textual content may be 
entered or modified by the user, provided @ATK_STATE_EDITABLE is present.
 *@ATK_ROLE_CHART: The object is a graphical depiction of quantitative data. 
It may contain multiple subelements whose attributes and/or description may be queried to obtain both the quantitative data and information about how the data is being presented. The LABELLED_BY relation is particularly important in interpreting objects of this type, as is the accessible-description property.
 *@ATK_ROLE_CAPTION: The object contains descriptive information, usually textual, 
about another user interface element such as a table, chart, or image.
 *@ATK_ROLE_DOCUMENT_FRAME: The object is a visual frame or container which contains 
a view of document content. Document frames may occur within another Document instance, in which case the second document may be said to be embedded in the containing instance. HTML frames are often ROLE_DOCUMENT_FRAME. Either this object, or a singleton descendant, should implement the Document interface.
 *@ATK_ROLE_HEADING: The object serves as a heading for content which follows it in 
a document. The 'heading level' of the heading, if availabe, may be obtained by 
querying the object's attributes.
 *@ATK_ROLE_PAGE: The object is a containing instance which encapsulates a page of 
information. @ATK_ROLE_PAGE is used in documents and content which support a paginated navigation model.
 *@ATK_ROLE_SECTION: The object is a containing instance of document content which 
constitutes a particular 'logical' section of the document. The type of content within a section, and the nature of the section division itself, may be obtained by querying the object's attributes. Sections may be nested.

Having added the above roles, I don't think it would be acceptable to
add the proposed finer-grained HTML roles to the AtkRoleType
enumeration, nor to expose them via atk_get_role_name.

It may make sense to expose XHTML element types as attributes on the
relevant objects, for instance "XHTML:role = h1", but for instance in
the case of headers, the agreed upon plan was to use ATK_ROLE_HEADING,
with the appropriate heading level exposed as an object attribute.

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.

> The proposal is relatively simple:
> 
>      1. Continue to map HTML constructs to existing AT-SPI roles where
>         natural from both the Gecko and AT-SPI perspectives.
>      2. Expose new roles for structural HTML element. The rolenames
>         will be of the form "HTML:tag", where 'tag' is the actual HTML
>         tag
>      3. Treat container elements as containers which can have
>         children. Embedded objects, links and other containers will
>         appear as children of these containers.
>      4. Expose text with one of 2 methods:
>         a) expose text as child text leaf nodes with a role of "text",
>         or 
>         b) Expose contatenated text on the container for the text,
>         using unicode 0xfffc to indicate embedded objects 
>         A general rule is: if something exposing AccessibleText has
>         children, then each child will be marked in the text with
>         0xfffc
>      5. Treate image maps as a container image with a set of anchor
>         children
>      6. Hypertext will still be necessary, but only to return a
>         Hyperlink object for getting the URL of a link
>      7. The following interfaces would be supported: AccessibleAction,
>         AccessibleComponent, AccessibleText, AccessibleEditableText,
>         AccessibleImage, AccessibleSelection, AccessibleTable,
>         AccessibleValue, AccessibleRelation 
>      8. AccessibleTable would be implemented on the <table> object,
>         and the children could also be obtained by walking the regular
>         hierarchy.

Overall this proposal makes sense (apart from the fact that the 'roles'
should be object attributes), but I don't see the value in failing to
use Hypertext as intended for image maps, links within text elements,
and activation of links. So one could say that I do not agree with items
#2, #5, and #6 as presently proposed.  As for #4a vs #4b, that certainly
merits some live discussion but either seems workable.

best regards,

Bill


> We can discuss the pros and cons of these two approaches by email and at
> the FSG AT-SPI teleconference tomorrow, Wednesday, March 1, being held in
> place of the regular FSG accessibility call (at 2 PM EST).
> 
> Janina, are you sending out the meeting notice for tomorrow?
> 
> 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
> 
> ______________________________________________________________________
> _______________________________________________
> Accessibility-atspi mailing list
> Accessibility-atspi at lists.freestandards.org
> http://lists.freestandards.org/cgi-bin/mailman/listinfo/accessibility-atspi




More information about the Accessibility mailing list