Skip to content

CONCEPT Cited by 1 source

WCAG platform applicability gap

Definition

WCAG platform applicability gap is the observation that the Web Content Accessibility Guidelines (WCAG) are — as the name says — web-centric, and that a11y conventions on native mobile platforms sometimes legitimately diverge from WCAG's web mappings. Mechanically applying every WCAG success criterion to a native Android or iOS app produces both false- positive a11y "bugs" (findings that contradict platform convention) and missed coverage (WCAG criteria that have no obvious native analog).

The correct response to a platform-applicability-gap finding is not remediation but documented closure with a platform-convention rationale, preferably after cross- checking native system apps (Google apps on Android, Apple apps on iOS) to confirm the divergence.

Canonical examples (from Slack's VPAT triage)

1. Top-app-bar title as heading

  • WCAG 1.3.1 Info and Relationships (Level A) reading: page titles should be marked as headings so assistive tech can navigate to them.
  • Web convention: <h1> for the page title.
  • Android convention: top-app-bar titles are not marked as headings in native Google apps.
  • Slack's disposition: "we found that this pattern is not consistent with Android standards after testing other apps. Therefore, we closed those tickets." (Source: sources/2025-11-19-slack-android-vpat-journey)

2. Strikethrough text announcement

  • WCAG 1.3.1 Info and Relationships (Level A) reading (vendor interpretation): strikethrough formatting should be conveyed to screen reader users.
  • Platform convention (TalkBack and most screen readers): strikethrough is intentionally not announced because doing so is verbose and ambiguous — users may interpret the announcement as part of the message content.
  • Slack's disposition: consulted a blind-community member, closed without remediation; also recommended authors avoid strikethrough for accessibility reasons. (Source: sources/2025-11-19-slack-android-vpat-journey)

When the gap is legitimate vs. when it's rationalisation

Criteria for a legitimate platform-applicability-gap closure (derived from Slack's posture):

  • The divergence is observable in native first-party apps on the same platform (Google apps on Android; Apple apps on iOS).
  • The underlying user-experience rationale is documented — why the platform convention produces a better outcome for users of the platform's assistive tech.
  • A peer review or community consultation backs the decision, particularly for decisions about what assistive- tech users actually want announced.

If the divergence is not observable in first-party apps and no user-experience rationale exists, the finding is not a platform-applicability gap — it's an un-fixed a11y bug with a platform-convention alibi.

Generalisation beyond Android

  • iOS — VoiceOver has conventions that similarly diverge from web WCAG mappings (e.g. hint-vs-label distinction, accessibility-rotor navigation).
  • Desktop (macOS, Windows) — native screen readers (VoiceOver, NVDA, JAWS) each have conventions that sometimes diverge from web.
  • Smart TVs, voice interfaces, AR/VR — WCAG's mapping gets progressively thinner.

Seen in

Last updated · 470 distilled / 1,213 read