AJAX. I am dealing with an web app built using AJAX. I understand the need
to sync the virtual screen with Ins + Escape. I got some other info from
JucyStudio.
http://juicystudio.com/article/making-ajax-work-with-screen-readers.php#informreaderÂ
. I was looking for some general guidance. Please don't just wish me good
luck. They are running the app in Chrome. I would like them to move to I E
or Firefox. Any advice here? I was thinking of invoking Ins + Escape in some
script areas. Has anyone done that? They are running Jaws 15. I want them
to go to 16 in the event I need to talk to Freedom Scientific. FS is short on
advice if you don't own their latest Jaws. Is there any body of knowledge you
can point me, any Jaws specific, even scripting specific stuff? If I get a
chance to talk to the web app developers, I intend to point them to the
JucyStudio stuff regarding JavaScript and ARIA techniques for notifying screen
readers of updates.Happy July Fourth to my fellow U S A scripters.Paul
Bonarrigo
On Wednesday, July 1, 2015 10:08 PM, FreeLists Mailing List Manager
<ecartis@xxxxxxxxxxxxx> wrote:
jawsscripts Digest   Wed, 01 Jul 2015   Volume: 03 Issue: 118
In This Issue:
      [jawsscripts] Re: JAWS scripting and the Java Access Bridge
      [jawsscripts] Re: JAWS scripting and the Java Access Bridge
      [jawsscripts] Re: JAWS scripting and the Java Access Bridge
      [jawsscripts] How Browsers Interact with Screen Readers and
      [jawsscripts] Re: How Browsers Interact with Screen Readers
----------------------------------------------------------------------
Date: Wed, 1 Jul 2015 13:31:08 +0200
Subject: [jawsscripts] Re: JAWS scripting and the Java Access Bridge
From: Florian Beijers <florianbeijers@xxxxxxxxx>
Can you give a few examples? I can't seem to find the functions in the
insert function dialogue ...
Florian
2015-06-12 16:47 GMT+02:00, Doug Lee <doug.lee@xxxxxxxxxxxxxxxx>:
Play with the functions whose names start with nav. It's the only
system I know that will get you access from JAWS to Java Access Bridge
information.
On Fri, Jun 12, 2015 at 04:26:52PM +0200, Florian Beijers wrote:
Hi,
I am a relative newbie to JAWS Scripting and am working on a project
that frankly baffles me somewhat.
It involves using the Java Access Bridge to read out a jTable swing
component with some broken accessibility. The situation is as follows:
- The table is not readable with the JAWS cursor, it just says table
but you cannot read the individual cells
- when moving through the table using the system carrot, only 2
columns are actually read. The rightmost, final column, and a random
other column. Random meaning that it differs per table. Sometimes it
is the first, sometimes the third, etc. You move between the two
readable columns by pressing left and right arrow. So, instead of
reading the adjacent cell it skips over a number of cells and only
reads the other column.
- When clicking the other cells with a physical mouse, JAWS reads the
contents. But you cannot reach those other cells with any hotkey I
have found.
If I could arrow through the table properly, that would already help a
great deal. But I have no idea how to make JAWS go through all the
cells, when the only way to reach those seems to be to physically
click the right spot on screen.
When looking with the JavaFerret, i do see some properties that may be
of use, but I have no idea if JAWS can even get at those.
I can't really find any documentation on this type of project either,
does anyone have some insights for me?
Regards,
Florian
__________???
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@xxxxxxxxxxxxxxxx http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
__________�
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
Play with the functions whose names start with nav. It's the only
system I know that will get you access from JAWS to Java Access Bridge
information.
On Fri, Jun 12, 2015 at 04:26:52PM +0200, Florian Beijers wrote:
Hi,
I am a relative newbie to JAWS Scripting and am working on a project
that frankly baffles me somewhat.
It involves using the Java Access Bridge to read out a jTable swing
component with some broken accessibility. The situation is as follows:
- The table is not readable with the JAWS cursor, it just says table
but you cannot read the individual cells
- when moving through the table using the system carrot, only 2
columns are actually read. The rightmost, final column, and a random
other column. Random meaning that it differs per table. Sometimes it
is the first, sometimes the third, etc. You move between the two
readable columns by pressing left and right arrow. So, instead of
reading the adjacent cell it skips over a number of cells and only
reads the other column.
- When clicking the other cells with a physical mouse, JAWS reads the
contents. But you cannot reach those other cells with any hotkey I
have found.
If I could arrow through the table properly, that would already help a
great deal. But I have no idea how to make JAWS go through all the
cells, when the only way to reach those seems to be to physically
click the right spot on screen.
When looking with the JavaFerret, i do see some properties that may be
of use, but I have no idea if JAWS can even get at those.
I can't really find any documentation on this type of project either,
does anyone have some insights for me?
Regards,
Florian
__________???
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@xxxxxxxxxxxxxxxx http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
__________???
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
The first match if you type "nav" into that dialog is
NavGetAppMainObjectID(). They might not mention Java, but they work there.
On Wed, Jul 01, 2015 at 01:31:08PM +0200, Florian Beijers wrote:
Can you give a few examples? I can't seem to find the functions in the
insert function dialogue ...
Florian
2015-06-12 16:47 GMT+02:00, Doug Lee <doug.lee@xxxxxxxxxxxxxxxx>:
Play with the functions whose names start with nav. It's the only
system I know that will get you access from JAWS to Java Access Bridge
information.
On Fri, Jun 12, 2015 at 04:26:52PM +0200, Florian Beijers wrote:
Hi,
I am a relative newbie to JAWS Scripting and am working on a project
that frankly baffles me somewhat.
It involves using the Java Access Bridge to read out a jTable swing
component with some broken accessibility. The situation is as follows:
- The table is not readable with the JAWS cursor, it just says table
but you cannot read the individual cells
- when moving through the table using the system carrot, only 2
columns are actually read. The rightmost, final column, and a random
other column. Random meaning that it differs per table. Sometimes it
is the first, sometimes the third, etc. You move between the two
readable columns by pressing left and right arrow. So, instead of
reading the adjacent cell it skips over a number of cells and only
reads the other column.
- When clicking the other cells with a physical mouse, JAWS reads the
contents. But you cannot reach those other cells with any hotkey I
have found.
If I could arrow through the table properly, that would already help a
great deal. But I have no idea how to make JAWS go through all the
cells, when the only way to reach those seems to be to physically
click the right spot on screen.
When looking with the JavaFerret, i do see some properties that may be
of use, but I have no idea if JAWS can even get at those.
I can't really find any documentation on this type of project either,
does anyone have some insights for me?
Regards,
Florian
__________???
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@xxxxxxxxxxxxxxxx http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
__________???
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@xxxxxxxxxxxxxxxx http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
http://www.ssbbartgroup.com/blog/how-browsers-interact-with-screen-readers-and-where-aria-fits-in-the-mix/
Posted by Bryan Garaventa on January 2, 2013 in ARIA, Assistive
Technology, JAWS, NVDA
The differing behaviors of screen readers across various browsers are
noticed all the time by screen reader users, and differing levels of ARIA
support are noticed in a similar manner, but the reasons why this happens
arenât commonly understood by the majority of people.
For example, the most widely used screen reader, JAWS, is hard coded to
work best in Internet Explorer. The second most widely used screen reader,
NVDA, is hard coded to work best in Firefox. This includes ARIA support.
 All browsers that support accessibility, include an Accessibility API
