We implement accessibility support without changing the visual component of the mobile application.
In this article there will be neither a line of code nor a single complex term. I will try to present it in such a way that even a person who is far from development will understand.
It will focus on the implementation of accessibility (special features) in a mobile application.
Recently, on behalf of the “Accessible Life” project, I began helping Yandex with the accessibility of their navigation applications.
I was confronted with the fact that many things that do not come to my mind are obvious things from my point of view: invisible elements on the screen, direct output of voice messages using the screen access API, and so on.
')
Therefore, I decided to put it all in a separate article.
In general, let's go.
In the process of working on maps, we encountered a problem:
When you click on the screen area with the map, the application should switch modes (I don’t remember the details for sure).
For a blind user with a screen-access program, this seemingly simplest action becomes impossible.
The point is that screen-access programs “see” only specific objects on the screen: buttons, text blocks, input fields, controls and lists. And in the Yandex.Maps application, clicking on the map was not processed as an object selection, but as touching a certain area of ​​the screen.
The solution is quite simple: make a button on the screen without a frame, with a transparent background and no visible text (zero font, which is not so aesthetically pleasing from the programmer's point of view, or special attributes that display text only for screen access programs without displaying it on the screen).
This approach shocked and surprised programmers, but in practice everything turned out, the idea worked and is actively implemented everywhere where you need to handle direct clicks on the screen area.
Another problem is that sometimes you need to display additional information only for a blind user. In this case, pop-up messages will spoil the design and will interfere with the rest, and implementing a separate application mode in which such messages will be displayed is cumbersome and illogical.
The solution is not as obvious as in the case of invisible buttons, but also lies on the surface.
You need to use the API of the screen access program itself to display messages. This is less cumbersome in the program code, it does not force the developer to make additional efforts to create separate modes, additional settings, etc.
By the way, in case of using the screen reader API, you do not even need to check if it is enabled. If the program is running, it will display a message using a speech synthesizer selected by the user. And if the program is turned off, just nothing will happen, and the average user will not notice anything.
This is more of a recommendation than a life hack, but I have to mention it.
Remember that for the screen access program there are only objects on the screen?
So, the type of the object also matters. In the text can not be pressed, in her opinion, and the button can not be copied. That is, if the table with the settings is implemented as a large text block that “catches” clicks on different parts of itself, then such a table is not available for the screen access program. It will be read, but will not allow to interact.
The solution is quite simple: use the elements as intended.
If it should be a list, you need to use an element in the code that describes the list;
if it is a button, then it must be the button; if it is a slider, a regulator of something, then it should be a slider element, and not text with animation when dragging.
In conclusion, I want to say that the development for Windows, though not significantly, differs from the development for mobile platforms, therefore, the features of accessibility for Windows are different from those for Android / Ios.
It will focus on the implementation of accessibility (special features) in a mobile application.
Brief background
Recently, on behalf of the “Accessible Life” project, I began helping Yandex with the accessibility of their navigation applications.
I was confronted with the fact that many things that do not come to my mind are obvious things from my point of view: invisible elements on the screen, direct output of voice messages using the screen access API, and so on.
')
Therefore, I decided to put it all in a separate article.
In general, let's go.
Invisible elements
Problem
In the process of working on maps, we encountered a problem:
When you click on the screen area with the map, the application should switch modes (I don’t remember the details for sure).
For a blind user with a screen-access program, this seemingly simplest action becomes impossible.
The point is that screen-access programs “see” only specific objects on the screen: buttons, text blocks, input fields, controls and lists. And in the Yandex.Maps application, clicking on the map was not processed as an object selection, but as touching a certain area of ​​the screen.
Decision
The solution is quite simple: make a button on the screen without a frame, with a transparent background and no visible text (zero font, which is not so aesthetically pleasing from the programmer's point of view, or special attributes that display text only for screen access programs without displaying it on the screen).
This approach shocked and surprised programmers, but in practice everything turned out, the idea worked and is actively implemented everywhere where you need to handle direct clicks on the screen area.
Direct output of voice messages by means of the screen access program itself
Problem
Another problem is that sometimes you need to display additional information only for a blind user. In this case, pop-up messages will spoil the design and will interfere with the rest, and implementing a separate application mode in which such messages will be displayed is cumbersome and illogical.
Decision
The solution is not as obvious as in the case of invisible buttons, but also lies on the surface.
You need to use the API of the screen access program itself to display messages. This is less cumbersome in the program code, it does not force the developer to make additional efforts to create separate modes, additional settings, etc.
By the way, in case of using the screen reader API, you do not even need to check if it is enabled. If the program is running, it will display a message using a speech synthesizer selected by the user. And if the program is turned off, just nothing will happen, and the average user will not notice anything.
Divide!
Problem
This is more of a recommendation than a life hack, but I have to mention it.
Remember that for the screen access program there are only objects on the screen?
So, the type of the object also matters. In the text can not be pressed, in her opinion, and the button can not be copied. That is, if the table with the settings is implemented as a large text block that “catches” clicks on different parts of itself, then such a table is not available for the screen access program. It will be read, but will not allow to interact.
Decision
The solution is quite simple: use the elements as intended.
If it should be a list, you need to use an element in the code that describes the list;
if it is a button, then it must be the button; if it is a slider, a regulator of something, then it should be a slider element, and not text with animation when dragging.
Conclusion
In conclusion, I want to say that the development for Windows, though not significantly, differs from the development for mobile platforms, therefore, the features of accessibility for Windows are different from those for Android / Ios.
Source: https://habr.com/ru/post/432756/
All Articles