… also tried this on a simulator with Accessibility Inspector and it shows no update to the slider value as you move the slider.
Thanks for the suggestions. I tried them out and noticed that setAlwaysOnTop only seems to work if your cover the parent component. If you are also covering other components then they still “bleed through”. Probably bad UI design on my part, enterModelState() seems to do what I need.
Are you just using a standard JUCE Slider with no modifications? I’m testing on an iPad here and the updated value is being read out as I swipe up and down with one finger when the slider has focus.
This is also the case for native iOS sliders so I don’t think it’s related. For example, the “Brilliance” slider in the Photos app does not update the value property in the accessibility inspector when changing it. Instead you need to re-select the slider with the cursor and it shows the updated value.
I’ve added this to the develop branch here:
1 Like
This should be fixed on develop now:
Great, I’ll try it out, thanks!
I downloaded the latest JUCE develop version, ran it on an iPad, checked the JUCE version in the start screen (v6.1.2). Then tried DemoRunner on an iPad and an iPhone. Same result - it doesn’t read out the values. Then tried a native slider - that works fine.
Small oddity -Narrator now reads button states, but twice: “on, on”, “off, off”.
How can I access the right click menu in the TextEditor. VO + Shift + M doesn’t seem to work in Voice Over to bring it up.
I think on Windows you’d need to handle WM_CONTEXTMENU not sure what the equivalent is on macOS
Comment from customer:
XXX is nice and smooth to use now, other than context menus requiring some jiggery-pokery with all screen readers except Narrator. At the moment the context menus seem to be some sort of child window, if you can make them a menu role/class/whatever the proper word is, I reckon you can call XXX a done deal.
On macOS, there is the main menu bar model and you can add popupmenus to it. Any chance we can get something similar on Windows and macOS for using native context menus? And window menus on Windows.
On macOS, unless context menus are perfectly square, they have horrible pink rectangle around them now. And shadows can’t be used. So would be nicer just to switch to native menus.
Also on Monterey, ToggleButtons either say “1” or nothing. Didn’t they used to say checked or unchecked? Or is this a change in macOS?
On MacOS, if popup menus have submenu, VO automatically goes into submenus as soon as your cursor lands on it.
This makes it difficult to navigate the top level items because you have to keep get out of the submenu.
For example, let’s say a popup menu has top levels with submenus A, B, C … Z, and submenu A has a1 a2 a3, and submenu B has b1 b2 b3, and so on.
If you press VO space to open the popup menu, it automatically goes into subMenu A and select the item A1.
If you press left to get out, cursor is on subMenu A.
If you press down, it automatically goes into the submenu B and selects B1. You have to press left to get out again.
If you’re and submenu A, and if you want to go to Submenu Z, you have to repeat pressing left down left down left down instead of just pressing down to go through the submenus.
I’m not sure if this is Juce bug, but I haven’t seen any popup menu that lets me goes through submenus without automatically going into each one.
Some plugins uses a popup menu for presets, and it’s hard to navigate when there are many nested submenus.
Some examples include:
the menu on Surge XT with zoom, skin, and so on. It’s free.
Presets on Valhalla Super Massive. It’s free.
Preset menu on Pianoteq. You can demo for free.
hopefully this can be fixed.
Thanks!
1 Like
Hi,
I’m new to accessibility but I’ve been trying to figure out if there’s a way to have an element set as not enabled but still accessible.
For example I’ve got a PopupMenu::Item with setEnabled(false) however it’s then not visible to an accessibility user at all. It would be great for it to use the “Enabled” attribute within the native accessibility API instead of removing the handler altogether unless there’s something I’m missing.
Hello! Is this still the best thread to discuss accessibility questions?
I have a “musical key” menu, where the items for selection are “C”, “C#”, “D”, etc.
Is there a way to have “C#” displayed, but have the screen reader say “C sharp”?
Thanks in advance.
I believe you want to set the Component’s description (via setDescription), and perhaps its help text via setHelpText. If you need something more complex for any reason, you may have to resort to creating a custom AccessibilityHandler for your Component (createAccessibilityHandler).
@jrlanglois , thanks for your reply. I realize now that my original question was not specific enough. I am defining a PopupMenu, and I want to set the description text or help text for an Item in the popup menu. I don’t see a setTitle() or setDescription() function for Items in a PopupMenu.
I think that the issue here re: Items in a PopupMenu, is that Items are not components, and so they don’t have their own title, description, or help text.
There is another post on the forum (with no replies) asking about separate tooltips for Items in a PopupMenu.
Is there a solution for the issue? Restated below:
I have a “musical key” PopupMenu, where the Items for selection have text fields “C”, “C#”, “D”, etc.
Is there a way to have “C#” displayed, but have the screen reader say “C sharp”?
2 Likes
If you’re adding string items to a popup menu then no, there’s no way to specify separate accessibility info.
You could look at adding custom items instead: JUCE: PopupMenu Class Reference
Might be a bit overkill for such a simple feature though, but AFAIK that’d be the only way to do it right now.
That linked function: “Note that native macOS menus do not support custom components.”
Very early on in this thread @Scottsdale mentions the longstanding convention on Windows whereby Alt will bring focus to an application’s main menu. Together with the arrows keys one should be able to navigate all menu items this way. The same goes for Alt+F to access the file menu, Alt+E, edit, etc. Is there any way the JUCE menu can be set up like this? The screen reader can read almost every other part of my app, but blind users can’t access the dropdown menus using keyboard shortcuts. They can, off course, use shortcuts for the menu commands, but only if they happen to know all the shortcuts. Any ideas? Right now I’m using keyboard shortcut to manually show the menus, but it doesn’t fell like a good solution.
3 Likes
Does Pro Tools support VoiceOver navigation to the JUCE components?
When I enter my plug-in via VoiceOver keyboard navigation, from the “frame” that Pro Tools provides for the plug-in, it speaks the name of a window that I presume is the one created by the DAW. I enter the plug-in at this point using VO-Shift-DownArrow. After entering, Pro Tools reads the first parameter, with the type “Parameter”, rather than “button”, “slider”, etc. While in this mode, VO-left and VO-right navigate the parameter list, and the parameters are read in the order that they were created.
I have occasionally seen the VoiceOver navigation that is common in other DAWs, but only if I “trick” the system by setting VoiceOver to follow my mouse clicks (in the VoiceOver utility app) and then clicking within the plug-in.
Is there a setting in Pro Tools, or some other VoiceOver method, that I can use to navigate using the data that I am providing via the JUCE accessibility API?
Thanks in advance.