القائمة
Use when auditing digital products or services for European Accessibility Act (EAA) compliance, checking EN 301 549 conformance, or advising on EU Web Accessibility Directive obligations.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Run a model through the omni-bench benchmark to MEASURE it — produce a run-artifact and score it, then read the numbers. Use when asked to run, benchmark, measure, evaluate, or "test the results of" a model with omni-bench — ASR (WER/CER, RTFx) or text generation (tok/s, TTFT, prefill tok/s, prompt-cache speedup). Covers the adapter seam (Transcriber/Generator), the prepare→run→score→diff CLI flow, the offline no-download smoke task, and how to interpret each metric. NOT for publishing to a leaderboard (use omni-bench-publish) or changing the framework itself (use omni-bench).
Publish a scored omni-bench result (ASR or text-generation) to a leaderboard platform (e.g. bench.bshk.app) via its write API. Use when asked to publish, upload, submit, or "send a report" for an omni-bench result.json or parity-report.json — sharing ASR WER/RTFx numbers or text-generation TTFT/tok-per-s/prompt-cache numbers. Covers the one modality-agnostic `omni-bench publish` command and the MANDATORY secret handling: the api-key is injected from a secrets manager (1Password `op run` / AgentVault `av run`) at runtime, never read into context, never hardcoded.
Develop the omni-bench benchmark framework (ASR/STT + text generation) built on a producer/scorer split with an open JSON spec as SSOT. Use when working in an omni-bench checkout — changing the JSON schemas, the prepare/producer/scorer/diff pipeline, the adapter seams (Transcriber / Generator), datasets, fixtures, or the Swift producer SDK; or when running and validating benchmark artifacts. Encodes the schema-evolution rules, determinism invariants, commands, and repo gotchas that are easy to get wrong.
Use when generating/managing the offline root signing key or signing & publishing Zamok product keysets from the terminal (the Swift CLI; the ZamokApp GUI is the co-equal interface). Triggers — "generate root key", "rotate root", "publish keyset", "sign keyset", "escrow root key", "zamokctl", "trusted-roots.json", Tish/Zamok license signature setup.
Use when auditing websites or apps for Canadian accessibility law compliance, checking AODA (Ontario) or Accessible Canada Act (federal) requirements, or advising on CAN/ASC-EN 301 549 obligations.
Use when determining which accessibility law applies to an organization, comparing requirements across jurisdictions (US, EU, Canada, Japan), or planning multi-country accessibility compliance strategy.
| name | eaa-compliance |
| description | Use when auditing digital products or services for European Accessibility Act (EAA) compliance, checking EN 301 549 conformance, or advising on EU Web Accessibility Directive obligations. |
Guides compliance with the European Accessibility Act (EU Directive 2019/882) and the underlying technical standard EN 301 549. Covers scope, deadlines, exemptions, and enforcement across EU member states.
When conducting an EAA/EN 301 549 compliance review:
Determine which law applies:
Identify if the product/service is in scope (see Products and Services section)
Evaluate against EN 301 549 v3.2.1, which incorporates WCAG 2.1 AA for web content (Clause 9) and extends to:
Check exemptions — microenterprises, disproportionate burden, fundamental alteration
Provide remediation guidance with reference to specific EN 301 549 clauses
Recommend accessibility statement — required under both WAD and EAA
| Clause | Scope | Key Requirements |
|---|---|---|
| 5 | Generic requirements | Closed functionality, biometrics, preservation of accessibility |
| 6 | ICT with two-way voice communication | Real-time text (RTT), caller ID, video communication |
| 7 | ICT with video capabilities | Captions, audio description, player controls |
| 8 | Hardware | Physical dimensions, connections, keypads, biometrics |
| 9 | Web content | WCAG 2.1 Level AA (all success criteria) |
| 10 | Non-web documents | WCAG 2.1 AA applied to documents (PDFs, Word, spreadsheets) |
| 11 | Non-web software | WCAG 2.1 AA adapted for native apps and desktop software |
| 12 | Documentation and support | Accessible docs, help desk, support services |
| 13 | ICT providing relay or emergency services | Relay services, 112 emergency access |
| Law | Sector | Scope |
|---|---|---|
| Web Accessibility Directive (2016/2102) | Public sector | All EU public sector websites and mobile apps |
| European Accessibility Act (2019/882) | Private + public | Manufacturers, service providers, importers, distributors offering in-scope products/services in EU |
Territorial reach: Any organization offering in-scope services to EU consumers, regardless of where the organization is headquartered.
| Obligation | Date |
|---|---|
| WAD — Public sector websites | 23 September 2020 |
| WAD — Public sector mobile apps | 23 June 2021 |
| EAA — All in-scope products and services | 28 June 2025 |
| EAA — Products placed on market before June 2025 | Grace period until 28 June 2030 |
| EN 301 549 v4.1.1 (planned, includes WCAG 2.2) | Expected 2026 |
Enforcement is per member state. Examples:
| Country | Penalty |
|---|---|
| General range | Up to €500,000 in fines |
| Some states | Product removal from market |
| At least one state | Criminal penalties possible |
Penalties must be "effective, proportionate, and dissuasive."
Products/services conforming to harmonised European standards (notably EN 301 549) benefit from a "presumption of conformity" — they are presumed to meet EAA requirements without further proof.
Both WAD and EAA require publishing an accessibility statement that includes:
Input: "Our online store sells to EU customers, what do we need?"
Response approach:
Input: "We're a US company with EU customers, does EAA apply?"
Response approach:
