Folks,
I’ve just installed the latest version of WFview on my mac running Sequoia, and I use voiceover, which is Apple’s built-in screen-reader. With some sighted help I’m trying to get the app to connect to my ts-890 over tcp/ip on my local area network. So I’ve entered the ip address of my rig, 192.168.0.40, the username, and password that I use to connect with it via the ts-control for mac app, and ensured that the ports are correct, 60000, and 60001. When I try to connect, I’m not hearing audio and I see the button that says “connect to radio” change to cancel connection. Is there something that I’m missing? Also some of the controls that are being used on the mac don’t quite present themselves to the UI_accessibility API properly, I’m noticing that when I try and access radio settings with either a mouse click, or pressing enter on the control, nothing happens. Also, some "tabs appear to be masquerading as check boxes in the UI. Either way I’m happy to help where I can if I can just figure out how to get this thing to connect to my ts-890.
73s,
Justin-ai5os
We haven’t released a version for macOS or windows that supports the TS-890 yet!
It’ll be out soon though!
If you have Linux you can compile it yourself and it should work pretty well.
—E
de W6EL
Hi Justin,
Sorry for my brief reply earlier.
We will try and better support the screen reader. If you can tell us what things you suspect were not coming out right that would help. We are probably missing some of the clues in our UI that the screen reader looks for. Our UI recently went through a bit of an overhaul.
With regards to “Radio Settings”, clicking there causes the controls on the right-side of the Settings window to change and to show things related to the radio’s own settings, such as the radio’s modulation input and output. Each of those “categories” on the left (Radio Access, User Interface, Radio Settings, and so on) changes the UI controls on the right. It should be instantaneous with clicking on the text. You may have to somehow tell the screen reader to read from that side again once you click on a category.
As for the TS-890, we do have it working, and we are just bringing it up to “feature parity” with the other radios that wfview supports. There are many little things that aren’t quite right yet, and that is why we haven’t built a macOS version with support for the TS-890 yet. But it will come!
Stay tuned,
–E
de W6EL
hi there, Thanks for responding. Most of the buttons that I’m seeing such as radio access, or settings are actually showing up as text boxes, which from voiceover’s perspective makes it think that i can type in the given dialogue. I had to have a sighted person actually click the various buttons so that I could enter the information for my radio, once i did that the frequency tab, and the band tab seems fine. THough may I make a suggestion, I think I would, at least where Kenwood is concerned, set the hotkeys for bands similar to the front of the 890, with numbers 1-0 representing the various bands 160 through 10 meters. With regards to the UI of the app, is there any of it’s compilation done in xcode? If so Xcode does have an accessibility auditer that will actually allow you. to test the app, and does have some automated testing that can be used to see how different controls function with voiceover. Apple’s screen-reader. If i were to compile the app in Linux say on a pi 4 that I have using some of my node-red stuff, and an old installation of open-890, could I make use of the app at this point? Is there some kind of a web-ui that would present itself to allow me to connect to the 890? I’d have no problem beta testing even a sort-of-working mac version of the app if I knew it could connect to the rig or whatever. I’m just looking for something that offers a little more than ts-control, and the arcp-890 options that are currently available, which are not bad, albeit usable.
Thanks for your help,
Justin-ai5os
Hi Justin,
We are not using xcode to build the UI since it has to be cross-platform. However, the UI library we are using does support accessibility and should be working. I will give it a try here on Linux and see what it is reporting. I wonder if some of the confusion is how we are labeling the “labels” versus the text input boxes.
With regards to frequency input, the frequency input window is keyed so that each number is just the number on the keyboard, not too crazy right? The Band window is setup so that there is either a numeric or phonetic relationship between the band’s common name and the key. Key 1 for ten meters, and key “t” for twelve meters, and so on. This was challenging especially with radios like the IC-705 which support even more bands than the TS-890. What does “6” do? 6 meters or 60 meters? How about 70cm, should that be “7” or “s” or “4”? It gets really tricky once you get into it and of course, supporting over a dozen radios really adds to the difficulty. So while I like the idea of mimicking the TS-890 numeric panel, we’ll have to think about it in terms of all the supported radios and bands. Add to it that several ham bands are not listed on most radio band panels (4M, 60M and the sub-1 MHz experimental bands). What I will commit to though, is assigning key strokes to as many common functions as I can think of. I think it’s nice to be able to drive an app with the keyboard!
Once we get a few more bugs ironed out with the 890 I will let you know how to install it on your Pi (depending on how your Pi is setup of course). I can totally understand the excitement this generates but understand that working on the 890 code is a daily occurrence right now, and the usability of the builds varies greatly. Things need to settle down a bit before I can really ask anyone to try the TS-890 out.
I will let you know if I have accessibility questions, and I’ll try and enhance it as much as I can before we get that next version out.
–E
de W6EL
Hi Justin,
We can set the following fields in our UI toolkit, which are supposed to get translates on each platform into a similar field for the screen reader: accessibleName and accessibleDescription.
For a widget such as a push button, the accessibleName should automatically populate from the text of the button. But I have a question, if a button is called “Connect”, should we make the accessible name “Connect Button” for clarity, or is “Connect” clear enough? How can you distinguish between buttons, checkboxes, and text entry fields? I tried a screen reader here (orca) and I could not figure out how to tell which was which, which is why I’m wondering if it helps to include a hint about the type of thing the mouse is over.
Let me know.
Thanks,
–E
de W6EL
hi there,
My pi just boots in to the CLI, so I’m happy to wait on the mac version, I’m not sure if a pi can be made to talk in the GUI? I”m guessing it can, but I’ve never tried. What Library are you using for the front end? Yes it sounds like the way some of those controls are labeled is causing the confusion. ON the mac, we have something called the accessibility_UI api that if you can leverage may make your life a little easier. You can find out more at
Keep in mind some of this is x-code centric, but you may have some resources theree.
Thanks,
Justin-ai5os