Accessibility

Standards we target

Primary target: WCAG 2.2, Level AA. We design and build to the Web Content Accessibility Guidelines 2.2, Level AA. That covers the foundational areas — text alternatives, color contrast, keyboard operability, visible focus, predictable navigation, name/role/value for every interactive element — plus the 2.2 additions (focus appearance and visibility, minimum target sizes, no cognitive-function auth tests, redundant-entry avoidance).

Local legal framework: Israel. Israeli regulations require websites and services to conform to Israeli Standard 5568 Part 1 at Level AA, per the Equal Rights for Persons with Disabilities (Service Accessibility Adjustments) Regulations, 5773–2013, and specifically §35 (Internet services). WCAG 2.2 AA covers and exceeds the IS 5568 baseline; conforming to 2.2 AA satisfies the §35א obligation.

We continuously audit against these standards. This page is the §35ה accessibility statement.

What’s in place

• Skip link to jump past the header to main content on every page.
• Semantic landmarks (header, nav, main, footer) so screen readers can navigate by region.
• Labels on every form input. Errors and status messages live in ARIA live regions (role="alert" or role="status") so they announce as they appear.
• Alt text on photos. When you post a listing, the AI “Describe this” flow auto-generates short alt text from your image, and you can edit it before posting. Decorative graphics use alt="" so screen readers don’t read them aloud.
• Visible keyboard focus. A consistent focus-visible outline appears whenever you tab into an element, independent of the per-component hover styles.
• Minimum target sizes. Touch targets are at least 24×24 CSS pixels (WCAG 2.5.8); primary controls are larger.
• Accessible authentication. We sign you in with passkeys — no memorized passwords, no cognitive tests — which satisfies WCAG 3.3.8.
• Reduced motion. If your OS asks for reduced motion, our animations (slide-down menus, pulse indicators, skeleton loaders) are neutralized.
• Dialogs that behave. The accept-offer dialog has role="dialog", a label, focus moves into it on open, focus returns to the opener on close, and Escape closes it.
• No UUIDs read aloud. Internal identifiers like the truncated “Member ID” on profile pages are hidden from screen readers; only meaningful content is announced.
• Live region for the recents feed so the count of matching freebies is announced when filters change or as infinite scroll loads more rows. The list itself carries aria-busy="true"while a “load more” fetch is in flight, and the page-end “That’s the whole hive” note is a role="status" region.
• Three-state layout toggle on /recents (card / compact / dense). The segmented control is a group of buttons with aria-pressed and per-state aria-label; the chosen layout persists across visits via cookie + localStorage so the first paint already matches your preference.
• Color is never the only carrier of meaning. Condition chips, queue badges, and notification kinds all carry a text label in addition to color.

Known limitations

We test against assistive technology where we can, but we’re a small team and can’t guarantee every component is fully polished. Known rough edges we’re still working on:

• User-generated photos. Listings posted before the alt-text field existed may have empty alt text; we’re backfilling these via AI. Listings posted after will have accurate alt text either from the AI or the owner. If you find a photo with missing or wrong alt text, please report it via the listing’s “Report” button.
• RTL / Hebrew interface. We support Hebrew content (item titles, descriptions), but the surrounding chrome ships in English with LTR layout. A full RTL pass is on the roadmap.
• Browser push notifications. Push delivery depends on the browser’s native notification UI, which we don’t control.

Reporting an accessibility problem

If something on Freebee blocks you or doesn’t work with your assistive technology, please tell us. Per §35ה of the Service Accessibility Regulations, you have a direct channel for reporting:

• Email support@freebee.bz with the page URL, the action you were trying to take, and what went wrong (or what your assistive technology announced).
• Or use the contact form — accessibility reports go to the same inbox.

We aim to respond within a reasonable time, and never longer than the 60-day window §35א(ד)(1) gives us to fix a reported issue. Where a full fix takes longer, we’ll provide an alternative way for you to complete the same action in the meantime.

Scope and exemptions

Freebee is a small project. Even where Israeli regulation (§35ו(ז–ט)) would allow small entities reduced obligations based on average revenue, we voluntarily target the full WCAG 2.2 AA / IS 5568 AA baseline. If, in the future, a third-party platform or social-network embed prevents us from making a particular adaptation, we’ll list it here per §35ו(ג) along with an alternative path.