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

Shashidhara Veerabhadraiah shashidhara.veerabhadraiah at oracle.com
Wed Nov 14 07:00:48 UTC 2018

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,

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, November 13, 2018 6:09 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net; swing-dev at 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.veerabhadraiah at 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.

More information about the awt-dev mailing list