WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Bryan Garaventa
Date: Oct 22, 2012 11:08AM

No, I'm saying that if developers follow the W3C recommendations for Focus
and Blur usage without taking into account that NVDA triggers the 'focus'
handler automatically when arrowing, unlike JAWS, it may cause issues for
ARIA widgets such as Tabs, Radios, Listboxes, menus, menubars, trees,
treegrids, and tooltips when used in Windows.

For example, I've seen some accordion implementations that are designed to
expand when the parent node receives focus. This is an example where this
comes into play.

If developers don't consider these differences when designing interactive
widgets, they may not work equally across various ATs.


----- Original Message -----
From: "Jonathan C. Cohn" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Sunday, October 21, 2012 9:20 PM
Subject: Re: [WebAIM] Fw: [free-aria] Is auto focus triggering an NVDA bugor
intended functionality?


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