انطباق دسترس‌پذیری؛ Applicability تا Claim

پاسخ کوتاه: برای گفتن «محصول ما از نظر دسترس‌پذیری منطبق است» سه چیز مستقل لازم است: نخست، Applicability یا اینکه کدام قانون، قرارداد یا سیاست واقعاً بر کدام سازمان، محصول، بازار و تاریخ اعمال می‌شود؛ دوم، Technical Basis یا نسخه و بندهای مرجع فنی؛ و سوم، Conformance Claim محدود به Scope و Evidence ارزیابی‌شده. WCAG، قانون، اخلاق، User Research و امتیاز ابزار مترادف نیستند و QA به‌تنهایی نظر حقوقی صادر نمی‌کند.

این راهنما یک Accessibility Applicability & Conformance Claim Record می‌سازد تا ادعای عمومی از شواهد بزرگ‌تر نشود. مثال‌ها ساختگی و آفلاین‌اند؛ متن، مشاورهٔ حقوقی یا تأیید انطباق هیچ محصول واقعی نیست.

مالکیت این مقاله: از الزام تا ادعای محدود

برای یادگیری معیارهای POUR، سطح‌ها و تست فنی، راهنمای WCAG ۲.۲ و تست دسترس‌پذیری را بخوانید. برای طراحی Inventory، Sample، CI، شواهد AT و Release Gate به برنامه تست دسترس‌پذیری بروید. برای انتخاب NVDA، JAWS، axe و پروتکل ابزار نیز راهنمای ابزارهای A11y مالک موضوع است.

مقالهٔ حاضر یک سؤال متفاوت دارد: وقتی مدیر، قرارداد، مناقصه، تیم حقوقی یا صفحهٔ بازاریابی می‌خواهد بگوید «مشمولیم»، «مطابقیم» یا «دسترس‌پذیریم»، دقیقاً کدام Subject، مرجع، Scope، تاریخ و Evidence پشت این جمله است؟

چهار لایه را در یک Checkbox ادغام نکنید

لایه	پرسش	تصمیم‌گیر
Applicability	کدام الزام برای چه شخص/محصول/بازار/تاریخی اعمال می‌شود؟	مالک کسب‌وکار با بازبین حقوقی واجد صلاحیت
Obligation	متن الزام چه Outcome، Deadline یا Exceptionی دارد؟	مالک الزام و بازبین تخصصی
Technical conformance	Scope ارزیابی‌شده با کدام نسخه و سطح مرجع منطبق است؟	ارزیاب صلاحیت‌دار بر پایه Evidence
Ethical/product commitment	فراتر از حداقل چه Barrierهایی را باید کم کنیم؟	افراد متاثر، Product و Decision authority

WCAG قانون جهانی نیست

WCAG 2.2 یک W3C Recommendation و مرجع فنی برای محتوای وب است. ممکن است قانون، مقرره، قرارداد یا سیاست داخلی آن را با نسخه/سطح خاصی Incorporate یا Reference کند؛ اما انتشار WCAG به‌تنهایی هر سازمانی را در هر کشور مشمول یک تعهد حقوقی واحد نمی‌کند. رابطهٔ Instrument با WCAG را مستند کنید، نه اینکه از شهرت AA نتیجهٔ قانونی بسازید.

WCAG ۲.۰، ۲.۱ و ۲.۲ هنوز هویت‌های جدا دارند

W3C توضیح می‌دهد که ۲.۲ نسخه‌های ۲.۰ و ۲.۱ را منسوخ نکرده است و محتوای منطبق با ۲.۲ با نسخه‌های پیشین نیز سازگار است، اما قانون یا قرارداد ممکن است دقیقاً نسخهٔ قدیمی‌تر را نام ببرد. Record باید Standard title، Version، dated URI، Level/Clauses، وضعیت مرجع و Relation to obligation را ثبت کند. «Latest WCAG» جای نقل دقیق قرارداد را نمی‌گیرد.

AA هدف جهانی پیش‌فرض نیست

بسیاری از سیاست‌ها AA را انتخاب کرده‌اند، اما «بسیاری» به معنی «همه» نیست. یک الزام ممکن است WCAG ۲.۰ AA، WCAG ۲.۱ AA، مجموعه بندهای مشخص، EN ۳۰۱ ۵۴۹، استاندارد ملی، Functional performance، قرارداد خرید یا معیار دیگری باشد. حتی اگر سیاست داخلی داوطلبانه WCAG ۲.۲ AA را هدف بگیرد، آن را به‌عنوان Policy commitment ثبت کنید، نه حکم قانون.

نمونهٔ آمریکا: ADA را به همهٔ وب تعمیم ندهید

