Hi Shashi,
I absolutely agree with Sergey: the component must be accessible even if
it's not focusable.
And I don't quite understand what you're talking about.
The person who uses an accessibility tool will use the shortcuts of the
tool to navigate controls in the window.
Tab key, on the other hand, serves different purpose: it moves input
focus between interactive components which accept user's input. As
expected, the accessibility tool announces the change of the focused
component.
Thus, when you make the progress bar focusable, you can set input focus
to it. It's just a side effect.
At the same time, progress bar accepts no input. It should stay
non-focusable. Otherwise, it's confusing for both users: those who
prefer to use keyboard to navigate between components and those who use
accessibility tools.
Can you get the status of the progress bar using VoiceOver shortcuts on
macOS?
If yes, we're done. If not, we have to understand why the progress bar
cannot be selected with VoiceOver.
For Windows, Sergey provided the link to JAWS shortcuts:
https://www.freedomscientific.com/Content/Documents/Manuals/JAWS/Keystrokes.txt
Search for "For Dialog Boxes" section.
Insert+B or CapsLock+B (the latter is for laptops) should read the
entire window from top to bottom. It should also read the state of the
progress bar.
Insert+Tab or CapsLock+Tab is Announce Progress Bar Status
There should be a key shortcut to navigate between all controls.
Do Shift+Period and Shift+Comma work?
Regards,
Alexey
On 14/11/2018 07:00, Shashidhara Veerabhadraiah wrote:
All swing components has accessibility info associated with it. But how those
information is received thro' AT matters.
For ex., one can use the control+option(system accessibility shortcuts) on the
progress bar demo but you can't use it in the option pane demo. You can't reach
'show input dialog' and other buttons in that pane. You are forced to use the
TAB keys(java options) there.
It looks like TAB keys are delivered to the window(consumed for focus traversal
purpose) and I don't think the control+option keys are delivered to the window
but instead platform accessibility sub system consumes it and reads the backend
swift component's accessibility info there. Whenever a accessibility info of a
component is reached using the system short cut we would see a black rectangle
covering that component whereas it is not the same for TAB key based traversal
within the option pane demo(as it is consumed by java window).
So to conclude within some of our custom components, TAB key is the only way of
traversal and am not sure why the system short cut fails to navigate such
components though.
Thanks and regards,
Shashi
-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, November 13, 2018 6:09 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
On 11/11/2018 05:30, shashidhara.veerabhadra...@oracle.com wrote:
This fix works for both windows and mac. Mac may have a short cut to ignore
such things but we still need to solve the problem for windows and for mac(for
TAB key traversal case). TAB key is consumed by java swing for traversal
purpose and hence TAB key traversal is assumed to work for accessibility case
as well and it does work for with this fix. So why deny that?
Hope this answers your question. Accessibility is a new area to explore here
for everyone I think and am also learning along with these fixes. So please let
me know if you have any more questions.
This assumption is wrong, the components should be accessible even they are
have a focus or not, can be focused or not, editable or not, enabled or not, in
all these cases the accessibility tool should be able to provide this
information to the user.
--
Best regards, Sergey.
