[Feature Request] Make DefaultActionContext public
jasonmohyla opened this issue · 5 comments
Is your feature request related to a problem? Please describe.
We are managing controlled access to OEM software on a VM. This software requires a login after certain conditions are met. I have a POC using Axe to find the login controls and enter text (username and password so users don't know them). But the class DefaultActionContext is set up to be internal.
Describe the solution you'd like
I would like DefaultActionContext and its static method GetDefaultInstance to be public. This change will make using updates to Axe much easier for us. I understand this is out of the scope of this project.
Describe alternatives you've considered
The only other option is to maintain an internal fork of the Axe project where these two changes are maintained and when updates to Axe are published, merge the new codes into the fork.
Additional context
As I said above, I understand that our use of Axe is not in scope of what the project is for. But since the change is to only make a class and one of its methods public, it seems like a small ask. If not allowed, that is fine, but how could I go from having a process ID and getting access to the list of A11yElements and ElementContext of the process in question?
This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!
@jasonmohyla ,
When you say, "I have a POC using Axe to find the login controls and enter text (username and password so users don't know them)...", You're saying you are getting the UIA elements from axe-windows and setting focus to them and performing operations on them?
If my understanding as described above is correct, you would probably be better off just adding some UI Automation code to your app which does what you want directly rather than going through the trouble of using axe-windows. It's pretty easy in UIA to get the windows element and search for decendent elements using the IUAutomationElement7 interface.
Hi, @jasonmohyla! Axe.Windows has 2 interfaces--the publicly supported one documented here, and the unsupported one that we use for Accessibility Insights for Windows (also owned by our team). This unsupported interface may change at any time and in any way, depending on product needs. There are absolutely no guarantees for build-to-build compatibility, and we actively try to steer people away from it--that's why the DefaultActionContext class isn't public, and why we want to keep it that way.
If you're willing to live with that risk, then the workaround is trivial. Everything used by the DefaultActionContext is already public, so you can just make your own copy of the class in your code (MIT license allows this), then use your class instead of ours. I've written a tiny sample that does this: ActionContextDemo.zip
The "safe" option--as in very unlikely to change under you--is to call into UIA directly, as @RobGallo already suggested. Axe.Windows ultimately gets its data from UIA, and you're free (again, MIT license) to copy the code that you need. If your code just needs a list of elements, then Axe.Windows is adding a lot of stuff that you aren't actually using.
Thanks for your interest in Axe.Windows! I'm going to close this as out of scope, but best of luck!
This issue has been marked as being beyond the support scope of Accessibility Insights. It will now be closed automatically for house-keeping purposes.