Accessibility, stated plainly.

Our commitment

Reos is a research platform built by Flob Inc. Researchers use it to plan, run and analyse studies. The people they invite to those studies use it as well, usually once, often on a phone, and without any training. Both groups include people who use a screen reader, work by keyboard alone, use speech input or a switch device, magnify the screen, or need larger text and stronger contrast. We want Reos to work for all of them.

We measure ourselves against the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. In the European Union the harmonised standard for accessible technology is EN 301 549, and its clause 9 adopts WCAG at level AA for web content, so meeting WCAG 2.2 AA is how we meet clause 9. The same target covers the refreshed US Section 508 and the UK public sector regulations, and we hold ourselves to one bar rather than three.

A Reos interview is a live two-way call in a browser. That makes clause 6 of EN 301 549, which covers real-time text and knowing who is speaking, apply to our call surfaces alongside clause 9. We assess against it and we report the result.

Level AAA is not our target. We adopt individual AAA criteria where they are inexpensive and useful, such as stronger contrast and longer session timeouts, but we do not claim them.

Conformance status

Reos is partially conformant with WCAG 2.2 level AA. Most of the standard is met, and some of it is not yet.

Through August 2026 we reviewed the product against every WCAG 2.2 AA success criterion and worked through three rounds of fixes. As of 1 September 2026 our self-assessment records every criterion we assess as met on the build we are about to release. Two things stand between that and calling ourselves conformant, and we will not claim it until both are true: the manual assistive-technology testing we describe below has to be completed - it is underway, and it may well find problems our tools could not - and the assessed build has to actually reach production. A self-assessment that has never been checked by a person using a screen reader is not something we will present as conformance.

What that work put in place:

• The interface components most of the product is built from, including menus, tabs, dropdowns, dialogs, drawers, tables and form controls, are operable by keyboard, expose their state to assistive technology, and are covered by automated accessibility tests that run with every change.
• Pages that carry navigation have a skip link and named landmarks, so a keyboard or screen reader user can get past the chrome to the content.
• The session timeout warns two minutes before it expires, and any activity extends it, including pressing Escape. A paused AI-moderated interview warns five minutes ahead, gives a full minute to answer with one button press, and can be extended ten times.
• Every media player attaches a caption track when a transcript exists, and shows the transcript next to the player.
• On a call led by a person, a participant can type instead of speaking. What they type goes on the wire as they type it rather than when they press Enter, at the same time as the voice and without switching to another mode. Each line carries the name of whoever wrote it, a line still being written says so in words, and a screen reader can read it as it arrives. The protocol we carry that text by is published at /accessibility/rtt-protocol.
• Each person's tile in a call shows whether they are talking, using a ring and a level meter rather than colour alone, so somebody who cannot hear the call can see who has the floor. Any participant can also tell the room that they are signing, and every tile then shows it.

Two things keep us from a stronger claim. Our conformance report records real gaps, criterion by criterion, and the ones you are most likely to run into are listed below. And no manual testing with assistive technology has been carried out yet: every verdict comes from reading the code or from measurement in a browser, not from watching somebody use a screen reader. Until that testing happens, some verdicts could move in either direction, and we say so rather than round up.

The full conformance report is available through our trust centre, alongside our other compliance documents. Request access at /trust/request.

What this statement covers

This statement applies to the Reos web application and website at www.reos.ai:

• The researcher application. Everything a customer's team uses inside their organisation: planning, recruitment, live and AI-moderated interviews, uploads and transcripts, analysis, reports and settings.
• Participant-facing pages. What the people invited to a study see: joining a live interview, an AI-moderated interview, a survey, a usability test, booking or rescheduling a session, feedback forms, the observer view, and shared reports and documents.
• The public website. Marketing pages, pricing, the legal documents, the trust centre, sign-up and sign-in.

What it does not cover, and why:

• Content our customers create. Recordings, uploaded files, question wording, prototypes and study material are authored by our customers and their participants. The section below explains how responsibility divides.
• Third-party content shown inside Reos. A prototype hosted by a design tool, an external website loaded during a usability test, or a document rendered from a customer's connected drive. We display these; we cannot change how they are built.
• Files Reos generates for download. Exported documents and data files have not been assessed against the standards for accessible documents.

