Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MacOS Adapter - Sub roles #477

Closed
HolgerGottChristensen opened this issue Oct 29, 2024 · 7 comments · Fixed by #480
Closed

MacOS Adapter - Sub roles #477

HolgerGottChristensen opened this issue Oct 29, 2024 · 7 comments · Fixed by #480

Comments

@HolgerGottChristensen
Copy link
Contributor

I have been trying to implement accessibility for some of my controls, and is currently comparing the accessiblity tree generated from my application, and from the equivalent SwiftUI application.

When implementing accessibility for checkboxes, toggle buttons and switches, i noticed the accessibility tree generated by SwiftUI uses the role CheckBox for all the three controls, but with different sub roles.

https://developer.apple.com/documentation/appkit/nsaccessibilitysubrole?language=objc

How is it intended to implement these using AccessKit? I see AccessKit specifies CheckBox and Switch as different roles, but I see no role equivalent to the toggle button.

I can also see when the Switch and CheckBox roles from AccessKit are used, they both set the NSAccessibilityRole CheckBox, but no sub role.

Toggle button from SwiftUI

Screenshot 2024-10-29 at 21 16 28

Checkbox from SwiftUI

Screenshot 2024-10-29 at 21 17 13

Toggle from SwiftUI

Screenshot 2024-10-29 at 21 18 04
@DataTriny
Copy link
Member

Thank you @HolgerGottChristensen for digging into this. We currently don't implement sub roles. I actually investigated this for #372 but forgot to write about it.

@DataTriny
Copy link
Member

We need to implement the accessibilitySubrole method like Chromium does.

@HolgerGottChristensen
Copy link
Contributor Author

Adding support for sub roles would solve part of my problem. I can make a pull request for this feature, but maybe you have some code in chromium I should base it on?

The second part of my problem is now solved directly by implementing sub roles. As I understand it AccessKit contain roles for Switch and Checkbox, but not for toggle button. Would you be interested in adding a new AccessKit role for toggle buttons, or should this be implemented in some kind of extension?

@mwcampbell
Copy link
Contributor

In AccessKit, we express toggle buttons by using the Button role and setting the toggle state. The rationale for not having a separate ToggleButton role is that it's redundant. If we had a ToggleButton role, then two illegal states would be representable: a ToggleButton role but no toggle state, and a Button role with a toggle state. So the platform adapter should map the combination of a Button role and a toggle state to a toggle button role or subrole if applicable.

@HolgerGottChristensen
Copy link
Contributor Author

HolgerGottChristensen commented Oct 30, 2024

Perfect, I knew I had missed something😃

I will create a pull request in the upcoming days. Do you want the implementation based on some chromium code?

https://github.com/chromium/chromium/blob/main/ui/accessibility/platform/ax_platform_node_cocoa.mm#L59

@mwcampbell
Copy link
Contributor

Feel free to look at Chromium code if it clarifies anything for you, but we've diverged from Chromium at this point, and you may be able to figure out a straightforward mapping on your own.

@DataTriny
Copy link
Member

Looking at Chromium's mapping will save you time. As you can see not all subroles are documented by Apple and Chromium developers had to find the string values on their own.

With that being said, some subroles exist and you should use them instead of raw strings. In your specific case, you are looking for NSAccessibilitySwitchSubrole and NSAccessibilityToggleSubrole.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants