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.veerabhadra...@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.veerabhadra...@oracle.com>; Krishna Addepalli
<krishna.addepa...@oracle.com>
Cc: awt-dev@openjdk.java.net; swing-...@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>