Known limitations

These are the barriers you are most likely to run into. The conformance report holds the complete list of open findings.

1. Captions and transcripts are machine transcription, and nobody corrects them before they appear. Automatic captions are widely held not to reach the accuracy WCAG expects unless someone has confirmed them accurate by reading them. That confirmation now exists as a dated, signed attestation: our product owner reviewed live captions for hours across real calls in English and German while our transcription integration was built and tuned, and found them accurate enough to follow throughout. We record it as exactly what it is - an attestation of sustained review, not a call-by-call log - and our assistive technology testing now records a dated observation of the captions on every pass, so the record keeps growing. We have not measured a word error rate on our own calls, and we have stopped presenting a rate as the thing that would settle this: the accepted bar asks that captions be confirmed accurate by somebody reading them, which is a judgement rather than a percentage. Recognition comes from a third-party speech recognition service whose published accuracy figures are measured on its own test material rather than on audio from our calls, and our calls add two things those figures do not cover: compressed audio over a live connection, and speakers who change language mid-sentence. We would rather report our accuracy as unknown than quote somebody else's number as though it were ours. Only host and guest audio is captioned. In an AI-moderated interview the moderator's captions are the exact words it was given to speak, so they carry no recognition error at all.

2. Live captions are available in calls we run, and not in calls we only join. On a call led by a person, any participant can switch captions on for themselves, and the transcription starts whether or not the session is being recorded. Nobody has to ask the researcher for it, and nobody else in the call has to agree first. Everyone is told before they join that anyone in the call can do this, what it does and that nothing is saved when the session is not recorded, so the fact is disclosed rather than voted on - a person who needs captions cannot be left depending on everybody else. Captioning a session is not permission to keep a transcript: an unrecorded session that is captioned shows the lines to the people in the call and writes nothing down. Where a study is run through Zoom, Google Meet or Teams, the captions are that platform's and not ours. An in-person session recorded on one device gets no live captions from us and has no platform captions to fall back on. In an AI-moderated interview the moderator's words are captioned from the text it was given to speak, recorded or not.

3. Real-time text runs on calls led by a person, and keeps no history. It is not available in AI-moderated interviews. Only the host and the invited participant can send; an observer cannot. Nothing typed is stored, so somebody joining part-way through sees nothing of what came before, and there is nothing to read back after the call. Not recording what people type is deliberate. It is still a limit. The typing panel lays out correctly on a screen 320 pixels wide, but we have not yet confirmed that it and the indicator of who is speaking are both readable at once at every window size people use.

4. A transcript is not a full alternative for a screen recording. For a talking-head interview, the words carry the information and the transcript is a complete alternative. For a screen share or a usability session, the screen is the point, and a dialogue-only transcript does not capture what the participant clicked or what the interface did. Our analysis writes visual observations from the video into text, which narrows the gap. It is a summary, not an equivalent, and we do not present it as one.

   What is changing, and it has not reached you yet. We have built, but not yet released, a change that stops an undescribed screen recording playing outside the organisation: the link will return a message naming what is missing and who can add it, rather than a broken player. The same will apply to a call recording where the room recorded that somebody shared their screen while it was recording. Today, both still play. When it does ship, a share link already sitting in someone's inbox will stop working until a description is written, and we would rather say that here in advance than have it surprise somebody. We chose it over gating only new links, because gating only new links leaves every link already sent playing content that cannot be described to somebody who cannot see it. Recordings made before that release carry no record of whether a screen was shared, so they will not be gated. That is a decision rather than an oversight, and it has a cost we would rather state than have found: a call recorded before that release that does contain a screen share keeps playing outside your organisation with no description. We chose that over stopping every interview recording ever shared from playing, and over guessing which old ones qualify.

   And we are making the description easier to write rather than only harder to skip. The visual observations our analysis already extracts from the video will be turned into a draft description that the author reviews, edits and approves. A draft nobody has approved does not count as a description and does not unlock the link, because an unreviewed machine summary is not an alternative for somebody who cannot see the screen.

