Re: Establishing minimal set of information requirements for UA/AT communication

Ian,

Here are my answers to your questions:


Catherine Laws wrote:

> Here is a list of information requirements that I believe need to be met
to
> implement an AT like Home Page Reader:
>
> 1. For each element (DOM node) as well as at the page and frame level, be
> able to:


[snip]

> - Determine it's containing structure (form, table, frame, page, etc)


Can you define containing structure? Does this mean:

  * The element whose semantics is to group a number of descendant
    elements?

  * The rendering of an element that, in two dimensions, encloses
    some other content?

In short: can this be determined from the markup language alone?

CKL: What I mean is that an AT should be able to always determine from the
DOM (or an accessibility API), that an particular element is within the
bounds of another element. I am most interested in elements that are within
a particular form, table, select menu, map, or list. All of these
"containers" have beginning and ending tags in HTML, so the DOM is usually
pretty accurate. However, if any elements are missing end tags within a
form, for example, the IE DOM will be incorrect and show that there are no
elements in the form. I am less interested in thinking of containers that
have no ending tags, like headings as implied containers for sections,
although an AT should be able to determine this type of container by the
order of elements in the DOM.

[snip]



> 3. Ability to find the process/window for and place keyboard focus on an
> embedded object or applet.


The binding between process and window is something that is likely
done at the OS level. In UAAG 1.0, we talk about "viewports".

CKL: Yes, we can use the OS level to do this, but I was just pointing out
that this is not possible to do using the DOM interface but something this
is necessary to do as a web access AT.


> 4. The information and events from the APIs and DOMs must reflect the web
> document displayed (i.e. both must include error correction or not).
>
> 5. Ability to select/highlight text, controls, and images at character
> offsets programmatically like you can select with a mouse.


UAAG 1.0 doesn't require any particular type of selection; it can
be text-only or text-and-images, etc. Our requirement is that,
whatever the selection encompasses, that information be available
through the API.

CKL: I think we can get what the selection encompasses from the IE DOM
assuming that a blind user could select a portion of text using the
keyboard, but we cannot use the IE DOM APIs to select both text and images
(and controls) using an API. That is, there is an API for doing a
SetTextRange but not doing a set range that also includes images and
controls.

--
Cathy Laws

IBM Accessibility Center, 11400 Burnet Road,  Internal Zip 9151, Austin,
Texas 78758
Phone: (512) 838-4595, FAX: (512) 838-9367, E-mail: claws@us.ibm.com, Web:
http://www.ibm.com/able

Received on Friday, 5 April 2002 13:04:16 UTC