WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: JAWS and ARIA's application role

for

Number of posts in this thread: 14 (In chronological order)

From: Ney André de Mello Zunino
Date: Wed, Jul 06 2011 7:06AM
Subject: JAWS and ARIA's application role
No previous message | Next message →

Hello.

Has anybody else had problems with JAWS not entering application mode
when the role="application" attribute/value pair is not set on the body
element, but in an inner container? I have a page which should work in
document mode until an ARIA widget receives focus. This ARIA widget is
within a container div with role="application" set. However, keystrokes
continue to be intercepted by the screen reader, instead of being left
to the application. Setting the role on the body element results in the
expected behavior.


DOESN'T WORK

<body>
...
<div role="application">
...ARIA widget...
</div>
...
</body>


WORKS

<body role="application">
...
...ARIA widget...
...
</body>


Thank you in advance,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Donald Evans
Date: Wed, Jul 06 2011 7:12AM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

I have had the same experience as you and will be very interested to see
other comments.

2011/7/6 Ney André de Mello Zunino < = EMAIL ADDRESS REMOVED = >

> Hello.
>
> Has anybody else had problems with JAWS not entering application mode
> when the role="application" attribute/value pair is not set on the body
> element, but in an inner container? I have a page which should work in
> document mode until an ARIA widget receives focus. This ARIA widget is
> within a container div with role="application" set. However, keystrokes
> continue to be intercepted by the screen reader, instead of being left
> to the application. Setting the role on the body element results in the
> expected behavior.
>
>
> DOESN'T WORK
>
> <body>
> ...
> <div role="application">
> ...ARIA widget...
> </div>
> ...
> </body>
>
>
> WORKS
>
> <body role="application">
> ...
> ...ARIA widget...
> ...
> </body>
>
>
> Thank you in advance,
>
> --
> Ney André de Mello Zunino
> Pesquisa e Desenvolvimento
> Softplan/Poligraph
> Sistema da Qualidade Certificado ISO9001:2008
> Fone/Fax: 0xx(48) 3027-8000
> http://www.softplan.com.br/
>

From: Pratik Patel
Date: Wed, Jul 06 2011 10:30AM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

Can you provide information about the browser in which you tested this? With
so many recent changes to browsers, please also provide the version number.
What version of JAWS?

Regards,

Pratik


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Donald Evans
Sent: Wednesday, July 06, 2011 9:08 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] JAWS and ARIA's application role

I have had the same experience as you and will be very interested to see
other comments.

2011/7/6 Ney André de Mello Zunino < = EMAIL ADDRESS REMOVED = >

> Hello.
>
> Has anybody else had problems with JAWS not entering application mode
> when the role="application" attribute/value pair is not set on the body
> element, but in an inner container? I have a page which should work in
> document mode until an ARIA widget receives focus. This ARIA widget is
> within a container div with role="application" set. However, keystrokes
> continue to be intercepted by the screen reader, instead of being left
> to the application. Setting the role on the body element results in the
> expected behavior.
>
>
> DOESN'T WORK
>
> <body>
> ...
> <div role="application">
> ...ARIA widget...
> </div>
> ...
> </body>
>
>
> WORKS
>
> <body role="application">
> ...
> ...ARIA widget...
> ...
> </body>
>
>
> Thank you in advance,
>
> --
> Ney André de Mello Zunino
> Pesquisa e Desenvolvimento
> Softplan/Poligraph
> Sistema da Qualidade Certificado ISO9001:2008
> Fone/Fax: 0xx(48) 3027-8000
> http://www.softplan.com.br/
>

From: Ney André de Mello Zunino
Date: Wed, Jul 06 2011 11:03AM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

On 06/07/2011 13:29, Pratik Patel wrote:

> Can you provide information about the browser in which you tested this? With
> so many recent changes to browsers, please also provide the version number.
> What version of JAWS?

I apologize for not including this fundamental information. Here it is:

Browser: Firefox 5
JAWS: 11.0.1471

During my experimentation with screen readers and ARIA, I have noticed
how fragile and inconsistent the outcome can be depending on the
combination of different types and versions of browser and screen
reader. So far, I believe the best combination I have had was Firefox 4
and JAWS 12. But because our clients are still using JAWS 11, we're
stuck with that.

Regards,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: McKeithan, Thomas
Date: Wed, Jul 06 2011 11:15AM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

