Improving Accessibility of the Reading and Search Experience in the Wikipedia Android App

By / / News

This case study explores the following problem statement:

How might we improve the Wikipedia Android app’s reading and search experience to be fully accessible for users with disabilities while meeting WCAG 2.1/2.2 compliance standards?

Our team consisted of Thalia Richter, Tracy Khiew, Rohini Raj, Annie Huang, and Youyuan Wang. We focused on assessing the reading and search experience in the Wikipedia app. This involved nine functionalities: 

  1. Article search functionality
  2. Offline reading capabilities
  3. Search results and filtering
  4. Image viewing / galleries
  5. Opening articles in new tabs
  6. Media playback
  7. Article reading interface
  8. In-article navigation
  9. Language selection and switching

My Role

I conducted background research into motor/mobility disabilities. I completed the audit on the article search functionality and opening new tabs. I also audited WCAG guidelines pertaining to external keyboards, contrast, and DP size in all of the other functionalities.

The Process

The first step in our process was to conduct research into different disabilities. There are five major categories of disabilities: visual, auditory, motor/mobility, cognitive, and temporary situational. Since we had five group members, we each researched one category. From here, we began to have a picture of the kinds of disabilities that would most impact a Wikipedia user, as well as the most common disabilities that would impact the largest number of users. We decided to focus on ADHD, arthritis, low vision, and deafness.

When building our personas, we also incorporated research into common needs and barriers to access among users with these disabilities. Below are our two personas: Daniel, who is profoundly deaf and has ADHD, and Stacy, who has low vision and arthritis.

Evaluation Standards

We evaluated the Wikipedia app using the Web Content Accessibility Guidelines (WCAG) 2.1/2.2. We also evaluated the app using the Material Design 3 (M3) Guidelines. We used a tiered system to categorize the severity of finding. Tier 1 findings violated WCAG Level A and/or were critical or urgent. Tier 2 findings violated WCAG Level AA and/or were important, but more medium term. Tier 3 findings were enhancements to the experience, but could be long term.

Findings

We found 26 Tier 1 failures, 6 Tier 2 Failures, and 3 Tier 3 failures. We bundled these failures into experience issues. These centered on functions that would be most key to the reading and search experience. A full list of all of our findings by tier is listed at the end.

Finding #1: Inaccessible images and videos

  1. Some images are invisible to screen readers.
    1. Violates WCAG 1.1.1 Non-text Content and M3 guidelines to provide fallback text for images with no available description.
  2. If a user with low vision wants a description of this image, they can try Talkback’s AI labeling feature. However, using this feature on the Wikipedia app takes multiple clicks to fetch an image description and leads to users losing their reading position entirely.
    1. Violates WCAG 3.2.1 On Focus and M3 guidelines to follow a semantic image labeling pattern.
  3. Finally, many videos which have audio tracks do not provide captions.
    1. Violates WCAG 1.2.2 Captions (Pre-recorded) and M3 guidelines to provide captions for video content. 

Recommendations

  1. When alt text is missing: announce “Image, no description available” or use existing caption as description text.
  2. Use contentDescription attribute for all images.
  3. Provide synchronized closed captions when videos contain speech or important audio, or indicate when videos are audio-free

Finding #2: Broken Tab Management Experience

  1. When a new tab is opened, no announcement/ confirmation is made by the screen reader to the user.
    1. Violates WCAG 4.1.3 Status Messages, 3.2.2 On Input and M3: Status changes must be announced to screen reader users.
  2. TalkBack reads the tabs button as ‘Show tabs’ and does not indicate the number of open tabs.
    1. Violates WCAG 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value and M3: Button labels must convey complete state information.
  3. In the tab listing page, the tab count button is called out as “back” button instead of informing users about the number of tabs.
    1. Violates WCAG 4.1.2 Name, Role, Value, 3.2.4 Consistent Identification and M3:Labels must accurately match their function and purpose.
  4. Close “X” buttons read as “Button, detected text x”, user’s don’t know x stands for ‘close’.
    1. Violates WCAG 4.1.2 Name, Role, Value, 2.5.3 Label in Name, 2.4.6 Headings and Labels and M3: Action buttons must describe what they do, not their appearance.

Recommendations

  1. Announce when tab opens: “New tab opened: [Article name]”.
  2. Label “X” buttons: “Close tab”
  3. Label tab count button: “[number] tabs open”
  4. Replace ‘+’ icon with ‘←’ icon.
  5. Place the ‘+’ next to the tab count button. 

Finding #3: Broken Reading Experience

  1. Talkback announces ”font size, color, font family” whenever there is a change in text style in the paragraph.
    1. Violates WCAG: 1.3.1 Info and Relationships, 1.3.2 Meaningful Sequence and M3: Visual styling changes should not trigger screen reader announcements.
  2. Citation links are announced only as numbers.
    1. Violates WCAG: 2.4.4 Link Purpose (In Context), 4.1.2 Name, Role, Value and M3: Links must have descriptive text explaining their destination
  3. Article has multiple links that are called out as ‘xyz link, double tap to open’ + generally having multiple visible links creates a fragmented reading experience.
    1. Violates WCAG: 1.3.2 Meaningful Sequence, 2.4.6 Headings and Labels M3: Excessive interactive elements reduce readability. Should provide simplified reading mode option.

Recommendations

  1. Remove font metadata announcements.
  2. Give citation links descriptive names:     “Citation 1: Amphibian species of the world”.
  3. Create “Reading Mode” button or toggle that hides link formatting and metadata.

Finding #4: Search incompatibility with assistive tech

  1. When using an external keyboard, the tab key does not allow users to select search suggestions as it cycles between back, delete and language buttons.
    1. Violates WCAG: 2.1.1 Keyboard, 2.4.3 Focus Order and M3: All interactive elements must be reachable via keyboard navigation
  2. Empty search gives no error – appears to load forever
    1. WCAG: 3.3.1 Error Identification, 3.3.2 Labels or Instructions and M3: Empty states must provide clear feedback and guidance
  3. The filter history button announces itself but doesn’t explain that users should type keywords to search, leaving them with no instruction on what to enter or how the filtering actually works.
    1. WCAG: 3.3.2 Labels or Instructions , 4.1.2 Name, Role, Value and M3: Non-obvious interactions require clear usage instructions

Recommendations

  1. Enable keyboard Tab/Arrow navigation through search results
  2. Announce empty search: “Search field is empty. Please enter text”
  3. Add instruction: “Type to filter search history” 

Finding #5: Gallery has no visible position indicator

  1. No visible position indicator on screen.
    1. Violates WCAG: 2.5.1 Pointer Gestures, 2.1.1 Keyboard and M3: Multi-item carousel views must provide visible position feedback
  2. No previous/next buttons. Navigation requires swipe gesture only.
    1. Violates WCAG: 2.5.1 Pointer Gestures, 2.1.1 Keyboard and M3: Gesture-only controls must have single-tap alternatives

Recommendations 

  1. Add visible position indicator and dot navigation.
  2. Add previous/next buttons for single-tap navigation.

Full List of Tier 1 Findings

Full List of Tier 2 Findings

Full List of Tier 3 Findings

References 

Deaf/Hard of Hearing


Motor / Mobility


Cognitive


Vision

Android Accessibility