Edinburgh face to face, May 20 21 2006. Second draft minutes

["Dave Pawson" <dave.pawson@gmail.com>]

Attached, two files html format.

Unless anyone has comments please
take these as the meeting minutes.

I'll ask Nathan to foward to the TC if there are no comments
within a couple of days when people have arrived home.


Thanks to those who attended.
I think RNIB was a good host.

I enjoyed the meeting and believe we
did a good piece of work.

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Title: F2F Day 1

F2F Day 1

Date: 2006-05-20T09:25:17Z
Time:
Venue: RNIB Edinburgh
Date: 2006-05-20T15:21:31Z

Version: 1 Date: 2006-05-22T10:50:13Z

Version: 1

Attendees

• Dave Pawson
• Peter Korn
• Janina Sajka
• Malte Timmerman
• Rich Schwerdtfeger
• Hironobu Takagawi
• Chieko Asakawa

Scribe(s): Dave Pawson

Agenda

Item. Table in presentation proposal

Item. What is left for DAISY support?

Item. Gap analysis - Chieko

1  Table in presentational proposal

DISCUSSION: PK. Email yesterday - from Florian.

• RS. Table draft 1 and 2 from Florian.
• MT. element in a frame or element inside group object should be considered.
• PK. 1. MS office and Powerpoint can create tables. Import needs to provide access. None of todays products generate tables naturally. 2. We want to be able to create tables in ODF applications properly marked up. Star office wants these to be live tables (e.g. connect to databases). They don't think they can fix number 2 in ODF 1.1 timeframe. Hence Florian proposal is based around number 1. This is backwards compatible with ODF 1.0 readers. By making an OLE embedded link, we preserve the data format which is easy to read for most applications. Then for 1.2 we solve the table problem in a more general way, i.e. make them a full suite of elements. Look at suggested XML to see how hard it is.
• RS. Looking at first document. 9.3 in florians document. This is the XML specification, only adds a new reference name table-table.
• PK. Example 3 col 4 row table. Table read off by row.
• RS. This converts to table format, not ole embedded.
• MT. This is what we would like, but I don't see backwards compatibility.
• RS. Could be that for 1.0 readers, have embedded OLE, for newer readers, has the actual table.
• PK. No comparison - pros and cons of the two proposals.
• MT. Proposal to have it in a frame or in a draw:group. Better in frame than group. Replacement can only be OLE. Draw:frame cannot have draw:group as a child. This is a 1.2 proposal
• RS. Consider a slide with a table. Embed an OLE object that renders the table. The AT has to go to a different API to get to it.
• MT. They have this already (access to embedded OLE objects)
• RS. Have a embedded calc spreadsheet.
• MT. Prefer 1 from Accessibility viewpoint. Not mandatory to create the parallel object element, only recommended for backwards compatibility. Hiearchy is frame, table and object as children.
• DP. Summary. Spreading discussions to the Mass case, how AT accesses headers in a table in a presentation. This can be separated from the selection of the proposals 1 and 2.
• RS. Group has accepted that Florians proposal 1, embed a calc table inside a presentation frame is preferred over proposal 2 (using group instead of frame).
• RS. AT cannot get at useful, local headers provided by the author. This is an agenda item for tomorrow.
• CA. With this proposal we are compatible with MS. We could consider joining the metadata sub committee.
• RS. Found a problem with way we deal with tables in writer. When we want a header in a table, I get a row header element, others I just use style to make it look right, but lose the semantics. This is Pete Bournets issue.
• PK. Would like to defer this to day 2. Under directions for authors and implementors.
• RS. Examples on screen. Shows that spec is presentation oriented. Spec allows no headers. So ODF doesn't tag it as a header unless needed for presentation.

Action item: Propose wording change for 8.2.4, to add use case for accessibility. Note: RS has edited version of spec. Will post to the list ASAP

Who? RS

Due date: By Sunday night (PK)

2  Daisy

DISCUSSION: bg. DaveP. Described different types of DAISY book. Explained Daisy versions.