قاعدهٔ وب Title II که وزارت دادگستری آمریکا منتشر کرده، WCAG ۲.۱ AA را برای Web content و Mobile app نهادهای State و Local government با تاریخ‌ها و استثناهای مشخص تعیین می‌کند؛ این گزاره برابر «ADA همهٔ وب‌سایت‌های جهان را به WCAG ۲.۱ AA ملزم کرده» نیست. صفحهٔ رسمی راهنمای انطباق ADA برای نهادهای کوچک را فقط برای Scope همان قاعده بخوانید و وضعیت جاری مهلت‌ها را در تاریخ تصمیم دوباره بررسی کنید.

Section ۵۰۸ نیز Scope فدرال و ICT دارد

راهنمای رسمی Applicability & Conformance بخش ۵۰۸ دربارهٔ ICT آژانس‌های فدرال آمریکا است و Revised Standards آن WCAG ۲.۰ A/AA را با Scopeهای Web، non-web content، software و mobile به کار می‌گیرد. وجود این نگاشت، هر فروشنده یا محصولی را خودکار مشمول نمی‌کند؛ نقش آژانس، Procurement، Deliverable، Exception و Clause قرارداد باید روشن باشد.

نمونهٔ اروپا: EAA فقط «همهٔ سایت‌ها» نیست

Directive (EU) 2019/882 برای دسته‌هایی از Products و Services الزام دسترس‌پذیری تعیین می‌کند و از ۲۸ ژوئن ۲۰۲۵ وارد مرحلهٔ کاربرد شد؛ اما Scope، Economic operator، انتقال به قوانین کشورهای عضو، تاریخ عرضه/خدمت، Microenterprise service exception، Fundamental alteration و Disproportionate burden نیازمند بررسی‌اند. E-commerce یا Banking ممکن است در Scope باشد، ولی صرف داشتن مشتری اروپایی برای نتیجه‌گیری نهایی کافی نیست.

EAA را مستقیماً با WCAG مساوی نکنید

Directive، الزامات عملکردی و اطلاعاتی خود را دارد و سازوکار Standards/technical specifications و اجرای ملی نیز مهم است. Record باید مشخص کند کدام قانون ملی، کدام Harmonised standard یا Technical specification، کدام Presumption of conformity و کدام محصول/خدمت بررسی شده است. عبارت کوتاه «WCAG AA زدیم، پس EAA compliant هستیم» زنجیرهٔ استدلال را حذف می‌کند.

ایران: متن قانون را دقیق و محدود بخوانید

قانون حمایت از حقوق معلولان مصوب ۱۳۹۶، در تعریف دسترس‌پذیری به اطلاعات، فناوری و منابع ارتباطی/رسانه‌ای نیز اشاره دارد. آیین‌نامهٔ اجرایی مادهٔ ۳ در مادهٔ ۷ از تدوین استانداردهای طراحی درگاه‌ها و وبگاه‌های الکترونیکی دستگاه‌های مشمول سخن می‌گوید. این متن برای ساخت Candidate obligation مهم است، ولی از آن نمی‌توان خودکار نتیجه گرفت هر وب‌سایت خصوصی ایرانی دقیقاً مشمول WCAG نسخه X سطح AA است.

برای تصمیم واقعی در ایران، دستگاه/شخص مشمول، متن معتبر و اصلاحات، آیین‌نامه، استاندارد مصوب جاری، نوع خدمت، Procurement/Contract، مرجع ناظر و تاریخ را از منابع معتبر بررسی و به بازبین حقوقی/تخصصی ارجاع دهید. QA می‌تواند رفتار و Evidence را بیازماید؛ تعیین شمول و ضمانت اجرا را از روی یک پاراگراف وبلاگ صادر نمی‌کند.

قرارداد و مناقصه ممکن است از قانون دقیق‌تر باشند

RFP، Statement of Work، سیاست مشتری، App store، Design system یا شرط Vendor می‌تواند نسخه، Level، Deliverable، Evaluation method و Acceptance را تعیین کند. این تعهد قراردادی را با «قانون کشور» یکی نکنید. Clause ID، طرف متعهد، محصول/نسخه، Deadline، Exception، Artifact تحویلی و Dispute route را در Obligation record نگه دارید.

Artifact اصلی: Applicability & Claim Record

