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