3 ms·

The accessibility APIs can be programmed against by anyone. If there is a way to make something like this accessible to screen readers in some useful way, it wo

The accessibility APIs can be programmed against by anyone. If there is a way to make something like this accessible to screen readers in some useful way, it would likely involve specific accessibility work either way.

saagarjha 6y ago
Platform widgets do a lot of the accessibility work for you. In some cases you can get away with doing zero* work. *Or very close to zero
mwcampbell 6y ago
> If there is a way to make something like this accessible to screen readers in some useful way If by "something like this" you mean a text editor, then there's no question; they can be made accessible with a screen reader, and some complex ones (e.g. Visual Studio Code, Visual Studio, and Xcode) are accessible already. > it would likely involve specific accessibility work either way. For the main UI of a full-featured programmer's editor or word processor, that's definitely true. What I want to avoid is developers using a custom GUI toolkit where the platform's native toolkit would do, because they want the best possible performance (regardless of whether the platform's toolkit is good enough), and forfeiting all of the accessibility benefits that the platform's native toolkit brings more or less automatically.
- notriddle 6y ago
  One of the cliches of modern business is: don't outsource your core competencies. If you are developing a text editor, you should put the time into your text editor. It's the thing that distinguishes you from your competitors. And it's the part that users interact with the most. Your users are likely to ask for features, like vi keybindings, that you can't easily build with the OS-native text field anyway. Incidental forms, like your preferences screen? Unless you have a lot of time and money to burn, the OS widgets will probably be better than yours.
rudedogg 6y ago
Not sure about other platforms, but I like the way macOS/iOS uses the accessibility metadata to look up UI elements for testing. So in order to "access" a button in a test, you have to do the accessibility work. You need it to take automated screenshots too.
- ygra 6y ago
  It's the same on Windows. Automated UI testing almost always uses the accessibility APIs, both to find controls and to interact with them.
- mwcampbell 6y ago
  Implementing enough accessibility to enable automated testing is a good start, but unless you're aware of the needs of people using screen readers and other assistive technologies (and possibly incorporate those requirements into your automated tests), you won't automatically get full accessibility just by exposing the information that your tests need in order to control the UI.

saagarjha 6y ago

Platform widgets do a lot of the accessibility work for you. In some cases you can get away with doing zero* work. *Or very close to zero

mwcampbell 6y ago

> If there is a way to make something like this accessible to screen readers in some useful way If by "something like this" you mean a text editor, then there's no question; they can be made accessible with a screen reader, and some complex ones (e.g. Visual Studio Code, Visual Studio, and Xcode) are accessible already. > it would likely involve specific accessibility work either way. For the main UI of a full-featured programmer's editor or word processor, that's definitely true. What I want to avoid is developers using a custom GUI toolkit where the platform's native toolkit would do, because they want the best possible performance (regardless of whether the platform's toolkit is good enough), and forfeiting all of the accessibility benefits that the platform's native toolkit brings more or less automatically.

notriddle 6y ago
One of the cliches of modern business is: don't outsource your core competencies. If you are developing a text editor, you should put the time into your text editor. It's the thing that distinguishes you from your competitors. And it's the part that users interact with the most. Your users are likely to ask for features, like vi keybindings, that you can't easily build with the OS-native text field anyway. Incidental forms, like your preferences screen? Unless you have a lot of time and money to burn, the OS widgets will probably be better than yours.

rudedogg 6y ago

Not sure about other platforms, but I like the way macOS/iOS uses the accessibility metadata to look up UI elements for testing. So in order to "access" a button in a test, you have to do the accessibility work. You need it to take automated screenshots too.

ygra 6y ago
It's the same on Windows. Automated UI testing almost always uses the accessibility APIs, both to find controls and to interact with them.
mwcampbell 6y ago
Implementing enough accessibility to enable automated testing is a good start, but unless you're aware of the needs of people using screen readers and other assistive technologies (and possibly incorporate those requirements into your automated tests), you won't automatically get full accessibility just by exposing the information that your tests need in order to control the UI.