RecordID / Version / Status / AsOf / Owner / ReviewAt
DecisionQuestion / Options / Authority / Due / NotDecided
OrganizationRole / Product / Version / Service / Channel / Release
Markets / Users / CustomerType / PublicPrivate / Procurement / Contract
Jurisdiction / Instrument / Version / OfficialSource / EffectiveDate
Applicability: Subject / Activity / Territory / Sector / Size / Date
Exceptions / LegalBasis / Evidence / Scope / Authority / Expiry
Obligation / SourceClause / RequiredOutcome / Deadline / Reviewer
TechnicalBasis / Version / URI / LevelOrClauses / AdoptionRelation
EvaluationScope / Support / Inventory / Method / Sample / Evidence
ConformanceClaim / LegalClaim / Statement / ReleaseDecision
Monitoring / ChangeTriggers / Correction / Supersession / Limits

این Schema استاندارد W3C یا قانون خاصی نیست؛ ترکیبی عملی برای جلوگیری از ادعاهای مبهم است. هر فیلد باید به Source و Owner واقعی سازمان متصل شود و Record کامل نیز صحت نتیجهٔ حقوقی یا فنی را تضمین نمی‌کند.

Decision question را پیش از جست‌وجوی قانون بنویسید

«آیا Accessibility لازم است؟» بیش از حد کلی است. نمونهٔ قابل تصمیم: «آیا شرکت X برای عرضهٔ نسخه Y از سرویس Z به مصرف‌کنندهٔ بازار M در تاریخ D، تحت Instrument I چه الزاماتی دارد و چه Claim عمومی می‌تواند منتشر کند؟» Options می‌تواند Claim محدود، Statement با Known limitation، Hold claim، Remediate یا ارجاع برای نظر تخصصی باشد.

Subject را با Brand یکی نگیرید

Legal entity، Entity role، Manufacturer/Importer/Service provider، Product ID/Version، Service، Channel، Release، Operating model و Contract party را ثبت کنید. وب‌سایت Marketing، Checkout، اپ موبایل، PDF قرارداد، دستگاه Self-service و Call center ممکن است Subject و Obligationهای متفاوتی داشته باشند.

Market و Territorial nexus را شاهددار کنید

کشور ثبت شرکت به‌تنهایی کافی نیست. محل عرضه، Targeting، Customer، قرارداد، Billing، Procurement، App store، شعبه، نماینده و محل ارائهٔ خدمت می‌تواند مهم باشد. QA نباید Geo-IP یا Language را به‌تنهایی نتیجهٔ Jurisdiction بداند؛ اینها Evidenceهای زمینه‌ای‌اند که Reviewer تفسیر می‌کند.

As-of date بخشی از نتیجه است

Instrument ممکن است تصویب شده ولی هنوز Applicable نباشد، مهلت آن تغییر کند، اجرای ملی متفاوت باشد یا Transition داشته باشد. Official source، Effective/Application date، Rule/transposition، Last checked و Review trigger را نگه دارید. نتیجهٔ سال قبل را بدون Revalidation به Release امروز منتقل نکنید.

Applicability Matrix قابل کپی

محور	Evidence	نتیجه	Unknown/Owner
Subject/Role	ثبت حقوقی، قرارداد، Operating model	Match/No match/Unknown	Legal/Business
Product/Service	Catalog، Architecture، User journey	Covered/Excluded/Unknown	Product
Territory/Market	Offer، customer، procurement	Nexus/No nexus/Unknown	Legal/Sales
Date	Release و Application dates	In/Out/Transition	Policy owner
Exception	Criteria و مستند ارزیابی	Approved/Rejected/Unknown	Qualified authority

Unknown را به No تبدیل نکنید

نبود Source، ترجمهٔ نامطمئن، نقش اقتصادی مبهم یا اختلاف نسخه باید نتیجهٔ UNKNOWN و Owner/Due بسازد. «چیزی پیدا نکردیم» معادل «الزامی وجود ندارد» نیست. تصمیم Release در حضور Unknown باید ریسک، شرط، Expiry و Authority مشخص داشته باشد؛ چارچوب کیفیت به‌اندازه کافی خوب برای خود تصمیم انتشار مفید است، نه برای تفسیر قانون.

Exception یک یادداشت دائمی نیست

Fundamental alteration، Disproportionate burden، Archive، Third-party یا Microenterprise اگر در Instrument وجود داشته باشد، Criteria و Scope خاص دارد. ExceptionID، Legal basis، Evidence، Assessor/Authority، affected requirement، alternatives، Expiry و Review date را ثبت کنید. هزینهٔ کلی یا «Vendor کنترلش می‌کند» به‌تنهایی Exception معتبر نمی‌سازد.

Obligation را به Requirement آزمون‌پذیر ترجمه کنید

Source clause، obligated party، covered object، required outcome، deadline، documentation/monitoring duty و Enforcement context را بدون حذف قیدها ثبت کنید. سپس با Legal/Accessibility/Product یک Requirement فنی یا فرایندی نسخه‌دار بسازید. روش تبدیل قانون حریم خصوصی به تست نیز همین اصل جداسازی شمول از Test case را در حوزه‌ای دیگر نشان می‌دهد.

