Minutes from Dec 1

Please review and comment...

Attendees: Rich, Pete, Malte, Tatsuya,
Hiro, Chieko, Janina

1. Approval of minutes from 24Nov08
meeting http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200811/msg00018.html

Pete/Rich approve

2. Radio Button Groups

ODF overloads form:name to specify which
radio buttons are in a group.  

Rich's proposal to TC: http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200811/msg00017.html

The TC has indicated that form:name
duplicates form:id essentially creating two unique names and suggested
that form:name can be removed.

They also propose adding a form:group-name
attribute: http://wiki.oasis-open.org/office/Grouping_for_Radio_Elements

Another problem is that form labels
(form:fixed-text with form:for attribute) can label individual controls
but the labeled radio buttons could be in separate groups.  So a means
to label groups is needed.

Rich would like  to bring forward
to TC.

Action Item: Malte wants to look into
this deeper and will over next couple days.

3. Specification related Issues: 

3a: Hiro to post clearly marking whether
links are local as an issue to our list and the TC list.

Same discussion in main TC: 
      http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200812/msg00000.html

The proposal suggests using URI: 
      http://wiki.oasis-open.org/office/Change_Proposal_for_ODF_1.2_using_URL_fragment_identifiers_for_ODF_media_types

If this proposal is accepted we can
use it for intrapage links

Action: Hiro to write a proposal to
use the TC proposed mechanism

Note: There are three issues for 1.2
- radio groups, intradoc links, and caption id

3b: Use of ARIA concepts to assist ATs
in processing dynamic content through added meta data

Peter Korn did not provide input. regarding
live region support in ATK/AT-SPI.

Rich checked with Aaron Leventhal who
said live regions can be supported by ATK/AT-SPI.

This item can be closed.

3c: Should we include live region capabilities
and how should we render these? 

rs: We can do this without changing
the spec 

rs: Live sections need to be marked

rs: Do we want to specify priority level,
i.e. polite, assertive, rude from the aria-live property

rs: Do we want to include the equivalent
of aria-atomic

rs: I think aria-channel is overkill

rs: See http://www.w3.org/WAI/PF/aria/#liveregions

rs: Live regions are still in the early
stages; not sure we want in the ODF spec yet

mt: I agree; don't force this into 1.2
- find a good default and let API map that

js: It's typical to have an optional
attribute in a spec for a while, then make it required later

mt: You could have an optional attribute
with a reasonable default, but let's do it in a later version of the spec;
it's getting too late for 1.2

rs: Should we handle it in a a11y API
mapping guideline?

mt: I recommend not to since there would
be nothing in the spec

rs: An example http://finance.yahoo.com/q/cq?s=^DJI%20^IXIC%20ibm%20qqqq%20xli%20pph%20EEM%20IBB%20MUE%20msft%20aapl

rs: This is an updating table bound
to backend data source; you could mark the changing regions as live

rs: In an a11y api mapping, if there
is data bound to backend it's a live region; the only thing needed from
ODF markup is that the info is changing

js: I think we need this in the guidelines,
we need to start talking about use cases and showing that there are engineered
solutions. 

rs: I agree

Action: Continue discussion at the next
meeting.

Pete Brunet

                    
                     
                     
         

IBM Accessibility Architecture and Development

11501 Burnet Road, MS 9022E004, Austin, TX 78758

Voice: (512) 286-5485, Cell: (512) 689-4155

Ionosphere: WS4G