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: OASIS ODF Accessibility SC meeting minutes, 14Feb08


Greetings,

Attached - somewhat belatedly - are the minutes from our previous meeting, Thursday 14Feb08.  In this meeting we had special guest Marc Mulcahy, who is looking at using ODF as the native file format for documents created/edited by his Braille note taker, the ICON.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


----------- Minutes from the OASIS ODF Accessibility Subcommittee, 14Feb08 -----------


Attendees
----------
Dave Pawson
Marc Mulcahy
Malte Timmermann
Peter Korn
Tatsuya
Janina Sajka
Pete Brunet
Steve Nobel
Rich Schwerdtfeger


Agenda:
--------

1) Approve minutes for last ODF Accessibility SC Meeting - attached
  * So approved.

2) Special guest Marc Mulcahy of LevelStar, whose ICON PDA may be in the future natively support reading/writing ODF and wanted to meet with us about it.
  * Make two PDAs - the ICON and the Braille+ (essentially same underlying hardware)
  * Designed specifically for use by blind folks - one with telephone style keyboard, one with braille kbd
  * Right now they use their own XML-based document format; interest to move to ODF
  * One limitations seen currently is integration of braille directly into a document (they can have a document that includes Braille text & print in the same document)
  * So the broad topic to bring to us is that of adding braille to ODF.  Questions that arise is: what does that mean for a user agent?  how to emboss braille?  how to save as braille, as text, etc.
  * Peter: what does "intermix braille" mean when we have UNICODE Braille tables and the ability to enter UNICODE characters into a document?
  * Dave Pawson: yes - there is a UNICODE code-point range for Braille
  * Marc - a dot pattern is a dot pattern; doesn't mean a whole lot.  Persist as ASCII and then decide how to interpret it.
  * Obviously need to know what Grade it is in, what language, NEMETH, Music braille, etc.
  * Marc - essentially you need to know the "mode" of the content.  Their XML content has text objects, and each text object gets labeled as what kind of text it is (ASCII, computer braille, Grade 2, etc.).
  * Marc: e-mail example; receive an e-mail (whole thing is "plain text"), you write a reply to that which is a new document containing the original reply as quoted.  You want to reply in Grade 2 braille as you are typing.  You don't want to translate into and out of braille.  It must be stored as braille characters, but we need meta-data to let the folks know the user settings used when the braille was being entered (e.g. user is entering text in English and as Grade 2, or French in music braille).
  * Marc: how we do it now: if we have a paragraph containing both text & grade 2 braille, it is stored as several objects that get converted to several text elements, and each has a content type (one is "text-plain", another is "text-braille"; could imagine "text-grade2-braille", "text-music-braille").
  * Peter: this is also remarkably similar to font attributes - a paragraph of text, some of which is in bold, some of which is in italic, some of which is plain
  * Peter: another similarity is to language tagging - where in ODF we note which language a string of characters is in
  * Malte: thinks there are two different things to achieve: Braille some of the normal english text (keep it in sync),
  * Dave: we have the ISO 693-2 set of language tags (see http://en.wikipedia.org/wiki/ISO_639-2) - a set of 3 letter language tags.
  * Marc: what would be the best open source technology to invest in...?  OOo is too heavyweight to run on the Icon
  * Peter: there are several candidates to consider: there is a slimmed down OOo code base (which is underneath the ODF Plug-in to MS-Office); also of course KOffice, and AbiWord (which I believe is embedded into the OLPC which is a rather small device...).


3) Review of action items from last week:

* Hiro to provide more information on agenda item 5 related to table headers (from http://www.oasis-open.org/apps/org/workgroup/office-accessibility/email/archives/200711/msg00007.html)

* Rich to find deadlines for ODF 1.2; also to verify whether TC would like to see our 1.2 guidelines doc delivered at same time (in same "bundle") as 1.2 spec.
  -> [While we didn't get a report from Rich, recent e-mail from Robert Weir (see http://lists.oasis-open.org/archives/office/200802/msg00025.html) outline the "rough road map" for ODF 1.2:
 
  • ODF 1.2 technical drafting complete May 2008
  • ODF 1.2 public review June-July 2008
  • ODF 1.2 approved as OASIS Standard - Sept 2008
  • ODF 1.2 approved as an ISO standard - Summer 2009

So certainly no later than May we should be finished with our accessibility review of ODF 1.2.


* Hiro - Write proposed modification to 8.1.1 to add caption-id for table, and 9.2.15.2 to include tables - <ref name="common-draw-caption-id-attlist"/>

* Janina to check with Dave Pawson on status of ODF to DAISY work he was involved in
  -> Dave Pawson to speak to this himself: will be employed on March 17th (in the furniture trade!).  Dave has done "next to nothing" in this space.  Concern is that he had a working system on OOo and it was based (because of DAISY constraints) on getting the structure based on the headings.  His code required that headings be decreasing (H1 must be first, and H1 could only be followed by H1 or H2; H2 could only be followed by H1, H2, or H3).  Obtained that structure from an additional file.  Came back in an OOo update, and that information was no longer available.  Was Dave relying on optional attributes that are no longer there, or did OOo break the spec.? 
  -> The request to the main TC: please ensure that this heading information is available & stable & in a relatively-easy to discern way

* Pete Brunet: Provide guidelines as to how to supply tracking change information to ATs.
  -> Malte & Pete & others have been looking at how to expose document revision information in platform a11y APIs, so they can be exposed via IAcc2 and ATK/AT-SPI.  Are converging on a specification.  But then is the question


Action items
-------------
 * [unassigned] How does ODF do language tagging of a range of text?  Font attributes?  And how best to tag a string as "Grade 2 English Braille", vs. "music Braille in German". 
 * [unassigned] Can OOo be a good codebase for Marc to start from for the Icon (which is ARM based)
 * [unassigned] Determine what the stable means is for persisting heading information in ODF (same issue as export to HTML where we persist headings as <H1>, <H2>, etc.)
 * PeteB to set up a meeting at CSUN around the revision API (already looking to set up an IAcc2 meeting & an OpenA11y meeting at CSUN)
 * Janina's action on "3.13.2" of the document - text about flashing of the screen for folks with seizures should really be new text in section 2.


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