Normative و Informative را جدا نگه دارید

در WCAG، Success Criteria و الزامات Conformance بخش Normative هستند؛ Understanding، Techniques و مثال‌ها به فهم/پیاده‌سازی کمک می‌کنند اما خودشان الزام Conformance جدید نمی‌سازند. «Technique خاص را استفاده نکردیم» خودکار Failure نیست و «Technique را اجرا کردیم» نیز خودکار Success criterion را Pass نمی‌کند. Basis record باید نوع Source را نشان دهد.

Conformance WCAG پنج شرط دامنه‌ای دارد

Level مورد ادعا به‌طور کامل برآورده شود.
Full page ارزیابی شود؛ بخش مشکل‌دار را نمی‌توان حذف کرد.
Complete process در همهٔ صفحات فرایند منطبق باشد.
فقط راه‌های Accessibility-supported اتکا شوند.
فناوری غیرمتکی باعث Interference ممنوع نشود.

Passکردن چند صفحه Sample یا چند Criterion برای ادعای AA کافی نیست. اگر Claim فقط دربارهٔ یک Scope کوچک است، آن Scope را با URI/Pattern و تاریخ دقیق بنویسید و دربارهٔ خارج Scope سکوت را به انطباق تعبیر نکنید.

اجزای اجباری Claim اختیاری WCAG

WCAG می‌گوید Conformance claim الزامی نیست؛ اما اگر ساخته شود باید تاریخ Claim، عنوان/نسخه/URI Guidelines، Level، توصیف مختصر صفحات تحت Claim و فهرست Web content technologies relied upon را داشته باشد. لوگوی Conformance نیز Claim محسوب می‌شود و نشان نمی‌دهد W3C آن را بررسی یا تایید کرده است.

WCAGClaim = {
  claimDate,
  guideline: { title, version, uri },
  level,
  pages: { urisOrPattern, subdomainsIncluded },
  reliedUponTechnologies,
  evaluationId,
  approvedBy,
  validUntil
}

Conformance Claim با Evaluation Report فرق دارد

Evaluation Report روش، نمونه، Test environment، نتایج، Evidence و Limitations را می‌گوید. Claim گزارهٔ محدود حاصل است. Accessibility Statement برای کاربران Scope، وضعیت، محدودیت‌ها، Alternative و Feedback channel را توضیح می‌دهد. Legal claim دربارهٔ Obligation قابل اعمال است. یک PDF ممیزی را به‌جای هر چهار Artifact استفاده نکنید.

Scope را با URI تنها تمام نکنید

URIها، Subdomain، Auth state، Role، Responsive breakpoint، Language، Theme، Personalization، Error/empty/loading state، Third-party embed، Document/Media و Complete process را ثبت کنید. صفحهٔ Checkout در حالت Happy path با همان صفحه در خطای پرداخت، Timeout، Validation و بازگشت PSP یک Scope واحد ساده نیست.

Inventory پیش از Sample

Pages/views، Templates، Components، Journeys، Documents، Media، Mobile screens، Generated content و Third-party را فهرست کنید. Sample frame باید از Inventory نسخه‌دار بیاید. Sample نماینده می‌تواند Risk را ارزیابی کند، اما انطباق تمام Items خارج نمونه را ثابت نمی‌کند؛ Claim باید با روش و Coverage هماهنگ باشد.

Accessibility Support فقط نام Screen reader نیست

User agent، AT، نسخه، OS/platform، Language، Technology، relied-upon way، fallback و Evidence را به‌صورت ماتریس ثبت کنید. «با NVDA تست شد» بدون Browser، نسخه، زبان، Task و Outcome کافی نیست. فارسی و RTL می‌تواند رفتار نام/نقش/ترتیب خواندن را تغییر دهد؛ Support را از تجربهٔ انگلیسی قرض نگیرید.

Method و Evaluator را نسخه‌دار کنید

EvaluationID، Method/version، Evaluator، Independence، Sample frame، Sample، Coverage limits، Date و Environment را ثبت کنید. WCAG-EM، روش مشتری، Harmonized test method یا Protocol داخلی نتایج متفاوتی می‌سازند. نام شرکت ممیز جای Method و Evidence را نمی‌گیرد و Internal بودن نیز نتیجه را خودکار بی‌اعتبار نمی‌کند؛ Conflict و Independence را شفاف کنید.

Evidence باید Requirement و State را پیوند دهد

Evidence = {
  evidenceId, requirementRef, subjectRef,
  pageOrState, procedureRef, expected,
  observed, result, artifactRef,
  toolOrHuman, environment, capturedAt,
  provenance, freshness, reviewer
}

