There is no accessible mode. It is accessible by design.
But there are limits. A UI that has dynamically updating graphs that change
by the millisecond displaying data from a source that can't even be read
by eye sight is not going to be able to accessible via speech.
That is out of our scope. The swing progress bar is in the grey area
mainly because
it is a UI component. I can understand arguments as to where it falls.
As an application designer I might suppose it reasonable that I have
to do something to provide updates to an AT for anything that changes
outside the users control. But what then if you have ten progress bars
loading ten things concurrently. It is hard for the eye to track that.
A screen reader is doomed.
-phil.
On 11/8/18, 8:54 PM, Shashidhara Veerabhadraiah wrote:
Hi Phil, Right, Accessibility in swing was way ahead and is still ahead of
other alternatives. What I meant was that certain existing framework elements
are used interchangeably between 'normal' mode of operation and in
'accessibility' mode. Probably we could have separated that out. Like for ex.,
focusability in the normal mode of operation means that the user needs to
enter\edit some information and the same flag is used for accessibility too.
And here software I meant the platform software as well, as they don't have a
separate framework and they use the existing framework for accessibility as
well where it may have a different meaning, causing certain confusion from
developer's point of view.
Thanks and regards,
Shashi
-----Original Message-----
From: Philip Race
Sent: Friday, November 9, 2018 10:14 AM
To: Shashidhara Veerabhadraiah<shashidhara.veerabhadra...@oracle.com>
Cc: Alexey Ivanov<alexey.iva...@oracle.com>; Krishna
Addepalli<krishna.addepa...@oracle.com>; Sergey Bylokhov<sergey.bylok...@oracle.com>;
awt-...@openjdk.java.net; swing-dev@openjdk.java.net
Subject: Re:<Swing Dev> <AWT Dev> [12] JDK-7124285: Nothing heard from
VoiceOver regarding the status of the progress bar
On 11/8/18, 9:10 AM, shashidhara.veerabhadra...@oracle.com wrote:
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.
Whoa. I don't know what you mean here. Maybe it is very narrow but I can't let
this pass.
Swing was absolutely designed with accessibility in mind. Probably the first
and maybe only UI toolkit to have it designed in from inception. The
accessibility team were embedded in the Swing team. There was nothing
comparable anywhere else in 1997-8 (20 years ago!) So Java + Swing was years
ahead of anything else anyone had and it is not fundamentally lacking even
today.
Bugs, overlooked things, things that should be updated etc. sure.
But don't go propagating misinformation that A11Y was ignored in the design.
-phil.
