Many people with disabilities regularly use assistive technologies to access digital content.
Special software or devices make it possible for these users to access and interact with digital content when the common modes of interaction via mouse, touch or keyboard do not work for them. In these cases, assistive technologies help.
Both iOS (iPhone) and Android offer built-in features that allow users to turn the screen into a braille keyboard.
The Web Content Accessibility Guidelines (WCAG) 2.2 define assistive technology this way:
“assistive technology (as used in this document): hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents.”
Typical examples of assistive technology for digital content are screen magnification software, speech control software, and screen readers.
In the world of desktop computing, many of these assistive technologies were (and still are) provided as a desktop application, sometimes in tandem with a physical device (e.g., a switch, a sip-and-puff mouse, or a refreshable braille display). Assistive technologies provide different ways for navigating digital content, entering input, and rendering output.
Even in desktop computing, there has been a trend to integrate accessibility functions such as page zoom, high-contrast mode, large cursor and enhanced keyboard focus, speech output, voice input, and the system screen reader in the operating system. On the mobile platforms Android and iOS, there is no extra assistive technology needed to cater for people with disabilities. While external assistive apps certainly exist that provide dedicated additional functionality for specific needs, for example, text or image recognition for blind users, optical magnification for low vision users, or communication via images for non-verbal users, most features that were traditionally provided by externally installed assistive technology have migrated into the platform, available in the device’s settings.
The major mobile operating systems, Android and iOS, now have a wide and ever-growing array of accessibility settings that replace functionality that used to be provided as additional software in desktop computing. Hardware input devices like Braille readers, keyboards or switches can also hooked up to mobile phones or tablets, usually via USB C or Bluetooth, and without needing dedicated software. In some cases, there are now alternative touchscreen interfaces for input that used to require physical devices, for example, Apple’s Braille Screen input (see photo above).
When testing the accessibility of mobile apps, the use (and knowledge) of the built-in screen readers TalkBack (Android) and VoiceOver (iOS, iPadOS) is far more important than when testing websites and web applications. The reason: While the tester can “look under the hood” during web testing by using the browser’s developer tools — that is, analyse the page’s source code and even modify the DOM (the Document Object Model, which represents the page’s current state in the browser) — the source code of apps is generally not available for the tester. Only by using the app with the screen reader can one truly determine whether all text is exposed programmatically; whether interactive elements can be focused and activated also with the screen reader enabled; and whether the accessible names and changing states of interactive elements such as switches are correctly exposed.
Exactly how “assistive technologies” are defined seems largely irrelevant until one encounters a WCAG success criterion (also used in the European standard) where the very applicability of the requirement depends on that definition. I am referring to 1.4.4 Resize Text. The success criterion requires that text can be resized without assistive technology up to 200 percent without loss of content or functionality (my emphasis). This requirement, which was created for web content even before browsers offered zoom functionality, is also included in the success criteria for software.
Given this situation, the question arises whether these integrated functions can rightly be called assistive technology. Settings for text size, enlarged display, bold text or dark mode can be found as a standard user setting, i.e., not tucked away under Accessibility Settings. Screen readers and other accessibility functions are updated jointly with each regular system update. These integrated accessibility functions do not act as user agent or work “along with a user agent”. For native apps, there is no user agent; the underlying platform is the mobile operating system.
While browsers typically not only change the text size when you zoom in but also cause the page content to reflow, mobile apps generally do not offer text enlargement on their own. Mobile browsers typically support zooming in on content via a two-finger pinch gesture without reflow, not so native mobile apps. There is however in both Android and iOS a system zoom function which can be activated in the accessibility settings. It works in slightly different ways, but in both operating systems but allows to enlarge any content on the display to 500%.
Is this an ideal experience for low vision users who need large text? Definitely not. Due to the small screen size of a mobile phone, zoomed-in text is cut off, and reading will require a lot of panning. It works slightly better when the device is turned to landscape orientation since then there is more space for the line of text. Still, the experience is far inferior to the reflow in a mobile browser.
Which is why many experts tend to argue that system zoom, being an accessibility function, should fall under the rubric of “assistive technology” and therefore not be deemed sufficient to meet the Resize Text requirement (see, for example, a discussion thread of the Mobile Accessibility Task Force: System settings as sufficient techniques?). Instead, they argue, mobile app text content should respond to changes in the OS text size settings. If implemented well, text will then reflow and provide a better experience. 1.4.4 Resize Text, however, does not mandate reflow. This is subject to another Success Criterion, 1.4.10 Reflow, which is also tricky to apply to native mobile apps.
Supporting Resize text through OS text size settings is certainly a recommended practice. However, it is not mandated when looking at the letter of the normative requirement. Also, as Resize Text would extend to all content, making all text on a small display resize to 200% can create serious problems for content with limited space. Think of the typical tab bars at the bottom of the screen providing navigation with about 4-5 tabs. Many of these have text labels that when resized would either wrap and mess up the design, or be truncated, becoming harder to read.
The latest version of the European Norm (EN) 301 549 V4.1 (not yet official) recognises that Success Criterion 1.4.4 Resize Text is difficult to apply directly to software like mobile apps, and states that “the non-web software should work with the text sizing features to the extent the platform provides”.
NOTE 2 in Understanding 1.4.4 Resize Text (WCAG2ICT) makes it explicit that for meeting 11.1.4.4, platform features (like iOS Zoom, Android Magnification) are considered sufficient to meet it:
“The Intent section in Understanding 1.4.4 Resize Text refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the non-web software provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality, or that the non-web software works with the platform features to satisfy this success criterion.”
Here, as in many other cases, best practice goes beyond what is normatively required. But a test procedure like BIK BITV Test (App) that follows what is set out in standards needs to follow the normative text of requirements, not mandate a best practice.
In the case of 1.4.4 Resize Text (in the EN numbered 11.1.4.4) this means that ourcurrent view is that mobile apps automatically pass 1.4.4 if content can be zoomed in using platform functions. For evaluations based WCAG applied to ICT as described in the WCAG2ICT document, that is the end of the story.
However, if the baseline is the EN 301 549 (clause 11 Software), there are additional requirements. Here, 11.7 User preferences demands that the “user interface shall follow the values of the user preferences that users have set for the documented platform accessibility features.” If users choose a larger font size in their settings, the text in the app should respond, certainly text that is not constrained by tab bars and the like, but can reflow and grow. You can see this as a win for users whose apps fall under European legislation (even though it may make the life for app developers more difficult).
Comments
All fields are mandatory