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

Re: UAAG Minutes for 9/30 teleconference

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Fri, 1 Oct 2004 16:11:05 -0400
Message-Id: <p06110403bd836408dc88@[]>
To: w3c-wai-ua@w3.org

At 7:13 PM -0500 9/30/04, Catherine Laws wrote:
>AG: I have two high level comments from Protocols and Format group. I only
>looked at Jon's proposal. It has 2 switches being thrown at the same time -
>how fine or limited space nav stops for character and active element, and
>does focus follow - in caret mode it doesn't and in standard mode it does.
>Not clear that screen reader should have separate modes and controls to
>unhitch. Other - Jon's proposals separates from actions bound to specific
>keys but they can be rebound. How is Mozilla going to integrate XML and
>XPL? Important that author should propose key binding but user can change
>the bindings.
>XPL is a way for the author to set view-specific layer on the DOM. XHTML
>which tries to be specific. Example - Does an access key event just move
>focus or move focus and fire.


Aaron explained that there is already XBL used in Gecko to implement XUL.

There is work based on the existing XBL but not limited to that for binding
in SVG and other XML-based document contexts.

See for example

>AL: XPL to implement XUL. Allows attachment of behaviors and events to
>tags. Attach context to buttons.
>AG: Might be able to query DOM to see it.
>AL: Ordinary scripts would just see one element.
>JG: DOM would have description.
>AL: Can extend Mozilla with XPL. Like create a slider with 2 sliders.
>AG: How to repair conflicts? Maybe between optimization. In earlier
>discussions, AT vendors said that they weren't implementing W3C DOM because
>it doesn't match the screen. View-specific shows bounding rectangles. There
>is desire to have better info of the view programmatically. One mode to get
>view, the other to get content.
>PK: DOM doesn't provide info about final rendering. We supplemented this in
>JG: In your proposal, not clear for caret mode versus standard mode for
>focus. If navigating a table cell, where is the header info or label info
>for a control?
>PK: We're serving 2 masters - screen reader user and user without AT.
>Evolving discussion. May need additional keyboard bindings beyond proposal
>for screen reader user. JavaScript is a good way to do that. Implement
>Gnome accessibility for ATK. AccessibleTable object has a table with
>children. Ask what is your row extent or column and headers. Sun has not
>yet implemented AccessibleTable for HTML tables. But it should be nice for
>JG: Accessing row and column headers is more complex than that . What about
>the headers attribute?
>PK: The algorithm is not yet implemented. Need mappings
>AG: The data model is not there.
>JG: Example in WCAG guidelines I will send you.

For more good info on how table markup can be used see the FedStats Worshop
materials at


PS:  Peter, yes, 'accessible relation' may be the way to map the relationships
from a [ TD | TH ] table cell to the other elements whose IDs are given in the
'headers' attribute for that starting cell.

In this process, if there is a way to encode it, it would be useful 
to note that
this relationship, i.e.

[TD | TH ]   --> via IDREFS in 'headers' --> [TD | TH]

is a special case of a broader relationship class roughly equivalent 
to 'labeledBy'
[in Java? in Java Accessibility?].

In other words the AT could query for all examples of 
"self.labeledBy" and would
get the cells pointed to in the 'headers' attribute as part of the 
returned collection
of hits.

There is a user keystroke in Jaws that performs this sort of a 
logical-context query on
a table cell.

The concept of this query is the "immediate information context" for 
the element
at which the query starts.  These are fields that as a function of 
their markup are
clearly implicated as conditioning the interpretation of the subject 
cell's contents.

The point is that the canonical questions include

- Where am I? - recapping the *physical* context per document 
structure is in this aspect
- What is there?  - recapping the *logical* context for a table cell 
is in this aspect
- What can I do? - discover and label all handlers bound to events in 
this context

But in simple cases the user should just be able to say Hunh??? and 
get a bit of
fresh orientation on all those aspects in reply.

The context query in GUI mode has lots of "where am I?" and "what is there?"
re-enforcement from the persistent screen display.  Thus the context query
defaults to just "what can I do?"  In other delivery contexts, the mix of the
above three questions that is answered on context query should be adjusted.

The content model has to support the information to answer all the 
above questions
and the [user settings, AT] can profile down to what actually gets used at what
level of depth in the layered (generalized) Help responses.

>CL: I'll send a complex table example from the IBM Accessibility
>PK: Another tool in Gnome - AccessibleRelation - extensible.
>JG: These relationships should be exposed to all users, not just through an
>PK: How do you expose them?
>JG: UAAG has conditional content techniques. Like for alt text, offer
>option to not display the images.  For headers, could be exposed as tool
>tip when mouse moves over a table cell. For keyboard model, if caret focus
>moves into table cell, put headers on the status line. Could have table
>view with headers put in front of each table cell content.
>PK: Reasonable additions to Mozilla. Don't see how it's about
>JG: If not using magnifier or screen reader but you zoom the text, when
>viewing the table cell, you can't see the headers. Also, accessible
>authoring - people never see alternative content. If there's a headers
>view, they wouldn't need an AT.
>PK: Good proposals.
>AG: Was a description? in content model for table.


Received on Friday, 1 October 2004 20:13:40 GMT

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