5. The video briefings we generate describe themselves through their narration. A briefing is a set of slides with a spoken narration over them, so somebody who cannot see the slides receives their content only through that narration. We write it to speak the figures, quotes and names on screen, and the product refuses a slide whose narration leaves something out. That check compares words: it can tell that a figure was spoken, not whether the sentence around it is helpful to listen to. The text of every slide is also shown next to the player, so what was on screen can be read as well as heard.

6. Keyboard focus can end up partly covered by the header. Several pages in the researcher application stack a header, a tab bar and a toolbar at the top of the screen. We tell the browser to hold the focused element clear of them, and a headless browser presses real Tab and Shift and Tab keys through several hundred screens, almost eighteen thousand stopping points in all, checking what covers the control that has focus. No stop ends with the focused control completely hidden. About one stop in six ends with it partly covered, which passes the level AA criterion and would fail the stricter AAA version we do not claim. That measurement runs one browser at one window size with no zoom, and it is not the same thing as a person using the product.

7. Most forms still do not announce their errors, though the ones you meet first now do. Signing in, registering, resetting a password, entering a two-factor code and completing onboarding now put each message on the control that is actually wrong, where a screen reader reads it out. The input components that do that are used by a minority of the form controls in the product, so elsewhere an error can still appear on screen without being announced.

8. No testing with assistive technology has been done yet. Everything above was found by reading code, by automated tools and by measurement in a headless browser, and the same is true of the fixes. Screen reader announcements, real focus behaviour in a browser somebody is using, speech input and magnification have not been tested by hand. There will be barriers we have not found, and some of what we believe we have fixed will need confirming.

Content our customers create

Most of what a researcher looks at in Reos was made by somebody else: a recording of an interview, an uploaded video, a prototype, the wording of a survey question. Reos captures, stores and analyses that material. It does not author it and cannot review it.

Where a barrier is in the content itself, the customer who created it is responsible for it, in the same way that the accessibility of a document uploaded to a file store belongs to whoever wrote the document. We do not treat that as a reason to stop there. What we are responsible for, and what we provide, is everything around the content:

• Media players with keyboard-operable controls and proper labels.
• A caption track attached whenever a transcript exists for the recording. Where no captions appear it is because transcription has not run or has not finished, not because the player drops them.
• Automatic transcription of recordings, and the transcript presented next to the player under a heading of its own, as the text alternative.
• Written visual observations extracted from video, which put some of what happens on screen into text.
• A page around the player that meets the same standard as the rest of the product.

If a customer needs help making their own study material accessible, or a participant hits a barrier in content a customer wrote, tell us. We will pass it to the organisation that created it and help them fix it.

How we tested

This statement is based on a self-assessment carried out by Flob Inc., using four methods.

• Static analysis. Thirty-seven accessibility rules run across the whole codebase as errors. They catch missing alternative text, invalid ARIA, controls with no accessible name, and interactive behaviour attached to plain containers.
• Automated testing. axe-core runs against rendered components in our test suite, restricted to the WCAG 2.2 AA rule set. The tool's default rules mix in best practice and level AAA advice; we run only the standard we commit to, so a pass means what it says.
• Manual code review. Every success criterion was reviewed against the source by hand, and separately for each surface. That included keyboard paths, focus handling, contrast ratios computed from the design tokens for both the light and the dark theme, and the caption pipeline end to end.
• Measurement in a browser. Eight instruments load real screens into a headless browser and measure what reading the code cannot settle: layout at a window 320 pixels wide, where the keyboard actually puts focus and what covers it, the rendered size of touch targets, the order of the headings on the page, and colour read back out of painted pixels rather than computed from a token. They run one browser engine on test data.
• Two of those instruments now run on every change. Layout at 320 pixels wide and heading order are checked automatically before any change can be merged, and a change that breaks either one is blocked. We added the second of those after a change of our own broke heading order and only a hand-run check noticed.

Automated tooling finds a minority of accessibility problems, and the mechanical ones at that. It cannot tell you whether alternative text is meaningful, whether reading order makes sense, or what a screen reader actually says. That is why our conformance status stops at partial.

No external auditor has reviewed this assessment, and no independent audit is commissioned at present. Where a customer needs third-party validation, we will arrange one with them as part of their contract.

The next step is manual testing with a screen reader on Windows and macOS, keyboard-only passes over the main journeys, and checks at 200 percent zoom, after which we will publish an updated statement.

