Publish mobile VPAT as a VPAT 2.5 conformance report

[danielparasbuffer]

Replaces the 2020 mobile accessibility page with a full VPAT 2.5 International Edition conformance report for the iOS and Android apps, formatted to match buffer-web.md.

Source material is the engineer-reviewed mobile VPAT testing guide. Internal testing notes have been converted into formal conformance results, with reviewer names, checkmarks and internal-only phrasing removed. The guide's setup instructions, tooling list, gesture tables, flows-to-test list, and the "How to test" and "Priority" columns are not carried over.

Published as a work in progress

A prominent note near the top states that evaluation is incomplete, that testing so far covers the Android app only with no formal iOS evaluation, that Buffer is validating remaining criteria incrementally, and how readers can flag a criterion that matters to them. The legal disclaimer says the same.

Findings recorded

All from Android TalkBack testing:

Criterion	Result	Basis
1.1.1 Non-text Content	Partially Supports	Most elements announce meaningfully; Instagram hashtag count does not
2.1.2 No Keyboard Trap	Partially Supports	Focus cannot leave the composer when exiting
2.4.2 Page Titled	Partially Supports	Screen names announced, but Create screen announces no title
2.4.3 Focus Order	Partially Supports	Logical order except the composer trap
2.5.3 Label in Name	Partially Supports	Instagram hashtag count, plus calendar days read as single letters
1.3.2 Meaningful Sequence	Not Evaluated	Android passed, iOS untested
302.1 / 4.2.1 Without vision	Partially Supports	Derived from the WCAG rows above, cross-referenced

Everything else applicable is Not Evaluated: 22 of 32 Level A criteria, 22 of 24 Level AA, and most of the Section 508 and EN 301 549 rows.

Not Applicable entries are carried over only where the source material already justified them. None were added.

Combining iOS and Android

With zero iOS coverage, a blanket "Supports" would over-claim, so the document states the rule it applies, following the testing guide's own lower-of-two convention:

• A defect on either platform sets the combined status.
• A pass on one platform with the other untested stays Not Evaluated, with the pass described in the Remarks. Only 1.3.2 is affected.
• Neither platform tested means Not Evaluated.

Claims removed

• Automated scans. The draft said automated checks were run with iOS Accessibility Inspector and Android Accessibility Scanner. Per Andy's comment on the guide, Inspector has no automated audit, and per Daniel's, Scanner is semi-manual. No results exist from either. Evaluation Methods now states manual TalkBack testing only.
• "Design-side review by Buffer's product design team." No supporting evidence.
• The 2020 iOS and Android supported-feature lists (Bold Text, Reduce Transparency, Dynamic Type, VoiceOver, TalkBack). These assert support for exactly what 503.2 and 11.7 now record as Not Evaluated.

The "fixed within one to two weeks" pledge from the 2020 page is kept, moved into the work-in-progress note.

Open items for reviewers

1. 1.2.2 says there are no in-app videos, but 1.2.3, 1.2.5 and 503.4 are Not Evaluated with instructions to watch in-app videos. Left as Not Evaluated with a cross-reference. One answer closes four rows.
2. 2.1.2 test method is unrecorded. The criterion covers external keyboard and switch control, but the finding reads like TalkBack swipe navigation. The composer trap is real either way; the criterion it belongs under may shift.
3. Calendar single-letter day headings may sit better under 1.1.1 or 4.1.2 than 2.5.3, since the accessible name does match the visible label. Recorded where it was found.
4. "Emojis read out clearer" omitted. Not a defect and unclear what it compares to.
5. Flow coverage is undocumented. Navigation, composer, and calendar/queue were inferred from the findings themselves.
6. 302.1 and 4.2.1 are derived from the WCAG rows, not separately tested.

Date set to September 2026 as the publication date. Criterion links use the WCAG TR spec pages to match buffer-web.md rather than the Understanding pages used in the guide.

🤖 Generated with Claude Code

https://claude.ai/code/session_0153QkjcQKCgUBNt7rvNhEhB

---

Generated by Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 66ded30e-91e2-44a7-b678-ab544f84167c

---

_{Comment @coderabbitai help to get the list of available commands.}

[hitherejoe]

Looks good to me!

The only thing I was not sure about is the declaration of "The mobile apps do not include in-app video content." (there are a few similar points also). We do have videos in the app, but they are from the user and not pre-generated so I think that does not count here

[danielparasbuffer]

Looks good to me!

The only thing I was not sure about is the declaration of "The mobile apps do not include in-app video content." (there are a few similar points also). We do have videos in the app, but they are from the user and not pre-generated so I think that does not count here

Yeah I understood those to be in-app content eg. video demos coming from us, videos of others (eg. a feed of sorts) etc. Since it's their own content I don't think it should apply.

Thanks for having a look 🙏