Screenshot بدون حالت و Expected result، یا خروجی Tool بدون Ruleset و Version، Evidence قابل ممیزی نیست. Artifact ممکن است DOM snapshot، ویدئوی Focus، Transcript، Contrast calculation، Accessibility tree، Test log یا Observation باشد؛ دادهٔ شخصی و صدای Participant باید کمینه و محافظت شود.

Result فقط Pass و Fail نیست

Passed، Failed، Cannot tell، Not applicable و Not tested را جدا کنید. Not applicable باید Rationale و Scope داشته باشد؛ Cannot tell نیازمند اطلاعات/Reviewer بعدی است؛ Not tested نباید Pass Aggregate شود. Aggregation rule را پیش از نتیجه بنویسید و Criterionهای Level مورد ادعا را مخفی نکنید.

Lighthouse ۱۰۰ ادعای انطباق نیست

Tool name/version، Ruleset، Coverage boundary، False-positive route، False-negative boundary و Incomplete review را ثبت کنید. Score ترکیبی ممکن است با تغییر Version عوض شود و فقط Ruleهای قابل اتوماسیون را ببیند. امتیاز ۱۰۰، صفر Violation یا Badge CI نه Full page/Complete process را ثابت می‌کند و نه Applicability قانونی را.

Widget جای اصلاح و Claim نیست

Overlay/Widget ممکن است Featureهای کمکی ارائه دهد، اما وجود آن به‌تنهایی Semantics، Keyboard، Focus، Error، Media، Reflow یا سازگاری AT را اصلاح نمی‌کند و Scope حقوقی را نیز تعیین نمی‌کند. خود Widget و تعامل آن با User agent/AT باید در Inventory و Evaluation بیاید. وعدهٔ «Compliance فوری» را بدون Evidence نپذیرید.

Manual protocol را از حافظه اجرا نکنید

Keyboard/Focus، Structure/Semantics، Zoom/Reflow، Forms/Errors، Media، Dynamic updates، Authentication و Cognitive review باید Protocol، Preconditions، Expected، Evidence و Result داشته باشند. اجرای آزادانه مفید است، اما برای Claim باید قابل بازپخش و متصل به Requirement باشد.

مشارکت افراد دارای معلولیت مکمل Conformance است

User Research می‌تواند Barrier واقعی، Workaround، زبان، Context و Priority را آشکار کند؛ اما تجربهٔ چند Participant همهٔ Success criteria یا همهٔ افراد را اثبات نمی‌کند. Research question، Participant criteria، Accommodation، Consent، Privacy، Task و Observation boundary را ثبت کنید. شخص را برای «شبیه‌سازی معلولیت» ابزار نکنید و یافته را به کل جمعیت تعمیم ندهید.

Accessibility و Usability هم‌پوشان‌اند، یکی نیستند

محصول ممکن است Criterion فنی را Pass کند ولی Workflow برای گروهی دشوار بماند؛ یا Task در یک مطالعه موفق شود ولی Requirement فنی Fail باشد. برای Context، Participant و Task به تست کاربردپذیری Workflow رجوع کنید و دو Evidence stream را در Decision کنار هم بگذارید، نه اینکه یکی را جانشین دیگری کنید.

Finding را به Barrier و Requirement وصل کنید

FindingID، Barrier، Requirement reference، affected users، Task impact، Frequency، Evidence، Severity rationale، Owner، Remediation و Retest را ثبت کنید. Level معیار مساوی Severity نیست؛ یک A failure محدود و یک AA failure در مسیر حیاتی اثر متفاوت دارند. تعداد Violation نیز تعداد افراد یا شدت آسیب نیست.

Partial Conformance اصطلاح آزاد بازاریابی نیست

WCAG برای Third-party content خارج کنترل یا فقدان Accessibility support زبان، Statementهای جزئی با شروط مشخص دارد. محتوا باید قابل شناسایی باشد و Counterfactual/توان Monitor or correct بررسی شود. «تا حد زیادی مطابقیم» یا درصد Conformance، جای Claim تعریف‌شده نمی‌گیرد. از عبارت Partial فقط مطابق شرایط مرجع استفاده کنید.

Accessibility Statement را برای کاربر بنویسید

Scope summary، Status دقیق، Known limitations، Alternative، Feedback channel قابل دسترس، Response expectation، Published/Updated date و Owner را منتشر کنید. Statement نباید فقط دفاع حقوقی باشد. اگر کاربر به Barrier رسید، باید بداند چگونه خدمت جایگزین بگیرد و چه زمانی پاسخ می‌رسد.

Legal claim لایهٔ Approval جدا می‌خواهد

