Re: Minutes. Telcon 060330. First draft

Agenda

Item. Roll Call

Item. Approval of Minutes of Previous (3/9) Meeting

Item. Old business:

Item. -- CSUN meeting report(s)

Item. -- Table/SVG in presentation, status report (Nathaniel) -- Need formal approval of Rich's requirements

Item. -- Alt texts, short/long/caption

Item. -- Presentation Issues

Item. - Improved keyboard navigation (nextFocus, Z-Order)

Item. - Relationships with TC

Item. New business: -- Relationship with and reports to parent TC (Nathaniel) -- Soft/hard page break issue from Dave P -- Nested list markup issue from Dave P

Item. Deferred for post-June (keeping on agenda as placeholder): -- Mediaobject proposal from Dave P

Item. Agenda/Topics for Next Meeting

1 Roll Call. Approval of previous minutes.

DISCUSSION: PK's blog has some detail and links to podcasts from CSUN. link

JB. Apologies for recent absence.
NB. Approval of last meetings minutes. Accepted.

2 CSUN meeting report(s)

DISCUSSION: RS presented outline

Panel went well, People are coming round to the fact that it's a good idea. Some concern with the interaction with AT vendors. No AT vendor support currently available.
Had private sessions. Curtis Chong, President of the National Federation of the Blind, was supportive. Believe that open standards and open source can advance the industry.
Good questions presented to the panel. Went well
PK. Myra Berloff - Director of the Massachusetts Office on Disability, her comments were appreciated. Industry is waking up to accessibility much faster this time. Now moving rapidly, supported by a positive management stance. Now have commercial and OS applications that interact and work well together. We want commercial and OS applications to work together with ODF.
An ACB radio podcast, roundup with comments on ODF. I heard Accessibility is not all the way there yet, but lots of people are working on it, watch this space. The message is getting out.
JS. Confidence is coming from the progress on making it work with AT. Makes it more familiar with such as Jaws users.
PK. AT vendors have been impacted by ODF uptake across the world. Now a question of fit with development schedules and budgets. No unfriendly responses. We showed that much of it is working.
JS. Many more are supportive of OS in general. I was encouraged on open standards. It's firefox that is making the biggest mark.
PK. No one is suggesting that Mass change AT; the maturity of demonstrations is helping address concerns that OS AT will become viable on OS Operating systems.
JB. I've had no feedback from Myra Berloff as yet.
PK. We're not done yet, there is more to come on AT.
JS. Important that we had slides up of places adopting ODF. Underlying message is that it must be accessible. The message is getting out.
PK. Many of the places adopting ODF are becoming aware of accessibility and asking for it. The ODF alliance is raising this as a topic of interest.
Also had a good ODF accessibility meeting on Friday.

3 Table/SVG in presentation, status report (Nathaniel). We need formal approval of Rich's requirements

DISCUSSION: NB. We've done all we have to. Now want a formal approval. Any further comments?

PK. Looks good.
NB. Consensus, no objections. Approved.
PK. Propose make new markup (as per writer) for presentations.
NB. Will circulate comments from TC.

Action item: Circulate comments from TC

Who? NB

Due date: When available

4 Alt texts, short and long captions

DISCUSSION: RS. Discussed at CSUN

RS. Do we need grouping? Do we need longdesc and title. On drawings, do we need title and caption?
PK. Summary. We need both short and long descriptions - agreed. We have svg:desc and svg:name. All svg items have a name, but its not very useful. Do we need longdesc on all individual lines? Groups are more useful. Probably not on individual lines. Could be named, but generally not useful. Do we need to add it (for groups)? Do we use svg:desc to be used as longdesc. Do we use name field for other reasons? Should we introduct a new short name, e.g. svg:title.
Post meeting addition from PK. see later
JS. We actioned Malte to establish the purpose of name elsewhere in ODF.
PK. Other thought was that the GUI was available to enumerate the elements in a drawing which picks up the name. Could we automatically name them xxx1..7? We were close to agreement, RS held out with some concerns.
RS. Does name already have a usage?
MT. May also be used for macros.
PK. If name att is for drawing objects, we could introduce svg:title as an attribute as alphanumeric string, blank by default, which takes user value from name and maps to MSAA name or Unix ATK name, then introduce svg:desc mapped to longdesc.
DP. Concerned that name strings may not match those used for ID in the exported XML. I think this is bad overloading
PK. svg has both title and desc.
RS. Propose. If caption, no need for title.
PK. Is caption mapped to tooltip? No. It is prose under the graphic. It's bound to the object using an idref. Hence we need a relation 'described by'. We still have desc and title. Direction to author is that you only need it if you haven't entered a name. Short desc mapped from desc. (FIXME. Is this last sentance true??)
RS. We will define a relationship in the markup. Text sequence is used to describe the object. We need to say on grouped object that the 'described by' property is related. AT API will set the link from the name to the item described. Applications can follows the reference.
PK. Issue. We (in Sun) have left the mapping to AT to follow relationships and to decide how to present it to the user. We have both name and a 'labelled by' field. We don't expect UA to know the right thing to do. AT is in a better position to describe it.
DP. Issue of duplicate ID values. This is a UA discussion. How to get it to them?
PK. Develop a list of user agent recommendations. Prompts etc. This could go to ODF adoption committee.
NB. That group met last week.
RS. If we have a caption, shouldn't need a title.
NB. We need a clear written description of all this.
PK. Need to confirm that name is used elsewhere. If we can use it, we don't need to introduce title.
DP. Is name content matched to ID syntax? Needs clarification prior to accepting the use of name for this. W3C shows the BNF.
PK. If names being used as ID's could cause conflict. If we assume that is correct. We can either use id and name for users, we need to introduce shortname. Will write this up.
RS. Used to tie text object to drawing.
NB. Can we move on? Next time we will have a

