On Nov 27, 2015, at 15:50 , Alex Hall <email@hidden> wrote:
Just for the record, the VoiceOver keys are control and option.
Yes, I forgot. Command was relevant in this case because I needed Control-Option-Command plus whatever else to release the drag lock, IIRC. Option is also a problem because it changes a move-drag in to a copy-drag, although that might be different if it’s Option + other modifiers.
But it’s certainly extremely disappointing that Caps Lock doesn’t work.
it's how I always add controls from the object library to my scenes' views. I realized afterwards that you seemed to be more successful at this than I was. Quite possibly I was using a less-than-optimal series of VO commands. In the absence of a single list of VO keyboard commands (at least I couldn’t find one), I didn’t really know if there were other commands I was missing. The VO help window isn’t extremely helpful in finding things. Searching the help was hard for a neophyte like me, because VO has its own set of jargon words, and I was never quite sure what “interact with” meant, things like that.
The other thing I’d add is that the containment hierarchy in an Xcode window is way too complicated, what with nested splits and multiple toolbars. It seems like the VO elements need to be in a much, much flatter hierarchy.
After reading more about custom accessibility elements (well, the Mac version, so far), I also think that the fact that contained items are arranged left-right only is a mistake. The only up-down traversal (within a container, not into or out of a container) is in things like grids or tables, that have a very regular row and column structure. Containers should be more like a DVD or Blu-ray menu, where you can custom-design up/down/left/right relationships that aren’t strictly geometric.
For example, if I got to the toolbar across the top of the object library, I had to go right 4 times to get to the objects. Going down didn’t do anything, even though the objects are immediately below the toolbar.
It also seems like it would be useful for accessibility elements to be repeatable in different places in the hierarchy, even though they represent the same view/control/area. The actual view hierarchy is not in itself that important to someone actually navigating around the window.
|