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 williewal...@openoffice.org Thu Dec 17 18:47:13 +0000 2009 ------- There is a lot to process in this thread with a number of very long replies to read. I apologize for adding to the length. :-( @ww->od: "I am proposing to use the accessible description to identify the different elements - it's easy to implement and no new attributes are needed." The accessible description is for human consumption and is not really meant to provide any meaning or direction for assistive technologies -- it's just a string to pass on to users. In looking at what you are proposing to expose to the AT, most of the content is probably just inferable to a user, just as a sighted user can infer the content type. That is, a date looks like a date, a name looks like name, etc. For the button that opens a menu of further actions, giving it an accessible name of something like "Actions" and an accessible description of "Activate this button to open a list of actions to perform on this comment" might be enough for the user to infer its purpose. The accessible description should also appear as a tooltip that is available when hovering over the button and/or when one presses Ctrl+F1 when the button has keyboard focus. What would be very nice is for the user to know that the entire container is a comment. ARIA has the notion of a "note" role: http://www.w3.org/TR/wai-aria/roles#role_definitions. I believe you can expose this via the "xml-roles" attribute of the container for the object. See https://developer.mozilla.org/ARIA_User_Agent_Implementors_Guide. Popping up a level, the other big questions seem to be: 1) Representing the hierarchy 2) Identifying the range(s) of text being commented on 3) Handling visibility of comments 4) Providing keyboard-only access to comments - navigating to them, editing them, copying them, creating new ones, etc. Representing the hierarchy -------------------------- The current proposal is to embed an EOC character in the paragraph and then make the container for the comment object be a child of the paragraph. The position of the EOC character represents the start of the range(s) of text being commented on, and the container hierarchy basically maps to the building blocks for the comment. This seems fine to me. Identifying the range(s) of text being commented on --------------------------------------------------- This is where things get a little messy. In all the examples I've seen so far, comments seem to be anchored to a single point in the text. But, http://lists.oasis-open.org/archives/office/200708/msg00007.html indicates some sort of new <office:annotation-end> tag. I'm not sure how to interpret this, but it seems to imply a comment can apply to a range of text instead of a single point, and that comments are represented by either one or a pair of objects. If it's one object, then it's a single point in the document. If it's two, the first is the start of a range and the second is the end of that range. Assuming we use the EOC model as it exists, the first object can always get us to the actual comment container directly. That leaves the second object. To handle that, I propose the following -- the second object is embedded as an EOC just like the first, but it is basically a non-showing empty object whose xml-role is "note-end". The link between the start and end objects can be handled via an accessible relation RELATION_MEMBER_OF added to both objects. With this, when I encounter the first object, it has the full container with an xml-role attribute of "note". It also has a RELATION_MEMBER_OF relation that points to the end object (if it exists). When I encounter the end object, it is basically empty (maybe ROLE_FILLER?), but with an xml-role attribute of "note-end". It also has a RELATION_MEMBER_OF relation that points to the starting object. Handling visibility of comments ------------------------------- IMO, these are like any other objects and the STATE_SHOWING state should be used to indicate whether they are burning pixels on the screen or not. Providing keyboard-only access to comments ------------------------------------------ I'm not really familiar with all the keyboard navigation techniques and styles in OOo, so I'll leave this up to the OOo developers. From a user-based task model, however, the important things seem to be: * The user should be able to quickly add or delete a comment. * The user should be able to quickly navigate between the document content and the comments. * When in the document content area and the user sees a comment is present, navigating to the comment should automatically make the comment become visible. I might also argue that as you arrow through a document, any associated comment for the current caret position should be visible and it should be obvious which comment it is. * The user should be able to quickly jump from one comment to the next (e.g., let them quickly scan what other people had to say about the document). * The user should be able to easily navigate within a comment -- go from field to field, select/copy/edit text, etc. --------------------------------------------------------------------- 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
