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 be about the implementation of accessibility (special features) in the mobile application.

    Brief background


    Recently, on behalf of the “Accessible Life” project, I began to help Yandex in implementing the accessibility of their navigation applications.

    I was confronted with the fact that many things that do not come to 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.

    So 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 a map, the application must switch modes (I don’t remember exactly the details).

    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 worked 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, the 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 the 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 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.

    Also popular now: