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

[shashidhara.veerabhadraiah at oracle.com]

Hi Alexey, I totally understand your perspective and even I ran into 
some of those questions. Below are my responses!!

Thank you Alexey for bringing out unique issues pertaining to accessibility.

Thanks and regards,
shashi

On 08/11/18 10:00 PM, Alexey Ivanov wrote:
> Hi Shashi,
>
> On 08/11/2018 04:18, Shashidhara Veerabhadraiah wrote:
>> Hi Alexey, Thanks for running the test on Windows. With accessibility 
>> in question we should reach the component using the keyboard only. 
>> Touch and mouse is not permitted.
>
> In this case each component must be focusable.
> Can you reach each JLabel when using Tab? You can't (usually).
Typically the idea is to be reachable for disabled person and a 
component is must be accessible if a value needs to be entered. For ex., 
JLabel is next to a edit box and when the control goes to edit box, VO 
tells its an edit box and needs to enter something. One can set the 
accessible name for this edit box and the same will be told over VO. So 
in this case reaching Jlabel is not required.
>
>> So the question is can it be reached via a keyboard stroke? If not 
>> then that component is not accessible and that's the assessment.
>
> I haven't searched for special keyboard shortcuts for Narrator.
> What Sergey found is not general purpose but rather accessibility tool 
> shortcuts. In that case, progress bar is still not accessible when 
> using Tab, is it?
Yes, it is not accessible with TAB key strokes.
>
>> I could not reach to the progress bar(thro' keyboard) without 
>> explicitly setting the focusability 'on' it for both Windows and Mac. 
>> Sergey found a way to do it on Mac but I was not able to do the same. 
>> But with this fix, I see it working on both Windows and Mac.
>
> But your fix also changes the behaviour for the case where no 
> accessibility is used: progress bar receives keyboard focus even 
> though it never needs it because it does not support any input.
>
> It's just the other side of the coin.
Very true. The problem is that our software never designed from the 
accessibility stand point of view and we are trying to use the existing 
framework for a different purpose(focusability). Hence it leads to such 
confusions.
>
>
> To be clear: I don't object to making progress bar focusable in 
> SwingSet2 if it's the only way to mitigate the problem. However, it 
> does not feel right. That's why I'm trying to understand how other 
> applications deal with this problem.
Yeah true. Adding an additional meaning to Focusability brings in such 
confusions. Ideal solution is to add certain framework for the 
accessibility point of view. But that's a long shot I believe.
>
>
> Regards,
> Alexey
>
>>
>> Thanks and regards,
>> Shashi
>>
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: Thursday, November 8, 2018 1:13 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 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 controls.
>>
>>
>> Narrator does not work with Java apps: it sees only the top-level window
>> of SwingSet2.
>>
>> Regards,
>> Alexey
>>
>> 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
>>>>>>
>