OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-accessibility message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ODF A11y Minutes Draft for Monday, 6 October


Minutes
Office Accessibility SubCommittee Teleconference
Monday, 6 October 2008

Attendees: Pete Brunet, Peter Korn, Malte, Rich, Janina, Tatsuya, Hiro
Regrets: Chieko, Mike

Scribe: Janina

1. Approval of minutes from 25Aug08 meeting (attached, and also at: 
http://lists.oasis-open.org/archives/office-accessibility/200808/msg00029.html)
Unanimously approved.

2. Discussion & plan: Readiness of ODF v1.2 draft for review (and if so, 
our plan is...)

RS: We're to the point that we should take another pass through the 1.2
draftspec by the next mtg.

rs: We probably need to address the separate schema.

pk: Do we have a list of issues from the last review?

rs: Yes, but the main issue was that it was all too up in the air for us to
work on meaningfully.

rs: We also need to decide what we will do for the 1.2 spec release.

ht: Will try to scan and compare by the 27th.

rs: Doesn't seem to be much to add to the spec. Most of the work is probably
directions to Office developers.

ht: Mainly focus on spec and not UI?

pk: Wonderful.

ht: Do we have an interest in the metadata? I'm not sure.

pk: Perhaps two things:
	a.) What's being added?
	b.)	Do we want to tag a11y metadata?

ht: OK, will look at metadata as well.


3. Discussion: Action plan for next rev. of ODF Accessibility Guidelines

pk: Taking up from previous discussions re possibility of folding our guidance
into the 1.2 spec docs.

rs: One of Rob's concerns is to not scatter a11y guidance throught the spec.
TC is looking at a collection of docs that accompany the spec and the
suggestion is that our doc be one of those. The spec would then refer to this
a11y doc.

rs: Issue is time to work this up properly. Could be a large task.

rs: We should tell the TC our strategy re 1.2.

pk: Concerned we don't have the cycles to do this.

rs: Ditto.

rs: Suggest proceeding with current guidelines for now, unless someone wants
to own the doc?

rs: Perhaps we decide after Hiro's review?

pk: We've not had great success farming this out.

rs: We fixed a lot of the issues in 1.0. Things are much improved in the spec
now. Our task is probably educating application developers.

rs: We made changes in 1.0 that didn't make it into 1.1 (particular disjunct
table headers). We need to follow up
to make sure these are addressed in 1.2.

rs: When they broke the spec into several docs, our changes may have
disappeared. We need to check on that.

rs: If our changes are only in a few places, perhaps we don't need a separate
document.

pk: Sounds like we're inclined not to do this, but will await Hiro's report to
decide.

4. New action items from last meeting

    * Malte and Peter: Provide input on the above topic of integration 
of the a11y guidelines into the suite of docs comprising the ODF 1.2 spec.

Done.

    * Malte: Provide input on charts backed by disjoint cells: 
    How does (or how will) OpenOffice provide access to charts backed by
    disjoint cell ranges either in a single or multiple tables?  If this
    case be done today, what are the examples?
    http://www.oasis-open.org/apps/org/workgroup/office/email/archives/200808/msg00054.html
    http://mediacast.sun.com/share/korn/chart-accessibility-challenge.ogg
    http://mediacast.sun.com/share/korn/chart-in-writer.behavior.ogg

pk: We've discussed one approach some time ago. Did we write it up well? ...
No, not there.

mt: Don't know if we should special-case chart data? However, suspect this is
more of an API issue.

pk: Weren't we suggesting constructing a the combined table--perhaps in a
dialog?

mt: Remember that discussion.

pk: Should that be in our guidelines? More important, how do we give AT and
the AT user sufficient information to meet the need.

js: Never been a fan of the idea that we shouldn't construct special UI for
a11y.

pk: Perhaps we should discuss with the TC.

mt: Does the app need to offer some UI? Or is it enough to export the
displayed data to a table.

pk: Think the export would suffice. Probably not a new ui, just pushing
sufficient data, perhaps to a spread sheet.

mt: That might be a generically useful feature for anyone.

js: Always a good yardstick if it's generally useful.

mt: Also more likely we get it soon if it's generally usefuly.

    * Malte: Provide input on radio button groups

mt: Just sent email. Think we confused labeling and grouping. You can already
group with form name, no frame needed. One frame can contain multiple groups.
I think we've got what we need.

pb: How does the name work?

mt: Actual label, not text.

pb: AT user will want to hear label.

mt: So frame label can be different, and you could have three groups inside
the frame.

pk: We inherit this from Xforms?

mt: Don't think so. Maybe from html.

pb: I have iinput from the Symphony team on this, but must defer to Malte.

pk: So we have everything we need?

mt: Yes.

pk: So how is it exposed to the AT?

mt: A11y api should give labeledby, not sure if at will use name or check with
multiple are labeled by the same.

pk: So, we may have a question of Symphony to understand how this is handled
for IA2, JFW, etc.

pb: I believe there was some bug and you couldn't properly implement.

pb: Is there a way to look at this in OpenOffice?

mt: From the api point of view, not sure what at is doing --- looking at the
frame?

pb: Does Orca?

pk: Should, but don't know.

pk: Will check with Orca.

What are the best practices for creating button groups?  There are two 
tags providing labeling: 1)form:frame and 2) form:fixed-text.  In the 
latter case, i.e. static text is labeling a group of buttons (rather 
than the buttons being groups in a form:frame, would you be able to 
implement an accessible hierarchy (including the proper relations) for a 
button group?

obe

5. Action item from prior meeting

    * Pete: Ask Symphony team about best practices for radio button 
groups (see last action item above)

    * Janina to modify accessibility guidelines to state how common 
field attributes (section 6.7 of the ODF 1.2 spec.) should be supplied 
to the AT. The field attributes would indicate whether something were a 
Boolean, Gregorian date, etc.

obe

    * Janina to clarify text in section 3.4

js will resend to pk. js still not able to send to the list.

    * Peter to add a new section with guidelines as to how to provide 
tracking information to ATs.
    * Peter to modify guidelines to ensure applications respond to 
system font and color settings.
    * Peter will add explanation that this ODF 1.1 OLE embedding for 
presentation tables is no longer supported and that native ODF tables 
are used in 1.2

Above three pk items complete.

    * Steve Noble to look at formulas specification identify data that 
would update frequently, such as volatile formula information that would 
require the Office application to inform the AT of updates sections. 
Will complete by next meeting.

We believe Steve has moved on. So, the question is what to do with this item.
Rich and Peter will consider.

    * Rich to provide base document for ODF 1.2 change specification 
(starting with caption-id reference) to Mike Paciello. Mike is to own 
the requirements document for ODF 1.2 which will be submitted to the ODF 
TC. Rich is waiting on a decision as to where the ODF schema is to 
reside (separate or within the base document).

rs has had to leave the mtg, so we'll expect advisory in e-mail.

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina@a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]