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.
• Predictable app navigation. Header links keep the same task order across wide and narrow layouts, expose the current page with aria-current, retain visible keyboard focus, and use comfortably sized controls. The compact menu reports whether it is open and closes with Escape, returning focus to the menu button.
• 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.
• Search and filter controls. A labeled clear-search button removes the query, keeps your other filters, and returns keyboard focus to search. Selected condition filters include a checkmark and announce their current state. Decorative bees and flight paths are hidden from screen readers.
• Photo upload and alt text. The photo picker exposes one native button as its single keyboard and screen-reader focus target; its hidden file input is not exposed as a second control. Every photo you attach to a freebie has its own optional description field, and the AI “Describe this” flow auto-generates short alt text for the cover photo, which you can edit before posting. On freebies with several photos, labeled dots and previous/next buttons announce the selected photo. You can also swipe between photos. Clicking a card’s photo or title opens the freebie’s detail page. Opening a photo from that page shows the entire image in a dialog with keyboard arrow navigation, contained focus, and a close button. Swiping up or down, pressing Escape, or using Close returns to the detail page and restores focus to the photo control. Photos keep a stable frame during loading and switching, and a failed photo can be retried. Decorative graphics usealt="" 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, menu expansion, form steps, photo expansion and fades, save feedback, pulse indicators, and skeleton animations are neutralized. Controls remain usable during transitions, and a closed menu immediately leaves the keyboard and screen-reader navigation order.
• Dialogs that behave. The accept-offer dialog has role="dialog", a label, focus moves into it on open and stays inside while it is 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.
• Responsive filtering and saving. Search keeps focus as results update, without jumping back to the top of the page. Filter progress is announced. Optional popular tags are in an expandable section, and save and loading failures provide written feedback with retry controls.
• Forms that keep you informed. Photo description failures retain the current draft and can be retried. Posting and pickup confirmation announce progress and disable their submit buttons while the request is pending.
• Native app accessibility. The iOS and Android apps provide separate labeled controls for opening and saving a freebie, larger photo selectors, controls that grow with system text size, and written retry states. Press, photo, posting, and navigation animations respect the system reduced-motion preference, including changes while the app is running. Pressed controls retain visible feedback with motion disabled. iOS uses white backgrounds in light mode and black in dark mode, with solid cards, form sections, inline buttons, and filter tags. Floating controls use native Liquid Glass on supported devices and return to solid styling when they move inline. These controls use solid backgrounds on older iOS versions and when iOS Reduce Transparency or Increase Contrast is enabled, including changes while the app is running. Low Power Mode keeps native glass on floating controls. Light-mode cards use a subtle shadow against the page. Android follows Material You system colors where supported, with a yellow-based Material palette as the fallback. Text and controls use the palette’s matching foreground colors in both light and dark mode. Selected filter tags show a checkmark and announce their selected state, with the same control size before and after selection. Unselected labels are centered; selection gently moves the label and fades the checkmark. These transitions are immediate when reduced motion is enabled. Native chip groups provide individual Show all and Show fewer controls that report their expanded state. Compact groups scroll horizontally, with decorative edge fades where more choices remain; expanding reveals complete wrapping labels that grow with system text. The same controls serve filters, tags, report reasons, and other chip selectors. Active feed filters also remain summarized. Freebie cards provide separately labelled Save and Share actions with 48-point touch targets, alongside the photo and details links. Mac and system-identified Android desktop windows use smaller controls suited to a pointer. Chips begin at 28 points on Mac and 32 dp on Android desktop; control sizes still grow with system text, while touch layouts retain their larger targets. Mac freebie details group the Save and Share icons together; each keeps a screen-reader name and a native hover tooltip. On Android, app-drawn buttons show keyboard focus and mouse hover feedback. A right-click on a freebie opens its quick actions; native keyboard activation remains available. Forms account for the keyboard and bottom safe area.
• Desktop and tablet controls. Wide workspaces provide labelled Freebies and Alerts navigation, search, New Freebie, recent alerts, and profile controls. The bell reports unread alerts in its accessible label; the recent-alerts panel includes loading, empty, error, and signed-out messages, plus View all alerts and native dismissal or a Close control. Mac uses its native window toolbar and app menus, with Settings in a separate window that leaves the main page and unfinished input open. Android workspaces provide a labelled Settings cog that opens the settings panel. On iPad, Settings opens a SwiftUI sheet with a native title, Close control and swipe dismissal; the bell opens an anchored native popover. About Freebee remains available in Settings. The iPad Profile button opens a page with the native back gesture. In portrait and landscape, touch tablets place navigation in the top bar: the Freebee wordmark is a labelled button back to Freebies, and search, alerts, Settings, and profile remain reachable. Search text and unfinished input remain in place through rotation. iPad toolbar spacing follows the window controls reported by iPadOS, and compact windows move content below those controls. Its search field uses native Liquid Glass where supported. Custom iPad buttons support the system pointer hover effect. The search field and frosted toolbar use solid backgrounds when iOS Reduce Transparency or Increase Contrast is enabled; older Android versions without the supported blur effect also use a solid toolbar. iPad app menus offer New Freebie, Search, Settings, About Freebee, Freebies, Alerts, Profile, Back, and Forward. Back and Forward are available when navigation history permits; New Freebie is disabled while the posting form is open. The iOS posting sheet uses native Cancel/Back and Next/Post controls, confirms before discarding a draft, and keeps entered details when a request fails. Settings is disabled while that sheet is open. Mac and iPad support Command+N for New Freebie, Command+F for search, Command+comma for Settings, Command+[ for Back, and Command+] for Forward. iPad also provides Command+1 for Freebies and Command+2 for Alerts. Android desktop uses Control+N for New Freebie, Control+F for search, Control+comma for Settings, and Alt+Left for Back. These commands have visible alternatives; normal text entry, text composition, and native Enter and Space activation retain their platform behavior.
• Adaptive native layouts. The apps adjust feed columns and freebie details to the available width and system text size. On supported Android foldables, the feed, posting form, and freebie details use system-reported hinge bounds to keep content clear of the hinge. In tabletop mode, freebie photos appear above the fold with details below. On iPhone Duo with iOS 27.1 or later, the app uses system-reported folding and active-camera regions to keep custom content and controls clear. Readable feed columns sit on either side of a vertical fold; a horizontal fold places filter controls above results, and Me’s account overview above its collections. Fully open displays may use the center as part of the normal layout; larger text and narrow panes use one scrolling surface. Apple navigation on iPhone and compact iPad layouts keeps its system placement, and content clearance follows tabs when they move to a different edge. Android desktop workspaces use labelled side navigation; touch tablets use the top bar. Compact workspaces return to system tabs when the available space becomes smaller. Display changes preserve the open freebie, selected photo, reading position, search filters, and unfinished form input. The Me tab uses compact account sections and photo-card grids on wider screens, returning to a single column when larger text needs more reading space. Tablets use the available width; a center gap appears only for an active reserved folding region.
• Color is never the only carrier of meaning. Condition chips, queue badges, and alert kinds all carry a text label in addition to color.
• Accessible moderation. The private reports console preserves a logical heading and reading order as it reflows, and every report state has an icon and written label instead of relying on color alone. Dismissing a report announces success or failure, prevents duplicate submissions, and returns keyboard focus to the reports heading when the report leaves the open view. Open and dismissed reports have labeled navigation.
• Cross-browser and mobile checks. Core public navigation and feed flows are manually checked in current Safari, Firefox, Chrome, and Mobile Safari, including narrow reflow and iPhone safe-area spacing.

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. Freebies posted before the alt-text field existed may have empty alt text; we’re backfilling these via AI. Freebies 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 freebie’s “Report” button.
• RTL / Hebrew interface. We support Hebrew content (freebie titles and descriptions), but the surrounding chrome ships in English with LTR layout. A full RTL pass is on the roadmap.
• Browser push alerts. Push delivery depends on the browser’s native alert UI, which we don’t control.
• Native assistive-technology coverage. Testing with VoiceOver, TalkBack, large accessibility text, and varied device sizes is ongoing. Native build and simulator checks alone do not establish that every journey works with every assistive technology.
• Desktop input coverage. Hardware-keyboard, pointer, and screen-reader testing across Mac, Android desktop, and iPad is ongoing. A successful build or an emulator layout check does not establish that every shortcut, focus order, context menu, or window configuration has been verified on physical hardware.

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.