Someone on your campus will ask whether a student can use the app with VoiceOver, with the text turned all the way up, or with a keyboard. You want an answer you can send that includes the parts that still fail. This report is the answer. It's for the person who runs orientation, an open house, admitted student day, a conference, or a visit day, and for the staff member who builds the guide. It's to help students get through an orientation day without needing someone else’s phone.

We tested the Guidebook iOS app, the Android app, and Builder against WCAG 2.2 Level A and AA, and issued our latest report on September 28, 2026. Event Mobile Web and the registration site sit outside this test. If the question is about either of those, we will have more information in the future.

We started from the person using it. A student on VoiceOver or TalkBack, a student with the type turned all the way up, and someone who uses a keyboard because a touchscreen isn't an option. Builder is in the same report for the staff member who has to publish that guide.

If they can't operate it, the student never gets the update.

What we tested

Each platform was tested on its own, with automated checks and with a person using a screen reader, a keyboard, and enlarged text. A green scan can still leave someone stuck on the schedule, so the manual pass is the one we trusted.

On iPhone, that meant VoiceOver, Dynamic Type at the largest sizes, turning the phone sideways, an external keyboard with Full Keyboard Access, and Xcode's Accessibility Inspector. On Android, it meant TalkBack, the largest font scale, rotation, an external keyboard, and Accessibility Scanner.

We walked the screens a student opens when they are trying to get through the day:

• Home

• The list of guides

• The guide menu

• General info

• The schedule

• Notifications

• Profile

• Lists

• Photos

• Interact

• The leaderboard

• Maps

• The to-do list

• Notes

• Welcome

• Connect

That menu is Louisiana Tech's orientation guide.

It's an example of what a new student opens: welcome, notifications, the schedule, to-do lists, and campus maps, all one tap away.

Builder is where your staff build that guide, so it was tested on its own. The checks were axe DevTools, WAVE, NVDA, JAWS, VoiceOver, keyboard-only use, and tools for contrast, flashing, and text spacing. The screens were navigation, the guides dashboard, Spaces and Apps, the guide dashboard, builder navigation, the builder modal, the branded dashboard, Manage Org, the flow for building a guide, and login.

How to read the scores

WCAG 2.2 Level A and AA has 55 criteria. Some don't apply to a phone app or to a web tool, so the totals below leave those out.

iOS and Android each have 7 criteria that don't apply. Builder has 9. The accessibility report is where you can filter the full list.

The word "supports" is the generous reading. It means at least one way through that criterion has no known defects, which is not the same as every screen being finished. Partially supports means some of the product misses it. Does not support means most of the product misses it. Not applicable means that criterion doesn't belong on that platform.

That's why the total is a bad thing to forward on its own. Android has nothing in "does not support," and it still has 14 criteria that only partly pass. Open the row in the accessibility report. The note names the screen, and the control, that a person would actually hit.

What we're still fixing

The phones come first. Work on the iOS and Android apps is underway, and Builder starts in Q4 2026. Someone asking about orientation wants to know if a student can get through the day. That question lands on the app, not on the tool we use to build it.

On iOS, the open gaps are text size and landscape on screens that haven't been redesigned. Landscape works on Schedule, General Info, and Space and Guide Home. Text resizing fails more widely. The notes include general info details, notifications, profile, lists, welcome, notes, photos, the to-do list, maps, the leaderboard, and Interact. A student sets the largest type once, for the whole phone, and then a welcome page or a map can still ignore it.

Kentucky's open house is another example. One phone has the visit details, one has the day's schedule, and the third is a short guest survey from the same day.

On Android, the main gap is list screens that have no real structure. To-do, welcome, custom lists, and the leaderboard are flat lists, so TalkBack reads the page as one long pile. The item they came for is in there, but they have to walk the whole page to reach it. Those pages are being rebuilt. A few controls are unlabeled too, including photos in the album and the Like button. On the map page, the map itself is skipped, which is a hard thing to explain to someone who opened the app to find a building.

Builder is the one we would not hand to a keyboard user today. Navigation and menus don't take focus the way they should. The focus ring is hard to see, or missing. Labels are missing on controls a staff member needs, including guide settings, preview, and edit. Twenty-two of 46 applicable criteria are supported, and ten are not. If the person building the guide can't reach those controls, the updated schedule never goes out.

Where to read each criterion

The full table is on the accessibility report. Filter by platform, level, or status, or search by criterion number, then open Details for the tester's notes. The same report is a PDF dated September 28, 2026.pdf).

Send that page when disability services, a parent, or a form asks for the current test. Say which product you mean. The iPhone app, the Android app, and Builder are three different results.

If the question is about the guide new students download, this is the report to send. New student programs is the campus job, and the event app is where the schedule, the maps, and the lists live. An earlier post on how event apps support accessibility is about why that work matters. This is about testing, fixing and making sure we leave no student behind.

Frequently asked questions

[faq] Q: Which Guidebook products are in this report? A: The iOS app, the Android app, and Builder. Event Mobile Web and the registration site are not included. Q: What does supports mean? A: At least one method meets the criterion with no known defects. Partially supports means some of the product misses it. Does not support means most of it misses it. Q: What are you fixing first? A: The iOS and Android apps. Builder remediation begins in Q4 2026. Q: Can a student resize the text on iPhone? A: On many screens, the text stays small. Resize text is marked does not support on iOS, including notifications, lists, maps, welcome, and the to-do list. Q: How did the Android app score? A: Android supports 34 of 48 applicable criteria and partially supports the other 14. None are marked does not support. The partial rows include list screens that are being rebuilt. Q: Where is the full list of criteria? A: On the [accessibility report](https://www.guidebook.com/accessibility), with tester notes on each row. The [PDF](https://cdn.prod.website-files.com/68b01d3752e6264d97325944/6ad60ce0a4e549c3c71f6363_Guidebook-Accessibility-Conformance-Report-WCAG-2026-09-28%20(1).pdf) of the same report is dated September 28, 2026. [/faq]