Claim text، Claim type، Applicable obligations، Evidence refs، Exceptions disclosed، Qualified approval، Approval date و Valid until را ثبت کنید. عبارت‌های «قانوناً منطبق»، «ADA compliant»، «EAA ready» و «مطابق قانون ایران» را QA یا Marketing از روی Scanner تولید نکند. Legal reviewer نیز برای نتیجهٔ فنی به Evidence معتبر نیاز دارد.

اخلاق جای قانون را نمی‌گیرد؛ حداقل را نقد می‌کند

حتی اگر Exception قانونی یا Scope محدود وجود دارد، Barrier ممکن است به آموزش، سلامت، کار، ارتباط یا استقلال آسیب بزند. Affected people، Harm question، Participation plan، Equity risk، Beyond-minimum options، Trade-off، Dissent و Decision owner را ثبت کنید. اخلاق را به شعار «کار درست» یا امتیاز CSR تقلیل ندهید؛ صدای افراد متاثر و منابع واقعی لازم است.

مزیت تجاری را تضمین نکنید

دسترس‌پذیری می‌تواند بازار، Completion، Support و رضایت را تحت شرایطی بهبود دهد، اما وفاداری، SEO، درآمد یا اعتبار برند خودکار نیست. Baseline، Segment، Outcome، Countermetric و Attribution method لازم است. Alt text نامناسب یا Heading مکانیکی حتی می‌تواند تجربه و SEO را بدتر کند. ادعای Business outcome را از Conformance claim جدا کنید.

Release Gate بر Claim completeness بنا شود

Gate type، Blocking criteria، Evidence cutoff، Known barriers، Exceptions، Residual risk owner، Authority، Decision و Conditions را ثبت کنید. Scanner pass به‌تنهایی Gate نیست؛ Unknown applicability نیز نباید پنهان شود. مدیریت توقع ذی‌نفعان دربارهٔ Scope و Claim با قرارداد کیفیت و تصمیم منظم‌تر می‌شود.

Dashboard ادعای بزرگ‌تر نسازد

نسخهٔ Basis، Scope، Inventory coverage، Passed/Failed/Cannot tell/Not tested، Evidence freshness، Known barrier، Exception expiry و Claim status را نشان دهید. درصد سبز بدون Denominator و Scope خطرناک است. اصول داشبورد تصمیم‌محور QA کمک می‌کند Drill-down و Freshness کنار عدد دیده شوند.

Monitoring پس از Claim اجباری عملی است

تغییر Content، Component، Dependency، CMS، AT/Browser، Standard، قانون، Contract، Market یا Feedback می‌تواند Claim را منقضی کند. MonitoringID، Change triggers، Drift، Feedback intake، Retest cadence، Incident route، Owner و Next review را ثبت کنید. Claim بدون امکان Monitor/correct در بعضی حالات حتی با قواعد Partial claim سازگار نیست.

Correction ادعای اشتباه را علنی اصلاح کند

اگر Scope، نسخه، Level یا وضعیت اشتباه منتشر شد، CorrectionID، Incorrect claim، Affected audience، Withdraw time، Replacement claim، Reissue channels، Evidence و Owner را ثبت کنید. ویرایش بی‌صدای صفحه برای مشتری، مناقصه و تصمیم Release کافی نیست؛ مصرف‌کنندگان Claim قبلی باید قابل شناسایی باشند.

آزمایش قطعی: هفت چراغ سبز سطحی

یک Validator مستقل و بدون وابستگی با Node.js ۲۴.۱۸.۰ روی Fixture ساختگی اجرا شد. Checker سطحی فقط دید تیم نوشته WCAG AA، امتیاز Lighthouse برابر ۱۰۰، axe بدون Violation، Keyboard smoke پاس، Widget نصب، یک User test انجام و در Legal page از Accessibility نام برده شده است؛ بنابراین به‌اشتباه گفت:

SUPERFICIAL=LEGALLY_COMPLIANT_AND_ACCESSIBLE

ممیز قراردادی ۲۵۴ کنترل یکتا را در ۲۸ گروه بررسی کرد: Identity، Decision، Subject، Market، Jurisdiction، Applicability، Exception، Obligation، Basis، Scope، Support، Inventory، Evaluation، Evidence، Automation، Manual، User research، Finding، Result، Conformance، Partial، Statement، Legal claim، Ethics، Release، Monitoring، Correction و Limits. همه غایب بودند:

AUDIT=HOLD-254
INDEPENDENT_BOUNDARY=qa-issued-legal-opinion:false:PASS

