JAWS and focus mode

[kahun...@gmail.com]

Anyone know if JAWS has something similar to NVDA's focus mode? How do
I test a dynamic aria-enabled widget with jaws. Does the space bar get
you into this mode in JAWS? Is it called "focus mode" in Jaws?

[alexander farkas]

Yes, there is something similiar. It´s called JAWS PC Cursor Mode. You
can turn this mode on/off with Insert + Z. (http://juicystudio.com/
article/making-ajax-work-with-screen-readers.php). But you shouldn´t
use this, to test your widget.

If you develop an aria-enabled widget, you should test it in the
normal mode (virtual cursor mode). The screenreader has to change the
mode automatically, (not the user). With other words: If you are using
a proper Aria Structure for a widget, wich needs special keyinputs,
the screenreader will turn into a mode, that won´t intercept the
needed keyinputs anymore. If your widget don´t work, your structure or
behaviour could be wrong. You can post it here. A possible workaround
would be the use of the role application, wich also turns the
screenreader in a more scriptable mode (but this is often a bad and
overused workaround).

On Oct 5, 9:55 pm, "kahunaco...@gmail.com" <kahunaco...@gmail.com>
wrote:

[Aaron]

I see.
On this page:
http://preview.ncbi.nlm.nih.gov/guide/

on the top there is an aria-enabled navigation menu. It works pretty
well in NVDA .06p32 with Firefox 3.5x

Although I see that I have to click the space bar to go into focus
mode.

In IE8, Jaws 10, I can only get the thing to navigate property using
the keyboard if I click INSERT+Z

What am I doing wrong?

[Aaron]

As far as I can tell the menu behaves erratically with screen readers,
but is find with keyboard navigation when the screen reader is turned
off. It has to do with the screen reader not automatically changing to
the right mode. Unless I can figure this out, I think the best thing
to do is forget the role attribute and ARIA, forget the tabindex
suggestions and make so that the user can just navigate it like a list
of links. Unless of course someone can tell me what I am missing...

[James Teh]

On 8/10/2009 1:45 AM, Aaron wrote:
> As far as I can tell the menu behaves erratically with screen readers,
> but is find with keyboard navigation when the screen reader is turned
> off. It has to do with the screen reader not automatically changing to
> the right mode.

The screen reader should only change modes automatically if appropriate
when the focus changes. For example, using NVDA, if you tab to the menu
bar, NVDA will automatically switch to focus mode. You can also activate
focus mode by pressing enter on one of the menu items while in browse mode.

For the most part, this page seems to work fine for me in NVDA. I am
noticing it occasionally switches to browse mode when it shouldn't while
navigating the menus. I think this is because the page occasionally sets
focus to a menu instead of setting focus to a menu item. I can't quite
work out what causes this. NVDA should probably enable focus mode for
"menu" nodes anyway (I'll look into this), but menus probably shouldn't
ever gain focus; rather, the active menu item should.

>> On this page:http://preview.ncbi.nlm.nih.gov/guide/
>> on the top there is an aria-enabled navigation menu. It works pretty
>> well in NVDA .06p32 with Firefox 3.5x
>> Although I see that I have to click the space bar to go into focus
>> mode.

This is necessary. Otherwise, every time you moved up to the top of the
document, you would get "stuck" in the menu, even if you didn't intend
to interact with it.

Btw, NVDA 2009.1beta1 has now been released. I recommend that you try it
with that.

Jamie

--
James Teh
Email/MSN Messenger/Jabber: ja...@jantrid.net
Web site: http://www.jantrid.net/

[James Teh]

On 8/10/2009 11:22 AM, James Teh wrote:
> For the most part, this page seems to work fine for me in NVDA. I am
> noticing it occasionally switches to browse mode when it shouldn't while
> navigating the menus. I think this is because the page occasionally sets
> focus to a menu instead of setting focus to a menu item. I can't quite
> work out what causes this. NVDA should probably enable focus mode for
> "menu" nodes anyway

Actually, I just double checked the code and NVDA does already treat
focusable menus as candidates for focus mode. However, the menu that
gets focus does not have the focusable state, so NVDA doesn't treat it
that way. Even so, the menu shouldn't get focus in the first place.

[Aaron]

Thanks for your input. I will look into this.

NVDA is great and all, but a lot of people use JAWS. I find it not
usable with JAWS. Do you have JAWS or does someone else have JAWS 10
who can check it?

Thanks

[kahun...@gmail.com]

James, I don't see what you mean about menus getting focus. I added
this rule to firebug:

*:focus {
border: 1px solid red;
}

and confirmed that only the <a> nodes are getting focus. I checked my
code too; I only put focus on <a> nodes.

So, I am wondering if I am misunderstanding what you are saying.

Thanks.

[James Teh]

On 15/10/2009 7:15 AM, kahun...@gmail.com wrote:
> James, I don't see what you mean about menus getting focus. I added

> this rule to firebug:...

> and confirmed that only the<a> nodes are getting focus. I checked my
> code too; I only put focus on<a> nodes.
> So, I am wondering if I am misunderstanding what you are saying.

No, you aren't misunderstanding. I was definitely seeing focus events on
menus. Perhaps this is an issue with Mozilla a11y? We'll need to run
accProbe or the like to capture accessible events to be sure NVDA isn't
doing something strange, though I can't see why it would be.

[kahun...@gmail.com]

Ok. If someone can follow through with this that would be great. I am
trying very hard to use ARIA and make this, and other widgets on
NCBI's site, use ARIA and aria-related best-practices (like tabindex
control etc). However I am having a hard time making it work as
expected. If it's possible to do I will do it, but right now it seems
worse than just not using ARIA and letting people just tab though the
nested list.

