To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=88070
------- Additional comments from joaniedi...@openoffice.org Sat Dec 12 21:55:45
+0000 2009 -------
joaniediggs->OD:
- I am right that the ATKObject with role ATK_ROLE_SCROLL_PANE in the proposed
hierarchy is the representative of the comment?
Yes.
- To distinguish a comment scroll pane from other scroll panes you are proposing
a new attribute. You are also suggesting to have a certain attribute to identify
the role of the comment's children. Are you thinking of a new general type
attribute? Something like ATKAttribute{ "type", "comment"|"comment
content"|"comment author"|"comment date"|"comment actions" }?
Something along those lines, yes. I don't have a specific set of attribute names
and values in mind; I would just like a reliable way to identify these objects.
- A relation between the comments should be implemented if such a relation is
also exposed in the user interface. In my opinion the ATs should not 'see' more
than the normal user.
Fine with me.
- For a comment which annotates a certain text range of the document content
also the end position is available. Currently, it is not yet been decided, if it
will be present as a character in the text string. I propose that the
accessibility object which represents such a comment is related with the
paragraph which contains the start of the annotated text range.
Makes sense.
-(con't) May be a new attribute at the comment representing accessibility object
is needed which contains the end position.
Perhaps. Although I think this will be tricky. Each paragraph is exposed to us
as a separate AtkObject. So the end position is not merely an offset; it's an
offset in an accessible object, which may or may not be the same object as the
one in which the annotation started. I have no idea what the right thing to do
is. Merely pointing out a potential issue.
-(con't) We have also not decided yet how the annotated text range is presented
in the user interface - may be something like a selection is presented in the
user interface.
I'm not sure. Perhaps Will could chime in on this (and, for that matter, the
other issues).
- What about the comments which are not visible in the user interface, because
-- all comments are hidden by triggering the corresponding user action (Menu
View - Comments) OR
-- there are too much comments for the text on a page?
I propose that these comments are also not visible for the ATs. Ok?
Maybe. :-) Is it possible for the user to arrow to a block of text which has an
associated comment, but that comment is not visible on the screen? If so, then
not exposing that comment to ATs will be problematic. If, on the other hand,
moving to a block of text which has an associated comment necessarily causes
that comment to be visible on the screen (and thus visible to ATs), I have no
objections to what you propose.
- What about the buttons to bring certain comments into view when too much
comments are present?
They should be exposed as push buttons. Although this raises an issue I'd not
really given much thought to -- and don't know what the answer is:
My proposal is very much based on users who are blind. The user would presumably
be reading the text by arrowing through it. When there is an comment present,
the screen reader should at the very least be able to:
1. announce the presence of the comment
2. provide an easy way to access the comment's contents
3. provide an easy way to return to the text being read
Exposing a comment as a child of the text to which it applies makes it easy for
the screen reader to do the above. And is consistent with the flow of the
content. The fact that all of the comments exist off to the right of the
document and that there are buttons which can be used to scroll comments
into/out of view is, I believe, largely irrelevant to the user who is blind. But
it might be very relevant to the user who is sighted but requires an alternative
input device. It would be good if someone more familiar with that area could
chime in as that is not my background.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org
For additional commands, e-mail: issues-h...@sw.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
