Accessible event apps

Two things are true at once. Accessibility in an event app is a real technical question that most vendors in this market answer badly. And most of what makes a conference accessible is not in the app at all — it is in the room, the schedule and the briefing.

This guide covers both, and is specific about what our own product does and does not do.

What to ask a vendor

Four questions, in the written round, before any demo.

1. Do you have an accessibility conformance report or a VPAT? Most will not. Ask anyway, because the shape of the answer is the information: a vendor who says “no, here is what we do instead” is in a different place from one who says “yes, we’re fully accessible” without producing a document.

2. Which WCAG version and level do you test the attendee app against? “Accessible” with no version and no level is not a checkable claim. AA is the level that procurement and regulation generally point at.

3. Do you support screen readers on iOS and Android? Both. Support on one platform is common and is a partial answer.

4. What are the minimum supported operating system versions? Attendees who need accessibility features are disproportionately likely to be on an older device that they have configured carefully and do not want to change.

Two follow-ups worth asking if the first four go well: whether the app supports the system text size setting, and whether there is a web version, since a web event site is often more accessible than a native app and is a genuine fallback.

What you control in the app

Some of the accessibility of your event app is set by you, not by the vendor.

Contrast in your own theme. If the product lets you choose colours, you can choose colours that fail. A brand palette designed for print frequently fails at body-text size on a phone in daylight. Check before you launch, on a phone, outdoors.

Room names. Attendees navigate by the door. If the venue calls it the Windsor Suite and the app says Room 2, everybody is worse off and people with cognitive or visual differences are much worse off.

Session descriptions that say what happens. “An interactive session” tells somebody nothing about whether they can participate. Say if there is movement, if there is loud audio, if there is group work.

Image descriptions. Speaker photos, sponsor logos, session images. If your console lets you write alt text, write it.

Not relying on colour alone. Track colour-coding is fine as a supplement and useless as the only signal. Put the track name next to the colour.

Notification volume. Frequent interruptions are a barrier for some attendees, not just an annoyance. This is one more argument for the discipline in push notification best practices.

What matters more than the app

Ranked by how much difference it makes, at most conferences:

Ask on the registration form. One field: “Is there anything we can do to make this event work better for you?” Free text, not a checkbox list, because a checkbox list only catches what you thought of. Then read the answers and act on them, individually, by email.

Read every question aloud. From the stage, before answering. It helps hard-of-hearing attendees, remote attendees, the recording, and everyone at the back. It costs four seconds and it is skipped constantly.

A quiet room, signposted, unbranded. Not a nice-to-have. For a meaningful number of your attendees it is the difference between staying all day and leaving at three. Do not sell it to a sponsor and do not put branding in it.

Reserved seating near the front. For lip-reading, for low vision, for anyone who needs to leave quickly. Signposted, held until five minutes before, then released.

Step-free routes that are actually usable. Walk them yourself, on the day, with the venue. The published accessible route and the route on the day differ more often than venues admit, usually because of a delivery, a cable run, or a door that is locked.

Longer breaks. Twenty-five minutes rather than fifteen is an accessibility measure as well as a networking one. Queuing for coffee and getting to the next room is not equally easy for everyone.

Captioning, if you can fund it. Live captioning is the single highest-cost item on this list and one of the highest-value. If the budget covers it for one room, put it in the main room.

Brief the speakers. Describe images, read slides aloud, avoid colour-only distinctions, do not speak over a video. Three lines in the speaker brief and most speakers will do it.

Where event67 stands, exactly

Said plainly, because a vague claim here is worse than an honest gap.

What is in the product. The theme editor checks every colour pair you set against WCAG AA and surfaces the measured result to you as you choose. That check warns and confirms; it never blocks a save. The organizer owns the decision, and we describe the feature that way everywhere. Attendees choose what appears on their own profile and can stay out of the directory. Q&A and polls work without any audio dependency, which means an attendee who cannot hear a question can still read and vote on it. There is a web event site alongside the native apps, which is a real fallback for anyone whose device or configuration works better in a browser.

What we do not have. We do not currently publish an accessibility conformance report or a VPAT. We will not describe the contrast advisory as if it were one — a contrast check is one success criterion, automated, and it says nothing about focus order, screen reader labelling, target size or reflow.

What that means for your review. If your organization requires a conformance report by name, score us as absent on that line rather than partial. If you want to know how a specific screen behaves with a screen reader, ask us and we will tell you what we know rather than what we hope.

That is an uncomfortable paragraph to publish and it is the accurate one. A vendor claiming full conformance without a document is telling you something about their testing, not about their product.

A pre-launch check you can run yourself

Thirty minutes, on a real phone, before you invite anybody.

• Turn on the screen reader and open the schedule. Can you find and open a session?
• Set the system text size to its largest. Does anything overlap or get cut off?
• Look at the app outdoors, in daylight. Is your theme’s body text still readable?
• Navigate with an external keyboard if the web version supports it. Is the focus visible at every step?
• Check that every track colour has a text label next to it.
• Check room names against the venue’s own signage list.
• Ask somebody who uses assistive technology to spend ten minutes in it, and pay them for their time.

The last one finds more than the other six combined. If your organization has an employee resource group or an accessibility lead, ask there first.

Getting it into procurement

If you need this to pass a review, bring three things:

1. The vendor’s written answer on WCAG version and level, and the conformance report if one exists.
2. Your own pre-launch check results, with dates.
3. The list of non-app measures you are taking, because a reviewer assessing the event as a whole should see the whole.

The third item is the one people leave out, and it is frequently what turns a conditional approval into an approval. The app is one part of an accessible event, and it is not the largest one.