This menu is (or shortly will be) on a site (pubmed) that gets *a lot*
of visibility, and I would hate to inconvenience anyone. As it stands
now most sighted people would probably expect to tab through the menu,
and wouldn't think of using the arrow keys. It would be ok to
inconvenience those people, if I knew that the people that are using
screenreaders could easily navigate the widget using the keyboard, but
I am having trouble getting JAWS and NVDA to to stick in "focus mode".
The result is very inconstent. Sometimes using the arrow keys moves to
the next item, or opens up a submenu, other times pressing the arrow
key just reads the next letter. If that's the case nobody will be
happy, and I will be forced to give up on ARIA for now.

Thanks for any help that anyone can provide.
-Aaron

On Oct 14, 5:54 pm, James Teh <ja...@jantrid.net> wrote:
> On 15/10/2009 7:15 AM, kahunaco...@gmail.com wrote:> James, I don't see what you mean about menus getting focus. I added

[Todd Kloots]

Aaron -

Regarding sighted people's expectations: When you think about it,
having fewer items in a menu's tab index is better for sighted users
as well. Anyone who is using the tab key to navigate between sections
of a page will be able to move much faster if the tabindex of widgets
is managed per the ARIA spec. Think about it: if every item in your
menu is in the default tab flow it requires the user to have to move
through the entire menu when using the tab key to navigate. That's
great if you are actually interested in the menu. But if you are just
trying to navigate around or past the menu it is quite painful. :)
However, if only one of the menu's items is in the default tab flow,
it ensures keyboard access for those interested in navigating to the
menu, as well as an easy means of navigating past the menu. It is a
win-win for all users--something that improves the user experience and
the user's expectations. Additionally, this pattern is not unique to
the ARIA specification. This is a well establish pattern used on the
desktop for a long while. Try using the tab key to navigate on the
desktop and you will see what I am talking about.

Regarding your concerns about JAWS and NVDA staying in "focus mode":
Focus mode isn't the default mode for screen readers. It is my
understanding that users of screen readers know when it is best to
toggle the screen reader into and out of focus mode. So, I wouldn't
worry about that. Additionally, I believe that some screen readers
are working on automatically switching to focus mode when the user
moves to an ARIA-enabled widget, so you might be experiencing that
behavior unknowingly.

If you think that your menu implementation is causing screen readers
to switch modes erratically, can you provide a URL so that some folks
in the group can test your implementation? Otherwise, it is hard to
help. :)

- Todd

[kahun...@gmail.com]

Hi Todd. I totally agree with you. It's just that I keep finding the
implementation of my menu switching back and forth between focus modes
and normal modes without me changing it manually.

