Captions are not an add-on in Codexal Meet, they are how the product works. This is our formal conformance statement, the criteria we meet, and the places we know we fall short.
"Partially conformant" is the honest word. We build and test to WCAG 2.1 Level AA and meet it across the site and the meeting room, with two known exceptions we list openly below rather than burying: automatic caption accuracy varies with accents and background noise, and screen sharing shows a video stream whose contents we cannot make accessible on the presenter's behalf. Neither is a reason to stop improving, and both are why an accessibility report from you is treated as a bug report.
Speaker-aware captions in Arabic and English in every meeting, on every plan including the free one, and a written summary afterwards — so following a meeting never depends on hearing every word live.
Every control in the room and on the website can be reached and operated with the keyboard, in a logical order, with a focus ring you can actually see. No control is mouse-only.
Semantic HTML and labelled controls, so a screen reader announces what a button does rather than what it looks like. State changes — muted, hand raised, someone joined — are announced, not just drawn.
Text meets AA contrast. Colour is never the only signal: a muted microphone has an icon, a live meeting has a label, a recording says "recording" as well as turning red.
The recap is text: summary, decisions and action items, emailed and readable in any assistive technology. Someone who could not follow the call live is not left with a video to re-watch.
Animation is quiet by default and respects the operating system's reduced-motion setting. Nothing flashes, and nothing moves that did not need to.
The success criteria that a video meeting platform lives or dies on, and where we stand on each.
It goes in the same list as a crash, with the same owner and the same expectation that it gets fixed. It is not a feature request, and it does not wait for a quarter with room in it.
Automated checking catches perhaps a third of what matters, so the rest is done by hand, on the real product.
EN 301 549 is the accessibility standard European public bodies must apply when they buy ICT. For web content it incorporates WCAG 2.1 Level AA directly, so the table above answers most of it. Two clauses are specific to a product like ours, and they are worth calling out:
If you are running a procurement under EN 301 549 and need this mapped clause by clause onto your own template, send it to info@codexal.co and we will complete it.
Section 508 of the Rehabilitation Act requires federal agencies to procure accessible ICT, and its refreshed standard is harmonised with WCAG 2.1 Level AA — the same criteria as above.
A Voluntary Product Accessibility Template is the usual way to record that in a US procurement. We do not publish a pre-filled VPAT, because a VPAT written for nobody in particular tends to say "supports" a great deal more often than it should. We complete one against your version of the template, per request, with the two known limitations stated in it.
Request one at info@codexal.co.
If something on Codexal Meet does not work for you, write to info@codexal.co or call +962 6 582 4373. Tell us the page or the part of the meeting room, what you were trying to do, and what assistive technology you use if you use one — but a sentence saying "the mute button does not announce itself" is enough to act on.
We acknowledge accessibility reports within two working days and tell you what we are going to do about it, including when the answer is that it will take a while.
Codexal · Amman, Jordan.
We will complete your template, VPAT or EN 301 549 mapping, with the limitations stated.