Community
Participate
Working Groups
When switching back to the monitor tab, either with the mouse or the mnemonic, some screen readers (JAWS 11 in particular) do not read the Monitor tab as having been selected. Instead, details about the select collector are read instead. The first time the monitor tab is selected is generally read properly. It is read properly if Shift+Tab is pressed to move focus back from the data collectors to the Monitor tab. Reproduce: 1. Run > Profile Configurations 2. Create new External Java Application 3. Switch to Monitors tab 4. Switch to Destination tab 5. Switch back to Monitor tab The second time switching back to monitor tab is not read.
The problem is caused by the initialization that we perform when activating the Monitor tab. We actually query the data collectors twice in order to ensure we correctly respond to changes on the Hosts tab (see bug 291702 for details). This causes some focus shifting to occur which confuses the screen reader and the tab name is not read. I have a patch that corrects the problem. It re-implements the caching removed by bug 291702 so that we only fetch the data collectors when needed. The downside is that we also only fetch the collectors when the Monitor tab is activated. This means that the user must visit the Monitor tab in order for the default collector(s) to be selected and the "Profile" button to be enabled. Current behaviour is that the defaults are pre-populated and the user does not have to visit the Monitor tab in order to launch. Requesting comment on whether or not this change is acceptable?
Created attachment 169427 [details] patch With further investigation I was able to correct this without losing the auto-populate functionality of the Monitor tab. Patch attached.
Jon I think this falls under your umbrella. Can you review this patch?
Patch is good!
Created attachment 169832 [details] Clean up patch Attaching a new patch that cleans up the last one a little bit. Updated copyright notice and remove extraneous changes.
Mike, please fill in the PMC request template, which can be found in: http://www.eclipse.org/tptp/home/documents/process/development/stop_ship_template.html under Stop-ship Request Template. Once it's been filled in, I'll give the project approval and post it for the rest of the PMC team for PMC approval.
Requesting project lead approval to bring forward to PMC: 1. Explain why you believe this is a stop-ship defect. How does the defect manifest itself, and how will users of TPTP / consuming products be affected if the defect is not fixed? This affects accessibility verification in a consuming product. 2. Is there a work-around? If so, why do you believe the work-around is insufficient? There is no workaround to get the correct output from the screenreader. However, this does not prevent navigability of the interface, it impacts discoverability of the interface. 3. Is this a regression or API breakage? Explain. No API breakage. This is newly reported, but it is conceivable it was introduced in bug 291702. 4. Does this require new API? No 5. Who performed the code review? Jonathan West 6. Is there a test case attached to the bugzilla record? No 7. What is the nature of the fix? What is the scope of the fix? What is the risk associated with this fix? The fix is a simple bugfix, no new functionality is exposed. Scope is contained to the "Monitor" tab which lists available profiling data collectors. Risk is low, changes are not extensive and similar logic has already been in place prior to this fix. 8. Is this fix related to any standards that TPTP adheres to? If so, who has validated that the fix continues to adhere to the standard? No.
Requesting PMC approval for TPTP 4.7.
Patch checked into HEAD w/ PMC approval.
Verified in 4.7 GA.
Closing.
