OASIS ODF Accessibility SC Meeting
Attendees
- Dave Pawson
- Nathaniel Borenstein
- Steve Noble
- David Clark
- Hironobu Takagi
- Chieko Asakawa
- Tatsuya Ishihara
- Janina Sajka
- Pete Bournet
- Peter Korn
- Rich Schwerdtfeger
- Malte Timmerman
Apologies
- Mike Paciello
- Jerry Berrier
Scribe(s): Dave Pawson
Agenda
Item. Roll Call
Item. Approval of Minutes of Previous Meeting
Item.
Item.
1 Roll Call. Approval of previous minutes.
DISCUSSION: RS: Previous Minutes accepted.
2 RS proposal
DISCUSSION: RS: NB put proposal to Working Group. After feedback
resubmitted updated proposal. Now tailored to their
requirements, using svg:title and svg:desc. See list submission
for details. It's the same list of elements as before, added
comments re transcoding from Microsoft Office. Added a piece
about navigation tools to section 4. Added
draw:describedBy. Added CA proposed hint text for links, section
6, new attribute svg:title attribute as hint text. When
exporting to html, this could be re-used.
- PB. Noted minor typo, just before navigator picture. RS
corrected.
- ?? Met with ODF chair, mentioned a change from ISO work,
changing URI to IRI. We may want to adopt that or account for
it in section 6. Issue is that URI charset scope which does
not deal with some aspects of Japanese Language.
- DC corrected link proposal based on HTML
background. Switch from alt to title attribute. RS
noted.
- CA. Check if tab index can be used for tab
order. Current proposal could be confusing?
- DC. Should also address section 6 title?
- PK, RS suggested not necessary, proposed " 5.0
Establish text hints for hypertext links The <svg:title>
element must be provided as an optional attribute to
<text:a> <svg:title> is used as a short accessible
description for hint text. When transcoding from another
document format to ODF the alt text shall be mapped to the
<svg:title> element. When exporting ODF documents to HTML,
the contents of title text should be mapped to title attribute
text in HTML. As a minimum, authoring tools should provide a
mechanism to provide the hint text. When moving the mouse over
they hypertext, the hint text should be displayed
- PK. Concern that this is mouse based. Hint text must be
programmatically available to AT. Based on mouse over is not
accessible. Should we address UI?
- RS to amend wording appropriately.
Action item: Amend proposal to move away from mouse specific. Perhaps
with example using mouse.
Who? RS
Due date: Next
week.
Action item: Put forward proposal as suggested on telcon.
Who? HT
Due date: Next week.
3 Next face to face.
DISCUSSION: NB. Attendees
- RS PK JS MT CA HT
- Would appreciate phone access, try for Internet
access, need wheelchair access.
- NB. Teleconference not very successful over two
days. Could try end of day phonecall. Agreed
4 Status of tables in presentations - Role attribute
required (custom shapes, etc.)?
DISCUSSION: RS. Group still working on tables. Could use table API in
preference to draw elements or implement a new table interface
in presentations, or embed a spreadsheet object. Michael
preferred latter option.
- RS. There are issues over how it's exposed. Now too
lightweight. We lose the table on import. Calculations use
pushes us towards a spreadsheet.
- PK. Concerned that with Microsoft formatted content,
they don't have calculations.
- RS. Pouring content into a spreadsheet is easy. Also
gives us the flexibility. Export just pulls values. From ODF
viewpoint, so long as you can follow link to content, should
work.
- PK. Is it reference to a separate external document?
- RS. Don't know.
- RS. We need this for June, also need it implemented for
December, so ease of implementation is also a question. Talked
of moving away from frame towards direct access.
- PK. Would like a proposal that we could review at Face
to Face.
- RS to report back to group after todays meeting
5 Role attribute required (custom shapes, etc.)?
DISCUSSION: Custom shape can have styling to create any shape. How to
describe it. Could use a properties attribute. Need a means of
entering data.
- RS. Favour generic role for custom shape. Then leave
it to description.
- NB. Support lesser complexity.
- PK. Have all these shapes, we are to provide a title
and desc for each of those.
- DC. What is the purpose of the shapes.
- RS. General drawing problem is graphic user of
toolsuite, i.e. creating simple shapes. If in a tool such as
Illustrator, then rectangles could be piece of larger
item. With this range of use, labelling them might make sense
in presentation application, but less in Illustrator. Cautious
of a very rich description in office suite, we should look
towards convergence with other applications.
- ?? Should we use object properties, could a draw style
property be used?
- ?? The use cases for interaction is large. We maybe
shouldn't try to solve it in a short time frame.
- DC. but arent drawings THEMSELVES alternative
representations of other content?
- PK. Will talk to Freedom Scientific.
- DP. Label individuals
and groups as a basis for future?
- PK. RS suggestion for role opens up overloading
issue.
- JS. Don't impose a role now. Pieces could be assigned a
value.
- PK. Just don't provide a role, yet.
- ?? Should we say what the role is? Allow role
attribute
- PK. Application needs to know what an item is, we ask
how to expose that to AT. Bring it up with RS at other times
with JS group, FSGA WG. http://www.a11y.org
6 Future business
DISCUSSION: RS. Can have nested lists,
but tool bug is currently preventing it? Suggest remove from
agenda.
Action item: Describe soft page break issue
Who? DP
Due date: Next week.
Summary of Actions
- RS
-
Action item: Amend proposal to move away from mouse specific. Perhaps
with example using mouse.
Due date: Next
week.
- HT
-
Action item: Put forward proposal as suggested on telcon.
Due date: Next week.
- DP
-
Action item: Describe soft page break issue
Due date: Next week.
|
Date: 2006-04-27T16:01:16.0Z
Time: 1600Z
Venue: Telcon
Date: 2006-04-27T16:01:36.0Z
Version: 1