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

[Alexey Ivanov]

Hi Shashi,

First of all, I must emphasize that Swing has always been and is 
accessible by design. Phil replied to that part already. I just wanted 
to reiterate the same statement.

Please see my other comments inline:

On 08/11/2018 17:10, shashidhara.veerabhadraiah at oracle.com wrote:
> 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.

Okay.

What if a JLabel at the top of the window contains instructions for the 
purpose of the dialog window. Without this information, it could be 
impossible to fill the form displayed in the dialog box.

>>> 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 have found the keyboard shorts for Narrator:
https://support.microsoft.com/en-gb/help/22806/windows-10-narrator-keyboard-commands-touch-gestures

Using it's shortcuts — Caps Lock + Left / Right array — I can select 
either progress bar in my test: both focusable and non-focusable. (Caps 
Lock is the default Narrator key referenced in the table.)

Caps Lock + W reads the entire window, highlighting each control and 
reading its current value. All non-focusable controls are included.


I have not tested it with JAWS though.

>>> 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.

I meant this as a counterargument to making progress bar focusable.

Swing was designed with accessibility in mind. That's why each 
JComponent has AccessibleContext.

As far as I understand from another branch of this review, it works as 
expected. One has to use shortcut keys of the accessibility tool to 
"select" the progress bar so that its status is read.

I believe it's the way it's supposed to work.

>> 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.

I can't see any additional meaning added to focusability.
If a component is focusable, it can become the current focus owner and 
thus receive keyboard input.

It's exactly what happens in this case.
As a side effect, the current focus owner is read by VoiceOver, or 
another accessibility tool for that matter. It's pretty much expected: 
the user is supposed to interact with the current focus owner. If it 
wasn't announced by the accessibility tool, how would the user know the 
current focus owner has changed?


To sum up, it looks everything works as expected: VoiceOver reads the 
status of the progress bar once it's selected using shortcut keys of 
VoiceOver. So the test instructions should be updated to include these 
shortcut keys.

Progress bar should not be focusable. It should remain non-focusable as 
it has always been.


For Windows, we just need to find the right shortcuts.


Does it sound reasonable?

Regards,
Alexey

>>
>>
>> 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
>>>
>>> <SNIP>