OASIS ODF Accessibility SC Meeting
Attendees
- Dave Pawson
- Nathaniel Borenstein
- Peter Korn
- Mike Paciello
- Steve Noble
- Janina Sajka
- Pete Bournet
- Rich Schwerdtfeger
- Malte Timmerman
- Jerry Berrier
Apologies
- David Clark
- Hironobu Takagi
- Chieko Asakawa
- Tatsuya Ishihara
Scribe(s): Dave Pawson
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.
Summary of Actions
- NB
-
Action item: Circulate comments from TC
Due date: When available
- NB (no one offered).
-
Action item: Start to develop a list of user agent
recommendations. Prompts etc. This could go to ODF adoption
committee.
Due date: 2
weeks.
- PK.
-
Action item: Draw up document with proposal on alt text for comment.
Due date: by next meeting.
- MP.
-
Action item: Develop an explicit list of what needs documenting. Will
use RS format.
Due date: By Monday next week.
- RS.
-
Action item: Set up telcon after note to committee to discuss presentation issues.
Due date: By next week.
|