• PK. Need a down conversion to 2.02 for common
• MT. Pagenumbers are layout based. Can cause problems.
• DP. Need both soft and hard page breaks.
• PK. We provide list of requirements and annotation, suggested draft markup for each.
• DP. Suggest pagebreak, attribute soft or hard.
• MT. We have hard page break, just need soft.
• RS. Requirement. Add soft break to spec. Also need UAs to deal with the soft page break. Do same page layout for different appliation.
• PK. When to change page layout. At save time, dialogue could ask if we should renumber. Could be an issue when talking about page x, when read on different systems, this could be different.

3  Keyboard issues

DISCUSSION: Slides presentation - Hiro. Issue. Specification doesn't define any Z index usage.

• HT. Need to bring from specification into implementations. CSS usage of Z index is negative, ODF has non- negative values. We need to define in detail the Z index.
• PK. Specification, page 283. Could be a copy/paste error. Does not make sense. Could mean 'should use svg:z index'.
• MT. Z index is never used. Content order can only be changed by changing the z order
• PK. No reason for user to care about document order and its relationship to Z order. Except for 'additional meaning'.
• MT. Z order is presentational, not tab order.
• MT. In Star office, changing Z index affects tab order.
• RS. Must provide a means of specifying a 'thoughtful order', which should take precedence over default tab order. The author specifies the order in which objects gain focus (possibly using id value). Order must be editable. Scope within a single slide (or drawing object within spreadsheet sheet). Not for writer drawings. Default setup is document order, changed by the author of the document.
• HT. My proposal did not impact schema etc, this could be for a later specification version.
• PK. Can't do that due to backwards compatibility issues.
• HT. Z order still very unclear. Agreed by all.
• HT. Could use definition of nav-order from CSS3 for semantics and name.
• RS. Should be done on the 'draw:page' element for impress and page anchored objects in calc (table:table) or write (), as a 'nav-order' attribute, with a list of idrefs which can be rearranged by a thoughtful user. ID values cannot be removed (unless the object is removed). All focusable drawing elements must be present within the list.
• PK. For any application, the element has to be on a user conceptual page. For calc this is table:table, for impress it is draw:page, for a drawing, draw:page. For writer, we want it on office:body, i.e. the whole document! This makes sense with the other navigation in a document. The challenge is, I can insert a table and that table could have associated graphics.
• DP. Can we navigate the alternative view (graphical items or objects) in a document just as we do with impress drawing objects. Means all tables should be navigable in the same way (no difference between embedded or natural). Then navigation could recurse as needed.
• PK. Can an author omit an object? Agreed no.
• PK. Default lazy initial tab order is document order. When the nav-order attribute is not present a user agenst should create the tab order in the following manner, based on document order. This is done when an author starts to modify the tab order (and not before). This is done since nav-order is not needed by default. If it is put in too early then there is no way to distinguish navigation order as being purposefully set as apposed to not.
• CA. We have received much feedback that the IE table model is very good for navigation.
• PK. The user needs to discover objects on the page. A key could say 'describe my surroundings'. Informs the user about non text objects. Or she can tab through them. If we want a thoughtful author to specify a navigation order, User Agent could decide it?
• DP. Suggest that navigation order should be at top level only, not including objects at a lower hiearchical level.

Action item: Produce specification change proposal based on these minutes

Who? Group

Due date: By Sunday night if possible

4  Gap analysis

DISCUSSION: Deferred to the morning, though the link issue is now resolved.

Summary of Actions

RS

Action item: Propose wording change for 8.2.4, to add use case for accessibility. Note: RS has edited version of spec. Will post to the list ASAP

Due date: By Sunday night (PK)

Group

Action item: Produce specification change proposal based on these minutes

Due date: By Sunday night if possible

Title: F2F Day 1

F2F Day 1

Date: 2006-05-21T09:10:43Z
Time:
Venue: RNIB Edinburgh
Date: 2006-05-22T11:14:05Z

Version: 1

Attendees

• Dave Pawson
• Peter Korn
• Janina Sajka
• Malte Timmerman
• Rich Schwerdtfeger
• Hironobu Takagawi
• Chieko Asakawa

Scribe(s): Dave Pawson

Agenda

Item. Formulate Final 1.1 Requirements to TC

Item.

Item.

1  Formulate Final 1.1 Requirements to TC

DISCUSSION: Quick review of current 1.1 requirements. Captured as an ODF document by RS. See that document for details.

