Show if accessibility is being handled

[sudara]

This should basically report false for a lot of components. Not sure if it's possible to show which actions are being handled or what detail can happen here...

[dikadk]

I've added bool property to Properties panel. I'm showing value of "isAccessible()" on Component. It's actually is showing as "true" on all enabled & visible Components.

According to juce docs:

By default any visible and enabled Component is accessible to screen reader clients and exposes some basic information such as title, description, help text and its position in the hierarchy of UI elements.

I'll come back to this to add more information accessibility information like:
AccessibilityRole,
AccessibilityActions

[sudara]

Ah ok, if it's always going to be enabled on visible components, perhaps it doesn't make sense to show it, replacing it with the title/description/role/actions metadata makes more sense!

[sudara]

I guess accessibility metadata would be awesome to

1. edit in the inspector
2. json file gets updated
3. app notices the json file gets uploaded and re-consumes it

Not a job for this time around.... just thinking about which component things we can move to json to start work on a "declarative" api...😈

[baconpaul]

It's super handy to compare the accessibility view with what the built in accessibility inspectors show. Here's the macOS inspector looking at surge

So a few things which are super important ifAccessible

1. The name. You can get these with getAccessibilityHandler() check if null and then getTitle(). This is what users hear when then first hit an element in the screen reader. It usually defaults to component->getTitle() but not always.
2. The role. The accessibility handler returns a role. You can just display that enum for now
3. The value. This is a bit trickier to get since it depends on role but the API on AccesibilityHandler returns a Value object which you can query.

Just having these three displayed under the isAccessible true item in the inspector would be a huge boon

The actions are also available from the handler. You can see the mac inspector gives you an option to trigger them which is super handy. But since the inspector already exists you don't need to duplicate all of this in melatonin. Just having the three items above plus the focus traversal vs mouse traversal described in #97 would cover I would say 95% of the debugging i had to do to get surge accessible.

(Surge has a big blind user community and we worked hard to make almost everything work in the screen reader)

Oh and as with al my other issues this morning I'm happy to do this!

[sudara]

Would LOVE to display accessibility name and role. I'm a n00b and doesn't understand the benefit of value or whether that'll be useful— but I trust you 100% on this stuff.

Feel free to simply implement what makes most sense to you and submit a PR. Or if it's not something you need at the moment, @dikadk can also take a look, he just mentioned he'd like to keep contributing.

Super appreciative of your time and attention here!

[baconpaul]

I actually have a quick hack this morning that starts doing it. The code is organized super cleanly! Will get a pr together this week