Accessibility Conformance Report
Operax console and public site. International Edition, based on VPAT® Version 2.5Rev: WCAG 2.2 Level A and AA, Revised Section 508 and EN 301 549.
- Name of Product/Version
- Operax console and public site, release
d2fbc01e5d4e(every release from the report date). - Report Date
- Contact Information
- Open a support case from “Get help” in the console, or see Contact.
Of the 56 WCAG 2.2 Level A and AA criteria reported below, 10 are Supports, 41 Partially Supports, 0 Does Not Support and 5 Not Applicable.
Product description
Operax is an AI advertising agency delivered as a web application. Owners, managers and agencies use the console to connect ad accounts, read findings and reports, follow leads and calls, and approve or reject every change that starts or raises spend. The public site describes the product, its plans and its security.
Notes. This report covers the screens listed under Scope. Content that customers bring themselves (their ads, images, videos, landing pages and call recordings) is shown as they provided it and is not part of this evaluation, except where the product creates or edits it (see Section 508 504 and EN 301 549 11.8).
Evaluation methods used
- Automated testing with axe-core 4.14.0 in Chromium (Playwright), applying every WCAG 2.0, 2.1 and 2.2 Level A and AA rule (wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa). A violation whose impact is serious or critical fails the run.
- The 20 console screens below were tested in both themes (dark and light) at 1440 px and 375 px wide; the 9 public pages at both widths.
- Browser checks beyond axe-core: no screen scrolls sideways at 320 CSS pixels; every screen has a title of its own; a change is approved with the keyboard alone, focus is visible on every control on the way, and the result is announced to assistive technology; on a phone the Approve and Reject controls are at least 44 pixels tall.
- The run tests itself: on a page given an image without a text alternative, an unnamed button and unreadable text, it must report all three.
- These tests run on every release before it ships (the console-a11y job of the CI that every deployment passes).
- No evaluation with screen readers or other assistive technology, and no review by an independent accessibility evaluator, has been done yet. Where the automated tests decide only part of a criterion, this report says Partially Supports and names the part not yet evaluated.
Evaluations by a person: none yet. No screen-reader evaluation and no review by an independent accessibility evaluator has been done.
Scope of evaluation
Console screens
- Sign in (
/login): Sign in to the console. - Create an account (
/register): Create an account and accept the terms. - Onboarding (
/app/onboarding): Set up a business and connect its ad accounts. - Home (Simple view) (
/app/home): See what Operax did and what is waiting for you. - Command center (Expert view) (
/app/dashboard): Read the money, the pipeline and the approvals waiting. - Approvals (
/app/approvals): Approve or reject proposed changes, including changes to spend. - Decision detail (
/app/decisions/:id): Read the evidence behind a decision and approve or reject each of its actions. - Plan (
/app/plan): See the plan, its experiments and what is waiting to launch. - Launch plan (
/app/plan/launch/:id): Review a launch plan and approve the spend it starts. - Activity (
/app/activity): Read everything Operax did, and undo a change. - Customers (
/app/customers): Follow enquiries through the pipeline to booked jobs. - Leads (
/app/leads): Find and filter leads. - Lead detail (
/app/leads/:id): Read a lead's source, calls and messages. - Calls (
/app/calls): Read tracked calls and their reviews. - Campaigns (
/app/ads/campaigns): Read every campaign and its results. - Findings (
/app/findings): Read what the audit found and the evidence for it. - Reports (
/app/reports): Read and share the weekly reports. - Autonomy and guardrails (
/app/autonomy): Choose what Operax may do without asking, and its spending limits. - Billing (
/app/billing): Read the plan, the invoices and the credit balance. - Connections (
/app/connections): Connect and reconnect ad, analytics and call accounts.
Public pages
- Home page (
/): Learn what Operax does. - Pricing (
/pricing): Compare the plans. - How it works (
/how-it-works): Read how findings, approvals and measurement work. - Security and trust centre (
/security): Read the access Operax asks for and the controls it proves. - Free audit (
/free-audit): Start a free account audit. - Contact (
/contact): Find how to reach Operax. - Terms of Service (
/terms): Read the terms. - Privacy Policy (
/privacy): Read the privacy policy. - Accessibility (
/accessibility): Read this report.
Applicable standards and guidelines
| Standard/Guideline | Included In Report |
|---|---|
| Web Content Accessibility Guidelines 2.0 | Level A (Yes), Level AA (Yes), Level AAA (No) |
| Web Content Accessibility Guidelines 2.1 | Level A (Yes), Level AA (Yes), Level AAA (No) |
| Web Content Accessibility Guidelines 2.2 | Level A (Yes), Level AA (Yes), Level AAA (No) |
| Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018 | Yes |
| EN 301 549 Accessibility requirements for ICT products and services, V3.1.1 (2019-11) and V3.2.1 (2021-03) | Yes |
Terms
- Supports
- The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
- Partially Supports
- Some functionality of the product does not meet the criterion.
- Does Not Support
- The majority of product functionality does not meet the criterion.
- Not Applicable
- The criterion is not relevant to the product.
- Not Evaluated
- The product has not been evaluated against the criterion. This can be used only in WCAG Level AAA criteria.
WCAG 2.2 report
Tables 1 and 2 also document conformance with EN 301 549 Clause 9 (Web) and Revised Section 508 501.1, 504.2 and 602.3.
Table 1: Success Criteria, Level A
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content (Level A) | Partially Supports | Automated: every image, icon given a role, image input, meter and progress bar on the audited screens has a text alternative, and decorative icons are hidden from assistive technology. Not yet evaluated by a person: whether each alternative says what the image means, and whether every chart has an equivalent text summary or table. |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) | Partially Supports | The only prerecorded audio the console plays is a business’s own call recordings. A recording is shown with its transcript when the call was transcribed (to a person whose role may read it); a call that was not transcribed (transcription turned off, or not yet done) has no text alternative. The console has no video-only content of its own. |
| 1.2.2 Captions (Prerecorded) (Level A) | Not Applicable | The product has no prerecorded video with audio of its own. Videos in the media library and ad previews are the customer’s own ad media, shown as uploaded. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) | Not Applicable | The product has no prerecorded video of its own (see 1.2.2). |
| 1.3.1 Info and Relationships (Level A) | Partially Supports | Automated: lists, definition lists and tables are marked up correctly, header cells label their data, and ARIA roles sit inside the parents they require (tab lists, lists, grids) on every audited screen. Not yet evaluated by a person: whether every visual grouping and heading is also conveyed in the markup. |
| 1.3.2 Meaningful Sequence (Level A) | Partially Supports | Automated: the keyboard test moves through the Approvals screen in reading order, from the navigation to the first card’s Approve. Not yet evaluated by a person: the reading order of the other screens. |
| 1.3.3 Sensory Characteristics (Level A) | Partially Supports | Status badges always carry text and an icon beside their colour (src/components/Badge.tsx). Not yet evaluated by a person: whether any instruction relies on shape, position or sound. |
| 1.4.1 Use of Color (Level A) | Partially Supports | Automated: links inside text are underlined, so they are told apart by more than colour, and status badges carry text and an icon. Not yet evaluated by a person: charts, whose series are told apart by colour and legend. |
| 1.4.2 Audio Control (Level A) | Supports | No audio plays on its own: call recordings play only when a person presses play, with the player’s own pause and volume controls. |
| 2.1.1 Keyboard (Level A) | Partially Supports | Automated: scrolling regions take focus; a change is approved from the Approvals screen with the keyboard alone (Tab to Approve, Enter, Skip note); every drag on a board has a menu that does the same move by keyboard. Not yet evaluated by a person: every other operation on every audited screen. |
| 2.1.2 No Keyboard Trap (Level A) | Partially Supports | The phone navigation drawer keeps focus inside while open and closes with Escape, returning focus (e2e/responsive.spec.ts); the keyboard test Tabs through the Approvals screen without being held. Not yet evaluated by a person: every dialog and widget on every audited screen. |
| 2.1.4 Character Key Shortcuts (Level A) (WCAG 2.1) | Partially Supports | Known exception: on the Approvals screen the a and r keys open the approve or reject step of the highlighted card even when keyboard focus is not on it, and there is no setting to turn them off. They never approve by themselves (the step asks again). The Simple/Expert switch uses g then e. Both are ignored while typing in a field. |
| 2.2.1 Timing Adjustable (Level A) | Partially Supports | Known exception: notices (toasts) close after 5 seconds (8 for an error) with no way to keep them open; an Undo offered in one is also available afterwards on the Activity screen. No page refreshes itself (axe meta-refresh). |
| 2.2.2 Pause, Stop, Hide (Level A) | Partially Supports | Automated: no blinking or scrolling marquee text; animations stop when the system asks for reduced motion. Not yet evaluated by a person: screens that update live (activity, notifications) and whether each update can be paused. |
| 2.3.1 Three Flashes or Below Threshold (Level A) | Supports | The product’s own motion is a rotating spinner, a single 800 ms highlight and a loading shimmer; nothing flashes, and all of it stops under reduced motion. |
| 2.4.1 Bypass Blocks (Level A) | Partially Supports | Every console screen has a main landmark, and the public site has a "Skip to content" link (axe bypass). The console has no skip link of its own yet, so a keyboard user passes the navigation by landmarks or with Tab. Not yet evaluated by a person: whether the landmarks and headings let a screen-reader user pass the navigation on every screen. |
| 2.4.2 Page Titled (Level A) | Partially Supports | Automated: every console screen is titled with its own heading and the product’s name, every public page has its own title, and no two audited screens share one. Not yet evaluated by a person: whether each title describes its screen’s topic or purpose. |
| 2.4.3 Focus Order (Level A) | Partially Supports | Automated: on the Approvals screen focus moves from the top of the page through the navigation to the first card’s Approve, and the note step takes focus when it opens. Not yet evaluated by a person: the focus order of the other screens and dialogs. |
| 2.4.4 Link Purpose (In Context) (Level A) | Partially Supports | Automated: every link on the audited screens has an accessible name. Not yet evaluated by a person: whether each name, with its context, says where the link goes. |
| 2.5.1 Pointer Gestures (Level A) (WCAG 2.1) | Partially Supports | Moves on the pipeline and boards, the only path-based gestures, can also be done with a single press through the "Move to…" menu. Not yet evaluated by a person: charts and the media library. |
| 2.5.2 Pointer Cancellation (Level A) (WCAG 2.1) | Partially Supports | Controls are native buttons and links, which act on release. Not yet evaluated by a person: custom drag and press handlers. |
| 2.5.3 Label in Name (Level A) (WCAG 2.1) | Partially Supports | Automated: every control on the audited screens whose accessible name differs from its text contains its visible text, so a person who says what they see reaches it. Not yet evaluated by a person: controls whose label is an image of text. |
| 2.5.4 Motion Actuation (Level A) (WCAG 2.1) | Not Applicable | No function is operated by moving or shaking the device. |
| 3.1.1 Language of Page (Level A) | Supports | Every page declares English, the language its interface is written in, with a valid language code. |
| 3.2.1 On Focus (Level A) | Partially Supports | Automated: moving focus through the Approvals screen to Approve changes neither the page nor the selection. Not yet evaluated by a person: the other screens. |
| 3.2.2 On Input (Level A) | Partially Supports | Changes that start or raise spend are applied only after an explicit Approve and its confirmation, never on input. Not yet evaluated by a person: filters and selects that update a list as they change. |
| 3.2.6 Consistent Help (Level A) (WCAG 2.2) | Supports | The "Get help" button is part of the console’s top bar, drawn by the shell in the same place on every screen of a customer account; the public site links Contact from the same footer on every page. |
| 3.3.1 Error Identification (Level A) | Partially Supports | Form errors come from the server’s answer and are shown in text under the field they concern; refusals are shown in the server’s own words. Not yet evaluated by a person: that every error is announced and tied to its field. |
| 3.3.2 Labels or Instructions (Level A) | Partially Supports | Automated: no form field on the audited screens has two labels, and every field has a name (see 4.1.2). Not yet evaluated by a person: whether every instruction a field needs is given. |
| 3.3.7 Redundant Entry (Level A) (WCAG 2.2) | Partially Supports | Not yet evaluated by a person: whether any multi-step process (onboarding, a launch plan, an import) asks again for information already given in it. |
| 4.1.1 Parsing (Level A) | Supports | For WCAG 2.0 and 2.1, the September 2023 errata state that this criterion is always supported for HTML. It was removed from WCAG 2.2, where it does not apply. |
| 4.1.2 Name, Role, Value (Level A) | Partially Supports | Automated: every button, link, field, select, tab, toggle and ARIA widget on the audited screens has a name and a valid role, state and attributes, no hidden element takes focus, and no control is nested in another. Not yet evaluated by a person: whether states that change (expanded, selected, busy) are announced as they change. |
Table 2: Success Criteria, Level AA
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) (Level AA) | Not Applicable | The product has no live audio or video. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) | Not Applicable | The product has no prerecorded video of its own (see 1.2.2). |
| 1.3.4 Orientation (Level AA) (WCAG 2.1) | Supports | Neither the stylesheets nor the web app manifest lock the display to portrait or landscape; every audited screen is laid out at a phone’s portrait width and at a desktop’s. |
| 1.3.5 Identify Input Purpose (Level AA) (WCAG 2.1) | Partially Supports | Automated: every autocomplete value on the audited screens is valid; the sign-in, sign-up, invitation and password forms name the purpose of each personal field (email, given and family name, organisation, password, one-time code). Not yet evaluated by a person: personal fields on the other screens. |
| 1.4.3 Contrast (Minimum) (Level AA) | Partially Supports | Automated: all text on the audited screens reads at 4.5:1 (large text 3:1) or more in both themes at both widths; the design tokens are chosen so every text colour reads at 4.5:1 on every surface. Not yet evaluated by a person: text drawn over images or gradients, which axe-core cannot measure. |
| 1.4.4 Resize Text (Level AA) | Partially Supports | Automated: no page stops the browser from zooming (axe meta-viewport), and nothing scrolls sideways at 320 CSS pixels, the width of a 1280-pixel window at 400% zoom. Not yet evaluated by a person: whether text at 200% is ever clipped or overlaps. |
| 1.4.5 Images of Text (Level AA) | Partially Supports | The interface draws all of its text as text, including the logo’s wordmark. Not yet evaluated by a person: images on the public site. |
| 1.4.10 Reflow (Level AA) (WCAG 2.1) | Partially Supports | Automated: no audited screen, and no main content area, scrolls sideways at 320 CSS pixels; wide tables become card lists on a phone. Not yet evaluated by a person: whether any content or function is lost at that width. |
| 1.4.11 Non-text Contrast (Level AA) (WCAG 2.1) | Partially Supports | The focus ring is the solid accent colour, which reads at 3:1 or more on every surface in both themes, and badge colours read at 4.5:1. Not yet evaluated: the borders of inputs and the lines of charts in the light theme. |
| 1.4.12 Text Spacing (Level AA) (WCAG 2.1) | Partially Supports | Automated: no text on the audited screens sets an inline letter, word or line spacing a reader’s own style cannot override. Not yet evaluated by a person: whether content is clipped when a reader increases the spacing. |
| 1.4.13 Content on Hover or Focus (Level AA) (WCAG 2.1) | Partially Supports | Not yet evaluated by a person: whether every popover shown on hover or focus can be dismissed without moving the pointer or focus, can itself be hovered, and stays until dismissed. |
| 2.4.5 Multiple Ways (Level AA) | Partially Supports | Every console screen can be reached from the navigation and from the command palette (Search or run a command, ⌘K). The public site’s pages are reached from its header and footer links only; it has no search or site map page. |
| 2.4.6 Headings and Labels (Level AA) | Partially Supports | Every field on the audited screens has a name (see 4.1.2). Not yet evaluated by a person: whether each heading and label describes its topic or purpose. |
| 2.4.7 Focus Visible (Level AA) | Partially Supports | Automated: every focusable element is given a visible outline by the base stylesheet, and the keyboard test finds it on every control from the top of the Approvals screen to the first Approve. Not yet evaluated by a person: controls on the other screens that replace the outline with their own style. |
| 2.4.11 Focus Not Obscured (Minimum) (Level AA) (WCAG 2.2) | Partially Supports | Not yet evaluated by a person: the phone layout’s fixed tab bar and the sticky approve bar could cover a focused control near the bottom of a screen. |
| 2.5.7 Dragging Movements (Level AA) (WCAG 2.2) | Supports | Every drag in the product (cards on the pipeline and on boards) has a "Move to…" menu that makes the same move with single presses. |
| 2.5.8 Target Size (Minimum) (Level AA) (WCAG 2.2) | Supports | Every target on the audited screens is at least 24 by 24 CSS pixels or spaced so a 24-pixel circle around it touches no other target, at both widths; on a phone the Approve and Reject controls are 44 pixels tall. |
| 3.1.2 Language of Parts (Level AA) | Partially Supports | Automated: every language attribute on the audited screens is valid. Not yet evaluated by a person: customer text in another language (a review, a lead’s message) is shown without marking its language. |
| 3.2.3 Consistent Navigation (Level AA) | Supports | The console’s top bar, sidebar and phone tab bar are drawn by one shell around every screen, in the same order; the public site’s header and footer are the same on every page. |
| 3.2.4 Consistent Identification (Level AA) | Partially Supports | Shared controls (buttons, badges, the move menu, approve and reject) come from one component library, so they are named the same way everywhere. Not yet evaluated by a person: screen-specific controls. |
| 3.3.3 Error Suggestion (Level AA) | Partially Supports | Field errors carry the server’s sentence, which says what is wrong and what it accepts. Not yet evaluated by a person: every form. |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) | Supports | Every change that starts or raises spend waits for a person’s approval, which can be refused, and an applied change can be undone from the Activity screen; a launch plan is approved by typing its confirmation sentence. |
| 3.3.8 Accessible Authentication (Minimum) (Level AA) (WCAG 2.2) | Partially Supports | Sign-in asks for an email and a password in fields password managers fill (autocomplete email and current password) and allows pasting; a one-time code field accepts a pasted code; there is no puzzle or CAPTCHA. A sign-in provider’s own pages (Google, Microsoft) are theirs and are not evaluated here. |
| 4.1.3 Status Messages (Level AA) (WCAG 2.1) | Partially Supports | Automated: the result of an approval is announced through a live region without moving focus; notices are a polite live region. Not yet evaluated by a person: status messages on the other screens. |
Table 3: Success Criteria, Level AAA
Not evaluated: this report does not cover WCAG Level AAA.
Revised Section 508 report
Chapter 3: Functional Performance Criteria (FPC)
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 302.1 Without Vision | Partially Supports | See the WCAG 2.2 section: 1.1.1, 1.3.1, 2.4.3, 4.1.2. No screen-reader evaluation has been done yet. |
| 302.2 With Limited Vision | Partially Supports | See the WCAG 2.2 section: 1.4.3, 1.4.4, 1.4.10, 1.4.11. |
| 302.3 Without Perception of Color | Partially Supports | See the WCAG 2.2 section: 1.4.1 (charts are told apart by colour and legend). |
| 302.4 Without Hearing | Partially Supports | See the WCAG 2.2 section: 1.2.1 (a call recording that was not transcribed has no text alternative). |
| 302.5 With Limited Hearing | Partially Supports | See the WCAG 2.2 section: 1.2.1. |
| 302.6 Without Speech | Supports | No function needs speech. |
| 302.7 With Limited Manipulation | Partially Supports | See the WCAG 2.2 section: 2.1.1, 2.5.7, 2.5.8. |
| 302.8 With Limited Reach and Strength | Partially Supports | See the WCAG 2.2 section: 2.1.1, 2.2.1. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Partially Supports | See the WCAG 2.2 section: 2.2.1, 3.3.1, 3.3.3, 3.3.7, 3.3.8. |
Chapter 4: Hardware
Not Applicable: Operax is a web application and includes no hardware.
Chapter 5: Software
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 501.1 Scope - Incorporation of WCAG 2.0 AA | Partially Supports | See the WCAG 2.2 section. |
| 502 Interoperability with Assistive Technology | Not Applicable | Operax is web content, not a platform or software that runs outside a browser; see WCAG 4.1.2. |
| 503.2 User Preferences | Partially Supports | The console follows the system’s light or dark setting and its reduced-motion setting, and the browser’s zoom; most text sizes are set in pixels, so a browser’s minimum font size setting is followed only where text is sized in rem. |
| 503.3 Alternative User Interfaces | Not Applicable | The product provides no alternative user interface that works as assistive technology. |
| 503.4 User Controls for Captions and Audio Description | Not Applicable | The product has no video of its own (see WCAG 1.2.2). |
| 504.2 Content Creation or Editing | Partially Supports | The console’s editors are built from the same components as the audited screens (see the WCAG 2.2 section); a landing page Operax creates is checked before it publishes (below). |
| 504.2.1 Preservation of Information Provided for Accessibility in Format Conversion | Not Applicable | The product does not convert content between formats. |
| 504.2.2 PDF Export | Not Applicable | The product does not export PDF documents. |
| 504.3 Prompts | Partially Supports | A landing page whose brand colour would make its button text read under 4.5:1 is held back from publishing, with the reason (the publish gate’s page audit). The product does not yet prompt for text alternatives on customer images. |
| 504.4 Templates | Partially Supports | Every landing page built from a template passes the same check before it publishes. Not yet evaluated by a person: the templates against the other WCAG criteria. |
Chapter 6: Support Documentation and Services
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 602.2 Accessibility and Compatibility Features | Supports | This report lists the product’s accessibility features and its known exceptions. |
| 602.3 Electronic Support Documentation | Partially Supports | The help centre is part of the console and is built from the same components; it is not one of the audited screens. |
| 602.4 Alternate Formats for Non-Electronic Support Documentation | Not Applicable | All support documentation is electronic. |
| 603.2 Information on Accessibility and Compatibility Features | Supports | Support answers questions about accessibility, and this report is public. |
| 603.3 Accommodation of Communication Needs | Supports | Support is given in writing, through a support case in the console or by email, so it needs neither hearing nor speech. |
EN 301 549 report
Clause 4: Functional Performance Statements (FPS)
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 4.2.1 Usage without vision | Partially Supports | See Section 508 302.1. |
| 4.2.2 Usage with limited vision | Partially Supports | See Section 508 302.2. |
| 4.2.3 Usage without perception of colour | Partially Supports | See Section 508 302.3. |
| 4.2.4 Usage without hearing | Partially Supports | See Section 508 302.4. |
| 4.2.5 Usage with limited hearing | Partially Supports | See Section 508 302.5. |
| 4.2.6 Usage with no or limited vocal capability | Supports | No function needs speech. |
| 4.2.7 Usage with limited manipulation or strength | Partially Supports | See Section 508 302.7. |
| 4.2.8 Usage with limited reach | Partially Supports | See Section 508 302.8. |
| 4.2.9 Minimize photosensitive seizure triggers | Supports | See WCAG 2.3.1. |
| 4.2.10 Usage with limited cognition, language or learning | Partially Supports | See Section 508 302.9. |
| 4.2.11 Privacy | Supports | The product’s accessibility features need no extra personal data, and password fields are masked for everyone. |
Clause 5: Generic Requirements
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 5.1 Closed functionality | Not Applicable | The product runs in the person’s own browser and works with their assistive technology. |
| 5.2 Activation of accessibility features | Not Applicable | The product has no accessibility features to activate; the browser’s and the system’s are followed. |
| 5.3 Biometrics | Not Applicable | No function needs a biometric. |
| 5.4 Preservation of accessibility information during conversion | Not Applicable | The product does not convert content between formats. |
| 5.5 Operable parts | Not Applicable | The product has no hardware. |
| 5.6 Locking or toggle controls | Not Applicable | The product has no hardware. |
| 5.7 Key repeat | Not Applicable | Key repeat is the browser’s and the system’s. |
| 5.8 Double-strike key acceptance | Not Applicable | Keyboard input is the browser’s and the system’s. |
| 5.9 Simultaneous user actions | Supports | No function needs more than one action at the same time. |
Clause 6: ICT with Two-Way Voice Communication
Not Applicable: the console offers no voice communication. (The AI receptionist answers a business’s callers on the telephone network, outside the product evaluated here.)
Clause 7: ICT with Video Capabilities
Not Applicable: the product has no video of its own (see WCAG 1.2.2).
Clause 8: Hardware
Not Applicable: Operax is a web application and includes no hardware.
Clause 9: Web
See the WCAG 2.2 section.
Clause 10: Non-Web Documents
Not Applicable: the product’s documents are web pages. Exports are data files (CSV) for other software to read.
Clause 11: Software
Operax is web content, so the WCAG 2.2 section applies in place of 11.1 to 11.4 (11.8.2 to 11.8.5 as in Section 508 504). The platform clauses (11.5 interoperability with assistive technology, 11.6 documented accessibility usage, 11.7 user preferences) are answered as Section 508 502 and 503.
Clause 12: Documentation and Support Services
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 12.1.1 Accessibility and compatibility features | Supports | See Section 508 602.2. |
| 12.1.2 Accessible documentation | Partially Supports | See Section 508 602.3. |
| 12.2.2 Information on accessibility and compatibility features | Supports | See Section 508 603.2. |
| 12.2.3 Effective communication | Supports | See Section 508 603.3. |
| 12.2.4 Accessible documentation | Partially Supports | See Section 508 602.3. |
Clause 13: ICT Providing Relay or Emergency Service Access
Not Applicable: the product provides no relay or emergency service access.
Legal disclaimer
This report describes the product as evaluated on the report date, by the methods listed. It is not a certification. Accessibility is part of how the product is built and tested on every release; a defect found after the report date is fixed or added to this report.
“Voluntary Product Accessibility Template” and “VPAT” are registered service marks of the Information Technology Industry Council (ITI).