Accessibility Statement
Last updated: 2 September 2026 · Date of last accessibility review: [to be completed]
[Full registered company name] ("WebPower"), company number [ח.פ.], operates the WeHub service and regards accessibility as an essential part of providing an equal service. We work to make the Service accessible in accordance with the Israeli Equal Rights for Persons with Disabilities Law, 5758-1998, the Equal Rights for Persons with Disabilities Regulations (Service Accessibility Adjustments), 5773-2013, and Israeli Standard IS 5568, which is based on WCAG 2.0 Level AA.
Stated goal: beyond the standard's requirement, we aim to meet WCAG 2.1 Level AA, including the criteria for small screens, text spacing and adequate target size.
1. Scope of this statement
- The product site `wehub.co.il`
- The agent and administrator web app at `app.wehub.co.il`
- The iOS and Android mobile apps
- The public legal and information pages (terms, privacy, data deletion)
The internal WeHub staff console at `console.wehub.co.il` is not a public service, but we apply the same principles to it.
2. What has been made accessible
2.1 Keyboard navigation
- All core actions (conversation list, thread, composing a message, sending, assigning, closing, search, switching businesses) are operable by keyboard alone.
- Logical focus order, a visible focus indicator on every interactive element, and no focus traps.
- A "skip to main content" link at the start of each page.
- Keyboard shortcuts do not override assistive-technology shortcuts and can be disabled in settings.
2.2 Screen readers
- Semantic structure: hierarchical headings, landmarks, lists and tables with headers.
- Every form field has an associated label, and error messages are linked to the field and announced.
- Icon-only buttons have accessible names.
- Incoming messages and status changes are announced through live regions, calibrated so as not to overwhelm.
- Tested with VoiceOver on macOS and iOS, NVDA on Windows and TalkBack on Android [to be completed: test detail and date].
2.3 Contrast and colour
- Contrast ratio of at least 4.5:1 for body text and 3:1 for large text and interface components.
- Information is never conveyed by colour alone: statuses carry both an icon and a text label.
- Dark and light modes, both checked for contrast; the system honours the operating system preference.
2.4 Text and sizing
- Zoom up to 200% without loss of content or functionality.
- A flexible layout that permits single-axis scrolling on a narrow viewport.
- No text embedded in images as a substitute for real text.
2.5 Language and direction
- Hebrew (RTL) by default and English (LTR), with a logical layout that mirrors correctly in both directions, including directional icons and progress bars.
- Correct `lang` and `dir` values on every page.
2.6 Motion and media
- The operating-system "reduce motion" preference is honoured: animations are shortened or removed.
- No content flashes more than three times per second.
- Videos and voice messages do not auto-play.
2.7 The mobile app
- Support for Dynamic Type and system font sizing, touch targets of at least 44 points, and the built-in screen readers.
3. What is not yet fully accessible
We disclose this in full, together with a workaround for each item:
| Component | Limitation | Workaround | |---|---|---| | Flow builder (automation flows) | A graphical canvas of nodes and edges; dragging and the visual rendering are not fully accessible to screen readers | A textual list view of the flow steps is available, and our support team can configure a flow on request [to be completed: full textual editing mode] | | Recording player and waveform | The waveform is visual only; precise scrubbing is difficult for keyboard users | Play, pause and skip are keyboard accessible; a text transcript of the call is available where transcription is enabled | | Charts and diagrams in reports | Visual representation of trends | Every report has an equivalent data table and CSV export | | Integration card content | Content is fetched from the customer's external system and is outside our control | Fields are rendered as text; making the source data accessible is the customer's responsibility | | Invoice PDFs | Generated by an external provider (iCount) and not necessarily tagged for accessibility | Invoice details are also presented as an accessible table in the billing screen | | User-uploaded files | Images and documents sent by End Customers or agents do not necessarily carry alternative text | A description can be added in the conversation notes; we display file name and type |
We are working to close these gaps. The items are tracked in our backlog with a target date of [to be completed].
4. Additional accessibility arrangements
- Support by email and phone, including assistance with performing actions for people who find the interface difficult.
- Documents and reports supplied in an accessible format on request.
- Tailored training for teams that include employees with disabilities.
5. Feedback and accessibility requests
We welcome reports of accessibility problems, requests for adjustments and suggestions. We aim to respond within [10] business days.
- Accessibility coordinator: [accessibility coordinator name]
- Phone: [accessibility coordinator phone]
- Email: [[email protected]]
- Address: [address]
- Hours: [to be completed]
6. Statement details
- Statement published: 2 September 2026
- Last review: [to be completed]
- Reviewed by: [to be completed: certified service-accessibility consultant / internal review]
- Review method: [to be completed: manual testing, automated tools, testing with users]
- Planned review frequency: every [12] months and on any material interface change.
---
> Note: draft pending review by a licensed Israeli attorney (לתשומת-לב: טיוטה לבדיקת עורך-דין). An opinion from a certified service-accessibility consultant is also required before publication, along with the coordinator's details and the review date.