Report an accessibility barrier

If any part of Reos is difficult or impossible for you to use, we want to hear about it. This applies whether you are a customer, someone in a customer's organisation, or a participant who was invited to a study.

Email accessibility@reos.ai, or write to Flob Inc., 1111B S Governors Ave STE 49827, Dover, DE 19904, United States.

It helps if you can tell us the page or the address, what you were trying to do, and what assistive technology, browser and device you were using. Do not worry if you cannot supply all of that; report it anyway.

What we commit to:

• We acknowledge every report within five working days.
• We give a substantive answer within twenty working days: either the barrier is fixed, or we explain what we are doing about it and when we expect it to be done.
• If something blocks you from completing a task, we will provide the information or carry out the task another way while the fix is in progress. Ask us for it in the same message.

Responsibility for this statement and for our accessibility work sits with the engineering lead at Flob Inc.

Enforcement and escalation

If you are not satisfied with how we respond, you can escalate.

Users in the European Union may raise the matter with the market surveillance body designated in their member state under the national law implementing the European Accessibility Act. In Germany the designated body is the Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF), Carl-Miller-Straße 6, 39112 Magdeburg, telephone +49 391 567 6970, kontakt@mlbf-barrierefrei.de.

Customers with contractual accessibility requirements should raise them through their usual contact with us.

Preparation and review

This statement was prepared on 30 August 2026 and applies from that date. It replaces the version prepared on 28 August 2026.

What changed in this version:

• Real-time text on calls led by a person, the per-participant indicator of who is speaking, and the control for telling the room that you are signing, are described for the first time. None of them existed when the previous version was written.
• Live captions no longer require a recording, and no longer require everyone in the call to agree first. The disclosure moved to the notice everyone reads before joining.
• EN 301 549 clause 6 is named as in scope.
• The protocol we carry real-time text by is published, so it can be read by anyone who wants to work with it.
• The limitation about form errors is narrowed to the forms that still have it, and the limitation about keyboard focus is answered with a measurement rather than an estimate.
• The limitation about drag interactions is removed. Those interactions now have an alternative that does not require a drag.
• The commitment to measure caption accuracy is withdrawn, and the limitation about it says why. Corrected 31 August 2026: an earlier version of this page said no standard we report against sets a number for caption accuracy, and treated that as a reason the measurement did not matter. That was the wrong inference. W3C's guidance is that automatically generated captions do not meet accessibility requirements unless they are confirmed to be fully accurate - a requirement without a number, not the absence of one. Our live captions are unedited automatic speech recognition and we have not confirmed their accuracy, so we report it as unknown and treat the criterion as unmet rather than as unmeasured.
• This statement now covers only the surfaces customers and participants use.
• Our conformance status has not changed. Reos is partially conformant, nine criteria remain only partially supported, and no assistive technology testing has been done. (Superseded the next day - see the update below.)

Updated 1 September 2026. Six of the nine criteria moved to supported, none of them because code changed that day. We had been grading ourselves more strictly than the standard asks: a criterion where we had found nothing wrong was still reported as unmet until our measurements reached the whole product. We have adopted the standard's own rule - a criterion with no identified failure is met, and how far our measurement reaches is reported as a limitation, in the "How we tested" section, rather than as a failure. Two of the six also rest on the division of responsibility described under "Content our customers create", which has been on this page all along. Everything in the known limitations list above stays true and stays listed; nothing was removed to make the number smaller. Later the same day the last three closed: the live-caption accuracy record now exists as a signed attestation (described under known limitations above), the audio measurement job was run on our staging environment with the remaining unmeasured population being our own silent walkthrough clips, and the language-tag repair on old transcripts is scheduled as a fixed step of the release itself. Every criterion we assess now reads as met in our self-assessment. We still do not claim conformance on this page, for the reason we have given all along: the assistive technology testing has not been completed. It is now underway with a defined test plan, and this page changes only when it is done and what it finds is fixed.

We will review this statement at least once every twelve months, and sooner whenever a significant change ships or the results of assistive technology testing come in. The known limitations list is updated as items are fixed and as new ones are found. The next scheduled review is by 1 September 2027.

Approved by the engineering lead at Flob Inc. on 30 August 2026.