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

Special attribute for macOS accessibility #10305

Merged
merged 5 commits into from Sep 11, 2017

Conversation

Projects
None yet
3 participants
@ivmirx
Copy link
Contributor

ivmirx commented Aug 19, 2017

In the issue #7206 we were discussing that Electron apps are inaccessible unless VoiceOver is enabled. While it's a working solution for users with vision impairment, all other users and apps that require accessibility can't interact with Electron-based software because they don't keep VoiceOver running.

I suggest adding AXManualAccessibility for programmatically enabling it in Electron apps. The reason for a new attribute is that AXEnhancedUserInterface is already reserved by VoiceOver.

Adding this attribute will allow both Electron developers and 3rd party developers to enable and disable accessibility from their code by calling accessibilitySetValue:forAttribute: on the application.

It will be also possible to create a small utility app to switch accessibility in Electron-based apps until there's a native UI solution (like the accessibility settings page in Chrome).

Special attribute for macOS accessibility #7206
In the linked issue we were discussing that Electron apps are inaccessible unless VoiceOver is enabled. While it's a working solution for users with vision impairment, all other users and apps that require accessibility can't interact with Electron-based software because they don't keep VoiceOver running.

I suggest adding `AXManualAccessibility` for programmatically enabling it in Electron apps. The reason for a new attribute is that `AXEnhancedUserInterface` is already reserved by VoiceOver.

Adding this attribute will allow both Electron developers and 3rd party developers to enable and disable accessibility from their code by calling `accessibilitySetValue:forAttribute:` on the application.

It will be also possible to create a small utility app to switch accessibility in Electron-based apps until there's a native UI solution (like the accessibility settings page in Chrome).
@welcome

This comment has been minimized.

Copy link

welcome bot commented Aug 19, 2017

💖 Thanks for opening this pull request! 💖

Here is a list of things that will help get it across the finish line:

  • Follow the JavaScript, C++, and Python coding style.
  • Run npm run lint locally to catch formatting errors earlier.
  • Document any user-facing changes you've made following the documentation styleguide.
  • Include tests when adding/changing behavior.
  • Include screenshots and animated GIFs whenever possible.
    We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

@ivmirx ivmirx changed the title Special attribute for macOS accessibility #7206 Special attribute for macOS accessibility Aug 19, 2017

@zeke

This comment has been minimized.

Copy link
Member

zeke commented Aug 21, 2017

Thanks, @ivmirx. Can you add some API documentation for this?

@ivmirx

This comment has been minimized.

Copy link
Contributor

ivmirx commented Aug 22, 2017

@zeke thank you for looking into this. I added the macOS case to the accessibility tutorial.

The example code will work from Cocoa apps and should also work via NodObjC for Electron apps. But maybe I'm missing an easier way for Electron apps to switch their own accessibility.

@zeke

This comment has been minimized.

Copy link
Member

zeke commented Aug 22, 2017

maybe I'm missing an easier way for Electron apps to switch their own accessibility

Yeah this would be ideal. End-users of Electron should generally not be exposed to C++ code, but should rather use a JavaScript API that hooks into the underlying C++ implementation.

@ivmirx

This comment has been minimized.

Copy link
Contributor

ivmirx commented Aug 24, 2017

I added an accessibility setter to the app bindings and updated docs with a warning about performance.

Overall I haven't experienced noticeable performance issues when running many Chrome tabs with accessibility enabled (Mac Mini 2012) but there's some overhead according to dev tools (depending on DOM complexity and update frequency).

@@ -890,6 +890,15 @@ technologies, such as screen readers, has been detected. See
https://www.chromium.org/developers/design-documents/accessibility for more
details.

### `app.setAccessibilitySupportEnabled(value)` _macOS_ _Windows_

This comment has been minimized.

@zeke

zeke Aug 27, 2017

Member

I would suggest using a more descriptive name than value for the boolean. Something like enabled would be more consistent with other APIs that accept boolean arguments:

  • win.setResizable(resizable)
  • win.setMovable(movable)
  • win.setMinimizable(minimizable)

This comment has been minimized.

@ivmirx

ivmirx Aug 27, 2017

Contributor

Oh, it was enabled initially but then I decided to follow the app.commandLine.appendArgument(value) nearby. Fixed!

@zeke
Copy link
Member

zeke left a comment

From an user perspective, this is looking great. Left a few comments on documentation and expected behavior.

@@ -890,6 +890,15 @@ technologies, such as screen readers, has been detected. See
https://www.chromium.org/developers/design-documents/accessibility for more
details.

### `app.setAccessibilitySupportEnabled(enabled)` _macOS_ _Windows_

* `enabled` Boolean - Enable or disable accessibility tree rendering

This comment has been minimized.

@zeke

zeke Aug 28, 2017

Member

Is accessibility support disabled by default? If so, these docs should probably mention that.

For folks who don't know what the "accessibility tree rendering" is, a link would be helpful. Is this the right URL? https://developers.google.com/web/fundamentals/accessibility/semantics-builtin/the-accessibility-tree

This comment has been minimized.

@ivmirx

ivmirx Aug 28, 2017

Contributor

Yes, it's disabled by default both in Chrome and Electron. The link is super helpful, adding it.


### Assistive Technology

Electron application will enable accessibility automatically when it detects assistive technology (Windows) or VoiceOver (macOS). See Chrome's [accessibility documentation](https://www.chromium.org/developers/design-documents/accessibility#TOC-How-Chrome-detects-the-presence-of-Assistive-Technology) for more details.

This comment has been minimized.

@zeke

zeke Aug 28, 2017

Member

"Electron application will enable accessibility automatically" -- just so I understand correctly: does this mean the presence of these assistive features will automatically cause accessibility to be enabled, regardless of the current setting?

Or does it only mean that these features will be used if setAccessibilitySupportEnabled(true) was explicitly called in the app?

This comment has been minimized.

@ivmirx

ivmirx Aug 28, 2017

Contributor

The first one – system assistive utilities have a priority and will enable accessibility regardless of the setAccessibilitySupportEnabled(). So an Electron app's developer can be unaware of this method and accessibility will still work for many users who have VoiceOver on.

For users who need accessibility without VoiceOver there are 3 options:

  • ask an Electron app's developer to expose accessibility switch in settings using setAccessibilitySupportEnabled(true)
  • ask their assistive software developer to start applying the AXManualAccessibility attribute on Electron apps
  • use some custom utility to apply AXManualAccessibility on Electron apps (I'm going to create an open-source one later)

Electron application will enable accessibility automatically when it detects assistive technology (Windows) or VoiceOver (macOS). See Chrome's [accessibility documentation](https://www.chromium.org/developers/design-documents/accessibility#TOC-How-Chrome-detects-the-presence-of-Assistive-Technology) for more details.

On macOS 3rd party assistive technology can switch accessibility inside Electron applications by setting the attribute `AXManualAccessibility` programmatically:

This comment has been minimized.

@zeke

zeke Aug 28, 2017

Member

On macOS, third-party

@zcbenz

zcbenz approved these changes Sep 11, 2017

@zcbenz zcbenz merged commit e6733b4 into electron:master Sep 11, 2017

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@welcome

This comment has been minimized.

Copy link

welcome bot commented Sep 11, 2017

Congrats on merging your first pull request! 🎉🎉🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment