WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Bryan Garaventa
Date: Oct 21, 2012 4:47PM

FYI, this is important for other developers to be aware of.

----- Original Message -----
From: "Bryan Garaventa"
To: < <EMAIL REMOVED> >


> "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" < <EMAIL REMOVED> >
> To: < <EMAIL REMOVED> >
> 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: <EMAIL REMOVED>
>> 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 <EMAIL REMOVED> .
>> To unsubscribe from this group, send email to
>> free-aria+ <EMAIL REMOVED> .
>> For more options, visit this group at
>> http://groups.google.com/group/free-aria?hl=en.
>>
>