From my experience with Jaws v11, there are inconsistent results in terms of behavior within applications. I've found that JAWS12 is much more stable.

Respectfully,
Thomas Lee McKeithan II
Accessibility Program Manager
National Industries for the Blind
1310 Braddock Place
Alexandria, VA 22314
(703)310-0586 Direct
(202)276-6437 Cell
= EMAIL ADDRESS REMOVED =


"Believing is achieving, for if I believe, I can and I will achieve."




-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ney André de Mello Zunino
Sent: Wednesday, July 06, 2011 1:04 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] JAWS and ARIA's application role

On 06/07/2011 13:29, Pratik Patel wrote:

> Can you provide information about the browser in which you tested this? With
> so many recent changes to browsers, please also provide the version number.
> What version of JAWS?

I apologize for not including this fundamental information. Here it is:

Browser: Firefox 5
JAWS: 11.0.1471

During my experimentation with screen readers and ARIA, I have noticed
how fragile and inconsistent the outcome can be depending on the
combination of different types and versions of browser and screen
reader. So far, I believe the best combination I have had was Firefox 4
and JAWS 12. But because our clients are still using JAWS 11, we're
stuck with that.

Regards,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Léonie Watson
Date: Wed, Jul 06 2011 11:57AM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

"Has anybody else had problems with JAWS not entering application mode when
the role="application" attribute/value pair is not set on the body element,
but in an inner container?"

Having auto forms mode turned off has been known to cause a
conflict. Auto forms mode is turned on by default, but people sometimes turn
it off. Jaws effectively flips into forms mode when it encounters
role=application, to allow the keyboard commands to be passed back through.


Léonie.




--
http://tink.co.uk

Email: = EMAIL ADDRESS REMOVED =
Twitter: @LeonieWatson
Skype: Leonie.Watson

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ney André de
Mello Zunino
Sent: 06 July 2011 14:06
To: WebAIM Discussion List
Subject: [WebAIM] JAWS and ARIA's application role

Hello.

Has anybody else had problems with JAWS not entering application mode when
the role="application" attribute/value pair is not set on the body element,
but in an inner container? I have a page which should work in document mode
until an ARIA widget receives focus. This ARIA widget is within a container
div with role="application" set. However, keystrokes continue to be
intercepted by the screen reader, instead of being left to the application.
Setting the role on the body element results in the expected behavior.


DOESN'T WORK

<body>
...
<div role="application">
...ARIA widget...
</div>
...
</body>


WORKS

<body role="application">
...
...ARIA widget...
...
</body>


Thank you in advance,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Tim Harshbarger
Date: Wed, Jul 06 2011 12:39PM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

If I am understanding what you said correctly, you are using JAWS 11 with FF 5? I'm uncertain that combination will work. I think you have to be using JAWS 12 to be using FF 4---which probably means you need to be using at least JAWS 12 to have a chance of it working with FF 5. That could possibly be why you might be having problems with the application role.

When it comes to testing assistive technology (AT) with browsers, it's a good idea to check to see if the version of the AT supports the version of the browser. Depending on how the AT needs to integrate with the browser, changes in versions of both the AT and browser can alter your test results.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ney André de Mello Zunino
Sent: Wednesday, July 06, 2011 12:04 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] JAWS and ARIA's application role

On 06/07/2011 13:29, Pratik Patel wrote:

> Can you provide information about the browser in which you tested this? With
> so many recent changes to browsers, please also provide the version number.
> What version of JAWS?

I apologize for not including this fundamental information. Here it is:

Browser: Firefox 5
JAWS: 11.0.1471

During my experimentation with screen readers and ARIA, I have noticed
how fragile and inconsistent the outcome can be depending on the
combination of different types and versions of browser and screen
reader. So far, I believe the best combination I have had was Firefox 4
and JAWS 12. But because our clients are still using JAWS 11, we're
stuck with that.

Regards,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Ney André de Mello Zunino
Date: Wed, Jul 06 2011 2:36PM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

On 06/07/2011 14:56, Léonie Watson wrote:

> Having auto forms mode turned off has been known to cause a
> conflict. Auto forms mode is turned on by default, but people sometimes turn
> it off. Jaws effectively flips into forms mode when it encounters
> role=application, to allow the keyboard commands to be passed back through.

I have checked via Numpad INSERT + V that the "auto forms mode" was
"on". Is there any other setting I should verify?

