Automated testing of the basic accessibility of interfaces for Android applications
Google has developed a tool to make mobile apps interfaces for Android OS more accessible for users with disabilities. It is a special Accessibility Scanner application that scans the graphical user interface and displays a description of the accessibility problems found and recommendations for correcting them. Accessibility Scanner can provide recommendations for increasing too small controls, increasing the contrast of the image, as well as adding text labels to the controls, which together increase the convenience and accessibility of the interface.
The Accessibility Scanner application does not require special technical skills for its use and, among other things, is recommended for use by ordinary people who can generate a report on the problematic interface and send it to the developer. That is, in the foreseeable future, many Android developers may begin to receive descriptions of the accessibility problems of their applications in a similar standardized form. They will only understand what exactly the Accessibility Scanner means.
From a technical point of view, Accessibility Scanner is a so-called accessibility service, that is, an application that runs in the background and interacts with the accessibility API of the Android OS to implement additional functionality for users with disabilities. After installing the Accessibility Scanner, you need to open the section “Spec. Accessibility in the device settings, find the Accessibility Scanner in them and activate the service, giving it the necessary permissions. After that, the Accessibility Scanner button appears on the screen, displayed on top of the entire interface.
After opening the interface you want to test, you should click on this button, after which the service will successively describe all the problems found and suggest options for correcting them. You can also display all the problems found in a single list and send the resulting report by E-mail.
')
The report may contain recommendations like this:
Everything is pretty obvious here: the developer needs to increase the contrast of the text and background colors. Accessibility Scanner recommends providing a contrast ratio for large text of at least 3, and for small text at least 4.5. This is nothing more than a W3C WCAG 2.0 standard with an average level of AA compliance.
However, if the developer wants to increase the degree of accessibility, he can use more stringent requirements for the highest level of AAA compliance. In this case, the contrast ratio for large text should be at least 4.5, and for small text - at least 7.
Here, Google developers are a bit lazy, as such a comment is unlikely to be informative enough for an unprepared developer. However, everything is quite simple. This means that the control has only a graphical representation, and it has no text label. Thus, users who work with the interface not with the aid of sight, but through screen reader programs, will hear something like “Button 25 without a shortcut” on it.
To fix this problem, you must sign each text label control using the android: contentDescription attribute:
It is worth noting that the value of the android: contentDescription attribute will not be displayed visually. It is intended for screen readers and is pronounced by them when the control is focused. That is, there is no need to optimize the length of this text to fit the screen. However, android: contentDescription is a full-fledged string resource, so it also needs localization. That is why it should be placed in strings.xml and translated along with all the others.
In addition, as was shown above, screen readers independently determine all the necessary metadata about the type of element, so duplicate this information in the text label is not required. In other words, you should not write "Cancel button", simply "Cancel".
If Android developers spend a little time testing the interface of their applications through the Accessibility Scanner and then a little more time to fix the found basic accessibility problems, their products will become more user-friendly to users who have some vision limitations. In some cases, such an automatic audit and the corresponding corrections in general can ensure the full availability of the application. However, in more complex cases, you should not rely solely on the Accessibility Scanner and, if possible, test the availability of the interface manually, including with the involvement of real users. The Accessibility Scanner developers themselves warn about this in the description of the service: "Accessibility Scanner is not an app's accessibility."
Unfortunately, we have to admit that Google applications themselves are far from always capable of being tested through the Accessibility Scanner, which brings to mind the round timber assortments in sensory organs.
At the end, once again, the link to the Play Market is for those who have not clicked on it at the beginning of the article.
The Accessibility Scanner application does not require special technical skills for its use and, among other things, is recommended for use by ordinary people who can generate a report on the problematic interface and send it to the developer. That is, in the foreseeable future, many Android developers may begin to receive descriptions of the accessibility problems of their applications in a similar standardized form. They will only understand what exactly the Accessibility Scanner means.
From a technical point of view, Accessibility Scanner is a so-called accessibility service, that is, an application that runs in the background and interacts with the accessibility API of the Android OS to implement additional functionality for users with disabilities. After installing the Accessibility Scanner, you need to open the section “Spec. Accessibility in the device settings, find the Accessibility Scanner in them and activate the service, giving it the necessary permissions. After that, the Accessibility Scanner button appears on the screen, displayed on top of the entire interface.
After opening the interface you want to test, you should click on this button, after which the service will successively describe all the problems found and suggest options for correcting them. You can also display all the problems found in a single list and send the resulting report by E-mail.
')
The report may contain recommendations like this:
Text contrast
com.habrahabr.example: id / label
The item's text contrast ratio is 2.46. This is an estimate of # 999999 and an estimated background color of #EEEEEE. Consider increasing this item's text ratio to 3.00 or greater.
Everything is pretty obvious here: the developer needs to increase the contrast of the text and background colors. Accessibility Scanner recommends providing a contrast ratio for large text of at least 3, and for small text at least 4.5. This is nothing more than a W3C WCAG 2.0 standard with an average level of AA compliance.
However, if the developer wants to increase the degree of accessibility, he can use more stringent requirements for the highest level of AAA compliance. In this case, the contrast ratio for large text should be at least 4.5, and for small text - at least 7.
Those who want to understand the method of calculating the contrast ratio can click on this text and read the corresponding footcloth under the spoiler.
The contrast ratio (CR) is calculated using the following formula:
CR = (L1 + 0.05) / (L2 + 0.05)
Where
L1 is the relative brightness of the brightest of the colors;
L2 is the relative brightness of the darkest of colors.
In the sRGB color space, the relative color brightness (L) is calculated by the formula:
L = 0.2126 * R + 0.7152 * G + 0.0722 * B
Where
if RsRGB <= 0.03928, then R = RsRGB / 12.92, otherwise R = ((RsRGB + 0.055) / 1.055) ^ 2.4;
if GsRGB <= 0.03928, then G = GsRGB / 12.92, otherwise G = ((GsRGB + 0.055) / 1.055) ^ 2.4;
if BsRGB <= 0.03928, then B = BsRGB / 12.92, otherwise B = ((BsRGB + 0.055) / 1.055) ^ 2.4.
RsRGB, GsRGB, BsRGB are defined as:
RsRGB = R 8 bit / 255;
GsRGB = G 8 bit / 255;
BsRGB = B 8 bit / 255.
As a result, the value of the contrast ratio is in the interval [1; 21], where 1 is the minimum contrast, for example, white on white, and 21 is the maximum, for example, black on white.
CR = (L1 + 0.05) / (L2 + 0.05)
Where
L1 is the relative brightness of the brightest of the colors;
L2 is the relative brightness of the darkest of colors.
In the sRGB color space, the relative color brightness (L) is calculated by the formula:
L = 0.2126 * R + 0.7152 * G + 0.0722 * B
Where
if RsRGB <= 0.03928, then R = RsRGB / 12.92, otherwise R = ((RsRGB + 0.055) / 1.055) ^ 2.4;
if GsRGB <= 0.03928, then G = GsRGB / 12.92, otherwise G = ((GsRGB + 0.055) / 1.055) ^ 2.4;
if BsRGB <= 0.03928, then B = BsRGB / 12.92, otherwise B = ((BsRGB + 0.055) / 1.055) ^ 2.4.
RsRGB, GsRGB, BsRGB are defined as:
RsRGB = R 8 bit / 255;
GsRGB = G 8 bit / 255;
BsRGB = B 8 bit / 255.
As a result, the value of the contrast ratio is in the interval [1; 21], where 1 is the minimum contrast, for example, white on white, and 21 is the maximum, for example, black on white.
Item label
com.habrahabr.example: id / button
This item may not have a label readable by screen readers.
Here, Google developers are a bit lazy, as such a comment is unlikely to be informative enough for an unprepared developer. However, everything is quite simple. This means that the control has only a graphical representation, and it has no text label. Thus, users who work with the interface not with the aid of sight, but through screen reader programs, will hear something like “Button 25 without a shortcut” on it.
To fix this problem, you must sign each text label control using the android: contentDescription attribute:
<Button android:id="@+id/button" android:src="@drawable/button" android:contentDescription="@string/button"/> It is worth noting that the value of the android: contentDescription attribute will not be displayed visually. It is intended for screen readers and is pronounced by them when the control is focused. That is, there is no need to optimize the length of this text to fit the screen. However, android: contentDescription is a full-fledged string resource, so it also needs localization. That is why it should be placed in strings.xml and translated along with all the others.
In addition, as was shown above, screen readers independently determine all the necessary metadata about the type of element, so duplicate this information in the text label is not required. In other words, you should not write "Cancel button", simply "Cancel".
If Android developers spend a little time testing the interface of their applications through the Accessibility Scanner and then a little more time to fix the found basic accessibility problems, their products will become more user-friendly to users who have some vision limitations. In some cases, such an automatic audit and the corresponding corrections in general can ensure the full availability of the application. However, in more complex cases, you should not rely solely on the Accessibility Scanner and, if possible, test the availability of the interface manually, including with the involvement of real users. The Accessibility Scanner developers themselves warn about this in the description of the service: "Accessibility Scanner is not an app's accessibility."
Unfortunately, we have to admit that Google applications themselves are far from always capable of being tested through the Accessibility Scanner, which brings to mind the round timber assortments in sensory organs.
At the end, once again, the link to the Play Market is for those who have not clicked on it at the beginning of the article.
Source: https://habr.com/ru/post/280222/
All Articles