that is built into the browser application. This includes Internet
Explorer, Firefox, Chrome, and Safari in the Mac and iOS platforms.
The browserâs Accessibility API exposes public properties and methods that
can be queried by third party applications, like screen readers, to
retrieve information from the Document Object Model (DOM) within the
browser, which is then conveyed to screen reader users. This is like a
hand shaking procedure between the browser and the screen reader.
So, when you hear the word âlinkâ when arrowing down the page for
example,
even though the word âlinkâ is not actually on the page, the screen
reader
is conveying that the role of the current element is that of a link.
This happens, because the browserâs Accessibility API has exposed the role
of the element in one of its public properties or methods, which the
screen reader queries when it renders the page content in the Virtual
Buffer. The screen reader sees that, in the browserâs opinion, the element
is a link, so the screen reader reflects this element type in the Virtual
Buffer.
This is true for all element types.
When I say âin the browserâs opinionâ, I mean this literally, because
it
is possible to manually override what the browserâs Accessibility API
returns for screen readers. This is where ARIA comes in.
So, when ARIA is added to a page, the browser detects the ARIA attribute,
then it updates the information within its Accessibility API to reflect
what the ARIA is supposed to convey.
The screen reader then queries the browserâs Accessibility API as usual,
and renders the content in the Virtual Buffer using this updated
information.
This is why, if you put role=âbuttonâ on a standard link like so:
<a role="button" href="#"> Some Link </a>
the browserâs Accessibility API will convey that this element is a button,
and the screen reader will display the element as a button, which will
appear in the Form Field list in JAWS as though it were a form field, and
can be navigated to using the âbâ and âshift+bâ commands to jump
between
buttons on the page.
Itâs important to understand this part, because ARIA only changes the
information in the browserâs Accessibility API, and does not change the
element in the browser itself. Within the browser, the above element is
still a link, and appears as a link in the DOM, including all native
handlers. The only difference, is that the browserâs Accessibility API
portrays this element as a button for screen readers. Nothing else has
changed.
This is why, if you put role=âbuttonâ on a Span tag, it will appear as a
button for screen reader users, but it will still be a Span tag
regardless.
Here is where the browser differences come in.
All browsers have different Accessibility APIs, which may have different
public properties and methods, and may require different techniques for
accessing the browserâs API and DOM. The same is true for ARIA support
within each browser, since this needs to be added to each Accessibility
API in a consistent manner across all browsers.
This is why a complex interactive component may work perfectly using JAWS
and Internet Explorer, but not so well in Firefox or Chrome, or why the
same component may work perfectly using NVDA in Firefox, but not so well
in Internet Explorer or Chrome.
Here are some specifics.
In the Windows OS:
â¢The Accessibility API for Internet Explorer is implemented using MSAA and
UIA.
â¢The Accessibility API for Firefox is implemented using MSAA and
IAccessible2.
â¢The Accessibility API for Chrome is implemented using MSAA and
IAccessible2.
In the Mac OS:
â¢The Accessibility API for Safari is implemented using Ax/uiA.
In the Linux OS:
â¢The Accessibility API is implemented using the Assistive
TechnologyâService Provider Interface (AT-SPI) and IAccessible2.
All of which include a mixture of shared and proprietary properties and
methods that screen readers can tap into.
So what does this mean?
It means that, when programming complex interactive components according
to the ARIA specification, differing levels of accessibility across
various screen readers is unavoidable.
Here are a few examples of this, in one location for simplicity.
Now, all of the interactive components on the above page are specifically
programmed according to the ARIA specification to ensure full compliance,
and have been tested for full keyboard support.
In a perfect world, the keyboard accessibility would combine with the
correct usage of ARIA and provide fully accessible user interface
components for all screen reader users.
Unfortunately, in the world we live in, we can only do the best we can for
as many people as possible instead.
For example, using JAWS 13 and Internet Explorer, you can navigate to the
Calendar tab and press Enter or the Spacebar to activate it, then use Tab
to navigate to the Calendar icon, and press Enter to activate the popup.
The calendar will open and the current date will be highlighted. You can
then use the Left/Up/Right/Down arrow and Home/End keys to navigate the
calendar grid cells, PageUp/PageDown to navigate by month,
Alt+PageUp/PageDown to navigate by year, and press Enter to choose a
particular date.
You can do the same thing using NVDA in Firefox with equal accessibility.
Now, if you try the same using JAWS 13 in Firefox instead, you will notice
that the Virtual Cursor is not disabled when the popup opens as it was
when using Internet Explorer, making it impossible to use the same key
commands to navigate the calendar without first pressing Insert+Z to turn
off the Virtual Cursor. The reason for this, is actually a bug in JAWS,
where the role of âdialogâ is not being honored properly.
This shows an example of unequal support by screen readers within
different browsers.
Similarly, when using JAWS13 in Internet Explorer to navigate and activate
the tabs on the Bootstrap page, you were traversing an ARIA Tab control,
which also includes ARIA standards compliant markup and cross browser
keyboard event handling for keyboard only users.
This works equally well in both Internet Explorer and Firefox using both
JAWS and NVDA.
Now, when you open the same page in Chrome using JAWS 13, then use the
arrow keys to navigate from the top of the page to the bottom, you will
notice that the ARIA Tabs are not properly announced. Instead, they are
broken out onto separate lines, with repeating label text, and sometimes
say âtab tabâ with no label text at all. In contrast, the ARIA Tabs are
announced correctly when using NVDA in Chrome.
When you open the Tree tab in Chrome using either NVDA or JAWS 13 however,
then tab into the ARIA Tree control, and use the Left/Up/Right/Down arrow
keys to navigate and expand branch nodes, you will notice that none of the
branch nodes are announced as expandable, nor what the current state is,
nor what the current level is, even though all of these things are
announced correctly in both Internet Explorer and Firefox. This is
happening because the hand shaking procedure between the browser (Chrome)
and the screen readers (JAWS and NVDA) is not occurring properly, so this
information is not announced as it should be, even though the component is
programmed properly and in full accordance with the ARIA specification.
So, to conclude.
Programming accessible interactive components is not easy, and depending
on the browsers and OSs that are used to test these components during
development, accessibility results will vary between screen readers.
Therefore, the best way to ensure the highest level of accessibility for
the highest percentage of screen reader users, is to program complex
interactive components using the most widely used screen readers to test
this functionality in the Operating Systems where they are most widely
used.
Currently, this is within the Windows OS using JAWS and Internet Explorer,
and using NVDA in Firefox for laptops and desktops. For mobile devices,
the most widely used screen reader is Voiceover in iOS devices.
Lastly, here are a few important notes.
Interactive components should never be specifically programmed to work
within specific AT/browser combinations, such as using ARIA hacks to make
something work in Firefox and JAWS, when doing so results in non-standards
compliant markup and inaccessible functionality elsewhere.
Cross browser scripting should always be used to ensure full keyboard
accessibility without a screen reader running, which will work in all OSs.
When ARIA is used within HTML markup, it should only be used with strict
adherence to the ARIA specification that the component type applies to.
This will ensure that, when browsers that donât currently support such
components are updated according to the ARIA User Agent Specification,
they will automatically start working properly when screen readers tap
into this functionality. In the meantime, the majority of screen reader
users will still be able to use these components accessibly.
http://www.ssbbartgroup.com/blog/how-browsers-interact-with-screen-rea
ders-and-where-aria-fits-in-the-mix/
Posted by Bryan Garaventa on January 2, 2013 in ARIA, Assistive
Technology, JAWS, NVDA
The differing behaviors of screen readers across various browsers are
noticed all the time by screen reader users, and differing levels of ARIA
support are noticed in a similar manner, but the reasons why this happens
arenât commonly understood by the majority of people.
For example, the most widely used screen reader, JAWS, is hard coded to
work best in Internet Explorer. The second most widely used screen reader,
NVDA, is hard coded to work best in Firefox. This includes ARIA support.
 All browsers that support accessibility, include an Accessibility API