Thanks!

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Ney André de Mello Zunino
Date: Wed, Jul 06 2011 2:42PM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

On 06/07/2011 15:41, Tim Harshbarger wrote:

> If I am understanding what you said correctly, you are using JAWS 11 with FF 5? I'm uncertain that combination will work. I think you have to be using JAWS 12 to be using FF 4---which probably means you need to be using at least JAWS 12 to have a chance of it working with FF 5. That could possibly be why you might be having problems with the application role.

I have redone my tests using JAWS 12 and, although there are some subtle
changes, the actual problem of JAWS not entering application mode persists.

I have created a sample page to facilitate the discussion. The HTML, JS
and CSS files are attached.

Regards,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Ney André de Mello Zunino
Date: Wed, Jul 06 2011 2:51PM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

On 06/07/2011 17:41, Ney André de Mello Zunino wrote:

> I have created a sample page to facilitate the discussion. The HTML, JS
> and CSS files are attached.

This might be a problem with my mail user agent, but in case you are
also unable to see the 3 files I attached in my earlier, post, here is a
RAR archive with them. I hope it goes through correctly this time.

Regards,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Ney André de Mello Zunino
Date: Wed, Jul 06 2011 2:57PM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

On 06/07/2011 17:50, Ney André de Mello Zunino wrote:

> This might be a problem with my mail user agent, but in case you are
> also unable to see the 3 files I attached in my earlier, post, here is a
> RAR archive with them. I hope it goes through correctly this time.

I give it up. Here are the contents of the 3 files. Sorry about the noise.

=== BEGIN test.html ===

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<html lang="en-US">

<head>
<meta http-equiv="Content-type" content="text/html;
charset=iso-8859-1">
<title>ARIA - application role test</title>
<link rel="stylesheet" href="test.css" type="text/css">
<script type="text/javascript" src="test.js"></script>
</head>

<body onload="onBodyLoad()">
<h1>ARIA - <a
href="http://www.w3.org/TR/wai-aria/roles#application">application
role</a> test</h1>
<p>
This page is meant to test the behavior of JAWS when dealing
with ARIA's
<a
href="http://www.w3.org/TR/wai-aria/roles#application">application</a>
and <a
href="http://www.w3.org/TR/wai-aria/roles#document">document</a>
roles.
</p>
<p>
The sample menu below is embedded in a container
<code>div</code> with an
<code>role="application"</code> attribute/value pair. Upon
entering that
container, the screen reader should switch to application mode.
</p>
<p>
With Firefox 5, both JAWS 11 and 12 do not give the expected
results. When
focus arrives at the menu widget, keystrokes are not properly
passed onto
the application as they should. Instead, JAWS handles them in
the usual way,
e.g., for left and right arrow keys, it reads out each letter
when those
keystrokes should actually be handled by the widget's
associated script.
</p>
<p>
Simply moving the <code>role="application"</code>
attribute/value pair up
to the <code>body</code> element produces the desired behavior.
</p>
<div role="application">
<ul id="fruits" role="menu" tabindex="0" aria-activedescendant="1">
<li id="1" role="menu-item" class="selectedItem"
tabindex="-1">Apple</li>
<li id="2" role="menu-item" class="item"
tabindex="-1">Orange</li>
<li id="3" role="menu-item" class="item"
tabindex="-1">Guava</li>
<li id="4" role="menu-item" class="item"
tabindex="-1">Banana</li>
</ul>
</div>
</body>

</html>

=== END test.html ===


=== BEGIN test.css ===

body {
margin: 10% 15%;
font-family: sans-serif;
font-size: 100%;
min-width: 25em;
}

ul[role="menu"] {
margin: 0;
border: 2px solid gray;
padding: 5mm;
}

ul[role="menu"] li.item, ul[role="menu"] li.selectedItem {
display: inline;
padding: 2mm;
}

ul[role="menu"] li.selectedItem {
color: white;
background-color: gray;
}

=== END test.css ===


=== BEGIN test.js ===

const DOM_VK_LEFT = 37;
const DOM_VK_RIGHT = 39;
var fruitItemsCount = 0;

function onBodyLoad() {
var fruitsElem = document.getElementById("fruits");
fruitsElem.addEventListener("focus", function(e) {
onFruitsFocus(e); }, false);
fruitsElem.addEventListener("keydown", function(e) {
onFruitsKeyDown(e); }, false);
fruitItemsCount = fruitsElem.getElementsByTagName("li").length;
}

