Implementing ARIA and Accessibility Best Practices for Mobile Web Applications

Background – Previous accessibility work received media coverage and achieved good results. In the new year, the goal is to establish a more complete accessibility optimization mechanism and make JD’s accessibility experience an industry benchmark.

Current Situation Analysis – When using iOS VoiceOver or Android TalkBack, many buttons cannot receive focus, price information is read incorrectly, and decorative images receive focus, leading to a poor shopping experience for visually‑impaired users. The following sections focus on H5 accessibility development.

ARIA

01 What is ARIA? ARIA (Accessible Rich Internet Applications) is a W3C specification that adds accessibility information to HTML elements, enabling screen readers to recognize roles, states, and properties of custom UI components. It complements HTML semantics and is widely supported by modern browsers.

02 Why is ARIA needed? HTML5 improves accessibility but cannot solve all problems for blind users, such as indicating navigation regions, clickable elements, dialog openings, selection modes, or dynamic content changes. ARIA provides the missing semantics.

03 Browser Support All modern browsers (IE8+ and later) support ARIA, as do frameworks like Bootstrap and jQuery.

04 ARIA Composition ARIA consists of role attributes (e.g., role="button" ) and attributes prefixed with aria- that describe state and properties.

How Blind Users Interact with Phones

Android – TalkBack Gestures

Single‑tap: focus and read the element.

Swipe left/right: move focus to previous/next element.

Swipe up/down: read content line by line.

Double‑tap: activate the focused element.

Two‑finger swipe: page up/down.

iOS – VoiceOver Gestures

Single‑tap: focus and read.

Swipe left/right: move focus.

Double‑tap: activate.

Three‑finger swipe: page up/down.

Providing Equivalent Alternatives

Images – Add concise alt text; decorative images should have alt="" so they are ignored.

CAPTCHA – Offer both visual and audio options, or use SMS/Math CAPTCHAs.

Audio/Video – Provide transcripts or descriptive titles (e.g., <video title="Tree"> ).

Color – Ensure contrast ratio ≥ 4.5:1 (WCAG AA) and consider non‑color cues for color‑blind users.

UI and Navigation Operable by Assistive Technology

All functionality must be reachable by screen readers.

Provide sufficient time for reading, input, and interaction; allow pausing or extending time limits.

Enable fast navigation with clear headings and skip‑link mechanisms to avoid redundant content.

Common Accessibility Defect Statistics – The most frequent issues are missing or incorrect alternative text and focus problems (redundant or missing focus). Solving these covers the majority of accessibility gaps.

What Screen Readers Read – Example: an <a> element used as a button without role="button" is read as “text link”. Adding role="button" changes the reading to “text button”. Proper attribute usage ensures correct pronunciation.

Android vs. iOS Differences – The same content may be read differently on the two platforms; developers must test on both.

DOM Order Importance – Screen readers read elements in DOM order. Visual reordering (e.g., flex-direction: row-reverse ) can confuse users; use tabindex or avoid such CSS when possible.

Providing Text Descriptions for Non‑Text Elements

Images – Use alt ; if the image is inside a link that already has descriptive text, set alt="" to avoid duplication.

Videos – Use title attribute for concise description.

Using Semantic Tags – Tags like <header> , <nav> , <section> , <main> , <aside> , <button> convey meaning to assistive technologies and affect the spoken suffix (e.g., “button”).

Applying ARIA Attributes to Non‑Native Elements

aria-label="screen reader only label" – Provides a custom spoken description.

aria-controls="main" – Links a control to a region (useful on desktop screen readers).

aria-live="true" – Announces dynamic content changes automatically.

Space Usage in Numbers – Inserting invisible spaces between digits (e.g., “9 3 2 6”) prevents screen readers from reading the number as a whole, improving clarity for users.

Chinese Text Usage – In some cases, replacing mis‑read numbers with Chinese characters yields more natural speech.

Hiding Non‑Visible Elements – Ensure modal dialogs or alerts are hidden with display:none , visibility:hidden , or aria-hidden="true" so they are not read unintentionally.

Conclusion – Accessibility highlights the importance of semantic markup. Understanding screen‑reader behavior and applying ARIA correctly leads to a better shopping experience for visually‑impaired users.