that is built into the browser application. This includes Internet
Explorer, Firefox, Chrome, and Safari in the Mac and iOS platforms.
The browserâs Accessibility API exposes public properties and methods that
can be queried by third party applications, like screen readers, to
retrieve information from the Document Object Model (DOM) within the
browser, which is then conveyed to screen reader users. This is like a
hand shaking procedure between the browser and the screen reader.
So, when you hear the word âlinkâ when arrowing down the page for
example,
even though the word âlinkâ is not actually on the page, the screen
reader
is conveying that the role of the current element is that of a link.
This happens, because the browserâs Accessibility API has exposed the role
of the element in one of its public properties or methods, which the
screen reader queries when it renders the page content in the Virtual
Buffer. The screen reader sees that, in the browserâs opinion, the element
is a link, so the screen reader reflects this element type in the Virtual
Buffer.
This is true for all element types.
When I say âin the browserâs opinionâ, I mean this literally, because
it
is possible to manually override what the browserâs Accessibility API
returns for screen readers. This is where ARIA comes in.
So, when ARIA is added to a page, the browser detects the ARIA attribute,
then it updates the information within its Accessibility API to reflect
what the ARIA is supposed to convey.
The screen reader then queries the browserâs Accessibility API as usual,
and renders the content in the Virtual Buffer using this updated
information.
This is why, if you put role=âbuttonâ on a standard link like so:
<a role="button" href="#"> Some Link </a>
the browserâs Accessibility API will convey that this element is a button,
and the screen reader will display the element as a button, which will
appear in the Form Field list in JAWS as though it were a form field, and
can be navigated to using the âbâ and âshift+bâ commands to jump
between
buttons on the page.
Itâs important to understand this part, because ARIA only changes the
information in the browserâs Accessibility API, and does not change the
element in the browser itself. Within the browser, the above element is
still a link, and appears as a link in the DOM, including all native
handlers. The only difference, is that the browserâs Accessibility API
portrays this element as a button for screen readers. Nothing else has
changed.
This is why, if you put role=âbuttonâ on a Span tag, it will appear as a
button for screen reader users, but it will still be a Span tag
regardless.
Here is where the browser differences come in.
All browsers have different Accessibility APIs, which may have different
public properties and methods, and may require different techniques for
accessing the browserâs API and DOM. The same is true for ARIA support
within each browser, since this needs to be added to each Accessibility
API in a consistent manner across all browsers.
This is why a complex interactive component may work perfectly using JAWS
and Internet Explorer, but not so well in Firefox or Chrome, or why the
same component may work perfectly using NVDA in Firefox, but not so well
in Internet Explorer or Chrome.
Here are some specifics.
In the Windows OS:
â¢The Accessibility API for Internet Explorer is implemented using MSAA and
UIA.
â¢The Accessibility API for Firefox is implemented using MSAA and
IAccessible2.
â¢The Accessibility API for Chrome is implemented using MSAA and
IAccessible2.
In the Mac OS:
â¢The Accessibility API for Safari is implemented using Ax/uiA.
In the Linux OS:
â¢The Accessibility API is implemented using the Assistive
TechnologyâService Provider Interface (AT-SPI) and IAccessible2.
All of which include a mixture of shared and proprietary properties and
methods that screen readers can tap into.
So what does this mean?
It means that, when programming complex interactive components according
to the ARIA specification, differing levels of accessibility across
various screen readers is unavoidable.
Here are a few examples of this, in one location for simplicity.
Now, all of the interactive components on the above page are specifically
programmed according to the ARIA specification to ensure full compliance,
and have been tested for full keyboard support.
In a perfect world, the keyboard accessibility would combine with the
correct usage of ARIA and provide fully accessible user interface
components for all screen reader users.
Unfortunately, in the world we live in, we can only do the best we can for
as many people as possible instead.
For example, using JAWS 13 and Internet Explorer, you can navigate to the
Calendar tab and press Enter or the Spacebar to activate it, then use Tab
to navigate to the Calendar icon, and press Enter to activate the popup.
The calendar will open and the current date will be highlighted. You can
then use the Left/Up/Right/Down arrow and Home/End keys to navigate the
calendar grid cells, PageUp/PageDown to navigate by month,
Alt+PageUp/PageDown to navigate by year, and press Enter to choose a
particular date.
You can do the same thing using NVDA in Firefox with equal accessibility.
Now, if you try the same using JAWS 13 in Firefox instead, you will notice
that the Virtual Cursor is not disabled when the popup opens as it was
when using Internet Explorer, making it impossible to use the same key
commands to navigate the calendar without first pressing Insert+Z to turn
off the Virtual Cursor. The reason for this, is actually a bug in JAWS,
where the role of âdialogâ is not being honored properly.
This shows an example of unequal support by screen readers within
different browsers.
Similarly, when using JAWS13 in Internet Explorer to navigate and activate
the tabs on the Bootstrap page, you were traversing an ARIA Tab control,
which also includes ARIA standards compliant markup and cross browser
keyboard event handling for keyboard only users.
This works equally well in both Internet Explorer and Firefox using both
JAWS and NVDA.
Now, when you open the same page in Chrome using JAWS 13, then use the
arrow keys to navigate from the top of the page to the bottom, you will
notice that the ARIA Tabs are not properly announced. Instead, they are
broken out onto separate lines, with repeating label text, and sometimes
say âtab tabâ with no label text at all. In contrast, the ARIA Tabs are
announced correctly when using NVDA in Chrome.
When you open the Tree tab in Chrome using either NVDA or JAWS 13 however,
then tab into the ARIA Tree control, and use the Left/Up/Right/Down arrow
keys to navigate and expand branch nodes, you will notice that none of the
branch nodes are announced as expandable, nor what the current state is,
nor what the current level is, even though all of these things are
announced correctly in both Internet Explorer and Firefox. This is
happening because the hand shaking procedure between the browser (Chrome)
and the screen readers (JAWS and NVDA) is not occurring properly, so this
information is not announced as it should be, even though the component is
programmed properly and in full accordance with the ARIA specification.
So, to conclude.
Programming accessible interactive components is not easy, and depending
on the browsers and OSs that are used to test these components during
development, accessibility results will vary between screen readers.
Therefore, the best way to ensure the highest level of accessibility for
the highest percentage of screen reader users, is to program complex
interactive components using the most widely used screen readers to test
this functionality in the Operating Systems where they are most widely
used.
Currently, this is within the Windows OS using JAWS and Internet Explorer,
and using NVDA in Firefox for laptops and desktops. For mobile devices,
the most widely used screen reader is Voiceover in iOS devices.
Lastly, here are a few important notes.
Interactive components should never be specifically programmed to work
within specific AT/browser combinations, such as using ARIA hacks to make
something work in Firefox and JAWS, when doing so results in non-standards
compliant markup and inaccessible functionality elsewhere.
Cross browser scripting should always be used to ensure full keyboard
accessibility without a screen reader running, which will work in all OSs.
When ARIA is used within HTML markup, it should only be used with strict
adherence to the ARIA specification that the component type applies to.
This will ensure that, when browsers that donât currently support such
components are updated according to the ARIA User Agent Specification,
they will automatically start working properly when screen readers tap
into this functionality. In the meantime, the majority of screen reader
users will still be able to use these components accessibly.
