How WeChat Android Boosts Accessibility for Seniors and Disabled Users

Preface

To help elderly and disabled users better use the WeChat Android app, a senior‑friendly and accessibility redesign was completed. This article introduces the Android accessibility framework that assists business‑side developers, covering requirements, framework overview, basic knowledge, overall process, execution principle, core features, and inspection tools.

Framework Requirements

The framework provides:

Perceptibility – large‑font adaptation, color contrast, etc.

Operability – enlarging small touch targets to improve interaction for seniors/disabled users.

Understandability – providing screen‑reader content descriptions for blind users.

Requirement 1: Small Touch‑Target Enlargement

All interactive controls must have a clickable area of at least 44dp × 44dp; manually fixing each layout is impractical.

Requirement 2: Touch Area Changes with Accessibility Switch

An item composed of a SwitchButton and TextView behaves as a single focusable element when TalkBack is on, but only the SwitchButton when TalkBack is off, causing the touch area to change.

Requirement 3: Screen‑Reader Text Composed from Multiple Views

When selecting a profile picture, the screen‑reader must read “Tencent admin’s avatar, 2 unread messages,” requiring aggregation of information from other views.

Framework Overview

The framework encapsulates various accessibility requirements into rules. Business code declares a configuration class that expresses a page’s accessibility needs, and the framework applies the corresponding effects.

<code>class ChatAccessibility(activity: AppCompatActivity) :
    BaseAccessibilityConfig(activity) {
    override fun initConfig() {
        // set content description
        view(rootId, viewId).desc(R.string.send_smiley)
        // ...
    }
}
</code>

BaseAccessibilityConfig offers APIs such as unified contentDescription setting, combining multiple views for a single node, disabling focus, ordering read‑screen sequence, setting the first focusable view after activity launch, disabling children, and custom node information without focus.

Basic Knowledge

How Screen Readers Identify Views

Screen readers cannot read a View directly; they read a virtual node (“Node”) generated by the accessibility system. When a View changes, it sends an event, prompting the system to request a new node, which mirrors the View hierarchy.

Screen‑Reader Event Dispatch Process

Screen reader intercepts the touch event and locates the target node.

It translates the touch into a focus action.

The accessibility system forwards the focus event to the View.

The new virtual node is supplied to the screen reader, which reads the information via TTS.

Wrap every View with an AccessibilityDelegate and modify the node in onInitializeAccessibilityNodeInfo .

Overall Process

Business side implements a rule configuration class, which is stored in a pool.

The framework intercepts node creation ( onInitializeAccessibilityNodeInfo ).

It finds matching rules in the pool.

The rules modify the node accordingly.

The final node is handed to the screen‑reader.

Execution Principle

The core uses a chain‑of‑responsibility pipeline divided into a pre‑processing chain for Views and a node‑processing chain.

Core Feature: Global Touch‑Target Expansion

Background

Small touch targets must be enlarged to at least 44dp × 44dp; manually adjusting each layout is costly.

Implementation Details

TouchDelegate is set at a suitable parent View found by bubbling up from the target View. The delegate’s Rect is updated on layout changes, and the process is throttled to avoid frequent updates.

Performance Optimization

Expansion is performed asynchronously after layout inflation, traversing the view hierarchy off the UI thread to reduce main‑thread load.

Expansion in TalkBack Mode

Since the green focus rectangle is drawn based on the View’s screen bounds, the framework provides a custom AccessibilityDelegate that returns a virtual node with enlarged bounds, ensuring the focus rectangle matches the expanded area.

Additional Notes

Rule‑View Matching

The configuration pool is scoped per Activity, using layoutId + viewId or rootId + viewId to uniquely locate a View and avoid conflicts.

Rule Lookup Performance

Lookup occurs during node generation; a pre‑generated cache reduces latency.

Inspection Tool

Background

Manual verification of accessibility elements while TalkBack is on is inefficient.

Solution

An AccessibilityService‑based tool periodically traverses the active window’s node tree, highlights focusable nodes, and draws overlay information without requiring TalkBack.

Implementation

The service obtains the root node of the active window every 0.5 seconds, checks each node for focusability, collects information, and uses a dedicated overlay view to render the results.