function onFruitsFocus(event) {
var elem = event.target;
var activeId = elem.getAttribute("aria-activedescendant");
var active = document.getElementById(activeId);
active.focus();
}

function onFruitsKeyDown(event) {
var elem = event.currentTarget;
var active = elem.getAttribute("aria-activedescendant");
var fruitNum = active;
event.preventDefault();
if (event.keyCode === DOM_VK_RIGHT) {
++fruitNum;
if (fruitNum > fruitItemsCount) {
fruitNum = 1;
}
} else if (event.keyCode === DOM_VK_LEFT) {
--fruitNum;
if (fruitNum < 1) {
fruitNum = fruitItemsCount;
}
}
if (fruitNum != active) {
var currItem = document.getElementById(fruitNum);
document.getElementById(active).className = "item";
currItem.className = "selectedItem";
elem.setAttribute("aria-activedescendant", fruitNum);
currItem.focus();
}
}

=== END test.js ===


Cheers!

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Léonie Watson
Date: Thu, Jul 07 2011 10:36AM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

"I have created a sample page to facilitate the discussion. The HTML, JS and
CSS files are attached."

Only the HTML file made it through I think. Your archive didn't come
through with your second email either I'm afraid. Could you post your
example live somewhere perhaps?

Léonie.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ney André de
Mello Zunino
Sent: 06 July 2011 21:41
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] JAWS and ARIA's application role

On 06/07/2011 15:41, Tim Harshbarger wrote:

> If I am understanding what you said correctly, you are using JAWS 11 with
FF 5? I'm uncertain that combination will work. I think you have to be
using JAWS 12 to be using FF 4---which probably means you need to be using
at least JAWS 12 to have a chance of it working with FF 5. That could
possibly be why you might be having problems with the application role.

I have redone my tests using JAWS 12 and, although there are some subtle
changes, the actual problem of JAWS not entering application mode persists.

I have created a sample page to facilitate the discussion. The HTML, JS and
CSS files are attached.

Regards,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Ney André de Mello Zunino
Date: Thu, Jul 07 2011 11:18AM
Subject: Re: JAWS and ARIA's application role
← Previous message | Next message →

On 07/07/2011 13:34, Léonie Watson wrote:

> Only the HTML file made it through I think. Your archive didn't come
> through with your second email either I'm afraid. Could you post your
> example live somewhere perhaps?

Yes, the CSS and JS extensions were not taken kindly by some filter at
the mail server, which is why I made a third attempt, putting the
contents of the files inline. If that hasn't made it through as well, I
have no other option that using some online service. Oh, I've just
thought of pastebin. I'm gonna post the files there... Just a moment...

Here it is:

HTML: http://pastebin.com/jqWarsKC
CSS: http://pastebin.com/d2JAkuHx
JS: http://pastebin.com/uBksPRpT

Remember to name the files 'test.html', 'test.css' and 'test.js',
respectivelly.

Regards,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/

From: Ney André de Mello Zunino
Date: Mon, Jul 18 2011 5:27AM
Subject: Re: JAWS and ARIA's application role
← Previous message | No next message

On 06/07/2011 10:05, Ney André de Mello Zunino wrote:

> Has anybody else had problems with JAWS not entering application mode
> when the role="application" attribute/value pair is not set on the body
> element, but in an inner container? I have a page which should work in
> document mode until an ARIA widget receives focus. This ARIA widget is
> within a container div with role="application" set. However, keystrokes
> continue to be intercepted by the screen reader, instead of being left
> to the application. Setting the role on the body element results in the
> expected behavior.

On 07/07/2011 14:19, Ney André de Mello Zunino wrote:

> HTML: http://pastebin.com/jqWarsKC
> CSS: http://pastebin.com/d2JAkuHx
> JS: http://pastebin.com/uBksPRpT
>
> Remember to name the files 'test.html', 'test.css' and 'test.js',
> respectivelly.

Hello.

Has anybody had a chance to try out the test files? I haven't still been
able to figure out the application="role" JAWS issue mentioned above.

Thank you,

--
Ney André de Mello Zunino
Pesquisa e Desenvolvimento
Softplan/Poligraph
Sistema da Qualidade Certificado ISO9001:2008
Fone/Fax: 0xx(48) 3027-8000
http://www.softplan.com.br/