Hi Phil, Mostly yes, I think. This component is different from other components as the changes are permitted using an internal function rather based on the user actions. This component has setValue() method which is called programmatically based on the 'job' progress and looks like it does not have any user interaction handlers. Based on that my only question is that, should we be calling the setFocusable(true) explicitly in the JProgressBar constructor or be dependable on the user calling the same explicitly every time to make it accessible!! Advantage of calling it in the constructor is that it makes the component accessible(This is required based on the current default traversal policy that we use in our focus manager) without much affecting the use of this component with accessibility disabled mode.
Thanks and regards, Shashi -----Original Message----- From: Philip Race Sent: Tuesday, October 23, 2018 10:46 AM To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com> Cc: awt-...@openjdk.java.net; swing-dev@openjdk.java.net Subject: Re: <Swing Dev> <AWT Dev> [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar OK. If the progress bar is still not "user adjustable" then that should be fine. Wondering out loud ... is this the only Component class where such a thing matters. Most components won't change value on their own without some user intervention, so perhaps ProgressBar is (almost) unique ? But I expect there is some other rare case that is similar. -phil. On 10/22/18, 9:47 PM, Shashidhara Veerabhadraiah wrote: > Hi Phil, This change does not breaks the changing the value directly. I > verified that. > > We need to use the tab key to traverse thro' components but the control never > came to the progress bar hence it was not accessible. With this change > control comes to it in the order and is now accessible. > > Thanks and regards, > Shashi > > -----Original Message----- > From: Philip Race > Sent: Monday, October 22, 2018 8:57 PM > To: Shashidhara Veerabhadraiah<shashidhara.veerabhadra...@oracle.com> > Cc: awt-...@openjdk.java.net; swing-dev@openjdk.java.net > Subject: Re:<Swing Dev> <AWT Dev> [12] JDK-7124285: Nothing heard > from VoiceOver regarding the status of the progress bar > > > > On 10/22/18, 8:24 AM, Philip Race wrote: >> I'll partly answer my own question in so far as that if it doesn't >> have focus it probably isn't something that the AT would know is the >> component to be reading out ... >> but I expect it still should not be editable - please confirm this - >> and why is this a Mac-specific issue ? > Ah, the bug report says this is an issue on Windows as well. > > -phil. >> -phil. >> >> On 10/22/18, 7:58 AM, Philip Race wrote: >>> SFAIK the intent of the demo is that the ProgressBar is not user >>> adjustable so why does it have to be focusable ? >>> It should not be possible to change its value directly, whether an >>> AT is involved and you use the keyboard or directly with mouse. >>> >>> So does this change break that intent ? Why does it work >>> (presumably) with JAWS+AccessBridge on Windows ? >>> >>> -phil. >>> >>> On 10/22/18, 12:36 AM, shashidhara.veerabhadra...@oracle.com wrote: >>>> Hi All, Please review a swingset fix for the below bug. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7124285 >>>> >>>> Fix: http://cr.openjdk.java.net/~sveerabhadra/7124285/webrev.00/ >>>> >>>> Problem: The JProgressBar component used in the swingset demo was >>>> not focusable and once it is turned on, now the progress status is >>>> getting narrated via the voice over. >>>> >>>> Thanks and regards, >>>> Shashi >>>>
