Legal

Accessibility statement

Cítame aims to make the public directory and owner tools usable by as many people as possible, including people who use assistive technologies.

Last updated September 23, 2026

Citame is committed to making Citame accessible, in line with WCAG 2.2 Level AA.

Partially conformant. Partially conformant with WCAG 2.2 Level AA. "Partially conformant" means some parts of the content do not fully conform. 16 of the 55 success criteria have not yet been evaluated, so no claim is made about them.

Read the full Accessibility Conformance Report for Citame, with remarks for every success criterion.

1.3.1 Info and Relationships — does not support: All seven directory pages (/directory and each ?category= variant) render from a template that exposes an empty headings collection — no h1 through h6 anywhere — while the page visually presents a category label ("Understanding: plumbing"), a result count ("21 results"), a filter form, a results list and a Leaflet map. Because that visual hierarchy has no programmatic equivalent, screen reader and voice users get no outline for moving between the filters, the results and the map; adding a single h1 would not resolve it, since the section titles and per-result business names also need real heading or list markup. Separately, on the home page the HVAC category tile computes an accessible name of "HVACClimatización", running the English and Spanish labels together with no separator, which suggests the label/translation relationship is carried by styling alone — the underlying markup was not inspected, so a human reviewer should confirm whether those strings are distinct elements. Recommended changes: make "Understanding: plumbing" an h1, mark the results count and map regions with h2s or named landmarks, wrap the result cards in a ul/li with each business name as an h3, and split the tile text into separate elements (e.g. a span for "HVAC" and a span lang="es" for "Climatización"). Pages /app and /create were reached signed in but produced no findings under this criterion; absence of a finding there is not the same as a verified pass, and a structural review of the authenticated dashboard is still outstanding.
2.4.1 Bypass Blocks — does not support: Eight of the ten evaluated pages provide no working bypass mechanism. All seven directory views (/directory and each ?category= variant) render from one template in which the skip link, the main landmark and headings are all absent simultaneously — captured evidence shows hasSkipLink: false, landmarks limited to header/nav/aside/form, and headings: [] — so a keyboard user must pass the brand link, Directory, Dashboard, Log out and six filter controls before reaching results, which on the unfiltered view precede a 53-item list of over 100 interactive elements. /create uses a different template and is missing both the skip link and a main landmark, leaving its single h1 as the only bypass route. The home page and /app were not flagged. Suggested remediation: make the first focusable element of every page `<a href="#main" class="skip-link">Skip to results</a>`, wrap the results and map in `<main id="main" tabindex="-1">`, and add `<h1>Local business directory</h1>` with an `<h2>` naming the active category (for example `<h2>Plumbing</h2>`); the /create template needs its own main wrapper.
2.5.8 Target Size (Minimum) — does not support: 56 target-size findings were recorded and they affect the global chrome rather than isolated pages. The shared site header renders "Directory" (54×20), "Dashboard" (68×20), "Log out" (46×20) and "Add yours" (56×18) with zero reported spacing between adjacent targets at both desktop and 390 px, and the /app sidebar stacks "Billing", "Public page", "Free snapshot" and "Log out" at 199×18 with zero spacing, so a mis-tap between "Free snapshot" and "Log out" ends the session and a mis-tap between "Dashboard" and "Log out" discards in-progress data on /create. The Leaflet marker pins on the dentist, plumbing and water-damage-restoration views are 14×14 with zero spacing and cluster within a metro area, making individual businesses unreliable to activate; homepage city links ("Los Angeles, CA" 108×15, "Houston, TX" 84×15, "Chicago, IL" 72×15), the "View all →" link (56×18) and the footer links including "Terms of use" (72×18) show the same defect. None of these are links inside a sentence, so the inline-text exception does not apply, and overlapping 24 px hit areas rule out the spacing exception. Fix the navigation and footer with one rule — `display:inline-flex; align-items:center; min-height:24px; padding:2px 8px; margin:2px 0` on header nav, sidebar and footer anchors and buttons — and set the Leaflet icon to `iconSize:[24,24], iconAnchor:[12,24]` so the pin hit area meets the minimum without changing the visible pin art.
3.1.2 Language of Parts — does not support: Spanish-language content appears inside documents declared lang="en" without a part-level language declaration. On the home page, every directory category tile pairs an English name with a Spanish translation — accessible names captured include "Water Damage RestorationRestauración por Daños de Agua", "LandscapingJardinería y Paisajismo" and "Auto RepairMecánica Automotriz" — so a screen reader applies English pronunciation to the Spanish string. On /app, select#language-preference exposes the option "Español" (accessible name "Language preferenceEnglishEspañol") with no lang marking, which affects precisely the users most likely to need the voice switch. Fix: wrap the translated string in its own element, e.g. <span lang="es">Restauración por Daños de Agua</span> and <option value="es" lang="es">Español</option>; the run-together accessible names also indicate the two strings need separating whitespace or a comma. Both findings derive from accessible-name inspection rather than confirmed DOM review — a reviewer should open the tile markup to confirm no lang attribute is present before the vendor signs this row.
1.1.1 Non-text Content — partially supports: One failure was recorded in the 23 September 2026 evaluation: the Leaflet map on /directory?category=plumbing (.leaflet-container) has no role, no aria-label and no text alternative for the composite map, and its 21 result pins expose no accessible name. The 16 OpenStreetMap tile images are correctly marked decorative with alt="", so the tiles themselves are not the defect — the map as a unit is unnamed. The adjacent results list does repeat each business name and address and could serve as the equivalent alternative, but nothing programmatically connects the two. Suggested fix: give the container role="img" with aria-label="Map showing the locations of the 21 plumbing businesses listed below", or mark the map aria-hidden="true" and add visible text stating that the list below contains the same results. No other non-text content on the 10 evaluated pages, signed in, was flagged.
1.3.5 Identify Input Purpose — partially supports: The profile Name input on /app (input[name="name"], visible label "NAME") carries no autocomplete attribute, so user agents cannot identify that it collects the user's own name — 1 instance. Fix: add autocomplete="name" to that field. No other missing-token findings were recorded across the ten evaluated pages, including the /login form and the /create listing form, though the /create fields collect business rather than personal data and deeper authenticated settings screens beyond the dashboard shell were not reached, so coverage of this criterion is not complete.
1.4.1 Use of Color — partially supports: Inline links inside body sentences are distinguished from the surrounding prose by the terracotta colour alone: <a class="text-terracotta" href="/create">add a listing</a> in the empty-state list item on /directory?category=electrician, ?category=hvac and ?category=roofing (automated, 3 pages), and the "Add a new business" link inside "No businesses linked yet. Add a new business." on /app. Terracotta rgb(196,92,58) against the muted body text rgb(107,100,91) is roughly 1.4:1, far below the 3:1 needed for hue alone to carry the distinction. Fix: apply text-decoration: underline to .text-terracotta when it appears within a paragraph or list sentence, not only on :hover. Standalone linked headings, buttons and card links elsewhere on the site were not flagged, and no colour-only status or required-field indicators were recorded — but validation and error states behind the sign-in were not exercised, so that part of the criterion is unverified.
1.4.3 Contrast (Minimum) — partially supports: Automated contrast measurement returned 14 serious findings, and they trace to a small number of reused design tokens rather than isolated pages. The primary submit button (bg-terracotta with text-bone-raised, 12px) fails on nine of the ten pages — "Update results" on the directory filter and "Create listing & continue" on /create — at roughly 4:1 where 4.5:1 is required for text this size. Terracotta link text fails the same way ("Add yours", "add a listing", "View all →", "Add a new business" on /app), and the text-ink-faint token fails at 10–12px on /app ("Owner" chip) and on the homepage ("Unclaimed" badge, the 50-states paragraph) and directory cards. Suggested fix: darken terracotta from #C45C3A to approximately #A2492A (≈5.6:1 on the bone background) for both link text and the button fill, and replace text-ink-faint with a value at or below ≈#595249 wherever it is used at under 18.66px. Body copy and headings outside these tokens were not flagged; no text over images or gradients was present, so the automated measurement is reliable here.
2.4.2 Page Titled — partially supports: Two of the ten pages evaluated carry only the bare brand name as their document title: /create uses <title>Cítame</title> while the page content is the listing-creation form (h1 "Create your listing"), and /app uses the same <title>Cítame</title> for the account/settings screen (h1 "Account", breadcrumb "SETTINGS"). Because the identical string is used on both authenticated routes, users switching browser tabs or reviewing history cannot distinguish them. The public directory pages were not flagged for this criterion. Recommended fix: emit route-specific titles such as "Create your listing — Cítame" and "Account settings — Cítame".
2.4.4 Link Purpose (In Context) — partially supports: Four distinct link-purpose defects were recorded. The "Add yours" link to /create repeats on four directory category views (dentist, electrician, hvac, water-damage-restoration) with no noun in its name — its only adjacent context is a result count such as "0 results" — and the same /create destination is labelled "add a listing" elsewhere on those pages, giving one target two names. On /directory, two result links both read "Valley Restore" but resolve to /en/plumbing/new-york-ny/valley-restore-new-york-ny and /en/water-damage-restoration/fresno-ca/valley-restore-fresno; whether the disambiguating address shares a list-item ancestor needs confirmation in the live DOM. In the /app sidebar, "Public page" (href="/") opens a new window without saying so, and the header home link's accessible name computes to "CítameOwner" because the OWNER role badge is nested inside the anchor. Suggested changes: label the directory CTA "Add your business listing", give each result link an accessible name of the form "Valley Restore — plumbing, New York, NY", move the role badge outside the header anchor, and append "(opens in a new window)" to the sidebar link.
2.4.6 Headings and Labels — partially supports: Page headings on the evaluated routes describe their topic ("Create your listing" on /create, "Account" on /app), but two labelling defects were found. Each of the 21 directory result rows on the plumbing, dentist and water-damage-restoration category pages is a <button> whose accessible name is the concatenated card text with no separators or verb — e.g. "AshClear RestorationunclaimedPlumbing950 Cedar Ln, Monterrey, NLE, MX" — so the control's purpose is never stated; the vendor should confirm the button's actual behaviour (likely selecting the matching map pin) before wording is fixed, e.g. aria-label="Show AshClear Restoration on map". Separately, the home-page search field takes its accessible name from the placeholder "Plumber in Dallas TX, dentist Miami…", which is sample content rather than a description; add a visible or visually-hidden label reading "Search businesses". All three category pages share one card template, so a single component change resolves the button finding.
2.5.1 Pointer Gestures — partially supports: Vendor attests in the conformance interview that no swipe, pinch or two-finger gesture is required anywhere in Citame, and the crawl of /app, /create and the directory views found no custom gesture handlers outside the map. That attestation is contradicted in one place: the Leaflet map embedded in every /directory view is a standard Leaflet instance, which responds to pinch-zoom and to click-and-drag panning. Zoom has a conforming single-pointer alternative — the "+" and "−" anchors with accessible names "Zoom in" and "Zoom out" — but repositioning the viewport is a path-based operation with no button, list or other non-path equivalent exposed. Because the gesture behaviour was inferred from the Leaflet control markup rather than exercised on a touch device, a reviewer should confirm on the live product before this row is signed.
2.5.7 Dragging Movements — partially supports: Outside the map, nothing in the evaluated product requires a drag: the /create listing form, the /app dashboard and the directory result lists expose only links, buttons and standard form controls, with no sortable list, slider or drag-and-drop upload found. The single failure is the shared Leaflet map on /directory and all five category views (dentist, electrician, roofing, water-damage-restoration and the unfiltered view), where the only exposed pointer controls are "Zoom in" and "Zoom out" — repositioning the viewport requires a click-and-drag path with no single-pointer alternative, which excludes head/eye-pointer, switch-pointer and tremor-affected users. Because it is one shared component, adding pan buttons to the map chrome (four directional buttons calling map.panBy, or a "Recentre on results" control) resolves it on every page at once. Drag-only behaviour was inferred from the Leaflet control markup; a reviewer should confirm on the live build whether keyboard arrow panning or any non-drag pan affordance already exists.
3.3.2 Labels or Instructions — partially supports: The directory filter form fails on /directory and on all six category-filtered variants (plumbing, electrician, roofing, hvac, dentist, water-damage-restoration): the two free-text inputs report labelSource "placeholder" ("Business name or 'plumber in Dallas'" and "City (e.g. Dallas)"), and the four accompanying selects have no label at all — their only on-screen clue is the selected option text ("US + Mexico", "All categories", "All states", "Any status"). The home page search input at / has the same defect independently, taking its accessible name from the example-query placeholder "Plumber in Dallas TX, dentist Miami…". Placeholder text disappears on entry, so magnification, memory-impairment and voice-input users lose all field identification once typing begins. Fix: add persistent visible labels tied with for/id — e.g. <label for="q">Business or service</label>, <label for="city">City</label>, <label for="region">Country</label>, <label for="category">Category</label>, <label for="state">State</label>, <label for="status">Listing status</label> — keeping the current strings as placeholders for examples only; the directory form is one shared template, so a single edit corrects seven pages.
4.1.2 Name, Role, Value — partially supports: Signed-in evaluation on 23 September 2026 found no name/role/value defects on /, /app or /create, but the directory template fails on all seven /directory URLs: four filter <select> elements (status "Any status/Claimed/Unclaimed", the country selector "US + Mexico/United States/Mexico", and the two selects in the .grid.grid-cols-2 blocks) carry no accessible name at all, so they announce only as "combo box". On the same template, Leaflet map pins are rendered as <div role="button" tabindex="0"> with no text content and no aria-label, and each result row is a <button> that also contains nested interactive controls, which axe flags as nested-interactive and which screen readers announce inconsistently. The row button's accessible name is the run-together row text (e.g. "AllHours Water CareunclaimedRestaurant474 Hillcrest Dr, Phoenix, AZ"); it never states the action performed and no selected state (aria-pressed or aria-current) is exposed, so activation produces no perceivable change for AT users. Recommended fixes: give the selects real labels — <label for="filter-status">Listing status</label>, <label for="filter-country">Country</label> — set aria-label="Show AllHours Water Care on map" on each pin, remove the nested control from the row button, and add aria-pressed to indicate the selected row.
4.1.3 Status Messages — partially supports: The vendor's manual check "Status messages are announced without moving focus" was recorded as observed-supporting on 23 September 2026, but it conflicts with the page evidence on /directory?category=roofing, where the DOM declares no live regions (liveRegions: []) while the page renders "0 results" and "No businesses match — try clearing filters or add a listing." If filter changes update results in place, neither the count nor the empty state is announced; if each filter change causes a full page navigation, that specific case falls outside this criterion. This discrepancy is flagged for human review before the row is finalised — the scope of the tester's observation (which screen, which status message) is not recorded. Suggested remediation regardless of outcome: wrap the result count and empty-state text in a single container with role="status" (aria-live="polite") that is present in the DOM before filtering so updates are announced.

We welcome your feedback on the accessibility of Citame. If you encounter a barrier, or need information in a different format, please let us know at accessibility@usegoodform.co. We aim to respond within five working days.

Accessibility of Citame relies on HTML, CSS, JavaScript and WAI-ARIA, and on the combination of a modern web browser with any assistive technology installed on your device.

This product was evaluated by self-assessment using Affido, which combines automated testing in a real browser with analysis of page content. Platforms covered: Website or web app tested directly in a browser. 10 pages were tested, including pages behind sign-in. 12 success criteria that cannot be verified by automated means were checked manually by the vendor. This evaluation was not performed by an independent third party.

Accessibility statement

Accessibility statement for Citame

Conformance status

Measures we take

Known limitations

Feedback

Technical specifications

How this was assessed

About this statement