WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jonathan C. Cohn
Date: Oct 21, 2012 10:20PM

I am confused are you stating that VoiceOver / NVDA are behaving badly, or that web-designers are using features that they really should not use.


On Oct 21, 2012, at 6:47 PM, Bryan Garaventa wrote:

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