• Add soft and hard page breaks.
• Correct wording to require table header structural markup (8.2.2)
• Provide for author specified logical navigation.
• Fix incorrect documentation on z-index. (9.2.15). Believed it may be a cut and paste error?

2  Navigation order issue

DISCUSSION: Brought out as full agenda item

• All were in agreement on navigation being for Impress only
• MT. Native tables have their own native table navigation, Calc has its own keyboard navigation with richer functions. A screen reader cannot tell if it's a Calc table or a write table.
• Editing could have additional functions over basic navigation
• HT showed slides of all combinations in tables, different types, with and without jaws access. This was subsequently posted to the mailing list.
• PK. We could provide a general navigation model which is consistant accross applications. We should provide this in addition to legacy keys which are expected (would get complaints if these were lost)
• DP. All were in agreement on principle. We should develop this model. Insufficient time to do a good job at this face to face meeting.
• CA. Would this be for a guidelines document or the ODF specification. We can't get common keystrokes, there will be conflicts with existing keystrokes.
• PK. MT. Should be for implementors. Proposal is a new set of keystrokes in addition to existing ones. Then implement in Firefox, then all ODF applications. Should be for all tabular data. Does this change our decision on hiearchical navigation model? Agreed this is not yet resolved.
• CA. Yes, could be useful if we can find appropriate keystrokes. Could be in UA specification.
• RS has generated the proposal for TC. See separate ODF file.
• calc and write; we do not have an agreed user interface navigation model which is consistant. We need more work on this area. A stumbling block is objects in the graphics layer. Navigation across all levels or hierarchical (e.g. table inside a writer document could be seen as at layer 2)
• Sub group rejected page breaks as mandatory for schema. Re-worded with a pagination caveat. Now accepted by all.

Action item: Put forward a proposed general tabular navigation scheme for spreadsheets, tables in wprd processors, presentations, html and Gtk table, to the WG for comment.

Who? JS. CA

Due date: By 30 June 06

3  Remaining reqirements review.

DISCUSSION: RS confirmed the remaining alt text proposals.

• All in agreement with those presented, they had previously been reviewed by the group.

4  Structured tables in Presentations.

DISCUSSION: RS. Concern over change of user experience, cf Microsoft Office.

• Discussion on Florian Reuters submission. Group supported it.
• RS. Addressed the concern. Checked for groups views. All in agreement.
• RS built up the plans and current proposal. Agreed. See file odf11requirements052106a.odf, titled, ODF Accessibility Requirements, author RS on behalf of the group.
• Re pagebreak addition, DP proposed, Having met these requirements ODF can be used to produce DAISY Digital Audio which is in global use by blind and partially sighted people. Text edited by group and agreed for summary.

5  Hiro, prepared demonstration

DISCUSSION: Ran a demo on Accessibility checker, see www.alphaworks.com, Adesigner is the product.

• DocExplorer. Alternative view of a slide set. Works with Star office, Open office. Could use GtK, currently uses Jaws. Has been tested by CA. Mentioned a future proposal to embed metadata for creation of accessible diagrams. E.g. Visio like diagrams could generate metadata automatically, this type of tool can provide an accessible tool. Example, currently a connector only works on line based not on shape based objects. We have no metadata on custom shapes. For table metadata - who are the stakeholders?
• CA. We think the tree based view is very useful for accessibility.

6  Post 1.1 draft items

DISCUSSION: RS. Categories. Slides or drawings. Types of charts (CA work). Listed for future agenda items.

• Navigation models. In slides, outline view and a slide.
• RS. We need to consider other disabilities. E.g. giving presentations. E.g. Learning difficulties, currently largely ignored.
• PK. Multi-modalities (Referred to DP email to list). Synchronised streams, alternative streams. Better access to charts and graphs.
• Development of a better navigation model for tabular data.
• PK. Improve header associations in tabular data with multiple smaller tables. Also more general relationships, such as speaking formulae, cell labelling by row/column.

Summary of Actions

JS. CA

Action item: Put forward a proposed general tabular navigation scheme for spreadsheets, tables in wprd processors, presentations, html and Gtk table, to the WG for comment.

Due date: By 30 June 06