This is a more general problem. Try flat-reviewing the right-hand panel in the SwingSet2 Button Demo page. Flat-review acts like there is a component just to the right of the 'Display Options' check boxes. Flat-review speaks the check box state for this pseudo-component. The same goes for the 'Text Position' buttons.

Will,

I found the flat-review.Context._insertStateZone method that inserts a state zone next to the Swing buttons, check boxes, etc. 

I'm not sure what to do with this bug. For Swing components, it appears that the appropriate behavior when navigating by word or characters should be:

1. If the zone is a StateZone, don't draw a zone rectangle or speak/Braille the StateZone.

2. If the zone is not a StateZone, and the previous zone is a StateZone, append the StateZone utterances to the utterances for this zone.

There's also the issue of whether the StateZone is to the left or right of the component, plus the issue of whether flat-review navigation is to the left or to the right.

What should I do here?

Ignoring where/if the rectangle is drawn, does the speech/braille output provide the desirable user experience?  (i.e., what is the output when you navigate word by word or character by character?)

IMHO, the user experience is not desirable. When navigating left-to-right by character or word, one key press causes the component state to be presented and the next key press causes the component name to be spoken. The reverse is true naviaging from right-to-left. One key press causes the component name to be spoken. The next key press causes the component state to be spoken. I would think that users would expect one key press to cause both the compoent name and state to be spoken.
'

Actually the usibility here is what Will and I origionally discussed and is correct.  

(In reply to comment #5)
> Actually the usibility here is what Will and I origionally discussed and is
> correct.  

Phew.  Thanks for checking on this Mike.  Lynn, I believe the one confusing thing that is left is the debug rectangle that is drawn to indicate the state of the component.  The main problem I was facing when working on this was that I could not figure out a way to determine the bounds of just the indicator -- the only bounds I was able to determine reliably where the bounds of the label and the bounds of the entire component.  

I tried doing some heuristics, such as comparing the two different bounds (i.e., component versus just the text) to infer the bounds of the indicator, but couldn't come up with anything reliable.  If I recall, the main problem was that the bounds of the component might be really really wide.  For example, the bounds of a checkbox widget might be the entire line that it is on, even if the label is very short.  So, I punted and just put an imaginary rectangle in there to handle the indicator state.  Visually, the debug rectangle can be confusing, but the braille/speech user experience is the desired one.

If you can devise a way to infer the bounds of the indicator reliably, then it probably would be a good thing to get in.  Otherwise, we probably should close this as NOTABUG.

I don't think the indicator rectangle is a significant problem. I was only really concerned about the speech/Braille behavior. Closing as NOTABUG.

Thanks Lynn!