Community
Participate
Working Groups
When executing our product accessibility testing using the Inspect32 MSAA viewer the following problems were discovered on the Update Manager Product Configuration Dialog. (1) When tabbing through the screen there is a tab stop on the description in the panel on the right ("This is the description ...." ) but it does not get focus. (2) When tabbing through and the Scan for Updates link is reached, it shows a value of Role: Editable Text, rather than Role: link as expected and as shown by all other links on this page. (3) All links in the right hand panel show DefAction: as none, but we believe that they should show DefAction as "Press" I am sorry for including all of these in the same bugzilla record, but since they are all so closely related I was hoping to save developer time. If some of these are completed different separate bugzilla records should certainly be opened. Since these are seen as accessibility issues for our product I am marking the severity as Major. I will include a few screen shots as well to help illustrate what we are seeing.
Created attachment 61551 [details] Picture of Scan for Updates MSAA data that is incorrect
Created attachment 61554 [details] DefaultAction value in MSAA viewer
Created attachment 61555 [details] Example of a good url/link DefAction value.
Are we doing this for 3.3 ?
Note: if we do anything here, pls record a 3.3 patch, and a risk assessment for a 3.2.2 backport.
This is UI Forms (more precisely, FormText widget). This has been a regular complaint - we should see if we can do something for 3.3 here.
Thx, pls set the target accordingly.
Priority lowered, could be deferred until 3.4.
Chris - are you still targetting 3.3M7 ?
I'm out of time in M7, this bug could take a few days as there are three separate problems in it. Will try for RC1.
I have fixes for problems 2 and 3. To make it easier to follow the approvals process required for RC1 I have created a Bug 186053 to track the problems I can fix now. This bug now only tracks problem 1. Problem 1 (tab stop but no focus)is a little harder to fix than the other two. I will look into it some more since it is related to some other forms bugs relating to focus but I will fix problem 1 for Eclipse 3.3 only if I have a low risk fix.
Two of the three problems (2 and 3) are resolved, see Bug 186053. I am not going to be able to fix problem 1 for RC1 and would like to defer this. Removing the target milestone.
Targeting Eclipse 3.4.
Reassigning my forms bugs to Adam
Created attachment 75333 [details] patch for problem 1 This patch changes the description from a Text widget to a FormText. In order to do this it was necessary to add a method to FormText that returns a String with its contents (for the purpose of Section#getDescription()). The method FormText#getAccessibleText() has been added which simply returns the result of FormTextModel#getAccessibleText(). Also modified FormText#handleFocusChange() to ensure that focus is passed to a sibling when there are no focusable items.
Michael, does this patch resolve the remaining issue for you? Dejan, can you review?
Adam, adding a protected method to FormText qualifies at API. You need to add Javadoc and fully document it according to the API rules. Also remove the System.out.println from 'setDescription()'. I would have removed it myself but since you need to also add API, you should do it in the next patch.
Created attachment 76164 [details] patch I misunderstood the bug before. Please disregard that last patch. :| This patch fixes the problem by adding a call to setFocusToNextSibling(...) when the FormText has no focusable segments. Since the next sibling in this case is also a FormText, this fix actually revealed a problem in which a programmatic call to FormText#setFocus() was not focusing on the first segment. This problem is fixed as well by removing code that sets FormText#mouseFocus to true for a portion of the setFocus() method. This code was added as part of a fix to bug 95612 and removing it does not cause the bug to reoccur. Additional testing on forms clients has not revealed any other regressions caused by removing the code.
Committed to HEAD - that's #2 :-).
Marking as FIXED.
Setting milestone.
This fix caused a regression. See bug 236735. For 3.5M1, the default behaviour has been changed back to allow focus without painting it. In order to work around the problem, FormText now supports the SWT.NO_FOCUS style bit which will prevent it from receiving focus in all cases. We are also considering adding support for another style bit which would cause FormText to actually render its focus. See bug 236739.