مرز مستقل ۲۵۵ام تأیید کرد QA نظر حقوقی صادر نکرده است. پس از ثبت همهٔ فیلدهای ساختاری با دادهٔ کاملاً ساختگی و حفظ Unknownها، خروجی چنین شد:

CORRECTED=READY_FOR_ACCESSIBILITY_CLAIM_REVIEW-0
BOUNDARY=structure-only; no legal applicability, WCAG conformance,
accessibility, usability, user inclusion, release safety,
market benefit, or compliance proven

چرا صفر Finding هنوز Conformance نیست؟

Validator حضور و ارتباط فیلدها را می‌سنجد، نه حقیقت Source، صلاحیت Reviewer، کفایت Sample یا رفتار محصول. ممکن است تمام فیلدها با دادهٔ غلط پر شده باشند. نتیجه فقط READY_FOR_ACCESSIBILITY_CLAIM_REVIEW است؛ بازبین حقوقی Applicability و ارزیاب دسترس‌پذیری Evidence/Conformance را مستقل بررسی می‌کنند.

آزمایشگاه فارسی کاملاً آفلاین

یک Checkout ساختگی با Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification بسازید. حالت‌های Timeout پیش/پس از Commit ساختگی، Retry، Duplicate، Callback دیرهنگام، Reordering، Validation error و Session expiry را در فایل محلی اجرا کنید. هیچ Network، Production، شرکت، شخص، مشتری، سفارش، پرداخت، PSP یا بانک واقعی وجود ندارد.

Tenant/Order/Attempt/Event/Build/Run/Record/Claim شناسهٔ پایدار ساختگی دارند. IRR تخیلی و تومان فقط نمایش برچسب‌خورده است. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/LTR/Bidi، UTC و Asia/Tehran و تاریخ جلالی نمایشی تست می‌شوند. هیچ نام، معلولیت واقعی، کدملی، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، صدا، ویدئو، Log یا Screenshot واقعی وجود ندارد.

LabBoundary = {
  network: false,
  production: false,
  realOrganization: false,
  realParticipantOrDisabilityData: false,
  legalOpinion: false,
  purpose: "validate claim-record structure only"
}

تمرین Claim بدون ادعای واقعی

سه Instrument کاملاً خیالی با Scope و تاریخ متفاوت بسازید.
Subject/Market matrix را پر و دو خانه را عمداً UNKNOWN نگه دارید.
یک Basis ساختگی و Evaluation scope محدود تعریف کنید.
Scanner مصنوعی را PASS کنید، ولی Manual/User evidence را Not tested بگذارید.
تلاش برای Claim کامل باید HOLD شود.
Known limitation و Feedback channel ساختگی را در Statement بنویسید.
با تغییر Version، Claim قبلی را Expire و Correction ثبت کنید.

Anti-patternهایی که باید رد شوند

«WCAG قانون جهانی است»؛
«همهٔ قوانین WCAG ۲.۲ AA می‌خواهند»؛
«ADA برای همهٔ سایت‌ها دقیقاً یک Rule دارد»؛
«EAA یعنی هر سایت اروپایی»؛
«قانون ایران صریحاً همهٔ سایت‌ها را WCAG AA کرده»؛
«Lighthouse ۱۰۰ یعنی compliant»؛
«axe صفر یعنی accessible»؛
«Widget انطباق فوری می‌دهد»؛
«Sample پاس شد، کل محصول پاس است»؛
«یک User test نمایندهٔ همه است»؛
«AAA یعنی کاملاً دسترس‌پذیر»؛
«Level معیار همان Severity است»؛
«Not tested را می‌توان Pass حساب کرد»؛
«Third party همیشه Exception است»؛
«QA می‌تواند Legal sign-off بدهد»؛
«Conformance حتماً SEO و فروش را بالا می‌برد»؛
«Statement فقط متن دفاع حقوقی است»؛
«Claim تاریخ انقضا و Correction نمی‌خواهد».

چک‌لیست Owner پیش از انتشار Claim

RecordID، نسخه، As-of، Owner و Review date مشخص است.
Decision question، Authority و Not-decided روشن‌اند.
Legal entity/role و Product/Service/Release تثبیت شده‌اند.
Market/Territory/Customer/Procurement شاهد دارند.
Instrument/version/source/effective date و Reviewer ثبت‌اند.
Subject/Activity/Territory/Sector/Size/Date شمول بررسی شده‌اند.
Exception دارای basis/evidence/scope/authority/expiry است.
Obligation و Clause بدون حذف قید ترجمه شده‌اند.
Technical basis/version/level/adoption relation دقیق است.
Scope شامل full page/complete process/state/language/third party است.
Accessibility support matrix و Inventory نسخه‌دارند.
Method/evaluator/sample/limits/date/environment ثبت‌اند.
Evidence به Requirement/State/Expected/Observed وصل است.
Cannot tell/Not applicable/Not tested با Pass مخلوط نشده‌اند.
Claim اجزای اجباری WCAG را در صورت استفاده دارد.
Evaluation Report/Statement/Legal Claim جدا هستند.
Known limitation و Feedback channel قابل دسترس منتشر شده‌اند.
Legal approval و Technical review مستقل‌اند.
Release condition و Residual risk owner روشن‌اند.
Monitoring/Expiry/Correction/Supersession فعال‌اند.
هیچ تضمین SEO، فروش، Zero barrier یا انطباق جهانی وجود ندارد.

