Hi Sergey, I enabled 'All controls' access in the
'Keyboard->Shortcuts->Accessibility' but still was not able to get the
focus unto the progress bar and even with the short cut that you
mentioned it always skipped the progress bar. The control would move
from 'edit text box' to 'Start loading text' button. Even the bug
description says to use the tab key to do this operation.
Only with this fix, I was able to select the progress bar control and
otherwise not and that is true as per the focus traversal policy used
for this control type.
Thanks and regards,
Shashi
On 03/11/18 3:00 AM, Sergey Bylokhov wrote:
I am not sure that the focusable property should be changed to fix
this issue.
because the property is ignored when a11y shortcuts are used, at least
I am
able to select the progress bar using
ctr+shift+cnd+left/right/up/down. And
VO reads the current value of the progress bar, but if the demo is in
progress("Start
loading text" button was pressed) the VO did not read information
about the new
values of the progress bar.
On 24/10/2018 22:31, Shashidhara Veerabhadraiah wrote:
Hi Sergey, While fixing this bug I did not verified the behavior of
other components and how they behave with respect to the AT. Since
the question about other components came up and did some debugging on
that part. Below is the reason that I could find:
It is all about the focus traversal policy that is used for each
component type. While the both the JProgressBar and JLabel derived
from JComponent and then JComponent is also derived from Container
and Component class. JProgressBar component goes via the
DefaultFocusTraversalPolicy(.java) while the JLabel goes via the
ContainerOrderFocusTraversalPolicy(.java) where there are overriding
methods of accept() function. This builds different behavior for
JLabel and JProressBar while focus traversal.
Since the both the components are derived out of Component class both
are default to focusable to true(Component.java) but because of the
way accept() method is overridden, JProgressBar's focusable state is
considered only when the focus traversable is overridden(not
FOCUS_TRAVERSABLE_DEFAULT). Now by calling setFocusable() explicitly
overrides the current policy to FOCUS_TRAVERSABLE_SET, hence the
focusable state of the JProgressBar is considered afterwards.
Hope this answers. Please let me know if you have any questions.
Thanks and regards,
Shashi
-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, October 25, 2018 3:11 AM
To: Shashidhara Veerabhadraiah
<shashidhara.veerabhadra...@oracle.com>; 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.
Can you please provide more information about relation of focusable
state and a VoiceOver? The simple JLabel is not focusable, but
VoiceOver reads its contents, and it is possible to select the label
using VoiceOver's shortcuts.
On 22/10/2018 00:36, 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
