Is auto focus triggering an NVDA bug or intended functionality?

[Bryan Garaventa]

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.

 

 

[James Teh]

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

> --
> 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

[Marco Zehe]

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

[Bryan Garaventa]

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?

[James Teh]

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

[Bryan Garaventa]

Well, I reprogrammed the ARIA Tab section at
http://whatsock.com/modules/aria_tabs_menu_modules/demo.htm
So now it works properly in JAWS and NVDA according to spec.

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.

[Marco Zehe]

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

[James Teh]

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

[Bryan Garaventa]

Absolutely, all the expected attributes are present.

[Bryan Garaventa]

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...@googlegroups.com>
Sent: Thursday, October 18, 2012 10:48 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?

[James Teh]

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.

[Bryan Garaventa]

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...@googlegroups.com>
Sent: Friday, October 19, 2012 6:16 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?

[Victor Tsaran]

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)

[James Teh]

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.

[Bryan Garaventa]

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.

[Bryan Garaventa]

"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.

Don't take my word for it. please read the page at
http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#kbd_focus

*Excerpts*

. 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...@googlegroups.com>
Sent: Saturday, October 20, 2012 3:40 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?

[James Teh]

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.

[Victor Tsaran]

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.

[James Teh]

On 19/10/2012 3:48 PM, James Teh wrote:
> 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 confirmed this and filed a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=804040

[Bryan Garaventa]

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.

I don't understand why this doesn't make sense.

----- Original Message -----
From: "James Teh" <ja...@nvaccess.org>
To: <free...@googlegroups.com>
Sent: Sunday, October 21, 2012 4:00 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?

[James Teh]

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.

[Bryan Garaventa]

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...@googlegroups.com>
Sent: Monday, October 22, 2012 2:34 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?

[James Teh]

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.

[James Teh]

On 19/10/2012 3:48 PM, James Teh wrote:

>> 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.

[Bryan Garaventa]

I don't have a problem with platform differences.

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.

<a role="button" aria-pressed="false" href="#">
<img title="Options" alt="Options" src="img.jpg" />
</a>

<a aria-label="Options" role="button" aria-pressed="false" href="#">
<img title="Options" alt="Options" src="img.jpg" />
</a>

<a title="Options" role="button" aria-pressed="false" href="#"
style="background: url(img.jpg) #000 no-repeat;">
<span class="offscreenText">Options</span>
</a>

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.

I'm sorry if this wasn't clear earlier.

----- Original Message -----
From: "James Teh" <ja...@nvaccess.org>
To: <free...@googlegroups.com>
Sent: Monday, October 22, 2012 6:00 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?

[Bryan Garaventa]

Excellent!

----- Original Message -----
From: "James Teh" <ja...@nvaccess.org>
To: <free...@googlegroups.com>
Sent: Monday, October 22, 2012 8:26 PM
Subject: Re: [free-aria] Is auto focus triggering an NVDA bug or intended
functionality?

[James Teh]

Hi Bryan,

Well, if your point wasn't clear earlier, it is now. I apologise if the
error in interpretation was mine.

Ideally, everything *would* just work when it's semantically correct.
Unfortunately, as you say, it just isn't that simple. It's very hard to
catch all of the edge cases, though we do our best. Another issue, as I
already noted, is that the specs sometimes don't take existing behaviour
and functionality into account. It's very difficult for ATs to conform
in these situations. ARIA is ARIA, but for the most part, it's also
supposed to look and work like native widgets as far as ATs are
concerned. Sometimes, the specs don't reflect this and there's where we
get into trouble. Of course, one solution might be to get involved in
spec development, but while we (at NV access) would like to do this, we
just don't have the resources, especially given all the politics involved.

Regarding your button example, Mac OS X is announcing it as a checkbox
because it doesn't have a toggle equivalent. It's mapping it to the
closest thing that has the same behaviour on that platform. Users will
understand this.

I'll take a look at the examples to see why NVDA is misbehaving where it
does. For that kind of issue, it's worth filing a bug in the NVDA
tracker. It may not be an issue in NVDA, but we'll be able to determine
that and direct you to the right place if not.

Jamie

[James Teh]

On 24/10/2012 12:48 PM, Bryan Garaventa wrote:

> <a role="button" aria-pressed="false" href="#">
> <img title="Options" alt="Options" src="img.jpg" />
> </a>

> [This] 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.
This is a bug in Chrome. Chrome exposes no label and doesn't expose the
graphic beneath, so there's no way for a screen reader to retrieve the
label.