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.
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.
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.
> 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-aria@googlegroups.com.
> To unsubscribe from this group, send email to
> free-aria+unsubscribe@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
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:
> 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-aria@googlegroups.com.
>> To unsubscribe from this group, send email to
>> free-aria+unsubscribe@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-aria@googlegroups.com.
> To unsubscribe from this group, send email to free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/free-aria?hl=en.
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.
----- Original Message ----- From: "Marco Zehe" <marco.z...@googlemail.com>
To: <free-aria@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-aria@googlegroups.com.
>> To unsubscribe from this group, send email to
>> free-aria+unsubscribe@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-aria@googlegroups.com.
> To unsubscribe from this group, send email to > free-aria+unsubscribe@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-aria@googlegroups.com.
To unsubscribe from this group, send email to free-aria+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/free-aria?hl=en.
Browser and platform radio buttons don't get selected when they take focus, so invoking them doesn't change them. You have to select them, either by activating them or using the keyboard while they're focused. Of course, what happens for ARIA radio buttons depends on how they're implemented.
I'd argue the same should be done for ARIA radio buttons and tabs. That is, their onClick handler selects them and they can be selected using the keyboard (e.g. using the arrow keys) when focused.
> 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.z...@googlemail.com>
> To: <free-aria@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-aria@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> free-aria+unsubscribe@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-aria@googlegroups.com.
>> To unsubscribe from this group, send email to
>> free-aria+unsubscribe@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
Arrowing down the page in NVDA won't trigger anything, but Return will. So too will tabbing to the tablist and using the arrow keys, which will automatically trigger the focused tab accordingly.
ARIA Tabs still appear to be a bit buggy in NVDA, where when browsing down the page using the arrow keys, the currently selected tab is not conveyed in Firefox, and ARIA Tabs in Chrome are very bad using both JAWS and NVDA at this point.
I agree with Marco, that when complex AJAX is used, the server hit undermines performance quite badly when focus is used as the triggering factor.
Nevertheless, if people do make it a habit to deliberately not create ARIA widgets according to spec, they won't work reliably across various ATs. I just proved this with the ARIA Tabs, where, if it is programmed according to spec, it works equally well for both NVDA and JAWS in supporting browsers. Yet, if it's not programmed according to spec such as requiring a Return keypress to activate an ARIA Tab, it breaks functionality in JAWS.
In cases where advanced AJAX is used, I've found that it's much more reliable to use offscreen text and standard active elements, which are cross platform and cross browser compatible across all ATs.
Initially I programmed the left navigation tabs at WhatSock.com to use ARIA Tabs, but found that the behavior across various screen readers and the server hit lag when the arrow keys were used, was prohibitive. So I converted them into ARIA Toggles instead, which works well for the same functionality, even though visually they are page tabs.
I don't know what the right answer is regarding auto focus triggering. I do find it unfortunate that we now have to program accessible widgets using two separate event triggering models, which will make it more difficult to program accessible complex interactive controls that work across all ATs equally.
----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
To: <free-aria@googlegroups.com>
Sent: Thursday, October 18, 2012 5:19 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?
> Browser and platform radio buttons don't get selected when they take > focus, so invoking them doesn't change them. You have to select them, > either by activating them or using the keyboard while they're focused. Of > course, what happens for ARIA radio buttons depends on how they're > implemented.
> I'd argue the same should be done for ARIA radio buttons and tabs. That > is, their onClick handler selects them and they can be selected using the > keyboard (e.g. using the arrow keys) when focused.
> Jamie
> On 19/10/2012 1:40 AM, Bryan Garaventa wrote:
>> 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.
>> 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.z...@googlemail.com>
>> To: <free-aria@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-aria@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> free-aria+unsubscribe@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-aria@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> free-aria+unsubscribe@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-aria@googlegroups.com.
> To unsubscribe from this group, send email to > free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/free-aria?hl=en.
> Arrowing down the page in NVDA won't trigger anything, but Return will. So too will tabbing to the tablist and using the arrow keys, which will automatically trigger the focused tab accordingly.
> ARIA Tabs still appear to be a bit buggy in NVDA, where when browsing down the page using the arrow keys, the currently selected tab is not conveyed in Firefox, and ARIA Tabs in Chrome are very bad using both JAWS and NVDA at this point.
> I agree with Marco, that when complex AJAX is used, the server hit undermines performance quite badly when focus is used as the triggering factor.
> Nevertheless, if people do make it a habit to deliberately not create ARIA widgets according to spec, they won't work reliably across various ATs. I just proved this with the ARIA Tabs, where, if it is programmed according to spec, it works equally well for both NVDA and JAWS in supporting browsers. Yet, if it's not programmed according to spec such as requiring a Return keypress to activate an ARIA Tab, it breaks functionality in JAWS.
> In cases where advanced AJAX is used, I've found that it's much more reliable to use offscreen text and standard active elements, which are cross platform and cross browser compatible across all ATs.
> Initially I programmed the left navigation tabs at WhatSock.com to use ARIA Tabs, but found that the behavior across various screen readers and the server hit lag when the arrow keys were used, was prohibitive. So I converted them into ARIA Toggles instead, which works well for the same functionality, even though visually they are page tabs.
> I don't know what the right answer is regarding auto focus triggering. I do find it unfortunate that we now have to program accessible widgets using two separate event triggering models, which will make it more difficult to program accessible complex interactive controls that work across all ATs equally.
> ----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
> To: <free-aria@googlegroups.com>
> Sent: Thursday, October 18, 2012 5:19 PM
> Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended functionality?
>> Browser and platform radio buttons don't get selected when they take focus, so invoking them doesn't change them. You have to select them, either by activating them or using the keyboard while they're focused. Of course, what happens for ARIA radio buttons depends on how they're implemented.
>> I'd argue the same should be done for ARIA radio buttons and tabs. That is, their onClick handler selects them and they can be selected using the keyboard (e.g. using the arrow keys) when focused.
>> Jamie
>> On 19/10/2012 1:40 AM, Bryan Garaventa wrote:
>>> 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.
>>> 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.z...@googlemail.com>
>>> To: <free-aria@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-aria@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> free-aria+unsubscribe@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-aria@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> free-aria+unsubscribe@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-aria@googlegroups.com.
>> To unsubscribe from this group, send email to free-aria+unsubscribe@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-aria@googlegroups.com.
> To unsubscribe from this group,
> ARIA Tabs still appear to be a bit buggy in NVDA, where when browsing
> down the page using the arrow keys, the currently selected tab is not
> conveyed in Firefox
I need to do some further testing, but it looks like Firefox isn't firing a stateChange event when aria-selected changes on tabs. If you press NVDA+f5 to refresh the buffer, you'll notice that the tab selected at that point is reported correctly.
> and ARIA Tabs in Chrome are very bad using both
> JAWS and NVDA at this point.
Chrome doesn't expose the content of tabs, only their label. I can work around this in NVDA.
> I don't know what the right answer is regarding auto focus triggering. I
> do find it unfortunate that we now have to program accessible widgets
> using two separate event triggering models, which will make it more
> difficult to program accessible complex interactive controls that work
> across all ATs equally.
I don't see why this is non-standard. As I said, browser radio buttons and similar items don't get automatically selected when focused either. Also, how are there more event mechanisms doing it this way than handling focus? You're simply triggering the selection on onClick instead of onFocus.
Jamie
-- James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372
----- Original Message ----- From: "Marco Zehe" <marco.z...@googlemail.com>
To: <free-aria@googlegroups.com>
Sent: Thursday, October 18, 2012 10:15 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?
Hi Bryan,
did you put aria-selected="true" on the selected tab, and aria-selected="false" on the others? That way, NVDA *should* pick up the selected tab.
Marco
Am 19.10.2012 um 05:24 schrieb "Bryan Garaventa" <bryan.garave...@whatsock.com>:
> Arrowing down the page in NVDA won't trigger anything, but Return will. So > too will tabbing to the tablist and using the arrow keys, which will > automatically trigger the focused tab accordingly.
> ARIA Tabs still appear to be a bit buggy in NVDA, where when browsing down > the page using the arrow keys, the currently selected tab is not conveyed > in Firefox, and ARIA Tabs in Chrome are very bad using both JAWS and NVDA > at this point.
> I agree with Marco, that when complex AJAX is used, the server hit > undermines performance quite badly when focus is used as the triggering > factor.
> Nevertheless, if people do make it a habit to deliberately not create ARIA > widgets according to spec, they won't work reliably across various ATs. I > just proved this with the ARIA Tabs, where, if it is programmed according > to spec, it works equally well for both NVDA and JAWS in supporting > browsers. Yet, if it's not programmed according to spec such as requiring > a Return keypress to activate an ARIA Tab, it breaks functionality in > JAWS.
> In cases where advanced AJAX is used, I've found that it's much more > reliable to use offscreen text and standard active elements, which are > cross platform and cross browser compatible across all ATs.
> Initially I programmed the left navigation tabs at WhatSock.com to use > ARIA Tabs, but found that the behavior across various screen readers and > the server hit lag when the arrow keys were used, was prohibitive. So I > converted them into ARIA Toggles instead, which works well for the same > functionality, even though visually they are page tabs.
> I don't know what the right answer is regarding auto focus triggering. I > do find it unfortunate that we now have to program accessible widgets > using two separate event triggering models, which will make it more > difficult to program accessible complex interactive controls that work > across all ATs equally.
> ----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
> To: <free-aria@googlegroups.com>
> Sent: Thursday, October 18, 2012 5:19 PM
> Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended > functionality?
>> Browser and platform radio buttons don't get selected when they take >> focus, so invoking them doesn't change them. You have to select them, >> either by activating them or using the keyboard while they're focused. Of >> course, what happens for ARIA radio buttons depends on how they're >> implemented.
>> I'd argue the same should be done for ARIA radio buttons and tabs. That >> is, their onClick handler selects them and they can be selected using the >> keyboard (e.g. using the arrow keys) when focused.
>> Jamie
>> On 19/10/2012 1:40 AM, Bryan Garaventa wrote:
>>> 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.
>>> 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.z...@googlemail.com>
>>> To: <free-aria@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-aria@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> free-aria+unsubscribe@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-aria@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> free-aria+unsubscribe@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
Regarding the event triggering, my point is that there is a difference between the browsing behavior of JAWS and NVDA, where JAWS does not trigger the focus event automatically when browsing, and NVDA does.
This means that interactive control types that require focus handling may not work properly in both JAWS and NVDA without this knowledge in advance.
So it's not clear to me how developers who are unfamiliar with the differences between JAWS and NVDA are supposed to correctly implement focus-oriented ARIA control types when this information is not at all obvious.
----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
To: <free-aria@googlegroups.com>
Sent: Thursday, October 18, 2012 10:48 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?
> On 19/10/2012 1:24 PM, Bryan Garaventa wrote:
>> ARIA Tabs still appear to be a bit buggy in NVDA, where when browsing
>> down the page using the arrow keys, the currently selected tab is not
>> conveyed in Firefox
> I need to do some further testing, but it looks like Firefox isn't firing > a stateChange event when aria-selected changes on tabs. If you press > NVDA+f5 to refresh the buffer, you'll notice that the tab selected at that > point is reported correctly.
>> and ARIA Tabs in Chrome are very bad using both
>> JAWS and NVDA at this point.
> Chrome doesn't expose the content of tabs, only their label. I can work > around this in NVDA.
>> I don't know what the right answer is regarding auto focus triggering. I
>> do find it unfortunate that we now have to program accessible widgets
>> using two separate event triggering models, which will make it more
>> difficult to program accessible complex interactive controls that work
>> across all ATs equally.
> I don't see why this is non-standard. As I said, browser radio buttons and > similar items don't get automatically selected when focused either. Also, > how are there more event mechanisms doing it this way than handling focus? > You're simply triggering the selection on onClick instead of onFocus.
> Jamie
> -- > 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-aria@googlegroups.com.
> To unsubscribe from this group, send email to > free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/free-aria?hl=en.
> Regarding the event triggering, my point is that there is a difference
> between the browsing behavior of JAWS and NVDA, where JAWS does not
> trigger the focus event automatically when browsing, and NVDA does.
Understood. However, as I've explained, there are very good reasons we've done what we've done and we're not the only AT to do so.
> So it's not clear to me how developers who are unfamiliar with the
> differences between JAWS and NVDA are supposed to correctly implement
> focus-oriented ARIA control types when this information is not at all
> obvious.
Ideally, developers shouldn't care about the AT in question. Imo, the guidelines should state that focus should not cause the selection to change for these controls, especially radio buttons. That is consistent with browser radio buttons and radio buttons pretty much everywhere else I've seen.
Jamie
-- James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372
When you say you aren't the only AT to do so, which other screen readers are doing this? Not counting Voiceover which is already obvious because of the iOS platform.
I think you are still missing my point. Try running the following code in Firefox using NVDA, and arrow down to the bottom of the page.
<html>
<body>
<div>
<div>
Content before <br />
the element with<br />
a focus handler.
</div>
<div tabindex="0" onfocus="alert('ARG!');">
Surprise!
</div>
<div>
The Content After.<br />
Find me if you can...
</div>
</div>
</body>
</html>
And before you say something like 'don't do that', this concept is no different than when simulated menus, extended tooltips, and other control types are made to open automatically when they receive focus to ensure accessibility for keyboard only users.
Yes, it's possible to make them activate explicitly when Return is pressed so they function properly in NVDA.
But if developers do as you say and "shouldn't care about the AT in question", and are unaware about the differences in event triggering such as this, how does this logic make interactive controls more accessible?
----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
To: <free-aria@googlegroups.com>
Sent: Friday, October 19, 2012 6:16 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?
> On 20/10/2012 3:58 AM, Bryan Garaventa wrote:
>> Regarding the event triggering, my point is that there is a difference
>> between the browsing behavior of JAWS and NVDA, where JAWS does not
>> trigger the focus event automatically when browsing, and NVDA does.
> Understood. However, as I've explained, there are very good reasons we've > done what we've done and we're not the only AT to do so.
>> So it's not clear to me how developers who are unfamiliar with the
>> differences between JAWS and NVDA are supposed to correctly implement
>> focus-oriented ARIA control types when this information is not at all
>> obvious.
> Ideally, developers shouldn't care about the AT in question. Imo, the > guidelines should state that focus should not cause the selection to > change for these controls, especially radio buttons. That is consistent > with browser radio buttons and radio buttons pretty much everywhere else > I've seen.
> Jamie
> -- > 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-aria@googlegroups.com.
> To unsubscribe from this group, send email to > free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/free-aria?hl=en.
Hey Bryan,
If you're talking about virtual buffering techniques that different screen readers employ and when they decide to toggle different modes, then it will be impossible to make everyone happy. From what I remember, NVDA will disengage "Focus mode" as soon as the keyboard focus leaves the interactive area of the page. Up and down arrows do not trigger keyboard focus in browsers the way the TAB key does, for example. So, I don't think it's fair to expect arrrow keys to get you out of the tabs.
JAWS, on the other hand, allows you to inspect ARIA widgets inside the virtual buffer before interacting with them. That's their choice!
I will agree with Jamie that developers should not be coding for specific screen readers precisely for the reasons above.
In my view, the users of a particular SR should be familiar with the tool they use.
Just my two cents.
Sent from my iPhone (possibly with Siri)
On Oct 19, 2012, at 7:10 PM, "Bryan Garaventa" <bryan.garave...@whatsock.com> wrote:
> When you say you aren't the only AT to do so, which other screen readers are doing this? Not counting Voiceover which is already obvious because of the iOS platform.
> I think you are still missing my point. Try running the following code in Firefox using NVDA, and arrow down to the bottom of the page.
> <html>
> <body>
> <div>
> <div>
> Content before <br />
> the element with<br />
> a focus handler.
> </div>
> <div tabindex="0" onfocus="alert('ARG!');">
> Surprise!
> </div>
> <div>
> The Content After.<br />
> Find me if you can...
> </div>
> </div>
> </body>
> </html>
> And before you say something like 'don't do that', this concept is no different than when simulated menus, extended tooltips, and other control types are made to open automatically when they receive focus to ensure accessibility for keyboard only users.
> Yes, it's possible to make them activate explicitly when Return is pressed so they function properly in NVDA.
> But if developers do as you say and "shouldn't care about the AT in question", and are unaware about the differences in event triggering such as this, how does this logic make interactive controls more accessible?
> ----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
> To: <free-aria@googlegroups.com>
> Sent: Friday, October 19, 2012 6:16 PM
> Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended functionality?
>> On 20/10/2012 3:58 AM, Bryan Garaventa wrote:
>>> Regarding the event triggering, my point is that there is a difference
>>> between the browsing behavior of JAWS and NVDA, where JAWS does not
>>> trigger the focus event automatically when browsing, and NVDA does.
>> Understood. However, as I've explained, there are very good reasons we've done what we've done and we're not the only AT to do so.
>>> So it's not clear to me how developers who are unfamiliar with the
>>> differences between JAWS and NVDA are supposed to correctly implement
>>> focus-oriented ARIA control types when this information is not at all
>>> obvious.
>> Ideally, developers shouldn't care about the AT in question. Imo, the guidelines should state that focus should not cause the selection to change for these controls, especially radio buttons. That is consistent with browser radio buttons and radio buttons pretty much everywhere else I've seen.
>> Jamie
>> -- >> 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-aria@googlegroups.com.
>> To unsubscribe from this group, send email to free-aria+unsubscribe@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-aria@googlegroups.com.
> To unsubscribe from this group, send email to free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/free-aria?hl=en.
> When you say you aren't the only AT to do so, which other screen readers
> are doing this? Not counting Voiceover which is already obvious because
> of the iOS platform.
It's not just on iOS. It does it on Mac OS X as well. The focus follows the VoiceOver cursor by default. In this case, you can't argue it's a platform specific oddity, since the interaction model for browsers on these platforms work in a very similar way.
> <div tabindex="0" onfocus="alert('ARG!');">
...
> Find me if you can...
> And before you say something like 'don't do that', this concept is no
> different than when simulated menus, extended tooltips, and other
> control types are made to open automatically when they receive focus to
> ensure accessibility for keyboard only users.
Actually, it is. In this case, you're beginning a completely separate interaction. In the case of menus which open, you're just expanding something in the existing model of interaction. Even so, I'd still argue there's rarely a good reason to make something open on focus. Even in the desktop paradigm (which until recently has been much richer in terms of controls), this rarely happens.
Jamie
-- James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372
Thanks, I understand your point. This is what I'm referring to though.
When you say "Up and down arrows do not trigger keyboard focus in browsers", that's correct, but NVDA is doing this regardless simply when arrowing down the page.
This is causing the 'focus' handler to be fired on all active elements where one exists.
----- Original Message ----- From: "Victor Tsaran" <vtsa...@gmail.com>
To: <free-aria@googlegroups.com>
Cc: <free-aria@googlegroups.com>
Sent: Saturday, October 20, 2012 12:07 AM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended functionality?
Hey Bryan,
If you're talking about virtual buffering techniques that different screen readers employ and when they decide to toggle different modes, then it will be impossible to make everyone happy. From what I remember, NVDA will disengage "Focus mode" as soon as the keyboard focus leaves the interactive area of the page. Up and down arrows do not trigger keyboard focus in browsers the way the TAB key does, for example. So, I don't think it's fair to expect arrrow keys to get you out of the tabs.
JAWS, on the other hand, allows you to inspect ARIA widgets inside the virtual buffer before interacting with them. That's their choice!
I will agree with Jamie that developers should not be coding for specific screen readers precisely for the reasons above.
In my view, the users of a particular SR should be familiar with the tool they use.
Just my two cents.
Sent from my iPhone (possibly with Siri)
On Oct 19, 2012, at 7:10 PM, "Bryan Garaventa" <bryan.garave...@whatsock.com> wrote:
> When you say you aren't the only AT to do so, which other screen readers > are doing this? Not counting Voiceover which is already obvious because of > the iOS platform.
> I think you are still missing my point. Try running the following code in > Firefox using NVDA, and arrow down to the bottom of the page.
> <html>
> <body>
> <div>
> <div>
> Content before <br />
> the element with<br />
> a focus handler.
> </div>
> <div tabindex="0" onfocus="alert('ARG!');">
> Surprise!
> </div>
> <div>
> The Content After.<br />
> Find me if you can...
> </div>
> </div>
> </body>
> </html>
> And before you say something like 'don't do that', this concept is no > different than when simulated menus, extended tooltips, and other control > types are made to open automatically when they receive focus to ensure > accessibility for keyboard only users.
> Yes, it's possible to make them activate explicitly when Return is pressed > so they function properly in NVDA.
> But if developers do as you say and "shouldn't care about the AT in > question", and are unaware about the differences in event triggering such > as this, how does this logic make interactive controls more accessible?
> ----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
> To: <free-aria@googlegroups.com>
> Sent: Friday, October 19, 2012 6:16 PM
> Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended > functionality?
>> On 20/10/2012 3:58 AM, Bryan Garaventa wrote:
>>> Regarding the event triggering, my point is that there is a difference
>>> between the browsing behavior of JAWS and NVDA, where JAWS does not
>>> trigger the focus event automatically when browsing, and NVDA does.
>> Understood. However, as I've explained, there are very good reasons we've >> done what we've done and we're not the only AT to do so.
>>> So it's not clear to me how developers who are unfamiliar with the
>>> differences between JAWS and NVDA are supposed to correctly implement
>>> focus-oriented ARIA control types when this information is not at all
>>> obvious.
>> Ideally, developers shouldn't care about the AT in question. Imo, the >> guidelines should state that focus should not cause the selection to >> change for these controls, especially radio buttons. That is consistent >> with browser radio buttons and radio buttons pretty much everywhere else >> I've seen.
>> Jamie
>> -- >> 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-aria@googlegroups.com.
>> To unsubscribe from this group, send email to >> free-aria+unsubscribe@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-aria@googlegroups.com.
> To unsubscribe from this group, send email to > free-aria+unsubscribe@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-aria@googlegroups.com.
To unsubscribe from this group, send email to free-aria+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/free-aria?hl=en.
"It's not just on iOS. It does it on Mac OS X as well."
Interaction in the Mac and iOS may be similar, but Windows and Mac are two different animals. You are trying to emulate Mac behavior in Windows, and they are not the same.
"Actually, it is. In this case, you're beginning a completely separate
interaction. In the case of menus which open, you're just expanding
something in the existing model of interaction. Even so, I'd still argue
there's rarely a good reason to make something open on focus. Even in
the desktop paradigm (which until recently has been much richer in terms
of controls), this rarely happens."
According to the page at
http://www.w3.org/TR/wai-aria/usage#managingfocus All of the following ARIA widgets are subject to Managed Focus:
. combobox
. grid
. listbox
. menu
. menubar
. radiogroup
. tree
. treegrid
. tablist
I'm not saying that opening controls using onfocus is desirable, I'm saying that automatically triggering onfocus when arrowing down the page is not helpful in a Windows environment.
. Use focus and blur events (or event delegation) to track the current focus - focus and blur events can now be used with every element. There is no standard
DOM interface to get the current element with keyboard focus, so authors may keep track of it with a
JavaScript
variable. Don't assume that all focus changes will come via key and mouse events, because assistive technologies such as screen readers can set the focus
to any focusable element, and that needs to be handled elegantly by the JavaScript widget. Techniques such as "event delegation" (for example, intercepting
events on a list rather than on every listitem) can greatly increase web application performance and code maintainability, and authors are encouraged to
use JavaScript best practices whenever possible.
. Follow keydowns to move focus - A keydown event handler can determine the next object to receive focus and call that element's focus() method.
. Dynamically change focusability using the tabIndex property - You may want to update tabindex values if a custom control becomes disabled or enabled.
Disabled controls should not be in the tab order. However, you can typically arrow to them if they're part of grouped navigation widget. When an element
receives focus, it should change the tabindex value to 0 to make an element the default element of the widget. This is important if the user leaves the
widget and returns to the widget again so focus is on the last element of the widget the user was on. If other elements of a widget can receive keyboard
focus, only one element of the widget should have a tabindex value of 0.
. The use of :focus pseudo-class selectors to style the keyboard focus is not supported in many versions of Internet Explorer. Authors should use the :active
pseudo-class (which older versions of IE treat like :focus) in conjunction with the :focus pseudo-class. Example: a:focus, a:active { text-decoration:
underline; }
If the related CSS pseudo-classes are not appropriate or not supported in all browsers, authors can use JavaScript techniques to indicate an appropriate
focus alternative, such as using focus and blur events to toggle a classname on an element.
Often applications give the perception of having a dual focus. Two examples of this are multi-selection list boxes and selected tabs, within a tablist,
when focus is in a tabpanel. In the case of a muti-selection list box a developer may gray selected items as they move focus to list box items to toggle
their selected state. In the case of a
tabpanel
the user selects a tab but then navigates to a focused item in the corresponding
tabpanel
the tab appears to also have focus. In reality, only one element may have focus in an application. In these scenarios authors should ensure keyboard focus
is set on the current element that visibly receives keyboard user input while ensuring other "highlighted" elements have an aria-selected state of "true"
until de-selected. When the de-selection occurs, such as when a multi-select item is de-selected or a user moves to a new tab and de-select the old tab,
the author should ensure that the visible selection of the de-selected item is removed.
3.2.6.1. Supporting Tooltips with the Keyboard
A
tooltip
is a popup messages typically triggered by moving a mouse over a control or widget causing a small popup window to appear with additional information about
the control. To provide simple text tooltips, the
HTML title attribute
should more than suffice because the user agent will render it for tooltips. When creating a
tooltip,
it is essential that the user be able to activate it using the keyboard. When a form control or widget receives keyboard focus, the
tooltip
must display. When the form control or widget loses focus, the tooltip must disappear. Browsers do not currently support this functionality.
While WAI-ARIA is designed to address many disabilities, this section is best described in terms of screen reader use. In desktop applications, screen readers
typically treat widgets as discrete entities, reading and interacting with each widget one at a time. The user moves the point of focus from widget to
widget using tab/shift tab, mnemonics, or accelerators, keyboard commands which are usually provided by the application or the operating system. We refer
to this mode of interaction as "application mode."
When viewing Web content however, screen readers often gather information about all the widgets in an area and present them in a document-like view which
the user navigates using keyboard commands provided and controlled by the screen reader. Think of this mode as a virtual environment that presents Web
content in a way that makes it convenient for adaptive technology users to navigate and read. This is sometimes called browse mode, or virtual mode. We
refer to this as "document browse mode."
Because many screen readers provide document mode navigation support using single key mnemonics on the alpha-numeric keyboard, they may provide a third
mode, called "forms mode," used to interact with form controls that are encountered in document mode. Behavior in forms mode is similar to that of application
mode. The key feature of forms mode is that it can be toggled with document mode to make it easy to both interact with a specific widget, and read virtualized
content of which the widget is a part. Since, as described above, a screen reader's perception of an area as either a document or an application greatly
influences how the user reads and interacts with it, WAI-ARIA provides content authors a way to indicate whether their pages must be viewed as applications
or documents by assistive technologies.
*End of excerpts*
NVDA is trying to blur Applications mode and Virtual Mode, and this will lead to unavoidable conflicts in functionality in Windows.
----- Original Message -----
From: "James Teh" <ja...@nvaccess.org>
To: <free-aria@googlegroups.com>
Sent: Saturday, October 20, 2012 3:40 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?
> On 20/10/2012 12:10 PM, Bryan Garaventa wrote:
>> When you say you aren't the only AT to do so, which other screen readers
>> are doing this? Not counting Voiceover which is already obvious because
>> of the iOS platform.
> It's not just on iOS. It does it on Mac OS X as well. The focus follows > the VoiceOver cursor by default. In this case, you can't argue it's a > platform specific oddity, since the interaction model for browsers on > these platforms work in a very similar way.
>> <div tabindex="0" onfocus="alert('ARG!');">
> ...
>> Find me if you can...
>> And before you say something like 'don't do that', this concept is no
>> different than when simulated menus, extended tooltips, and other
>> control types are made to open automatically when they receive focus to
>> ensure accessibility for keyboard only users.
> Actually, it is. In this case, you're beginning a completely separate > interaction. In the case of menus which open, you're just expanding > something in the existing model of interaction. Even so, I'd still argue > there's rarely a good reason to make something open on focus. Even in the > desktop paradigm (which until recently has been much richer in terms of > controls), this rarely happens.
> Jamie
> -- > 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-aria@googlegroups.com.
> To unsubscribe from this group, send email to > free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/free-aria?hl=en.
> Interaction in the Mac and iOS may be similar, but Windows and Mac are
> two different animals. You are trying to emulate Mac behavior in
> Windows, and they are not the same.
You're assuming the behaviour of every control absolutely must be different on both platforms, which simply isn't the case. You're also saying that every AT on Windows has to behave in exactly the same way, which also isn't the case. As I've already stated, radio buttons and many other controls in browsers already behave as I've explained; i.e. focus does not trigger selection. Moving focus while reading is not a Mac specific feature. I'm not asking you to implement something for which there isn't already a huge deal of precedent; it isn't just a work around for what you believe to be buggy behaviour.
> All of the following ARIA widgets are subject to Managed Focus:
Managed focus doesn't necessarily mean "focus triggers selection". It does mean that your code must manage the focus in response to keyboard, manage tabindex, etc.
> I'm not saying that opening controls using onfocus is desirable, I'm
> saying that automatically triggering onfocus when arrowing down the page
> is not helpful in a Windows environment.
I'm saying I disagree. I notice you've completely failed to address the reasons I provided for why we implemented this in the first place. Essentially, you're asking us to change functionality which has been present in NVDA since 2007 for parity with JAWS without providing an alternative solution to the original problem.
> *Excerpts*
None of these excerpts explicitly says that focus should automatically trigger selection, especially for radio buttons and tabs.
In any case, I've given very good reasons as to why NVDA does this. This functionality is not going to be changed any time soon (if ever), especially not for this use case.
Jamie
-- James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372
I would agree that in general developers should avoid autoloading the content of a tab panel when a particular tab becomes active, however, as with everything, it really depends on the situation. I don't think that guidelines should regulate that kind of behavior. The guidelines should simply state that both interactions are possible and perhaps provide a couple of examples.
On Oct 18, 2012, at 1:51 AM, Marco Zehe <marco.z...@googlemail.com> wrote:
> 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-aria@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> free-aria+unsubscribe@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-aria@googlegroups.com.
>> To unsubscribe from this group, send email to free-aria+unsubscribe@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-aria@googlegroups.com.
> To unsubscribe from this group, send email to free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/free-aria?hl=en.
> I need to do some further testing, but it looks like Firefox isn't
> firing a stateChange event when aria-selected changes on tabs. If you
> press NVDA+f5 to refresh the buffer, you'll notice that the tab selected
> at that point is reported correctly.
I understand all of your points, and you are welcome to go back through all of my prior messages to see that I never said you should change anything.
What I said is that developers should be aware of the differences in behavior between JAWS and NVDA when designing widgets, and that having different event triggering models between ATs in the same OS isn't helpful for developers who are not aware of this.
----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
To: <free-aria@googlegroups.com>
Sent: Sunday, October 21, 2012 4:00 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?
> On 22/10/2012 8:39 AM, Bryan Garaventa wrote:
>> Interaction in the Mac and iOS may be similar, but Windows and Mac are
>> two different animals. You are trying to emulate Mac behavior in
>> Windows, and they are not the same.
> You're assuming the behaviour of every control absolutely must be > different on both platforms, which simply isn't the case. You're also > saying that every AT on Windows has to behave in exactly the same way, > which also isn't the case. As I've already stated, radio buttons and many > other controls in browsers already behave as I've explained; i.e. focus > does not trigger selection. Moving focus while reading is not a Mac > specific feature. I'm not asking you to implement something for which > there isn't already a huge deal of precedent; it isn't just a work around > for what you believe to be buggy behaviour.
>> All of the following ARIA widgets are subject to Managed Focus:
> Managed focus doesn't necessarily mean "focus triggers selection". It does > mean that your code must manage the focus in response to keyboard, manage > tabindex, etc.
>> I'm not saying that opening controls using onfocus is desirable, I'm
>> saying that automatically triggering onfocus when arrowing down the page
>> is not helpful in a Windows environment.
> I'm saying I disagree. I notice you've completely failed to address the > reasons I provided for why we implemented this in the first place. > Essentially, you're asking us to change functionality which has been > present in NVDA since 2007 for parity with JAWS without providing an > alternative solution to the original problem.
>> *Excerpts*
> None of these excerpts explicitly says that focus should automatically > trigger selection, especially for radio buttons and tabs.
> In any case, I've given very good reasons as to why NVDA does this. This > functionality is not going to be changed any time soon (if ever), > especially not for this use case.
> Jamie
> -- > 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-aria@googlegroups.com.
> To unsubscribe from this group, send email to > free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/free-aria?hl=en.
> I understand all of your points, and you are welcome to go back through
> all of my prior messages to see that I never said you should change
> anything.
I apologise if I misconstrued your point. However:
> What I said is that developers should be aware of the differences in
> behavior between JAWS and NVDA when designing widgets, and that having
> different event triggering models between ATs in the same OS isn't
> helpful for developers who are not aware of this.
It's this last point that leads me to believe you want something changed, especially given that you've argued that NVDA's behaviour of setting focus while moving the cursor is incorrect.
> I don't understand why this doesn't make sense.
It doesn't make sense to me because triggering selection on focus is uncommon behaviour for many widgets, both platform native and browser native, so I don't see why ARIA widgets should be any different.
Jamie
-- James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372
If the W3C is recommending that developers use 'focus' and 'blur' to control key aspects of interactive widgets, yet using 'focus' and 'blur' is not recommended for cross AT compatibility, how is this not contradictory?
It doesn't matter anyway, It's obvious that I'm beating a dead horse here.
Informed developers will build accessible interactive components in the future, uninformed developers won't. We can see evidence of this everywhere.
----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
To: <free-aria@googlegroups.com>
Sent: Monday, October 22, 2012 2:34 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?
> On 23/10/2012 3:28 AM, Bryan Garaventa wrote:
>> I understand all of your points, and you are welcome to go back through
>> all of my prior messages to see that I never said you should change
>> anything.
> I apologise if I misconstrued your point. However:
>> What I said is that developers should be aware of the differences in
>> behavior between JAWS and NVDA when designing widgets, and that having
>> different event triggering models between ATs in the same OS isn't
>> helpful for developers who are not aware of this.
> It's this last point that leads me to believe you want something changed, > especially given that you've argued that NVDA's behaviour of setting focus > while moving the cursor is incorrect.
>> I don't understand why this doesn't make sense.
> It doesn't make sense to me because triggering selection on focus is > uncommon behaviour for many widgets, both platform native and browser > native, so I don't see why ARIA widgets should be any different.
> Jamie
> -- > 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-aria@googlegroups.com.
> To unsubscribe from this group, send email to > free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/free-aria?hl=en.
> If the W3C is recommending that developers use 'focus' and 'blur' to
> control key aspects of interactive widgets,
I still haven't seen explicit recommendations to trigger selection based on focus, but I'll grant that I haven't read the entire document.
> yet using 'focus' and 'blur'
> is not recommended for cross AT compatibility, how is this not
> contradictory?
If you are definitely correct that the W3C recommends focus should trigger selection in these widgets, then yes, it's quite contradictory. This seems to be a classic case where the specs completely fail to take common, years-old existing behaviour into account, which I unfortunately see far too often, but that's academic now.
It's worth pointing out that by your definition, iOS and Mac OS X are violating the W3C recommendations as well, yet you seem to be a proponent of their behaviour based only on the argument that they are a different platform. I don't see how being a different platform makes any difference when following these recommendations to the letter.
Jamie
-- James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372
>> and ARIA Tabs in Chrome are very bad using both
>> JAWS and NVDA at this point.
> Chrome doesn't expose the content of tabs, only their label. I can work
> around this in NVDA.
Done for NVDA 2012.3.
Jamie
-- James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372
Basically, with all of this, I was hoping to make it clear that developers need to test interactive control designs across all available platforms and ATs, specifically JAWS and NVDA in Windows and Voiceover in Mac and iOS Safari, since there are differing behaviors for each and the W3C guidelines may not cover these bases adequately in some circumstances.
Unfortunately I didn't do a very good job at this.
Here is a simple example of why, using implementations I've seen used in the past.
Below are three ARIA Toggles, all of which are semantically correct.
The first button works correctly in both NVDA and JAWS using IE and FF. In Chrome however, JAWS sees nothing, and NVDA announces "Toggle Button" but no label. In iOS Safari, Voiceover incorrectly identifies the toggle as a checkbox with no label.
The second button works correctly in both NVDA and JAWS using IE, FF, and Chrome. In iOS Safari however, Voiceover also incorrectly identifies the toggle as a checkbox with no label.
The third button works correctly in both NVDA and JAWS using IE, FF, and Chrome. It also works correctly in Voiceover using iOS Safari, even though it still identifies it as a checkbox, but at least it has a label.
Plus, all of the same behavioral differences hold true for ARIA Radios and ARIA Checkboxes as well.
Many times, I've seen developers assume that because the code is semantically correct and adheres to the ARIA spec, that it must be accessible without cross platform and cross AT testing. I've even been told that, because it was tested using ChromeVox, it must be accessible without need for additional testing. Nothing is ever that simple though, unfortunately.
I've been saying for a long time that Accessibility is a programming discipline, and like other programming disciplines such as JavaScript, there are some techniques that work across various platforms, and there are others that don't.
This is why I believe it's important for developers in general, especially those in UI and feature development, to understand the differences between ATs, and not just platforms.
----- Original Message ----- From: "James Teh" <ja...@nvaccess.org>
To: <free-aria@googlegroups.com>
Sent: Monday, October 22, 2012 6:00 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?
> On 23/10/2012 8:11 AM, Bryan Garaventa wrote:
>> If the W3C is recommending that developers use 'focus' and 'blur' to
>> control key aspects of interactive widgets,
> I still haven't seen explicit recommendations to trigger selection based > on focus, but I'll grant that I haven't read the entire document.
>> yet using 'focus' and 'blur'
>> is not recommended for cross AT compatibility, how is this not
>> contradictory?
> If you are definitely correct that the W3C recommends focus should trigger > selection in these widgets, then yes, it's quite contradictory. This seems > to be a classic case where the specs completely fail to take common, > years-old existing behaviour into account, which I unfortunately see far > too often, but that's academic now.
> It's worth pointing out that by your definition, iOS and Mac OS X are > violating the W3C recommendations as well, yet you seem to be a proponent > of their behaviour based only on the argument that they are a different > platform. I don't see how being a different platform makes any difference > when following these recommendations to the letter.
> Jamie
> -- > 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-aria@googlegroups.com.
> To unsubscribe from this group, send email to > free-aria+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/free-aria?hl=en.
