Fw: [free-aria] Is auto focus triggering an NVDA bug or intended functionality?

[Bryan Garaventa]

That was the wrong test url, sorry about that, this is the modified ARIA tab
grouping:
http://whatsock.com/test/aria_tabs_menu_modules/demo.htm

----- Original Message -----
From: "Bryan Garaventa" <bryan.g...@whatsock.com>
To: <free...@googlegroups.com>
Sent: Thursday, October 18, 2012 8:40 AM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?


> This functionality goes deeper than tabs though.
>
> How is it possible, for instance, to read which ARIA radio buttons are
> available without invoking them?
>
> I understand that this works differently for Voiceover on the Mac and iOS
> platforms, which is possible to code for, annoying though it is.
>
> But NVDA runs in the Windows environment, and it should be possible to
> read data without invoking it automatically.
>
> Regarding the ARIA tabs, according to the docs at
> http://www.w3.org/TR/2011/CR-wai-aria-20110118/roles#tab
> It does specify that tabs should automatically be invoked when a tab
> receives focus.
>
> So if you disable the auto selection functionality for an ARIA tab, like
> I've done at the following test page
> http://whatsock.com/modules/aria_tabs_menu_modules/demo.htm
> Where you can tab to the tablist, set Forms Mode or equivalent, then use
> the arrow keys to focus to different tabs without invoking them, it
> actually introduces an accessibility issue in JAWS.
>
> After you focus to a tab, then exit Forms Mode, it says the focused tab is
> selected, even when it isn't.
>
> I know it can be said that this is a JAWS bug, but according to the ARIA
> spec, this actually is the correct behavior for an ARIA tab grouping.
>
> So who is correct? NVDA or JAWS?
>
>
> ----- Original Message -----
> From: "Marco Zehe" <marco...@googlemail.com>
> To: <free...@googlegroups.com>
> Sent: Thursday, October 18, 2012 1:51 AM
> Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
> functionality?
>
>
> Hi Jamie and Bryan,
>
> FWIW, in Mac desktop apps, one must activate tabs explicitly by pressing
> Space or using the according VoiceOver command. Simply setting keyboard
> focus to a tab doesn't switch it automatically.
>
> Early in the ARIA days, I even learned that, for several reasons, it is
> highly recommended to not load a new tab panel on mere focus, but to wait
> for a true selection instead, for the very reason that simply moving the
> focus across tabs may generate unnecessary queries to the server. With 5
> tabs, that could become quite some traffic, esp over mobile networks.
>
> I do not know if this has also made it into the authoring guidelines or
> other usability interaction recommendations. But it makes a lot of sense.
>
> Marco
>
> On Oct 18, 2012, at 10:45 AM, James Teh <ja...@nvaccess.org> wrote:
>
>> Hi Bryan,
>>
>> The reason for moving the focus is that it allows the user to interact
>> with objects using normal browser commands. For example, if a user
>> focuses on a link, they can press the Applications key to open the
>> browser context menu for that link or control+enter to open it in a new
>> tab. If we didn't move focus, this wouldn't be possible without
>> intercepting every possible browser command that operates on the focus.
>> It's true that some other screen readers take this approach and do suffer
>> from this disadvantage.
>>
>> It's worth noting that I think you'll see the same issue with VoiceOver
>> on the Mac, since the VoiceOver cursor moves the focus by default. I
>> can't test this myself, though, so I'm not certain.
>>
>> Yahoo! work around this issue by requiring users to press enter to
>> activate a tab, rather than just activating it on focus. This is
>> different to tab controls in most desktop applications, but I've seen
>> desktop applications which take this approach as well.
>>
>> One way we could work around this is to not present individual tabs in
>> browse mode and instead only present the tab control. However, I suspect
>> this would annoy users, since it makes navigation more tedious.
>>
>> Jamie
>>
>> On 18/10/2012 5:37 PM, Bryan Garaventa wrote:
>>> I noticed this the other day using NVDA, but I can't tell if this is
>>> supposed to be a feature, or if it's a bug, which is why I'm asking here
>>> for opinions.
>>> When you use the up/down arrow keys to browse the content of a page,
>>> NVDA automatically triggers the focus handler on whatever it comes
>>> across.
>>> This sounds sort of innocuous, but it means that you can't actually
>>> browse content objectively without changing the page unintentionally.
>>> The behavior is quite clear if you go to the ARIA Tabs page at
>>> http://whatsock.com/modules/aria_tabs_menu_modules/demo.htm
>>> using Firefox.
>>> When you press 'h' to jump to the ARIA Tabs heading, then simply press
>>> the downarrow to navigate down the page, you can see that NVDA is
>>> activating every tab it announces, so it's not possible to read the
>>> content without activating the tab unintentionally.
>>> I'm using NVDA2012.3 Beta1 and the latest version of Firefox.
>>> This seems like a bug to me, but if there is a reason for this, please
>>> let me know.
>>>
>>> --
>>> 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.
>>
>> --
>> James Teh
>> Director, NV Access Limited
>> Email: ja...@nvaccess.org
>> Web site: http://www.nvaccess.org/
>> Phone: +61 7 5667 8372
>>
>> --
>> 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.
>>
>
> --
> 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.
>

[David Ward]

Not sure what your trying to do, an I'm a bit swamped this morning so I can't read your post in detail. But here's a site I ran across yesterday when looking for tabindex feature which controls the sequence of elements read on page. But here's a site talking abotu the w3c tab feature
http://www.accessibleculture.org/articles/2010/08/aria-tabs/

As far as reading elements without actually focusing on them, if I understand correctly, its a bit counter intutive but I know that under certain circumstances it does happen in iOS. I have an app with HTML Live areas and when the AJAX field is updated (this case buttons) VoiceOver will read all the buttons out without you focus being on them.

[Bryan Garaventa]

Understood, thanks.

 

Actually I agree that in the case of iOS, tabs should be activated when explicitly tapped.

 

This is already part of the script, so this functionality already occurs in both the iPhone/iPad.

 

It was the difference in event triggering between NVDA and JAWS that I was referring to, not how tabs should be handled. Though, I've seen many examples of how ARIA Tabs specifically are being miss-used across the web lately, and it's frustrating because they don't work properly in any screen reader as a result.

 

--

You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.

To view this discussion on the web visit https://groups.google.com/d/msg/free-aria/-/3mK0MYBMr-kJ.