<AWT Dev> <Swing Dev> [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

Alexey Ivanov alexey.ivanov at oracle.com
Wed Nov 7 19:42:45 UTC 2018

Hi Shashi,

I ran a test with a native dialog-based Windows app with two progress 
bars. I used the built-in Narrator as the accessibility tool in Windows 10.

When using Tab key to navigate between controls on a dialog box, the 
progress bar without WS_TABSTOP style cannot be focused; the one with 
WS_TABSTOP style can be focused with Tab. When it's focused, Narrator 
reads its value, the range as well as its label in static control 
preceding the progress bar. Narrator also reads new value when the 
progress is updated.

At the same time, the non-focusable progress bar can be selected with 
touch. It's read by Narrator in this case.
I didn't find a way to select it with mouse though.

When the progress bar is focused, it has no focus indicators. I believe 
this is because progress bar controls aren't focusable by default as 
they don't support any user input.

So the current behaviour in Java coincides with that of Windows native 

Narrator does not work with Java apps: it sees only the top-level window 
of SwingSet2.


On 24/10/2018 16:19, Alexey Ivanov wrote:
> Hi Shashi,
> I see, setting setFocusable dynamically is not an option then. At the 
> very least it will be confusing for the user: in some cases progress 
> bar is skipped when traversing focus and in other cases, it's not.
> Progress bar embedded in a toolbar button is another case.
> Is progress bar focusable in native apps?
> Usually it's not because this control only displays the progress and 
> does not accept any user input: neither from keyboard nor from mouse.
> Perhaps there's an additional accessibility property to make it be 
> read by AT.
> What about JLabels? They're also non-focusable because labels do not 
> accept any user input. Are labels also required to be made focusable 
> to be read by AT?
> Making a progress bar focusable is acceptable as the workaround for 
> SwingSet. But I don't think it's a good idea to make JProgressBar 
> focusable by default. The control does not accept any user input, so I 
> think it should not become focus owner. Therefore there's no need to 
> add visual focus cues.
> Regards,
> Alexey
> On 24/10/2018 06:14, Shashidhara Veerabhadraiah wrote:
>> Hi Alexey, Yes, their value is read by the AT. Though I could not 
>> find any focusability on them though. AT can be enabled on the fly 
>> like Command + F5 on mac and it varies platform to platform.
>> In certain cases the progress bars are embedded within the button 
>> like in the 'show downloads' button on the Safari browser/Mozilla 
>> browser. I tried with an native windows progress bar demo application 
>> and found that they are not focused. But ideally certain visual cue 
>> is required to see where the cursor is highlighting else it seem lost.
>> Thanks and regards,
>> Shashi
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: Wednesday, October 24, 2018 12:16 AM
>> To: Shashidhara Veerabhadraiah 
>> <shashidhara.veerabhadraiah at oracle.com>; Krishna Addepalli 
>> <krishna.addepalli at oracle.com>
>> Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> <Swing Dev> [12] JDK-7124285: Nothing heard 
>> from VoiceOver regarding the status of the progress bar
>> Hi Krishna, Shashi,
>> I wonder how native progress bars behave. Is their value read by 
>> assistive technologies? Are they focusable? Are they focusable if no 
>> assistive technology enabled?
>> JLabel is not focusable. It does not accept user input directly. Are 
>> JLabels also skipped by assistive technologies?
>> If setLabelFor(Component) is called, the label is associated with a 
>> component. Is label read when the associated component is focused?
>> Regards,
>> Alexey
>> On 23/10/2018 11:49, Shashidhara Veerabhadraiah wrote:
>>> Hi Krishna, Thanks for your review.
>>> That was really a good observation and as you rightly said, some 
>>> visual cue needs to be there around the progress bar, else it does 
>>> look lost.
>>> Thanks and regards,
>>> Shashi
>>> -----Original Message-----
>>> From: Krishna Addepalli
>>> Sent: Tuesday, October 23, 2018 1:54 PM
>>> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
>>> Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
>>> Subject: Re: <Swing Dev> [12] JDK-7124285: Nothing heard from
>>> VoiceOver regarding the status of the progress bar
>>> Hi Shashi,
>>> The fix looks good to me. Regarding the decision of placing the line 
>>> “setFocusable(true)” in the constructor of ProgressBar, I think that 
>>> is a good decision since the Swing users needn’t explicitly make 
>>> that call to make it accessible.
>>> There is one problem though:
>>> The focus is not shown on the progress bar, and at that point, it 
>>> feels like the focus is lost and may lead to some confusion.
>>> I think it would be good if we can render a focus rect around the 
>>> progress bar to let users know that it is in focus, which ofcourse 
>>> can be addressed separately.
>>> Thanks,
>>> Krishna
>>>> On 22-Oct-2018, at 1:06 PM, shashidhara.veerabhadraiah at 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

More information about the awt-dev mailing list