Here is the menu in production:
Anyone who wants to check it out in a screenreader please do so, and
let me know if I've done anything badly.

Thanks. Here's the url:
http://preview.ncbi.nlm.nih.gov/pubmed/

The menu is in the header and contains the NCBI image, some
accessibility links and the "Resources" and "Howto" items.

[kahun...@gmail.com]

Has anyone been able to check this out in production? Anyone able to
address my concerns about screenreaders not properly switching or
staying in the proper mode for reading the widget?

On Oct 15, 7:53 pm, "kahunaco...@gmail.com" <kahunaco...@gmail.com>
wrote:

[Maraikayar Prem Nawaz]

On key down, the page is getting scrolled . Can u check if the preventDefault is called properly on keydown and keyups?

[James Teh]

On 16/10/2009 9:53 AM, kahun...@gmail.com wrote:
> Hi Todd. I totally agree with you. It's just that I keep finding the
> implementation of my menu switching back and forth between focus modes
> and normal modes without me changing it manually.

> http://preview.ncbi.nlm.nih.gov/pubmed/

Okay. I did a bit of further investigation on this. As I noted, the
problem relates to the menu seeming to get focus in NVDA, but I
discovered that it isn't actually a focus event. Rather, it is a
menuPopupStart event, which NVDA treats as a focus event under certain
circumstances.

When some of the menu items in your implementation get focus, a
menuPopupStart event is sometimes fired on the menu itself, as if the
menu has already been activated. This event should only be fired once
the menu is actually opened. Observe the following log from accprobe:
> time = 17:29:12:955 type = EVENT_OBJECT_FOCUS name = NCBI Logo role = menuItem state = [focusable, focused, defunct, linked] miscData =
> time = 17:29:15:529 type = EVENT_SYSTEM_MENUPOPUPSTART name = null role = menuPopup state = [selectable] miscData =
> time = 17:29:15:509 type = EVENT_OBJECT_FOCUS name = Resources role = menuItem state = [focusable, focused, defunct, hasPopup, linked] miscData =
> time = 17:29:17:312 type = EVENT_SYSTEM_MENUPOPUPEND name = null role = document state = [normal, invalidEntry] miscData =
> time = 17:29:17:342 type = EVENT_OBJECT_FOCUS name = NCBI Logo role = menuItem state = [focusable, focused, defunct, linked] miscData =
> time = 17:29:18:674 type = EVENT_OBJECT_FOCUS name = Resources role = menuItem state = [focusable, focused, defunct, hasPopup, linked] miscData =
> time = 17:29:18:704 type = EVENT_SYSTEM_MENUPOPUPSTART name = null role = menuPopup state = [selectable] miscData =

I'm not sure how this translates as far as ARIA is concerned (i.e. what
causes the menuPopupStart event to be fired); someone else will need to
answer that. I can tell you that this extraneous event is the reason
that NVDA is sometimes switching out of focus mode when it shouldn't. I
can't speak for any other screen reader.

[kahun...@gmail.com]

I'm not sure I can stop that from occuring. At least I have not
figured out a way how. YUI's scrolls too. If someone can give me a
hint about how to prevent scrolling, I'd appreciate it.

On Oct 23, 3:00 am, Maraikayar Prem Nawaz <mpnk...@gmail.com> wrote:
> On key down, the page is getting scrolled . Can u check if the
> preventDefault is called properly on keydown and keyups?
>

> On Thu, Oct 22, 2009 at 8:42 PM, kahunaco...@gmail.com <

[kahun...@gmail.com]

Any update on this? I am still stuck with Screenreaders switching back
and forth between regular and focus mode....

On Oct 23, 12:03 pm, "kahunaco...@gmail.com" <kahunaco...@gmail.com>
wrote:

> I'm not sure I can stop that from occuring. At least I have not

> figured out a wAny uoday how. YUI's scrolls too. If someone can give me a

[James Teh]

On 23/11/2009 12:16 AM, kahun...@gmail.com wrote:
> Any update on this? I am still stuck with Screenreaders switching back
> and forth between regular and focus mode....

