40.7°N  73.8°W
Wikimedia Foundation × Pratt · iOS · Accessibility audit · 2026

When glass gets in the way.

Apple’s new Liquid Glass design puts see-through menus over everything you read. It looks sleek, but it can make Wikipedia harder to use. Our team tested the Wikipedia iOS app against the WCAG 2.1 and 2.2 accessibility standards to find out where.

I was one of five researchers on the team. I helped run the audit and the walkthroughs, and I designed fixes the Wikimedia engineers could actually ship.

Wikipedia logo on a phone, with iOS Liquid Glass Accessibility Audit being typed into the search bar
RoleUX Researcher
& Designer
Team5 UX researchers
MethodsWCAG 2.1/2.2 audit
Cognitive walkthrough
Personas
Timeline4 weeks + shareout
Delivered May 2026
01 — The context

What’s the cost of making something more attractive, but not usable? Accessibility.

Apple rebuilt iOS around Liquid Glass: see-through toolbars, tab bars and menus that float over the page and change brightness as you scroll. The Wikipedia app inherits all of them. Through Pratt, the Wikimedia Foundation asked us one question: can people with low vision, hand tremors, or a need for predictable layouts still read and search?

We audited the app two ways.

We ran two methods side by side, because each covers the other’s blind spot. Scope stayed narrow on purpose: searching for an article, and reading one.

standards-based

WCAG 2.1 / 2.2 audit

Every screen in both flows mapped against 27 success criteria. Catches what fails on paper, regardless of who is using the app.

persona-based

Cognitive walkthrough

Both flows stepped through as Mia and Arun, tap by tap, against seven questions. Catches what a technically compliant screen still gets wrong.

Wk 1Scoping call, personas started, TestFlight set up
Wk 2Audit begins, screens captured
Wk 3Audit + walkthroughs split across the team
Wk 4Findings tiered, deck built
May 12Shareout to Wikimedia
We looked for things such as
FACTOR 01Severity & exclusionDoes it block someone with a disability outright, or add friction along the way?
FACTOR 02Ease of fixA five-minute contrast tweak ranks ahead of a navigation rebuild.
FACTOR 03ReachHow many screens and flows repeat the same failure across the app.
FACTOR 04Persona overlapWhether Mia and Arun both hit it, on their own, in separate walkthroughs.

Together they sort 13 findings into three tiers.

We found 13 accessibility issues.

Every finding carries a tier and the WCAG criterion it fails. The five most urgent get a full redesign below; the complete list, tier by tier, follows them.

27criteria audited
12passed
11failed
3partial
13findings

Five redesigns for the most urgent issues.

Each redesign answers one finding: the criterion it fails, what it costs the reader, and the smallest change that fixes it. The before is the app as shipped; the after is my redesign.

Tier 11.4.1 Use of Color

Hyperlinks Lack Non-Color Differentiation

Before · as shipped
After · bold link weight
The finding

Inline links differ from body text by color alone. Mia’s blurred central vision flattens color cues first, so links disappear into the paragraph.

The redesign

One consistent, heavier weight on every inline link across the app, so links stand out from body text even without seeing color. No underline, no new color: just weight.

How it gets built · CSS
article.cssCSS
/* article theme, applied to every page */
.content a { font-weight: 600; }

Articles render in a web view, so one rule in the shared article stylesheet reaches every inline link at once. Weight scales with Dynamic Type, and no link colors change.

Tier 11.4.11 Non-text Contrast

Icon Stroke Insufficient for Frosted Glass Navigation Bar Overlay

Before · as shipped
After · heavier icon strokes
The finding

Icons in the frosted glass navigation bar are too thin and fall below the 3:1 minimum. The blurred background shifts with whatever scrolls underneath, so contrast fluctuates and key controls get harder to find for people with low vision or cognitive disabilities.

The redesign

A heavier stroke weight on every navigation bar icon, so they stay legible whatever the glass is blurring. A bolder stroke also gives a larger visual target and holds contrast better.

How it gets built · UIKit
Toolbar.swiftSwift
let cfg = UIImage.SymbolConfiguration(weight: .bold)
item.image = icon.applyingSymbolConfiguration(cfg)

The toolbar icons are SF Symbols, so a heavier stroke is a single symbol configuration, not new artwork. One config applied to every toolbar item keeps them consistent.

