Community
Participate
Working Groups
Currently not all our diagrams have tables showing the same data. This is important for accessibility and was missed during the move to the new UML2 sequence diagrams. We need a standard, easy way to get the table for any of our diagrams. This is a must for 3.0.1.
The only views currently lacking tables are the UML2SD views. This includes: - Object Interactions - Class Interactions - Thread Interactions - Agent Interactions - Process Interactions - Host Interactions As well as the log-related sequence diagrams: - Log Interactions - Log Thread Interactions The usability team suggests using a toggle button in the view toolbar of each diagram view. When turned on, the view will show a table instead of a diagram. The table should show exactly the same information as the diagram, but in a table form. The table should look like the existing statistics tables. Other non-UML2SD diagrams (e.g. Execution Flow) have tables, but they are separate views accessed from the context menu. These should be removed and should follow the same approach as will be used for the UML2SD tables (toggle button, show in same view). This is being tracked in bug 68873. Note: this change will require a PII change. This needs to be resolved, as there are no PII changes scheduled for 3.0.1.
There is no table that could show the underlying data an acceptable way. So we propose to mark this one as a duplicate of one of the few accessibility defects that remains on UML2 SD: - 68986 (screen reader after keyboard selection, that already works with mouse selection) - 68987 (screen reader on lifeline titles) - 68989 (zoom in and out using keyboard only) And then these three ones would be targetted for 3.0.1. They have been entered against UML2 SD view following the accessibility checklist we have been provided with. Tell me your opinion here and I would make the changes in those 4 records if you agree.
new PII
Dominique, with PII available in 3.0.1. Can this be done in 3.0.1 timeframe? Comment from Harm's note: - In general the tree view gives you a call stack viewer that uses less UI real estate, is faster and doesn't require an understanding of basic UML. Many users prefer these simple text based viewers. In our resent assessment of the new Candle tools IBM has acquired, the tree view was in fact considered to be a competitive advantage over vendors with only graphical views. - The support we had was valuable. it was a simple tree rendering. Root was the diagram and first tier of branches represented the "left side" initial entry point of any stack. If there was multiple references to the same node in the graph it was duplicated in the tree. Simple, not perfect and useful. Loosing this is a serious regression.
Should be done for 3.0.1 if at all possible.
latest comment from Sylvain: the timeframe is too short for 3.0.1, taking into account the availability of developpers to do that. And the accessibility issue are addressed in - 68986 (screen reader after keyboard selection, that already works with mouse selection) - 68987 (screen reader on lifeline titles) - 68989 (zoom in and out using keyboard only) However, this missing feature is targeted in 3.1
alternative fix of enabling open Execution Flow table form UML2SD trace views is addressed in bug 70302 for 3.0.1 timeframe
Changed target iteration to 3.1 i2. Needs to know what to do exactly here: do we merge with execution flow table something that would show method invocations?
Needs to know what to do exactly (moving to 3.2)
Sebastien: Needs to know what to do exactly (moving to 3.3)
Dominique, you cannot update the defect target unless they are discussed and approved by the Hyades committers meeting. If you have defects you can't contain in 3.2 i2 send them in a note to me and they will be covered in the meeting. Add a short explanation of why you want to move the defect ( a feature request, suggestion, high risk fix , etc )
We need this one to be retargeted for 3.3 because of the lack of content definition for it. What's the difference between the table tree that is wished and the Execution Flow Table that is accessible from Trace SD view thanks to a coolbar button you can see in 3.0.1? In other words, can we say that Execution Flow Table is the accessible view for all 6 kinds of Trace Interactions? If not, can we imagine an update of this table that would be the accessible view for both Trace Interactions and Execution Flow? This would not add a new view and could help contain this bug in 3.2i2.
The whole aim of this was for accessibility. Consider a blind user trying to navigate a sequence diagram (or any diagram). The approach that we came up with (approved by Wayne) was to give the user the ability to toggle between the diagram and a table representation of the same data, via a toolbar button (I would also recommend a menu item). It wouldn't be a new view, but would be contained in the same view. The root messages in the sequence diagram would translate into top-level items in the table tree, and the sub-messages would be the children, and so on. Is it clear?
About accessibility, a blind user can already listen to the sequence diagram contents two ways: first one thanks to accessibility implementation made in the graphical diagram itself; second one thanks to the execution flow table that is accessible too and that has a shortcut button from trace interactions. Why do we need a third way? Regardless accessibility, what's the difference between the table tree that is described above and the Execution Flow Table?
Right, the execution flow is very similar to some of the trace interaction sequence diagrams. However, it doesn't deal with things like host/process/agent interactions. And there are sequence diagrams other than the trace ones - like log interactions. So I think the question is - are the current accessibility improvements to the sequence diagram enough to satisfy the accessibility requirements for the products built on top of Hyades? If yes, then I think we're ok and we don't need the additional tables.
According to the last comment, the tables seems to be not needed anymore
Did you check with the higher products to make sure that they're ok with not having tables (i.e. it meets their accessibility requirements). If not, then we still do need tables...
Could you reply to the last comment? Thanks
Scott, can you please give your feeling on this? Feel free to contact me.
I humbly admit that I am not familiar with the tooling context of this discussion. However, there are two primary accessibility requirements for visual diagrams. One, there must be a keyboard equivalent for all actions. That is, a user must be able to perform keyboard navigation to all rendered objects. The rendered object selected must have some sort of visual focus indicator. And, a user must be able to perform all actions on the rendered object via some combination of keys. Secondly, the diagram must provide semantic information about the rendered objects. Assistive technology must be able to determine the object identity, role, and state. If these conditions are met in the diagram a table is not necessary.
Thanks a lot Scott for your enlightments. That's very helpful. As it was our understanding of the accessibility requirements, Sébastien has already implemented for 3.0 the keyboard shortcuts that allow to navigate between the graph nodes and also assistive technology support (checked with a screen reader tool). The next step on this topic is Sébastien Veyrière to check on Trace Interactions that all actions are available from keyboard and that assistive information provided by the widget is complete. About log interactions, its dev team may have to do the same check in order to cover the two uses of SD view. 3.3i2 would be the target to have a definitive and consensual compliance on this. Ok for such a protocol?
Sounds good to me
Hi Dominique, I have one question on my part and please excuse my ignorance of IES component versions. Is Hyades 3.3 targetted for IES 3.0.2? Thanks.
FYI, Scott's question has been answered off-line.
Only the commands using a multiselection are not accessible using the keyboard. The focus on graph nodes will be implemented in order to allow the multiselection. This focus will behave like tree widgets (like in packages explorer for example)
Focus on graph nodes has been implemented. The user is now able to multi-select nodes using Shift or Ctrl key in combination with standard traverse keys (arrow keys, Home, End, Tab, Shift Tab) The following navigation has been adopted using the traverse keys: -no nodes focued + any arrow key = give the focus to the first lifeline -focus on a lifeline + up arrow = no effect -focus on a lifeline + down arrow = give the focus to the first lifeline execution occurrence -focus on a lifeline + left arrow = give the focus to the previous lifeline -focus on a lifeline + right arrow = give the focus to the next lifeline -focus on a lifeline + home key = give the focus to the first message leaving this lifeline -focus on a lifeline + end key = give the focus to the last message leaving this lifeline -focus on an execution occurrence + up arrow = give the focus to the directly above execution occurrence (if there is no execution occurrence above, then select the lifeline) -focus on an execution occurrence + down arrow = give the focus to the below execution occurrence -focus on an execution occurrence + left arrow = give the focus to the previous lifeline -focus on an execution occurrence + right arrow = give the focus to the next lifeline -focus on an execution occurrence + home key = give the focus on the top execution occurrence -focus on an execution occurrence + end key = give the focus on the bottom execution occurrence -focus on a message + up arrow = give the focus to the above message leaving the same lifeline (if there is no candidate above give the focus to the lifeline) -focus on a message + down arrow = give the focus to the below message leaving the same lifeline -focus on a message + left arrow = given the focus to the previous message following the execution flow (if any) -focus on a message + right arrow = give the focus to the next message following the execution flow (if any) As a consequence this navigation overrides most of the previous keyboard shortcuts, those commands have then been removed from the menu dropdown as they can not be redefined (as it is the case for navigation in package explorer for example). (This is due to the use of the Shift and Ctrl key modifiers used for the multi-selection) Nodes semantics have been increase to allow screen readers to provide information on focused node
Verified. Looks good. Closing bug.