I explained why this is breaking NVDA in my previous message (i.e.
menuPopupStart events). I can't explain what part of the code is causing
this; someone with more understanding of how ARIA menus are mapped to
platform a11y APIs by Firefox will need to analyse this.

[Rich Schwerdtfeger]

I am not sure why a menu's receiving focus is causing a switch out of focus mode. Firefox should be firing a WM_MENUSTART and a WM_MENUEND event respectively when menus open and close. This was put in a long way back when support was added for Window-Eyes which triggerred off of that. Is the problem that the focus is not being set back to the menuitem that launched the popup after the menu goes away?

Web site: http://www.jantrid.net/

--

You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To post to this group, send email to free...@googlegroups.com.
To unsubscribe from this group, send email to free-aria+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/free-aria?hl=.

--
Rich Schwerdtfeger

[David Bolter]

Jamie,

I just took a quick look at the menus on this site. When you move among
the menu-items their sub-menus automatically pop up. Could that be
throwing NVDA out of focus interaction mode?

cheers,
David

[James Teh]

On 23/11/2009 10:34 PM, Rich Schwerdtfeger wrote:
> I am not sure why a menu's receiving focus is causing a switch out of
> focus mode. Firefox should be firing a WM_MENUSTART and a WM_MENUEND
> event respectively when menus open and close.

As I noted in my original reply:
http://groups.google.com/group/free-aria/msg/a0fa1139a425cc5b
Firefox is firing menuStart events when the parent menu item gains
focus, even before the sub-menu is actually opened. This is unique to
this particular test case (or perhaps unique to ARIA menus, although I
don't think YUI suffers from this). I provided an accProbe log in said
email.

[James Teh]

On 24/11/2009 12:03 AM, David Bolter wrote:
> I just took a quick look at the menus on this site. When you move among
> the menu-items their sub-menus automatically pop up. Could that be
> throwing NVDA out of focus interaction mode?

When you say they pop up when you move among them, do you mean even when
moving with the keyboard? If so, that would explain the menuPopupStart
events. The menus really shouldn't pop up automatically, and if they do,
focus should be set to the menu itself or an item inside that menu.
Having menus pop up automatically is non-standard for keyboard
interaction and would make life extremely difficult for keyboard users.

[kahun...@gmail.com]

Thanks for the input guys. The menu is now in production at:http://
www.ncbi.nlm.nih.gov/

> I just took a quick look at the menus on this site. When you move among
> the menu-items their sub-menus automatically pop up.

No, the submenus are not popped up automatically when you navigate
with the keyboard onto a parent menu. Are they popping up for anyone
else when using the keyboard?

I seem to remember having a similar problem with the YUI menus. I
really appreciate everyone looking into this for me. This is a great
group.

Any other ideas why the screen readers are switching modes?

[kahun...@gmail.com]

Thanks for the input guys. The menu is now in production at:http://
www.ncbi.nlm.nih.gov/

> I just took a quick look at the menus on this site. When you move among
> the menu-items their sub-menus automatically pop up.

[Todd Kloots]

You've got some usability problems:

1) You need to prevent the browser from scrolling as the user uses the
up and down arrow keys to move focus through the items in the menu.

2) When the user presses the Esc key to hide the Menu, focus needs to
be sent back to the menuitem in the menubar that initially launched
the popup menu.

- Todd

> --
>
> You received this message because you are subscribed to the Google
> Groups "Free ARIA Community" group.
> To post to this group, send email to free...@googlegroups.com.
> To unsubscribe from this group, send email to free-aria+...@googlegroups.com
> .

> For more options, visit this group at http://groups.google.com/group/free-aria?hl=en
> .
>
>

[kahun...@gmail.com]

Thanks Todd. I had quickly tried to fix the scrolling problem by doing
preventDefault, but was unsuccessful. I will continue working on this.

I will address 2).

BTW, any idea why the screen readers are switching modes? Previously
someone mentioned it is because submenus are opening automatically
when navigating with arrow keys, but that is not the case.

On Dec 1, 1:34 pm, Todd Kloots <klo...@yahoo-inc.com> wrote:
> You've got some usability problems:
>
> 1) You need to prevent the browser from scrolling as the user uses the  
> up and down arrow keys to move focus through the items in the menu.
>
> 2) When the user presses the Esc key to hide the Menu, focus needs to  
> be sent back to the menuitem in the menubar that initially launched  
> the popup menu.
>
> - Todd
>

