Accesibility Change One: Show Acessible Info #99
Conversation
This change does two things 1. If a widget is accessible with a title, use that title for the melatonin sidebar rather than clasname and preferentially over juce name. (If it has both an accessible title and juce name and they differ the juce name is shown additionally) 2. collect and display basic accessible info in the inspector panel. these are title, type, value, and handler class.
|
I'd appreciate a review and feedback here the one thing I couldn't figure out is how to make the sub section in a properties panel indent properly. It works and folds but doesn't look right. Heres' what I mean
Your thoughts welcome! |
|
Awesome! Properties have been flat so far, which is why nested styles aren't happy out of the box. If we wanted to go with nested, I guess we'd want to match the styles in the main navigation tree and ensure that toggling the section is "remembered" across selections. Part of me wonders if "accessibility" should be a collapsable top level section (ala preview/color/properties)... I'll have to check the branch out to weigh in on that, so I'll get back to you! |
| if (nm != acctitle && !nm.isEmpty()) | ||
| { | ||
| // but if i also have an internal name, dont' suppress it | ||
| acctitle += "(name=" + nm + ")"; |
There was a problem hiding this comment.
I'll check this out locally and toy with it. From reading the code, I think will lead to ugly names in the tree like like Pitch Stiffness(pitchStiffness) for people like me who use component's setName widely. I think it's good thinking to prefer the accessible name for tree display but perhaps we should always display a component's name as a discrete property (like we do with Class).
Sidebar: I can't help but feel like this is in part a JUCE issue / historical artifact that component has both name / title. There's some conventions missing so I'm guessing devs are all over the place in terms of their implementations. In my setups, a component's name is a "key" that's used to look up its "UI friendly name" from data which is then used in the UI, can be used for accessibility, can be swapped out with translations, etc....
There was a problem hiding this comment.
Yeah I agree with your sidebar
Putting the name after the class in the properties list and backing out this change is a good idea
And yes having an accessibility top level area would also solve a lot of the other things we want to do but was a bigger change so wasn't sure if you were up for it. Then we could do things like 'next- and previous- focus target' and the action list also.
There was a problem hiding this comment.
Also: I found out from using inspector that I don't have a name on any of my components!
One of the things I think juce wanted to avoid with name/title by the way is if users had given their components names like 'dumbSwitchToUnbreakStuff' in code, exposing that as user display for screen reader users only was a bit risky. That's also why I chose the screen reader name to beat the accesible name since it is in the end user UX.
There was a problem hiding this comment.
One of the things I think juce wanted to avoid
Amazingly get/setName seem to be... 17 years old according to git blame. I'm guessing they are mainly used as internal identifiers by devs?
Then we could do things like 'next- and previous- focus target' and the action list also.
I'm into it! Let's make it its own panel.
Some of the panel / header logic is a bit messy if I remember (the headers overlay the panels as they can contain action buttons when collapsed. And I think PROPERTIES is setup to be the last panel, would need some work if we wanted to plop accessibility afterwards. In short, feel free to uhh.. nope out of that work if it gets finicky, I don't mind getting in there.
There was a problem hiding this comment.
Ha I'll take a peek today and if its impossible i'll revert but otherwise will update this PR once I have it in
- Remove clumsy (name=) from the title - Add name to the properties tearsheet - Add an accesibility panel section to the main component - Move the accesible information display into that panel
|
OK! So I made the changes you suggested
You are right that the properties panel being last is 'special' and I didn't figure out quite how, but I solved that problem by having the accessibility panel come before that. LOL. Here's a screenshot from surge. Happy to make any other changes. This is immediately become useful for me though with even just this change. |
|
Love it!!!
Heh, I figured :) I'll find some time to check out the branch and merge tomorrow. I was hoping the tests would run too, that always trips me up on GitHub... |
|
You probably need to approve me as a first time pr contributor - there’s usually a button but you may also need to do a review first but we have pretty good pr actions in the clap juce extensions and clap wrapper projects if that helps too? |
|
Yeah, just strange as I have Actions set to This keeps being a problem on my repos, so I opened a ticket with support, I don't see any way for me to run the actions here:
|
|
This is perfect! Nice work! Thanks for being willing to move stuff top level, I think it works great. Apparently I have 0 components with accessibility titles on my app! I guess it's time I get to work. I'll have to learn about roles and actions too somewhere — almost all of my components are hand rolled, I avoid JUCE's widgets where possible (except for text editors) |
I have custom widgets and custom handlers too. feel free to ask. |
|
On actions your 'on' seems odd vs in clap-wrapper we have |
This change does two things
If a widget is accessible with a title, use that title for the melatonin sidebar rather than clasname and preferentially over juce name. (If it has both an accessible title and juce name and they differ the juce name is shown additionally)
collect and display basic accessible info in the inspector panel. these are title, type, value, and handler class.