Accessibility at PalomaCEO.ai

Last updated: November 10, 2026.

PalomaFinTech LLC, doing business as PalomaCEO.ai (“Paloma”, “we”), builds the online ordering pages and websites that restaurants and stores publish with Paloma — at order.palomaceo.ai or at the business’s own domain — and runs this site, palomaceo.ai. We want everyone to be able to read a menu, build an order and pay, whatever device or assistive technology they use.

1. Our standard

Our working standard for the pages guests use — a business’s menu, a dish’s page, the business’s own pages, the cart and checkout on those pages — is the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA.

Status: partially conformant. Much of the standard is checked on every change to our code (section 2), but some parts are not checked yet or may not fully meet it (section 3). We say so rather than claim more than we can show.

2. What we check on every change

These checks are part of the tests every change to our code must pass.

• An automated WCAG scan. A business’s menu, a dish’s page and a page of the business’s website, in English, Spanish, Russian and Ukrainian, and the page shown after payment, are scanned with axe-core against the WCAG 2.1 A and AA rules (colour contrast is measured separately, below), and must show no violation. The test also proves the scanner catches a real violation, so a clean result means something.
• Colour contrast. Every business picks its own colours. Before a colour scheme can be published, we measure it against the WCAG contrast ratio of 4.5:1: body text, secondary text, item names on cards, button labels, prices and links, and badges. A scheme that fails can be previewed but not published.
• Keyboard and screen readers. The dish, cart, checkout, delivery address and location panels open as dialogs named by their heading; the focus moves into the panel, and Tab and Shift+Tab stay inside it while it is open.
• Language. Each page declares its language, and guests can switch between English, Spanish, Russian and Ukrainian.
• Pictures. On a dish’s page, the dish’s photo or drawn picture has the dish’s name as its text alternative. In the menu, where the name is printed next to the picture, the picture is marked as decorative so a screen reader does not say the name twice.
• Zoom. Our pages never block zooming.
• Motion. When a guest’s device asks for reduced motion, panels appear in place instead of sliding in, and the page jumps instead of gliding when it scrolls; only the small loading mark keeps turning, to show that something is on its way. On a business’s own pages, a slideshow turns by itself only when the business set it to, and never for a guest whose device asks for reduced motion; when it does turn, a Pause button with its name in the page’s language stops it. A business’s video on its website has no sound and plays only while it is on screen, never on a device that asks for reduced motion or for less data, and has a button to pause it; every frame goes through a filter that tones down rapid flashing.
• Photo galleries. On a business’s own pages, a photo in a gallery opens in a dialog that the keyboard’s arrows move through and the Esc key closes, and the focus goes back to the photo that opened it.
• Announcements and pop-up windows. On a business’s own pages, an announcement bar is a named region at the top of the page that does not move. A pop-up window opens no sooner than three seconds after the page is in view and never on the menu, cart, checkout, order status, booking or catering pages; it is a dialog named by its heading, the keyboard focus goes inside and stays there, the Esc key closes it, and its Close button has a name and a target of at least 24 by 24 pixels.

Also built in, though not yet covered by a test: closing a panel returns the focus to where it was, and when a line disappears from the cart, a screen reader is told; a slideshow also stops while the pointer or the keyboard focus is on it (until you press Play yourself), while it is off the screen and while its tab is hidden; closing a pop-up window returns the focus to where it was.

3. Known limitations

• Parts drawn after the page loads. The automated scan reads each page as our server sends it. The cart, the checkout form, the address form and a guest’s sign-in and account forms are drawn in the browser afterwards, so the scan sees the page around them but not these parts themselves. The dialog rules in section 2 cover the cart, checkout and address panels, but the full WCAG scan does not reach these parts yet.
• Contrast beyond the colour scheme. Extra styling a business adds through the design assistant, and text on top of a photo header, are not measured for contrast.
• What the business adds. Item names, descriptions, photos and the text and pictures on a business’s own pages come from the business. The assistant is asked to write a description for every picture a business adds to its pages, but a picture can still end up without one. The same goes for a business’s video: it has no sound, and words or anything else it shows reach a screen reader only if the business also writes them on the page.
• Payment pages. Payment is completed on the payment provider’s own hosted page (Clover, Square or Stripe). Those pages are built and maintained by the provider.
• Not yet reviewed. The pages have not been reviewed by an independent accessibility auditor, and we have no recorded end-to-end test with screen readers such as VoiceOver, TalkBack or NVDA. The automated scan does not cover palomaceo.ai or the Paloma app that businesses use.
• Phone calls. When a caller asks for a person, a business’s AI phone assistant puts the call through to the business only if the business has set a transfer number, and such a transfer can fail. Calls placed through relay services (711) have not been tested. A business’s online ordering page is another way to order.

4. Report a barrier

If something on a page made by Paloma keeps you from reading the menu, ordering or paying, email support@palomaceo.ai with “Accessibility” in the subject line, or write to PalomaFinTech LLC, 2590 Hollywood Blvd, Hollywood, FL 33020, United States. It helps to tell us:

• the address of the page;
• what you were trying to do and what happened;
• the device, browser and any assistive technology you use.

We reply within two business days. If the barrier is in our code, we fix it and tell you when the fix is live. If it is in what the business added — a photo without a description, its own colours or text — we pass it to the business and tell you that we did.

If you need to order right away, call the business: its phone number is at the foot of its pages when the business has given one.

5. Changes to this statement

We update this statement when what we check or what we know changes, and change the date above.