[kahun...@gmail.com]

Thanks Todd. I had quickly tried to fix the scrolling problem by doing
preventDefault, but was unsuccessful. I will continue working on this.

I will address 2).

BTW, any idea why the screen readers are switching modes? Previously
someone mentioned it is because submenus are opening automatically
when navigating with arrow keys, but that is not the case.

On Dec 1, 1:34 pm, Todd Kloots <klo...@yahoo-inc.com> wrote:
> You've got some usability problems:
>
> 1) You need to prevent the browser from scrolling as the user uses the  
> up and down arrow keys to move focus through the items in the menu.
>
> 2) When the user presses the Esc key to hide the Menu, focus needs to  
> be sent back to the menuitem in the menubar that initially launched  
> the popup menu.
>
> - Todd
>

[James Teh]

On 3/12/2009 9:02 AM, kahun...@gmail.com wrote:
> BTW, any idea why the screen readers are switching modes? Previously
> someone mentioned it is because submenus are opening automatically
> when navigating with arrow keys, but that is not the case.

We're certainly getting events which indicate that Firefox accessibility
thinks they're opening. This is why NVDA is switching modes
sporadically. Unfortunately, I can't tell you any more than that.

[kahun...@gmail.com]

I see the same problem with Todd's YUI menubar, at least on my machine
with my version of NVDA.

When I focus on the file menu item in
http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html

NVDA goes to focus mode. That's good. When I use my arrow key to go
down to the first submenu item, NVDA switches to browse mode and I
must manually go into focus mode to operate the menu with the
keyboard. Anybody else experience this, or just me?


On Dec 2, 6:05 pm, James Teh <ja...@jantrid.net> wrote:
> On 3/12/2009 9:02 AM, kahunaco...@gmail.com wrote:> BTW, any idea why the screen readers are switching modes? Previously

[kahun...@gmail.com]

I see the same problem with Todd's YUI menubar, at least on my machine
with my version of NVDA.

When I focus on the file menu item in
http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html

NVDA goes to focus mode. That's good. When I use my arrow key to go
down to the first submenu item, NVDA switches to browse mode and I
must manually go into focus mode to operate the menu with the
keyboard. Anybody else experience this, or just me?

On Dec 2, 6:05 pm, James Teh <ja...@jantrid.net> wrote:
> On 3/12/2009 9:02 AM, kahunaco...@gmail.com wrote:> BTW, any idea why the screen readers are switching modes? Previously

[kahun...@gmail.com]

I see the same problem with Todd's YUI menubar, at least on my machine
with my version of NVDA.

When I focus on the file menu item in
http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html

NVDA goes to focus mode. That's good. When I use my arrow key to go
down to the first submenu item, NVDA switches to browse mode and I
must manually go into focus mode to operate the menu with the
keyboard. Anybody else experience this, or just me?

On Dec 2, 6:05 pm, James Teh <ja...@jantrid.net> wrote:
> On 3/12/2009 9:02 AM, kahunaco...@gmail.com wrote:> BTW, any idea why the screen readers are switching modes? Previously

[kahun...@gmail.com]

Does anyone else have the problem I stated above in YUI's menubar too?

On Dec 3, 10:58 am, "kahunaco...@gmail.com" <kahunaco...@gmail.com>
wrote:

> I see the same problem with Todd's YUI menubar, at least on my machine
> with my version of NVDA.
>

> When I focus on the file menu item inhttp://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html

[kahun...@gmail.com]

I upgraded NVDA to:
2009.1

Now my menu widget at:
http://www.ncbi.nlm.nih.gov/

Also, YUI's Menubar does not go in and out of focus mode either.
Great.

JAWS 10 also stays in the right mode, but of course it doesn't take
advantage of a lot of the ARIA like NVDA does.

Works much better. NVDA does not go in and out of focus mode anymore.
I did no

On Dec 8, 11:32 am, "kahunaco...@gmail.com" <kahunaco...@gmail.com>
wrote: