Minutes Office Accessibility SubCommittee Teleconference January 26, 2009 Submitted by Janina Sajka

Attending: Hironobu Takagi HT Tatsuya Ishihara TI Janina Sajka JS Peter Korn PK Malte Timmermann MT

NEW ACTIONS SUMMARY:

ACTION: HT to review bookmark spec to see whether it confirms MT and PK's contention that it can meet our accessibility requirement.

NOTE: All former action items are now closed.

--------------------------------------------------------------------------

NEXT MEETING: February 9

--------------------------------------------------------------------------

1. Approval of two sets of minutes: * January 5th meeting minutes http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200901/msg00005.html * January 11th meeting minutes http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200901/msg00006.html Approved

2. Radio button groups in ODF -> can we come to a final decision? Key items to note for this: 1. Rich's proposal <http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200811/msg00017.html> (see http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/20081/msg00017.html) -> essentially the attribute form:name is being overloaded, and he suggests we introduce an element specifically for the grouping, borrowing from the XForms group element xforms:group 2. Malte has expressed concerns about backward compatibility 3. Peter created a document (see attached) with a group control. Absent in Rich's example is the fact that there is a form:frame element that seems to do the same thing as <form:frame form:name="GroupBox"... form:for="control5,control6"/> element which has it's own label and handles the group. Is this not sufficient?

PK: Does this address our need?

MT: Rich view is not for a list of ids, but a group name.

PK: Did not see the form frame element.

MT: Also discussed with Michael Brower, who's not sure about making changes at this time.

PK: I don't see why it's necessary. It's the responsibility of the authoring tool to generate all the necessary information, and there's sufficient specificity to do that.

PK: So, we'll defer until all the principals can be part of the conversation: Rich, Peter, Malte. We confirm that Peter and Malte are available on 9 February.

3. Intra-document links -> do we have a conclusion from Hiro & Svante?

HT: Intradoc linking critical, especially for screen reader user. TOC to inner document section is the most obvious example.

TI: We decided to support the TC proposal, which is not yet integrated into the spec.

TI: His proposal is sufficient for us. However, his proposal isn't yet completed. http://wiki.oasis-open.org/office/Change_Proposal_for_ODF_1.2_using_URL_fragment_identifiers_for_ODF_media_types

ACTION: PK and RS to work with TC to implement URL fragment. SCRIBE'S NOTE: Following discussion indicates that we did not, in fact, reach
agreement for the above action.

MT: Actually, existing mechanisms are sufficient for this: http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200901/msg00018.html

HT: Thought we discussed this in previous call--am I wrong?

MT: Text marker example is the best example in this document. It supports jumping from anywhere to anywhere.

PK: We just call these bookmarks ...

PK: Typical algorithm would be looking at link target.

MT: Yes and no. It's hard to figure out the target for auto generated links. But that's an implementation issue.

PK: So the fix we need is in apps, not in the spec.

MT: Yes

MT: The logic of it needs to be defined in the spec. We simply need to document how the current hyperlinks work.

PK: Hiro, have you reviewed this?

HT: Have you modified this?

MT: Only for manipulated text3. The other you can do with OpenOffice. Once you insert bookmark in OO, you can use it as a target.

JS: Seems we want automatic targets for TOC automatically.

PK: It does.

MT: But not auto gen'd bookmarks that depend on the pipe symbol ...

HT: One of my points is interoperability among applications that implement ODF. So, we would need to define how this is handled in the spec.

PK; But it appears there is consistent markup.

HT: Not well defined in the spec. I believe xml fragment would be a more consistent approach, but I will consider alternative approaches. So, in this case something like: "name of bookmark" for url fragment.

MT: It has many use cases. My only point is we have enough now for a11y. It's up to the interoperability committee to decide next steps.

PK: Is there a bug registered for start and end of bookmarks?

MT: No

PK: Do you agree that's the issue?

MT: No

PK: Looking at the xml for <h1>test and <h1>test2, there is no target. Is there no t the reason to have this target bookmark?

MT: From interop perspective, I agree.

PK: Which is why I think it's a bug against OpenOffice.

MT: Yes

HT: I also have a concern about consistency. I believe I checked bookmarks before following only the spec definition--so maybe I should check it again.

PK: One possibility is consistent start/end bookark; another is Sante's proposal; or some other. But all apps should use the same mechanism.

MT: Agree.

the issue is that OOo is failing to insert a <text:bookmark> element surrounding the string "H1 Test"

<korn> Janina: here is a suggestion for the minutes as our conclusion: "the issue is that OOo does NOT create targets (using the existing <text:bookmark-start><text:bookmark-end> element mechanism) for Headers for generated TOCs.A This is a BUG in OOo.A However, Malte suggests that we don't seek to fix this bug until the question of use of fragment identifiers (e.g. Svante's proposal) is settled."

ACTION: Hiro to review bookmark spec to see whether it confirms MT and PK's contention that it can meet our accessibility requirement.

PK: Votes requested for people not on the call whether aware of

All old actions now closed.

feb 9 next meeting.

MEETING ENDS

---------------------------------------------------------------------------

4. Actions remaining for the guidelines document -> Pete Brunet posted an updated edition at: http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200901/msg00013.html -> other than fixing the table of contents, and following the latest rules for the front page, anything else remain to be done? 5. Prior action items: * Hiro contact Svante Schubert regarding merging his xml:id proposal for local links into Svante's link proposal * Rich Provide a section on PDF conversion related to supporting repeating table headers in PDF * Peter Korn and Pete Brunet to specify the text of how table row and column information are mapped in ATK and IA2 Pete's response: http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200811/msg00020.html

Regards,

Peter Korn Accessibility Architect & Principal Engineer, Sun Microsystems, Inc.

--

Janina Sajka, Phone: +1.202.595.7777; sip:jan...@CapitalAccessibility.Com 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 jan...@a11y.org Linux Foundation http://a11y.org