Pilot سی‌روزه برای حاکمیت Claim

هفتهٔ اول: Claimهای فعلی سایت، قرارداد و فروش را Inventory و هرکدام را به Owner/Source وصل کنید. هفتهٔ دوم: برای یک محصول ساختگی یا داخلی، Applicability matrix و Basis register بسازید. هفتهٔ سوم: Evaluation/Statement/Legal approval را با داده Sanitized تمرین کنید. هفتهٔ چهارم: Change trigger، Expiry و Correction drill اجرا کنید و Claim بدون Evidence را Withdraw نمایید.

معیار Pilot: درصد Claimهای دارای Subject/Scope/As-of، تعداد Unknownهای Ownerدار، Exception منقضی، Evidence تازه، Statement دارای Alternative، زمان Correction و Claimهای Withdrawشده پیش از انتشار. این معیارها برای رتبه‌بندی کارکنان یا اثبات Inclusion نیستند.

جمع‌بندی

دسترسی‌پذیری با یک لوگو، Score یا جملهٔ اخلاقی قابل اثبات نیست. ابتدا Subject/Market/Date و Instrument را برای Applicability تثبیت کنید؛ Obligation را با قیدهایش به Basis فنی وصل کنید؛ Scope/Support/Inventory/Method/Evidence را بسازید؛ سپس فقط Claimی را منتشر کنید که از ارزیابی کوچک‌تر یا مساوی باشد. محدودیت، Unknown، Exception، Expiry و Correction بخشی از صداقت Claim هستند، نه نشانهٔ شکست.

سوالات متداول

آیا WCAG ۲.۲ AA یک الزام قانونی جهانی است؟

خیر. WCAG مرجع فنی W3C است. قانون، مقرره، قرارداد یا سیاست ممکن است نسخه/سطحی از آن یا مرجع دیگری را به کار گیرد. کشور، سازمان، نقش، محصول، بازار، تاریخ، استثنا و متن Instrument باید جدا بررسی شوند.

آیا امتیاز ۱۰۰ Lighthouse یا صفر خطای axe یعنی سایت منطبق است؟

خیر. ابزار فقط Ruleهای قابل اجرا در Scope/State مشخص را می‌سنجد و False negative/Incomplete دارد. Conformance نیازمند تمام Criterionهای Level، full page، complete process، accessibility support، manual evidence و Scope روشن است؛ انطباق قانونی نیز Applicability جدا می‌خواهد.

قانون ایران همهٔ وب‌سایت‌ها را ملزم به WCAG AA کرده است؟

از متن عمومی قانون حمایت از حقوق معلولان و آیین‌نامهٔ مادهٔ ۳ نمی‌توان چنین حکم فراگیری صادر کرد. آنها اطلاعات/فناوری و استاندارد درگاه‌های دستگاه‌های مشمول را مطرح می‌کنند؛ Subject مشمول، استاندارد جاری، قرارداد و ضمانت اجرا باید با منبع معتبر و بازبین واجد صلاحیت تعیین شود.

تفاوت Accessibility Statement و Conformance Claim چیست؟

Claim یک گزارهٔ فنی دربارهٔ نسخه/سطح WCAG و صفحات/فناوری‌های مشخص است. Statement برای کاربر وضعیت، Scope، محدودیت‌ها، Alternative و کانال بازخورد را توضیح می‌دهد. Evaluation Report شواهد و روش را نگه می‌دارد و Legal claim نیازمند بررسی شمول و Approval جداست.

QA در ادعای انطباق دسترس‌پذیری چه نقشی دارد؟

QA می‌تواند Subject/Scope/Version را تثبیت، Requirement را آزمون‌پذیر، Evidence را قابل ردیابی، Coverage/Unknown را شفاف و Claim completeness را ممیزی کند. QA به‌تنهایی Applicability حقوقی، Legal sign-off، Inclusion همهٔ افراد یا نتیجهٔ تجاری را تایید نمی‌کند.

اجرای تست‌ها

ادعای انطباق دسترس‌پذیری؛ از Applicability تا Claim