Sam, this is a concept you know well–you just don’t know it by the term I’ve used. When an item on a menu bar is highlighted, that is the focus object. Your cursor in an edit window is a focus object. Basically, any object you’re interacting with is the focus object. That object is usually in a window, so the window containing the focus object is the focus window. The problem comes that if, for example, you get an error message, you’re alerted to that by a blinking red color, perhaps. You simply look at the text & read it, fix the mistake or whatever, & go on about your business. Now–as screen reader users, we clearly cannot train our eyes on the spot in question. So therefore our screen reader either needs to read it aloud or it needs to be able to go to the window containing the text so we can use our arrow keys, etc, in order to read/interact w/the information being presented. Preferably both,ie, you’re alerted to a problem but you can also go to the window in order to be able to study it in greater depth, just as you would when looking at the information on your screen. So I have to set that window as the focus window for the screen reader so it can read/interact w/the text being presented. If you think about the screen reader having to do the looking for us, it might provide some help w/regard to thinking about the issue in question.
The help window may be another place where keyboard focus is needed. You could just click a sample or synth name w/the mouse. In order for me to choose 1, however, I’d need to be able to use my arrow keys, the highlighted option should speak, & I should then be able to press the enter key in order to make my choices. I’ll need to check & see if it reacts thus, & I will do so as work permits.
So what I discovered when intentionally introducing an error is that obviously the code won’t run. The silence is my error alert. I was able to use the menu bar to go to the info window where it said I had an error on line 13. Well, no, not really, as I had intentionally left out a ‘do’ on line 5, but compilers/interpreters are pretty notorious for getting this stuff wrong sometimes, so no biggie.
Another example is getting to the code edit window. When Sonic-Pi first opens, there are a series of windows on screen–log, cues, etc. It doesn’t immediately go to the code edit window–it seems I’ve got to do the equivalent of a mouse click to get there. It’d be nice to be able to press a hotkey & get to the window in question. How to do that is a little bit code-dependent.
Am I correct you’ve written Sonic-Pi in Ruby? It’s not a language w/which I’m very familiar, but, if required, I’ll try to get myself up to speed enough so that I can at least understand how it deals w/interface objects, etc in order to try to lend a bit more assistance here.
I was aware the forums weren’t developed by you. That was just more of an apology for the topic being in the wrong forum, & why that was the case. I mean–you know–I’m more than capable of doing stupid stuff–but in this case, it wasn’t actually me for a change. Lol. It would be good if they’d make those accessible, though. That’s for another day, however.
