Absolutely, but if there are other controls "interleaved" with the radio buttons of the same group, when the focus leave this interleaved components the focus is "moved back" to the selected button... even if this is "before" in the computed tab loop, actually creating a closed tab loop that is impossible to escape without using the mouse.
2013/9/20 Alex Harui <aha...@adobe.com> > The default behavior on Windows is/was that you tab to a group of radio > buttons which will focus the selected one or the first one if none are > selected, then use arrow keys to move between them. Another tab moves you > to the next/previous control or group. > > The Flex FocusManager attempts to replicate that behavior. Is that what > you are seeing? > > -Alex > > On 9/20/13 7:08 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote: > > >Hi list, maybe I found an issue with keyobard focus manager. > >I have a situation like this (hope you get the pic): > > > > > >[previous controls] > >[radio A] [radio B] > > [radio A1] [radio B1] [text input] > > [radio A2] [radio B2] > >[next controls] > > > > > >Now, the tab focus management is completely broken: > > - when focus is on [radio A2], tab go back to [radio A] - there's no way > >to move to [next controls] > > - when focus is on [text input], tab go back to [radio B1] - again, no > >way > >to move to [next controls] > > > > > >I think that the bug is in the FocusManager.getIndexOfNextObject method: > >when focus is on [radio A2], the next focus candidate is [radio B] (due to > >containers visual layout), but it is part of a focus group, so the > >FocusManager bring it to *the selected element of its focus group*, that > >is > >[radio A]. > > > >In my opinion, this should be done only if no other elements of the > >same focus group have an index, in the focus candidate list, that is less > >then the index of the current focused component, to avoid "moving back" > >the > >focus and creating closed tab loops (maybe reversing the index check when > >moving focus backwards). > > > > > > > >The only workaround I found so far is structuring the containers so that > >component belonging to the same focus group are kept adjacent, but it is > >very difficult (if not impossible) to achieve the same visual output (e.g. > >put [radioA] and [radioB] in a dedicated HGroup, ditto for [radio B1] and > >[radio B2], trying to keep [text input] aligned to [radio B1] someway). > > > >Any thoughts on this? If I'm not missing something obvious, I'd like to > >file an issue... > >
