Appeal to the company "1C" by the All-Russian Society of the Blind on the issue of ensuring the non-visual accessibility of its products (technical aspects of the problem)
According to the press service of the All-Russian Society of the Blind, the president of this organization sent an appeal to the general director of 1C Company, BG Nuraliev, in which he noted the urgency of the problem of employment and vocational rehabilitation of the visually impaired in the context of the inaccessibility of 1C products for software used for non-visual work with computer equipment.
The full text of the press release can be found on the BOC website . Here, it makes sense to give a few technical clarifications on the issue raised, since, in view of the specificity of this topic, there is a risk of her being misunderstood by people who are not very close to non-visual accessibility technologies, but who are decision makers.
First of all, it should be noted that working with a computer without using any vision is possible and is a common practice, including in Russia. At the same time, the work of a totally blind user is possible not only in a specially created working environment, but also in a standard interface of the operating system and in standard applications, often with a performance comparable to the performance of the average sighted person (although the performance of non-visual work is a separate big question, beyond the current topic).
Moreover, if we are talking about a serious professional activity of a blind person, then maximum efficiency, as a rule, is achieved with the use of common working environments, simply with the use of auxiliary software running in the background and providing screen information in an alternative form: speech stream or text output on a tactile display.
')
Details about the principles of non-visual work at the computer can be found in the relevant article on Habrahabr . Here we simply emphasize that any talk about the development of alternative working environments in the context of the professional work of the blind in general is untenable, and their inconsistency is proved by the history of the development of the entire industry, so this question can not even be raised.
The problem of non-visual availability of software interfaces, and in particular the 1C environment, is not far-fetched.
Unfortunately, the number of people with vision problems, despite the development of medicine, on the contrary increases, as in the modern world the load on the visual function of the body has increased significantly. This causes an increasing number of people every year who need to be rehabilitated due to a decrease or complete loss of vision. Moreover, including professional rehabilitation, and not just household.
At the state level, this problem is realized, and one of the ways to solve it is quoting jobs for people with disabilities. That is, the state obliges companies to necessarily have people with disabilities in their staff (the type of violation does not differentiate, but for reference, the proportion of visually impaired people in the total mass is about 8%). It can even be argued that, to a certain extent, there is an unmet demand in the labor market for people with disabilities who are able to work at a high professional level.
The inaccessibility of professional software for the blind is one of the factors that make it difficult to solve this problem for the benefit of all three parties:
The 1C software package for Russia and individual CIS countries in many areas is practically a de facto standard, therefore the issue of its availability, in the context of the identified problem, is extremely acute.
In the aforementioned address of the BOC President, there is the following phrase:
You should make a discount on the fact that this is just a press release, and do not take this information as a guide to action.
First, JAWS and NVDA are only special cases of auxiliary software, although the most common. However, besides them, even now there are two more solutions on the Russian market (COBRA and SuperNova), and in the foreseeable future a third one should appear (Window-Eyes).
Secondly, the availability of the application is more correctly implemented at a lower level, rising to the level of auxiliary software only in some cases.
In fact, there are two levels:
In turn, the level of the screen access program can also be divided into:
Thus, there are three approaches to implementing application accessibility. True, they often flow into each other.
Based on the foregoing, the following strategies for the implementation of application accessibility can be distinguished.
I. Adaptation of the program under the general system accessibility API
In this area, the developer must refine his graphical interface with the use of general technical recommendations of accessibility and special APIs: for Windows, in general, this is Microsoft Active Accessibility and more modern Microsoft UI Automation.
If an application interface is developed using some kind of separate environment or framework, then they usually have their own technologies, for example, Java Access Bridge for Java or QAccessibleInterface for Qt.
As a rule, a problem arises when a developer uses interface frameworks or custom classes, where unknowingly loses accessibility functionality, since if in the Windows environment the interface is built from standard elements and according to general rules, then its accessibility usually does not raise serious issues.
This is a good strategy, as it provides universal accessibility, that is, all screen programs at once.
Ii. Adaptation of the application for a specific screen access program
In this direction, the developer focuses on what implements the transfer of relevant information through the API of a specific screen access program. This can be either using the dll provided by the manufacturer of the screen access program, or calling OLE Automation objects also belonging to the screen access program.
The problem is that the API for all screen readers is different, so you have to sharpen the availability of the application for each of them. In addition, the functionality of the API is also different, for example, somewhere it allows you to initialize the transmission of both a voice message and data output on a tactile display, and somewhere only a voice message.
Moreover, while ensuring the availability of a rich interface, the use of quite a few functional APIs for screen access is extremely inconvenient and low efficient. In general, this is a fairly bad practice, justified only in some individual cases and for solving small local problems.
Iii. Development of a module for screen access program
In this approach, the original application, the availability of which is ensured, may not be modified at all. Work is conducted purely at the level of the screen access program.
Serious screen access programs have customization functionality, which makes it possible to develop for them a kind of script or plugin that will implement the specific processing logic of the interface elements of a specific application. Traditionally, this is the most common solution to a problem, but this does not mean that it is the best.
Its prevalence is explained only by the fact that it is often easier to develop a module for a separate screen-access program than to convince the developer of an application that it is necessary to modify it. That is, this is the only option that is available without the need for collaboration with the application developer.
The truth is to solve accessibility problems absolutely without the assistance of the developer also does not always work. Sometimes the interface in principle does not provide an opportunity to get any data except through a visual channel. In particular, this is very often the fault of antivirus developers, accidentally or just in case, by killing the accessibility API. In such cases, the application developer is required at least minimal assistance in the form of providing necessary data to some of the APIs, for example, the position of the system focus or window events.
As a rule, modules are written either by the developers of the screen access program, if we are talking about a very common application, the availability of which is extremely relevant, for example, Microsoft Office, independent programmers, who are usually just users of a screen access program and solving their own tasks, or outsource programmers employed by the application development company.
To make it clear, consider a simplified example with the implementation of the availability of a graphical button that does not have a text signature, by which it is identified by a blind user:
These are three basic strategies, although various combinations of these may exist, as well as some more sophisticated ways.
The question of choosing the optimal strategy for the implementation of the availability of an application can often be controversial, but in general it can be argued that it makes sense to give priority to strategies I, that is, the universal way through system-wide APIs. Strategy II in general in the case of large projects is inefficient, and strategy III, as a rule, is a kind of compromise, plus it can be used to increase usability when strategy I is fully implemented.
The full text of the press release can be found on the BOC website . Here, it makes sense to give a few technical clarifications on the issue raised, since, in view of the specificity of this topic, there is a risk of her being misunderstood by people who are not very close to non-visual accessibility technologies, but who are decision makers.
Initial educational program
First of all, it should be noted that working with a computer without using any vision is possible and is a common practice, including in Russia. At the same time, the work of a totally blind user is possible not only in a specially created working environment, but also in a standard interface of the operating system and in standard applications, often with a performance comparable to the performance of the average sighted person (although the performance of non-visual work is a separate big question, beyond the current topic).
Moreover, if we are talking about a serious professional activity of a blind person, then maximum efficiency, as a rule, is achieved with the use of common working environments, simply with the use of auxiliary software running in the background and providing screen information in an alternative form: speech stream or text output on a tactile display.
')
Details about the principles of non-visual work at the computer can be found in the relevant article on Habrahabr . Here we simply emphasize that any talk about the development of alternative working environments in the context of the professional work of the blind in general is untenable, and their inconsistency is proved by the history of the development of the entire industry, so this question can not even be raised.
The urgency of the problem for all
The problem of non-visual availability of software interfaces, and in particular the 1C environment, is not far-fetched.
Unfortunately, the number of people with vision problems, despite the development of medicine, on the contrary increases, as in the modern world the load on the visual function of the body has increased significantly. This causes an increasing number of people every year who need to be rehabilitated due to a decrease or complete loss of vision. Moreover, including professional rehabilitation, and not just household.
At the state level, this problem is realized, and one of the ways to solve it is quoting jobs for people with disabilities. That is, the state obliges companies to necessarily have people with disabilities in their staff (the type of violation does not differentiate, but for reference, the proportion of visually impaired people in the total mass is about 8%). It can even be argued that, to a certain extent, there is an unmet demand in the labor market for people with disabilities who are able to work at a high professional level.
The inaccessibility of professional software for the blind is one of the factors that make it difficult to solve this problem for the benefit of all three parties:
- Disabled people who want to get a job;
- States seeking to fulfill their social functions;
- Organizations wishing to get a competent and efficient employee.
The 1C software package for Russia and individual CIS countries in many areas is practically a de facto standard, therefore the issue of its availability, in the context of the identified problem, is extremely acute.
Technical approaches
In the aforementioned address of the BOC President, there is the following phrase:
... there is a need to solve the problem of ensuring compatibility of the 1C program (version 8) with non-visual screen access programs (Jaws and NVDA). According to preliminary estimates, this refinement does not require significant time and material costs and we are ready to attract blind programmers to jointly solve this problem. ”
You should make a discount on the fact that this is just a press release, and do not take this information as a guide to action.
First, JAWS and NVDA are only special cases of auxiliary software, although the most common. However, besides them, even now there are two more solutions on the Russian market (COBRA and SuperNova), and in the foreseeable future a third one should appear (Window-Eyes).
Secondly, the availability of the application is more correctly implemented at a lower level, rising to the level of auxiliary software only in some cases.
In fact, there are two levels:
- The level of accessibility APIs implemented in the operating system;
- Level of the program of screen access (each program has its own implementation).
In turn, the level of the screen access program can also be divided into:
- API of the screen access program through which any application may be limited to interact with it;
- A module within a screen-access program, which is like a plugin, which is written specifically to implement specific options for interacting with the application, the availability of which is ensured.
Thus, there are three approaches to implementing application accessibility. True, they often flow into each other.
Solutions to the problem
Based on the foregoing, the following strategies for the implementation of application accessibility can be distinguished.
I. Adaptation of the program under the general system accessibility API
In this area, the developer must refine his graphical interface with the use of general technical recommendations of accessibility and special APIs: for Windows, in general, this is Microsoft Active Accessibility and more modern Microsoft UI Automation.
If an application interface is developed using some kind of separate environment or framework, then they usually have their own technologies, for example, Java Access Bridge for Java or QAccessibleInterface for Qt.
As a rule, a problem arises when a developer uses interface frameworks or custom classes, where unknowingly loses accessibility functionality, since if in the Windows environment the interface is built from standard elements and according to general rules, then its accessibility usually does not raise serious issues.
This is a good strategy, as it provides universal accessibility, that is, all screen programs at once.
Ii. Adaptation of the application for a specific screen access program
In this direction, the developer focuses on what implements the transfer of relevant information through the API of a specific screen access program. This can be either using the dll provided by the manufacturer of the screen access program, or calling OLE Automation objects also belonging to the screen access program.
The problem is that the API for all screen readers is different, so you have to sharpen the availability of the application for each of them. In addition, the functionality of the API is also different, for example, somewhere it allows you to initialize the transmission of both a voice message and data output on a tactile display, and somewhere only a voice message.
Moreover, while ensuring the availability of a rich interface, the use of quite a few functional APIs for screen access is extremely inconvenient and low efficient. In general, this is a fairly bad practice, justified only in some individual cases and for solving small local problems.
Iii. Development of a module for screen access program
In this approach, the original application, the availability of which is ensured, may not be modified at all. Work is conducted purely at the level of the screen access program.
Serious screen access programs have customization functionality, which makes it possible to develop for them a kind of script or plugin that will implement the specific processing logic of the interface elements of a specific application. Traditionally, this is the most common solution to a problem, but this does not mean that it is the best.
Its prevalence is explained only by the fact that it is often easier to develop a module for a separate screen-access program than to convince the developer of an application that it is necessary to modify it. That is, this is the only option that is available without the need for collaboration with the application developer.
The truth is to solve accessibility problems absolutely without the assistance of the developer also does not always work. Sometimes the interface in principle does not provide an opportunity to get any data except through a visual channel. In particular, this is very often the fault of antivirus developers, accidentally or just in case, by killing the accessibility API. In such cases, the application developer is required at least minimal assistance in the form of providing necessary data to some of the APIs, for example, the position of the system focus or window events.
As a rule, modules are written either by the developers of the screen access program, if we are talking about a very common application, the availability of which is extremely relevant, for example, Microsoft Office, independent programmers, who are usually just users of a screen access program and solving their own tasks, or outsource programmers employed by the application development company.
To make it clear, consider a simplified example with the implementation of the availability of a graphical button that does not have a text signature, by which it is identified by a blind user:
- Strategy I: Add a text label in the application interface to the button element and ensure accessibility for all screen readers.
- Strategy II: We add a DLL from the developer of the program X to the application package, and when the system focus hits an unsigned button, we give the program to the screen access program to pronounce the text label. If the user of the program of screen access Y calls for support, then either we will implement a similar scheme for this program, or we will advise him to switch to program X, and he is unlikely to be happy about it.
- Strategy III: agree with a specialist competent in writing modules for the screen access program X, or we will grow up to a specialist who develops a plugin that speaks a text label if an unsigned button gets into focus. If the user of program Y turns to support, then it is similar to strategy II.
These are three basic strategies, although various combinations of these may exist, as well as some more sophisticated ways.
The question of choosing the optimal strategy for the implementation of the availability of an application can often be controversial, but in general it can be argued that it makes sense to give priority to strategies I, that is, the universal way through system-wide APIs. Strategy II in general in the case of large projects is inefficient, and strategy III, as a rule, is a kind of compromise, plus it can be used to increase usability when strategy I is fully implemented.
Source: https://habr.com/ru/post/210110/
All Articles