Tier 12.5.1 Pointer Gestures

No Clear Indicator of Images in Photo Galleries

Before · as shipped
After · page dots
The finding

There are no indicators that more images exist in a gallery or that people can swipe to move between them. Navigation relies on a path-based gesture, which fails the requirement that all functionality work with a single pointer.

The redesign

Page dots below the image show how many images there are and which one is showing, so it’s clear there’s more to see. They’re the first step toward a full single-pointer path, alongside tappable arrows or a counter.

How it gets built · UIKit
GalleryView.swiftSwift
pageControl.numberOfPages = images.count
pageControl.currentPage = index

UIPageControl is built into iOS. It shows how many images there are, VoiceOver reads it as “image 2 of 5,” and a tap moves one image, giving the single-pointer path.

Tier 2Usability✓ Since fixed in the app

Search Highlights Hidden Behind the Keyboard

Before · recreated from audit
After · live in the app today
The finding

Highlighted search results within articles are hidden by the keyboard. With nothing moving on screen, it’s hard to tell a match was found at all, especially for people with cognitive or visual disabilities.

The redesign

Move highlighted search results above the keyboard so matched content stays visible while searching.

Wikipedia has since shipped this fix. The after is a recording of the live app; the before is recreated from our audit captures.

How it gets built · UIKit
FindInPage.swiftSwift
webView.scrollView.contentInset.bottom = kb.height
webView.scrollRectToVisible(match, animated: true)

On keyboardWillShow, inset the article by the keyboard height, then scroll the current match into the visible area. This is the behavior Wikipedia has since shipped.

Tier 32.5.1 Pointer Gestures

Lack of Single Pointer Equivalent for Search History Options

Before · as shipped
After · tap-to-reveal menu
The finding

Options for search history items only appear with a swipe, and there’s no single pointer alternative. That blocks people with motor disabilities, tremors, limited dexterity or assistive input devices from a key action.

The redesign

Replace the swipe with a single pointer equivalent: a three-dot “more options” button on every row that opens Save, Share and Remove with one tap.

How it gets built · UIKit
HistoryCell.swiftSwift
moreButton.menu = UIMenu(children: [save, share, remove])
moreButton.showsMenuAsPrimaryAction = true

A ⋯ button on each row opens a native UIMenu on a single tap. It reuses the same three actions as the swipe, so nothing new has to be built behind it.

The full list

All 13 findings, by tier.

Tier 1Critical · 5 findings
F01WCAG 1.4.1
Hyperlinks lack non-color differentiation
F02WCAG 1.4.11
Icon strokes too thin on frosted glass
F03WCAG 4.1.3
VoiceOver announces the tap, not what happened
F04WCAG 2.2.1
Save confirmations vanish on a timer
F05WCAG 2.5.1
No indicator of more images in galleries
Tier 2Significant · 5 findings
F06WCAG 2.5.8
Icons smaller than a tap can promise
F07usability
Search highlights hidden behind the keyboard
F08WCAG 1.4.13
Pop-ups have no explicit close
F09usability
Help and Support is buried
F10WCAG 2.4.1
No way to skip to a section
Tier 3Survivable · 3 findings
F11WCAG 2.5.1
No single pointer option for search history
F12WCAG 1.4.10
Content overflows at larger text sizes
F13usability
Search context resets after every article

We delivered the audit to Wikimedia.

Four weeks closed with a shareout to Wikimedia Foundation stakeholders on May 12: 13 tiered findings, the 27-criterion compliance table, both personas and walkthroughs, and a fix strategy sequenced by impact and effort. Wikimedia has since scheduled fixes against several of the tiered findings.

The research team: Ananya Yadav, Ashwathi Thilak, Shavanie Singh, Hridya Nadappattel and Qasim Malik

What I learned

Two methods beat one.

The audit caught what a walkthrough would never stumble into, like login shutting out Face ID. The walkthrough caught what a checklist would pass, like the search match hidden under the keyboard.

Write fixes engineers can ship.

My CS background shaped every recommendation: I knew what a team could feasibly build, and wrote each fix within that constraint instead of against it.

NEXT  Moderated sessions with real people living with low vision, a tremor or autism, on their own devices and assistive tech.

next case studyCardStoryA marketplace collectors can trustView case studynext case studyAetherPlayA gesture-based AR music instrumentView case study