Action item: Start to develop a list of user agent recommendations. Prompts etc. This could go to ODF adoption committee.

Who? NB (no one offered).

Due date: 2 weeks.

Action item: Draw up document with proposal on alt text for comment.

Who? PK.

Due date: by next meeting.

DISCUSSION: Post meeting input from PK. Summary of alt text discussions on drawing objects to date.

DISCUSSION: Requirements:

Every drawing object should have a short name, persisted in XML, that can be presented to users. This short 'name field' should only be filled out by authors (and not automatically filled in, e.g. "line 1", "line 2").
Every "meaningful" drawing object should have a 'description field', persisted in XML, that can be presented to users.
Authors should be able to link text captions with the graphic object(s) they are associated with (e.g. the text "Tiger from the Amazon River Basin" that might be sitting underneath an image of a tiger).

DISCUSSION: Questions we need to resolve:

How is the existing 'name attribute' in ODF drawing elements used in ODF, ODF apps? Is it used by macros, etc., such that we can't have it be null by default, and only have contents when explicitly assigned by users?
Do we need a 'description field' on every drawing primitive (e.g. line, rectangle, oval) that makes up a more complex drawing (e.g. a tiger's paw, or the entire tiger), or just on groups of drawing primitives?
If we have a text caption, should it automatically be used as either the 'name field' or 'description field' as persisted in the XML ODF file, or should the job of presenting that caption be left to the policy of the assistive technology?

DISCUSSION: Group proposal (and the assumed answers to the unresolved questions this proposal is assuming):

[assuming the existing 'name attribute' in ODF *is* used and needed for other things] we introduce svg:title on *all* drawing objects and drawing groups, and map that to ATK_NAME and MSAA short name. [assuming the existing 'name attribute' is *not* used for anything else] that we re-purpose 'name', advise ODF apps to leave it blank by default, and map that to ATK_NAME and MSAA short name. [A third alternative: instead of introducing svg:title, we re-purpose 'name', and then have ODF apps use the default XML 'id' attribute for referencing drawing objects and groupings]
we introduce svg:desc, and [assuming that we agree we don't need it on primitives] define it as applying to drawing groups only
we introduce a "described by" relation in the XML markup, which links caption text objects to the drawing group that they caption (do we allow captions also on drawing primitives?)

DISCUSSION: Peter's opinion/suggestion:

Go with the third alternative: re-purpose 'name' for a user 'name field', and have ODF apps use the XML 'id' attribute for references. We'd use this for the "described by" relation anyway. Visual user presentation of un-named objects would programatically generate a user-presentation of an unnamed drawing object by concatenating the object type with the id (e.g. "line 3").
Put svg:desc only on groupings, not on individual drawing primitives
Allow the AT to decide how to present "described by" relations/captions; don't formally replace the XML 'name field' or 'svg:desc' field with their contents.

5 Presentation Issues

DISCUSSION: NB. Is ten minutes too short for this? Yes.

RS. Want to clear up alt text first.

6 Improved keyboard navigation (nextFocus, Z-Order)

DISCUSSION: Deferred

7 Relationships with TC.

DISCUSSION: TC wants more visibility of what we're doing.

NB. Will send mins to TC. Also want each new item as developed.
RS. Do you want schema change.... or FIXME? Who will produce new document. (Resolved MP, support from DP)
NB. Not necessary. A requirement may be enough, perhaps with suggestions for a schema change.
MP. I have an archive of emails. Will draw together the list of changes discussed.

Action item: Develop an explicit list of what needs documenting. Will use RS format.

Who? MP.

Due date: By Monday next week.

8 PK.

DISCUSSION: PK. Can visitors get into first ISO the errata options.

NB. We can't, but it doesn't matter. ISO voting is complex, but outcome if 1.0 comes out, and we have accy in Oasis updates, we should be OK.
RS. Wanted to ensure group is on same page on this. The submission has gone in, balloting is in progress. First standard based on Oasis ODF 1.0, expectation is that ISO will follow in due course (could be quick and easy). Implies that users should be comfortable following Oasis. NB agreed with this assessment. ISO ratification currently looking good. Even Microsoft have supported. Japan voted yes with comments.
PK. I'd like TC to come back with revised schema showing changes. OK if we have seperate sessions on presentation? E.g. focus, relationships to raise the bar.
DP. Anyone have current full schema? Seems not.

Action item: Set up telcon after note to committee to discuss presentation issues.

Who? RS.

Due date: By next week.

office-accessibility message

OASIS ODF Accessibility SC Meeting

Attendees

Apologies