سبزشدن یک اسکن خودکار، اجرای یکباره با صفحهکلید یا نصب Screen Reader هنوز «برنامهٔ تست دسترسپذیری» نیست. برنامه زمانی شکل میگیرد که سازمان بداند کدام محصول، نسخه، مسیر و State را بر اساس کدام استاندارد و Policy میسنجد؛ چه کسی نتیجه را تفسیر و اصلاح میکند؛ شواهد تا چه زمانی معتبرند؛ چه استثنایی با کدام مالک پذیرفته شده؛ و کاربری که با مانع روبهرو میشود چگونه پاسخ میگیرد.
این مقاله مالک ساخت و ادارهٔ برنامه تست دسترسپذیری است: Policy → Scope و Inventory → روش ارزیابی و نمونه → Automation/Manual/AT/User Evidence → Remediation → Release Gate → Accessibility Statement و Monitoring. برای یادگیری خود معیارها، Keyboard، Screen Reader، فرم، Contrast و چکلیست اجرایی به راهنمای تست دسترسپذیری بر پایه WCAG ۲.۲ مراجعه کنید؛ بحث قانون و اخلاق نیز در راهنمای الزامات قانونی و مسئولیت اخلاقی دسترسپذیری مالک جداگانه دارد.
پاسخ کوتاه: برنامه تست دسترسپذیری چیست؟
یک نظام نسخهدار برای تبدیل هدف دسترسپذیری به شواهد و تصمیم است. این نظام Scope، استاندارد و سطح هدف، فناوریهای مورد اتکا، فرایندهای کامل، نمونهٔ نماینده، مرور خودکار و انسانی، ترکیب مرورگر/فناوری کمکی، مشارکت کاربران، قالب Finding، SLA اصلاح، استثنا، Gate، ادعای انطباق و بازبینی مداوم را به هم متصل میکند.
| لایه | پرسش تصمیم | خروجی |
|---|---|---|
| Policy | چه هدفی، برای چه دامنهای و تا چه زمانی؟ | Accessibility Policy |
| Evaluation | چه چیز، با چه روش و نمونهای آزمون شد؟ | Evaluation Plan/Report |
| Remediation | مانع چگونه، توسط چه کسی و در کدام Build رفع میشود؟ | Finding Register |
| Decision | آیا شواهد برای انتشار/ادعا کافی است؟ | Accessibility Release Memo |
| User communication | محدودیت و کانال کمک چگونه اعلام میشود؟ | Accessibility Statement |
| Monitoring | پس از تغییر و در Production چه چیزی بازبینی میشود؟ | Dashboard + Feedback loop |
چرا «A11y Mindset» بدون قرارداد اجرایی کافی نیست؟
تعهد و همدلی برای آغاز مهماند، اما معیار پذیرش، مسئولیت و قابلیت ممیزی نمیسازند. یک تیم ممکن است با نیت خوب Alt Text بنویسد و همزمان Checkout، Authentication یا PDF را از Scope حذف کند. برنامه، ارزش را به عمل قابل سنجش وصل میکند و از تبدیل دسترسپذیری به کمپین مقطعی یا وظیفهٔ یک قهرمان تنها جلوگیری میکند.
| عبارت مبهم | قرارداد قابل آزمون |
|---|---|
| محصول برای همه قابل استفاده باشد | Scope، کاربران/نیازها، استاندارد، سطح، نسخه و روش معلوم |
| تیم A11y را رعایت میکند | Definition of Done و مالک هر Artifact ثبت شده |
| ابزار خطایی نشان نداد | Rule/version/applicability و Manual remainder گزارش شده |
| با Screen Reader تست شد | AT/browser/version/task/state/operator و نتیجه ثبت شده |
| AA هستیم | شرایط Conformance و Claim کامل بررسی شده |
| بازخورد میگیریم | کانال قابل دسترس، مالک، SLA، Escalation و Closure وجود دارد |
مرز این صفحه با راهنمای WCAG و تست کاربردپذیری
| موضوع | مالک | این مقاله چه میگیرد؟ |
|---|---|---|
| معیارهای WCAG، Keyboard، Screen Reader، فرم و Contrast | راهنمای تست A11y | پوشش و شواهد آنها را برنامهریزی میکند |
| قانون، حوزه قضایی و مسئولیت اخلاقی | راهنمای قانون/اخلاق | Applicability review را الزام میکند |
| Task، Context و رفتار کاربر | راهنمای کاربردپذیری سازمانی | مشارکت افراد دارای معلولیت را با Conformance ترکیب میکند |
| اتوماسیون عمومی و CI | نقشه راه تست خودکار | Rule contract و A11y quality gate میسازد |
| حریم خصوصی دادهٔ شرکتکننده/ضبط | راهنمای حریم خصوصی QA | حداقلگرایی و Retention را در Evidence میگنجاند |
| Runbook، Support و Rollback | آمادگی عملیاتی | پاسخ به مانع و انتشار را Gate میکند |
نسخه و وضعیت مرجع را قفل کنید
WCAG 2.2 یک W3C Recommendation و مرجع هنجاری معیارهای موفقیت و شرایط Conformance است. WCAG-EM 1.0 یک W3C Working Group Note برای ساختار ارزیابی وبسایت است و الزام تازهای به WCAG اضافه نمیکند. در زمان نگارش این مقاله، WCAG-EM ۲.۰ که محصولات دیجیتال گستردهتری را هدف گرفته هنوز Draft است؛ آن را نباید بیبرچسب بهعنوان استاندارد نهایی قرارداد کرد.
| مرجع | وضعیت/کاربرد | خطای رایج |
|---|---|---|
| WCAG 2.2 | معیارها و Conformance وب | استفاده از یک Checklist بدون شرایط Conformance |
| Understanding/Techniques | راهنمای informative برای فهم/پیادهسازی | نامیدن Technique بهعنوان تنها راه الزامآور |
| WCAG-EM 1.0 | روش ارزیابی Conformance وبسایت | تعمیم بیقید به همهٔ محصولات native |
| WCAG-EM 2.0 Draft | پیشنویس در حال تکامل | ادعای نسخهٔ نهایی یا ثابت |
| ACT Rules | قواعد informative برای تست شفافتر | یکیگرفتن Pass همه Rules با Conformance کامل |
| Policy/قانون قراردادی | هدف سازمان/حوزهٔ کاربرد | فرض اینکه WCAG بهتنهایی Applicability قانونی را تعیین میکند |
Accessibility Policy را از Test Plan جدا کنید
راهنمای Planning and Managing در WAI دسترسپذیری را فعالیتی تکرارشونده در چرخهٔ تولید میبیند. Policy هدف، دامنه، استاندارد، مسئولیت، نقاط عطف و پایش را تثبیت میکند؛ Test Plan برای یک Release یا Evaluation مشخص، روش و شواهد را تعریف میکند. تغییر Test Plan نباید بیاجازه هدف Policy را کوچک کند.
Accessibility Policy Contract policy_id / owner / approver / effective_date / review_date products / channels / domains / languages / third_parties target_standard / version / level / applicable_profile complete_processes / content_types / authoring_tools roles / training / procurement / definition_of_done evaluation_frequency / release_gates / monitoring feedback_channel / response_sla / escalation exception_authority / maximum_duration / disclosure applicable_law_or_contract_review_ref change_history
هدف AA را پیشفرض جهانی اعلام نکنید
WCAG سطوح A، AA و AAA را تعریف میکند، اما انتخاب هدف سازمان به Scope، قانون/قرارداد، ریسک، کاربر، پلتفرم و Policy وابسته است. WCAG ۲.۲ نیز توصیه نمیکند AAA سیاست عمومی همهٔ سایتها باشد، چون برآوردهکردن همهٔ معیارهای AAA برای بعضی محتواها ممکن نیست. از طرف دیگر «فقط A» یا «AA برای اکثر سایتها» بدون Applicability review، تصمیم معتبر پروژه نیست.
Scope Contract: دقیقاً چه چیزی داخل ارزیابی است؟
| بعد Scope | نمونهٔ ثبت |
|---|---|
| Product/Release | Web portal 8.4 / build hash |
| Hosts | دامنه، subdomain و embedded origin |
| Channels | Responsive web، PWA، email، PDF |
| Languages | fa-IR و en؛ صفحههای mixed language |
| Roles | Anonymous، customer، agent، admin |
| Complete processes | Signup، purchase، recovery، complaint |
| Content types | Article، form، data grid، video، map |
| States | Default، error، empty، loading، timeout، success |
| Third party | Payment widget، chat، identity provider |
| Excluded | مورد، دلیل، ریسک، مالک و تاریخ انقضا |
عبارت «کل سایت» بدون تعریف Host، نقش، زبان، محتوای پویا و مسیرهای کامل قابل بازتولید نیست. Scope را با URL list تنها نسازید؛ یک Route میتواند دهها State و Variant داشته باشد.
Full Page و Complete Process را در Gate حفظ کنید
شرایط Conformance در WCAG ۲.۲ شامل صفحهٔ کامل و فرایند کامل است. اگر Checkout زنجیرهای از صفحههاست، نمیتوان صفحهٔ پرداخت را جداگانه مطابق نامید در حالی که Address step همان مسیر مانع دارد. Variantهای Responsive که خودکار ارائه میشوند نیز بخشی از صفحهاند. برنامه باید گراف مسیر را نگه دارد تا نمونهگیری یک گام حیاتی را جا نگذارد.
Complete Process Manifest process_id: SYN-PURCHASE-v4 start: product discovery steps: product → cart → address → payment → receipt roles: guest/member required states: default/error/timeout/re-auth/success technologies relied upon: HTML/CSS/JavaScript/ARIA/SVG third-party boundaries: identity/payment evidence_refs: per step + end-to-end run owner / version / last_reviewed
Inventory را پیش از Sample بسازید
نمونهٔ نماینده بدون شناخت داراییها تصادفی نیست؛ ناقص است. Inventory باید Template، Component، Content type، نقش، زبان، State، فناوری، مسیر بحرانی، حجم/تغییر و مالک را بشناسد. Sitemap فقط صفحهٔ عمومی را میبیند و معمولاً Modal، validation error، session timeout، SPA route، سند دانلودی و پنل role-based را از دست میدهد.
| منبع کشف | چه چیزی مییابد؟ | Gap محتمل |
|---|---|---|
| Crawl/Sitemap | URL عمومی و Template | Auth/state/dynamic |
| Route/config | مسیر و Feature flag | محتوای CMS |
| Design system | Component و pattern | ترکیب در Workflow |
| Analytics aggregate | مسیرهای پرترافیک | کار کمترافیک اما حیاتی |
| Support/feedback | مانع واقعی گزارششده | مانع گزارشنشده |
| Process owner | فرایند و استثنا | رفتار پیادهسازی |
| Repository diff | تغییر کد/محتوا | وابستگی و Regression دوردست |
نمونهٔ نماینده را قابل دفاع انتخاب کنید
WCAG-EM ساختار Define scope → Explore → Select representative sample → Evaluate → Report را پیشنهاد میکند. نمونه باید Structured pages/states و در صورت روش انتخابی، بخش تصادفی را پوشش دهد. «ده صفحهٔ اول» یا «صفحات پربازدید» نمایندگی را تضمین نمیکند.
| لایهٔ نمونه | نمونه | دلیل |
|---|---|---|
| Key process | ثبتنام و بازیابی حساب | Outcome کامل |
| Template | Article، listing، detail، form | الگوی مشترک |
| Component | Dialog، tabs، grid، combobox | رفتار تعاملی |
| State | Error، empty، timeout، success | DOM/پیام متفاوت |
| Language | فارسی RTL، انگلیسی و mixed | نام/جهت/خواندن متفاوت |
| Role | کاربر و مدیر | UI و Permission متفاوت |
| Changed/high-risk | Auth یا پرداخت جدید | احتمال و پیامد |
| Random supplement | از Population تعریفشده | کاهش سوگیری کشف |
Sampling هیچگاه «صفحات خارج نمونه مطابقاند» را ثابت نمیکند
نتیجهٔ نمونه دربارهٔ Scope و روش انتخابشده تفسیر میشود. Component مشترک میتواند اعتماد به تعمیم را افزایش دهد، اما Override محتوا، Feature Flag، داده و نقش ممکن است رفتار را تغییر دهد. Report باید Population، نمونه، منطق انتخاب، محدودیت و صفحات/Stateهای بررسینشده را شفاف کند.
Test Matrix را چندبعدی و لایهای بسازید
| بعد | سطحها | راهبرد پوشش |
|---|---|---|
| Build | PR/RC/Production | عمق افزایشی |
| Surface | Web/email/PDF/video | روش تخصصی هر Surface |
| Input | Keyboard/pointer/touch/voice | مسیرهای بحرانی + Component |
| Perception | Screen reader/zoom/high contrast/captions | ترکیب هدف |
| Language | fa/en/mixed | نمونهٔ Template و مسیر |
| State | default/error/loading/timeout/success | Fixture deterministic |
| Viewport | responsive orientations | Breakpoint risk |
| Role | public/auth/admin | UI متفاوت |
ضرب کامل همهٔ ابعاد معمولاً عملی نیست. پوشش لایهای بسازید: Static/lint در authoring، Component automation، PR smoke، RC representative workflow، AT matrix و ارزیابی دورهای عمیق. هر کاهش Matrix باید Risk rationale و Coverage gap داشته باشد.
Test Basis را از Checklist جدا کنید
Test Basis شامل متن هنجاری معیار، شرایط Conformance، فناوری و Policy است. Techniques، Understanding، APG و Checklist به تفسیر/پیادهسازی کمک میکنند، اما ممکن است informative یا نمونهای باشند. برای هر Test Case مشخص کنید الزام کدام است، روش ارزیابی چیست، Applicability چگونه تعیین میشود و چه Artifactی Pass/Fail/Not Applicable را پشتیبانی میکند.
Accessibility Test Case Contract case_id / version / owner requirement_ref / normative_or_informative applicability_precondition surface / page_state / component / content setup / technology / browser / AT / viewport procedure / expected_result / oracle outcome: passed | failed | inapplicable | cantTell evidence_ref / evaluator / timestamp / build limitations / related_cases
ACT Rules چه میدهند و چه نمیدهند؟
فهرست ACT Rules در W3C قواعد approved/proposed/deprecated برای آزمون خودکار، نیمهخودکار یا دستی دارد. این قواعد informative هستند و ممکن است فقط یک جنبه از یک Success Criterion را پوشش دهند؛ Pass یک Rule مساوی Pass تمام معیار نیست. Rule ID، status، version و نگاشت ابزار باید در Baseline ثبت شود تا تغییر ابزار نتیجهٔ تاریخی را بیمعنا نکند.
| فیلد Rule Registry | دلیل |
|---|---|
| rule_id/title | هویت پایدار |
| status/date | Approved/Proposed/Deprecated |
| requirement mapping | دامنهٔ ادعا |
| implementation/tool version | تکرارپذیری |
| applicability | تفاوت Not Applicable با Pass |
| outcome vocabulary | Passed/Failed/Inapplicable/CantTell |
| manual remainder | آنچه Rule نمیسنجد |
| known divergence | اختلاف روش/ابزار |
Automation را Rule-based کنید، نه Score-based
راهنمای انتخاب ابزار ارزیابی WAI صریح است که ابزارها همهٔ جنبهها را خودکار نمیسنجند، ممکن است نتیجهٔ گمراهکننده بدهند و نمیتوانند خودشان دسترسپذیری را تعیین کنند. درصد ثابت مانند «ابزارها همیشه ۳۰ تا ۴۰ درصد مییابند» نیز بدون تعریف معیار، محتوا، Rule set و روش اندازهگیری قابل تعمیم نیست.
- Gate را بر Rule ID و Severity قراردادی بنا کنید، نه امتیاز تجمیعی فروشنده.
- New violation، Baseline debt و Regression را جدا گزارش کنید.
- False positive را با Evidence و Reviewer ثبت کنید؛ آن را خاموش و فراموش نکنید.
inapplicableرا Pass ننامید وcantTellرا Fail قطعی نکنید.- DOM state، viewport، auth، language و fixture اجرا را ثبت کنید.
- تغییر Engine/Rule set را مثل تغییر Test Basis مدیریت کنید.
CI Pipeline چندلایه برای دسترسپذیری
| لایه | زمان | شاهد | محدودیت |
|---|---|---|---|
| Lint/authoring | هنگام نوشتن | Rule result | Runtime/context را نمیبیند |
| Component | Unit/story | DOM/state snapshots | ترکیب صفحه را نمیبیند |
| PR browser | Changed routes/states | Machine report + artifact | دامنهٔ Rule محدود |
| RC workflows | پیش از انتشار | Keyboard/AT/manual trace | نمونه است |
| Periodic audit | نسخهدار/دورهای | WCAG-EM-style report | نقطهٔ زمانی |
| Production monitoring | پس از انتشار | scan/feedback/trend | جای ارزیابی انسانی نیست |
A11y CI Artifact build / commit / branch / timestamp tool_engine / version / rule_set_hash browser / viewport / locale / auth_role route / state_fixture / component_version passed / failed / inapplicable / cantTell by rule_id new / existing / waived with exception_ref DOM_or_screenshot_ref (masked) manual_follow_up / owner / due_date
Baseline Debt را مجوز Regression نکنید
در محصول قدیمی ممکن است صفرکردن همه Findings در یک Release ممکن نباشد. Baseline میتواند Regression تازه را متوقف کند، اما بدهی را مطابق یا کماهمیت نمیکند. هر مورد باید شناسه، اثر کاربر، معیار مرتبط، مالک، برنامه، Milestone و Expiry داشته باشد. Baseline بر اساس Count خام هم خطرناک است: حذف یک نقص و افزودن یک نقص پرخطر عدد را ثابت نگه میدارد.
تست دستی را Protocol کنید
«یک دور با Tab رفتیم» یا «NVDA را باز کردیم» قابل تکرار نیست. Manual Protocol باید Setup، Task، State، انتظار، کلیدها/gesture، Browser/AT، Outcome و Evidence را ثبت کند. تستر باید تفاوت میان عملکرد استاندارد فناوری کمکی، ترجیح شخصی و مانع محصول را بداند.
| پروتکل | نمونهٔ پوشش |
|---|---|
| Keyboard only | Order، visibility، trap، shortcut، modal، error recovery |
| Zoom/Reflow | ۲۰۰%، viewport هدف، loss/overlap/two-axis scroll |
| Text spacing | override و حفظ محتوا/عملکرد |
| High contrast/colors | forced colors، non-text cues، focus |
| Screen reader | structure، name/role/state، status، forms، live changes |
| Touch/pointer | target، drag alternative، cancellation، orientation |
| Media | captions، transcript، audio description applicability |
| Cognitive/input help | labels، errors، redundant entry، authentication |
Screen Reader «شبیهساز نابینایی» نیست
تستر بینا با Screen Reader میتواند Semantics، announcement، navigation و interaction contract را بررسی کند؛ تجربهٔ زیسته یا مهارت کاربر نابینا را شبیهسازی نمیکند. خاموشکردن نمایشگر یا بستن چشم نیز این شکاف را پر نمیکند. نتیجه باید «اجرای فنی با ترکیب X» نامیده شود، نه «تجربهٔ واقعی همهٔ کاربران نابینا».
AT Run Manifest run_id / build / evaluator / proficiency operating_system / version browser / version assistive_technology / version / settings language / voice / input_mode task / page_state / fixture expected announcements and interaction actual trace / outcome / evidence known support limitation / follow_up
AT × Browser Matrix را بر اساس کاربران و Support انتخاب کنید
فهرست بلند همهٔ ترکیبها نه ممکن است و نه لزوماً نماینده. ترکیب هدف را با مخاطب، analytics کمینه، Policy، فناوریهای مورد اتکا، قرارداد/حوزهٔ کاربرد، دادهٔ پشتیبانی و ریسک انتخاب کنید. نسخه و تنظیمات مهماند؛ نتیجهٔ یک ترکیب را به همهٔ Screen Readerها یا مرورگرها تعمیم ندهید.
| Tier | هدف | نمونهٔ تصمیم |
|---|---|---|
| Primary | ترکیبهای واقعاً مورد اتکا | هر Release برای فرایند بحرانی |
| Secondary | پوشش ریسک و تفاوت Engine | Release بزرگ/دورهای |
| Exploratory | ترکیب نو/کمداده | تحقیق بدون Claim عمومی |
| Unsupported/unknown | Gap شفاف | در Report/Statement با مسیر کمک |
Accessibility Support یک فهرست نام مرورگر نیست
WCAG اجازه میدهد فقط روشهای accessibility-supported برای برآوردن معیارها مورد اتکا باشند. برنامه باید قابلیت مشخص، فناوری، User agent، AT و شواهد پشتیبانی را ثبت کند. اینکه «Chrome و NVDA باز شدند» ثابت نمیکند همهٔ الگوها پشتیبانی میشوند؛ حمایت برای Feature مورد اتکا و Context استفاده بررسی میشود.
Design System را به Evidence System تبدیل کنید
Component library میتواند مانع را پیش از تکثیر مهار کند، اما Badge «Accessible» دائمی نیست. Contract باید anatomy، semantics، keyboard، focus، states، content constraints، responsive behavior، high contrast، RTL، known limitations و ترکیبهای آزموده را نسخهدار کند. مصرفکننده نیز میتواند با label غلط، ترتیب DOM، CSS override یا composition نامناسب Component سالم را خراب کند.
| Evidence سطح Component | Evidence سطح مصرف |
|---|---|
| Semantic contract | نام و Help واقعی |
| Keyboard states | ترتیب Focus در Workflow |
| Focus management | Invoker/next step درست |
| Contrast tokens | ترکیب رنگ و پسزمینهٔ واقعی |
| Error pattern | پیام دامنهای و Summary |
| RTL/zoom stories | محتوا و Layout صفحه |
| AT matrix | End-to-end task |
| Known limits | Mitigation/exception واقعی |
Content و CMS بخشی از برنامهاند
کد سالم با Heading بیمنطق، لینک مبهم، Alt نامناسب، جدول بدون Header یا ویدئوی بدون جایگزین دوباره مانع میسازد. Authoring guide، Template constraint، lint در CMS، Preview، آموزش نقشمحور و نمونهبرداری منتشرشده لازماند. Alt Text بهطور خودکار «SEO بهتر» یا دسترسپذیری تصویر را تضمین نمیکند؛ هدف و Context تصویر تعیین میکند چه جایگزینی لازم است.
PDF، Email، Video و Mobile را با روش Web خام نسنجید
| Surface | ریسک ویژه | Evidence جدا |
|---|---|---|
| Tags، reading order، form fields، export parity | Document/version/viewer/AT | |
| Client variance، structure، link context، dark mode | Template/client matrix | |
| Video/audio | Caption accuracy/timing، transcript، description | media-language review |
| Native mobile | platform semantics، gestures، dynamic type | OS/AT/device manifest |
| Canvas/map/chart | non-DOM interaction و data alternative | task-specific alternative |
| Kiosk/device | hardware/input/environment | physical context test |
اگر محصول فقط وب نیست، WCAG-EM ۱.۰ را بیتوضیح به همهٔ سطوح تعمیم ندهید. استاندارد/روش/قانون مناسب Surface را در Applicability Matrix تعیین کنید و وضعیت Draft منابع آینده را روشن بنویسید.
زبان فارسی و RTL را در Program Matrix نگه دارید
صفحهٔ فارسی ممکن است در DOM زبان اشتباه داشته باشد، بخش انگلیسی بدون زبان بماند، Focus order با چیدمان RTL ناسازگار شود، Bidi شناسه/عدد را مخدوش کند، Font در Zoom بشکند یا ترجمهٔ Label با Accessible Name متفاوت شود. اینها با بررسی نسخهٔ انگلیسی اثبات نمیشوند. معیارهای تخصصی در راهنمای ۷۶۱ میمانند؛ برنامه باید Locale، جهت، numeral set، content variant و AT voice را به Evidence متصل کند.
مشارکت افراد دارای معلولیت مکمل Conformance است
راهنمای WAI برای مشارکت کاربران در ارزیابی توصیه میکند ارزیابی با کاربران را با ارزیابی Conformance ترکیب کنیم. یک فرد نمایندهٔ همهٔ افراد با همان معلولیت نیست و مطالعهٔ چندنفره بهتنهایی انطباق WCAG یا دسترسپذیری برای همه را تعیین نمیکند. در مقابل، Conformance review نیز میتواند مشکلات کاربردپذیری واقعی را نبیند.
| فعالیت | پرسش | نمیتواند بهتنهایی ثابت کند |
|---|---|---|
| Expert conformance review | معیارها در Scope برآوردهاند؟ | سهولت تجربهٔ همهٔ کاربران |
| AT technical run | Contract فنی در ترکیب مشخص کار میکند؟ | تجربهٔ زیسته |
| User session | فرد هدف Task را چگونه انجام میدهد؟ | Conformance همهٔ معیارها |
| Support feedback | در Production چه مانعی گزارش شده؟ | نبود مانع گزارشنشده |
| Automated scan | Rules قابل خودکارسازی چه میگویند؟ | دسترسپذیری کل محصول |
«پرسونای معلولیت» جای مشارکت کاربر را نمیگیرد
Persona میتواند تیم را به نیازها یادآور شود، اما نباید کلیشه بسازد یا بهعنوان شاهد کاربر مصرف شود. Participant profile را بر Task، مهارت فناوری کمکی، تجربهٔ محصول، زبان، دستگاه و Context جذب کنید؛ Diagnosis پزشکی زائد جمع نکنید. نتیجهٔ هر فرد را با Scope و محدودیت گزارش کنید.
پژوهش و ضبط را از ارزیابی عملکرد کارکنان جدا کنید
رضایت آگاهانه، Scope ضبط، حق توقف، پاداش، دسترسپذیری خود جلسه، مترجم/همراه در صورت نیاز، حداقلگرایی داده، Masking، دسترسی و حذف را تعریف کنید. ویدئو یا اطلاعات معلولیت نباید برای ارزیابی شغلی یا هدف دیگری دوباره استفاده شود. نام شرکتکننده را برای Traceability به Finding فنی الصاق نکنید؛ Participant ID کنترلشده کافی است.
User Evaluation Evidence Contract study_id / purpose / product_build participant_segment (no unnecessary diagnosis) AT/device/browser proficiency and setup task / state / language / assistance observation / quote / outcome / barrier conformance_ref_if_reviewed_separately consent_scope / recording / masking access_roles / retention / deletion_date limitations / non-generalization statement
Finding را به Barrier، Requirement و Evidence وصل کنید
| فیلد | کاربرد |
|---|---|
| finding_id/build | هویت و نسخه |
| scope/page/state/component | محل قابل بازتولید |
| barrier/user impact | اثر عملی، نه فقط کد |
| requirement/rule ref | Test Basis و دامنهٔ ادعا |
| setup/procedure | Browser/AT/viewport/data |
| actual/expected | Oracle روشن |
| evidence | DOM، trace، media masked |
| severity/confidence | اولویت و عدم قطعیت |
| owner/due/retest | چرخهٔ اصلاح |
| duplicate/root cause | رفع سیستماتیک |
Severity را از Level معیار استخراج نکنید
سطح A/AA/AAA یک Severity ranking محصول نیست. یک مانع معیار A میتواند یک کار فرعی را محدود کند و مانع دیگری با پیامد عملیاتی شدید در Context خاص رخ دهد. اولویت اصلاح باید Blockage، Complete process، فراگیری، تکرار، Workaround، استقلال، Safety/Privacy/Financial consequence، تغییر و اطمینان Evidence را ببیند؛ بدون اینکه شکست معیار را بهدلیل Workaround نادیده بگیرد.
| کلاس عملیاتی | تعریف نمونه | Gate |
|---|---|---|
| P0 Blocker | Outcome بحرانی برای Segment هدف ناممکن/خطرناک | HOLD |
| P1 Major | استقلال شدیداً محدود یا Workaround نامطمئن | رفع پیش انتشار یا پذیرش صریح محدود |
| P2 Moderate | تلاش/ابهام قابل توجه با راه جایگزین | SLA نزدیک + retest |
| P3 Minor | اصطکاک محدود بدون انسداد | Backlog با مالک |
| Conformance failure | نقض معیار در Scope | جدا از Priority گزارش شود |
Root Cause را در چهار محل دنبال کنید
- Token/primitive: رنگ، spacing، focus ring یا semantic primitive؛
- Component: Dialog، Combobox، Grid یا Error Summary؛
- Composition/content: label، heading، DOM order یا استفادهٔ غلط Component؛
- Process/governance: Acceptance criteria، آموزش، CMS، Procurement یا نبود مالک.
رفع یک Selector بدون اصلاح Component و Regression test، همان مانع را در ده صفحه باقی میگذارد. در مقابل، تغییر Component shared باید مصرفکنندگان، overrideها و migration را نیز retest کند.
Remediation Contract و Definition of Done
Accessibility Remediation Contract finding_id / owner / target_release root_cause_layer / affected_instances design_decision / code_or_content_change component_migration / backwards_compatibility automated_regression_rule / manual_retest_cases AT_user_agent_retest_matrix user_retest_if_needed evidence_before / evidence_after known_limit / exception_ref / monitoring reviewers / closure_date
Done یعنی فقط Merge نیست: Expected result در Build هدف، در State و ترکیب لازم بازآزمایی شده؛ Regression مناسب اضافه شده؛ instanceهای مشترک بررسی شده؛ Documentation/Story/Content guidance بهروز است؛ و Evidence به Finding وصل شده است.
Exception و Waiver را زماندار و قابل افشا کنید
| فیلد استثنا | پرسش |
|---|---|
| scope/finding | دقیقاً چه مانعی؟ |
| reason | چرا اکنون رفع نشده؟ |
| user impact | چه کسی و چه Outcomeی؟ |
| temporary alternative | مسیر کمک واقعاً قابل دسترس است؟ |
| owner/approver | چه کسی پاسخگو و پذیرندهٔ ریسک است؟ |
| expiry | چه زمانی خودکار بازبینی/منقضی میشود؟ |
| fix milestone | برنامه و dependency چیست؟ |
| statement disclosure | کاربر محدودیت را کجا میبیند؟ |
| monitoring | گزارش و آسیب چگونه پیگیری میشود؟ |
استثنا محصول را مطابق نمیکند و Third party بهخودیخود مسئولیت تجربه را حذف نمیکند. شرایط Statement of Partial Conformance یا قانون مربوط باید توسط متخصص حوزه و بر اساس واقعیت Scope بررسی شود.
Procurement و Third-party را پیش از خرید Gate کنید
- نسخهٔ محصول و Scope ادعای فروشنده را بگیرید، نه فقط لوگو یا PDF قدیمی.
- Conformance report را با Task واقعی و نمونهٔ integration راستیآزمایی کنید.
- Known issue، roadmap، SLA، notification تغییر و حق retest را قرارداد کنید.
- Theme/embedding/SSO/configuration واقعی را در محیط خود بسنجید.
- خروج، جایگزین و مسیر Support قابل دسترس داشته باشید.
- تاریخ Evidence و تطابق آن با Build خریداریشده را ثبت کنید.
Conformance Claim، Evaluation Report و Accessibility Statement یکی نیستند
| Artifact | مخاطب/هدف | باید شفاف کند |
|---|---|---|
| Evaluation report | تیم/ممیز | Scope، روش، نمونه، نتایج، محدودیت |
| Conformance claim | ادعای رسمی اختیاری | تاریخ، WCAG نسخه/URI، سطح، صفحات، فناوریهای متکی |
| Accessibility statement | کاربر | تعهد، استاندارد، محدودیت، محیط آزموده، تماس |
| Release memo | تصمیمگیر | Evidence، gaps، exceptions، owner، decision |
| VPAT/ACR یا فرم قراردادی | خریدار/تدارکات | نسخه، محصول، معیار و توضیح پشتیبانی |
WCAG ۲.۲ میگوید Claim اختیاری است، اما اگر ساخته شود اجزای الزامی دارد. Claim برای صفحههای کامل و فرایندهای کامل باید شرایط مربوط را برآورده کند. «No automated violations» یا «Tested with screen reader» Claim انطباق نیست.
Accessibility Statement را برای کاربر بنویسید
راهنمای Accessibility Statement در WAI پیشنهاد میکند تعهد، استاندارد و کانال تماس دستکم روشن باشند و محدودیتهای شناختهشده، محیطهای آزموده و اقدامات نیز درج شوند. Statement ارزیابی فنی یا Declaration of Conformity نیست؛ باید با زبان قابل فهم بگوید کاربر در صورت مانع چه کند.
Accessibility Statement Content product/site/app name + version/date commitment and standard/policy applied scope covered and important exclusions known limitations in plain user language tested browsers/AT/environments with dates measures and review cadence accessible contact/feedback channels expected response time and escalation alternative access/help where available last reviewed / next review / statement owner link to evaluation background when appropriate
کانال بازخورد خود باید دسترسپذیر باشد
فرم گزارش مانع اگر Captcha غیرقابل عبور، تلفن اجباری، PDF نامناسب یا زمان پاسخ نامعلوم داشته باشد، برنامه را میشکند. چند کانال سازگار، اطلاعات کمینه، شماره پیگیری، SLA، مالک Triage، مسیر جایگزین برای Outcome فوری، Escalation و Closure confirmation تعریف کنید.
| فیلد Intake کمینه | اختیاری/حساس |
|---|---|
| صفحه/وظیفه و مانع | نوع معلولیت لازم نیست |
| زمان تقریبی و نسخه/دستگاه در حد نیاز | ضبط صفحه فقط با رضایت |
| راه تماس ترجیحی | نام واقعی اگر لازم نیست نگیرید |
| فوریت Outcome | اطلاعات سلامت/شناسه زائد ممنوع |
| اجازهٔ پیگیری | لاگ/DOM با Secret پاکسازی شود |
Release Gate را بر Evidence completeness بنا کنید
| Gate | شرط نمونه | شاهد |
|---|---|---|
| Policy | استاندارد/نسخه/سطح/Scope مصوب | Policy ID |
| Inventory/Sample | فرایند، Template، State، زبان و role نماینده | Sample rationale |
| Automation | Rule set نسخهدار؛ Regression تازه حلشده | CI artifact |
| Manual/AT | مسیرهای بحرانی با Matrix هدف اجرا شده | Run manifests |
| Complete process | هیچ گام یا State بحرانی جا نیفتاده | Process evidence map |
| Findings | Blocker باز نیست؛ بقیه مالک/SLA دارند | Register |
| Exceptions | معتبر، زماندار، افشاشده و قابل کمک | Waiver records |
| User evidence | در Scope لازم، مکمل Conformance و محدودشده | Study report |
| Feedback/Ops | کانال، مالک، SLA و alternative آماده | Dry run |
| Claim/Statement | با Evidence و محدودیت همخوان است | Review/sign-off |
آزمایش بازتولیدپذیر: Scanner PASS، Program HOLD
برای نشاندادن تفاوت، Fixture کاملاً ساختگی SYN-A11Y-PROGRAM-01 ساخته شد. اسکن PR برای شش Component، ۸۰ Rule execution عمداً تعریفشده و صفر violation ثبت میکند. Program Gate مستقل، دو Complete Process، چهار State، تازگی Evidence، استثنا و کانال بازخورد را میسنجد.
$ node .post-1823-experiment.js runtime: Node.js v24.18.0 fixture: SYN-A11Y-PROGRAM-01 build: SYN-A11Y-2026.08.13-rc1 prScanner.components = 6 prScanner.automatedChecks = 80 prScanner.violations = 0 prScanner.decision = PASS program findings: missing-process-step: purchase / receipt missing-required-state: timeout stale-at-evidence: age=59 days; other build expired-exception: SYN-WAIVER-7 / third-party-chat feedback-channel-without-owner-or-sla programGate.decision = HOLD
اعداد ۶ و ۸۰ پوشش معیارهای WCAG یا کیفیت ابزار را نشان نمیدهند؛ فقط ورودیهای ساختهشدهٔ Fixture هستند. HOLD نیز Claim انطباق واقعی نیست؛ نتیجهٔ پنج شرط قراردادی همین مدل است. آزمایش نشان میدهد حتی با صفر خروجی ابزار، Evidence program میتواند ناقص باشد.
حدود اعتبار آزمایش مصنوعی
- هیچ صفحه، DOM، معیار WCAG، ACT Rule یا ابزار واقعی اجرا نشده است.
- هیچ مرورگر، Screen Reader، کاربر، معلولیت، Device، PDF یا App بررسی نشده است.
- Rule count، سن شواهد، SLA و Expiry آستانهٔ صنعت یا پیشنهاد عمومی نیستند.
- صفر violation بهمعنای دسترسپذیری یا Conformance Fixture هم نیست.
- PASS/HOLD الگوریتم عمومی Release، ممیزی حقوقی یا گواهی نیست.
- تمام نامها، Buildها، Processها، Stateها و Exceptionها ساختگیاند.
آزمایشگاه فارسی کاملاً ساختگی
در محیط محلی بدون اینترنت، محصول خیالی SYN-PORTAL با Build ثابت، دادهٔ SYN-* و دو زبان fa/en بسازید. مسیر ثبت درخواست از Form تا Receipt، بازیابی حساب، PDF ساختگی و Email محلی را Seed کنید. هیچ نام، تماس، معلولیت، پرونده، حساب، پرداخت، رمز، Token، ضبط یا سرویس واقعی وارد نشود.
| Lab lane | Fault ساختگی | Evidence |
|---|---|---|
| CI | Rule registry version change | artifact diff |
| Complete process | Receipt خارج Sample | process map gap |
| RTL | mixed-language accessible name | DOM/AT trace |
| Keyboard | Focus پس از Error گم میشود | focus log |
| Zoom | Timeout state در ۲۰۰% پوشانده | state screenshot masked |
| Exception | Chat waiver منقضی | registry alert |
| Feedback | فرم گزارش بیمالک | ticket dry run |
| Statement | Build قدیمی و limitation حذفشده | statement/release diff |
این Lab برای تمرین Traceability است، نه شبیهسازی کاربر دارای معلولیت، ادعای WCAG، اثبات پشتیبانی فارسی یا نظر حقوقی در ایران.
Monitoring پس از انتشار: تغییر، Drift و Feedback
- اسکن دورهای با Rule set ثابت و ثبت تغییر نسخه؛
- بازآزمایی Template/Component بعد از Dependency یا Design token change؛
- نمونهگیری محتوای تازهٔ CMS، ترجمه، PDF و Media؛
- پایش Waiver expiry و Milestone اصلاح؛
- Triage بازخورد کاربر بر اساس Outcome و فوریت، نه تشخیص پزشکی؛
- بازبینی Accessibility Statement با Build و Known limits؛
- ارزیابی عمیق دورهای و پس از بازطراحی/تغییر مسیر بحرانی؛
- گزارش Trend بر barrier class، age، recurrence و closure—not score alone.
Metricها را برای تصمیم، نه Vanity Dashboard بسازید
| Metric | کاربرد | دام |
|---|---|---|
| Critical process evidence coverage | Gap مسیر/State | تبدیل به Conformance درصدی |
| New regression by barrier class | کیفیت تغییر | Count بدون پیامد |
| Median age by priority | توان اصلاح | پنهانشدن موارد قدیمی با میانگین |
| Recurrence/root-cause escape | اثر Design system/process | مقصرسازی فرد |
| Waiver age/expiry | کنترل ریسک پذیرفته | Waiver دائمی |
| Feedback response/closure | عملیات کاربرمحور | بستن Ticket بدون رفع Outcome |
| Evidence freshness | همخوانی با Release | روز ثابت بدون سنجش Change |
| Training-to-practice evidence | اثر قابلیت تیم | شمار شرکتکنندهٔ دوره |
Evidence Freshness را با Change Risk ترکیب کنید
شواهد قدیمی فقط بهدلیل سن نامعتبر نمیشوند و شواهد دیروز فقط بهدلیل تازگی معتبر نیستند. Build، Component version، rule set، content، dependency، browser/AT و مسیر باید مقایسه شوند. Policy میتواند حداکثر سن تعریف کند، اما تغییر پرریسک بازآزمایی زودتر میخواهد و بخش بدون تغییر شاید با Trace معتبر دوباره استفاده شود.
Accessibility Release Memo قابل کپی
Release / build / date / decision owner Policy ID / target standard-version-level / applicability ref Scope: products-hosts-languages-roles-processes-states-surfaces Inventory and sampling method / population / gaps Technologies relied upon / accessibility-support evidence Automation engine-rule-set + manual/AT/user evidence Complete-process evidence map Open findings by barrier impact and conformance outcome Exceptions: owner-expiry-alternative-disclosure Third-party and content limitations Feedback channel dry run / operations readiness Claim and statement consistency review Decision: PASS | CONDITIONAL | HOLD Risk acceptance / remediation / retest / monitoring / expiry
نقشها و حق تصمیم
| نقش | مسئولیت | حق تصمیم |
|---|---|---|
| Accessibility lead | Policy، روش، competency و interpretation | کفایت ارزیابی |
| Product/process owner | Outcome، Scope و priority | رفع/زمانبندی با محدودیت Gate |
| Design system | primitive/component contracts | نسخه و migration |
| Engineering/QA | implementation، automation، evidence، retest | کفایت فنی |
| Content/media | authoring و published artifacts | انتشار محتوا |
| Research/community | مشارکت کاربران و اخلاق مطالعه | اعتبار پژوهش |
| Privacy/security/legal/procurement | کنترل تخصصی و applicability | Gate حوزهٔ خود |
| Support/operations | feedback، alternative و SLA | آمادگی پاسخ |
| Release owner | جمع Evidence و Gap | PASS/Conditional/HOLD |
برنامهٔ Pilot سیروزه
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۴ | Policy، استاندارد/نسخه، Scope و مالک | Policy v1 |
| روز ۵–۸ | Inventory و Complete process map | Asset/Process registry |
| روز ۹–۱۲ | Sample و Test Matrix | Evaluation plan |
| روز ۱۳–۱۶ | Rule registry، CI و Component baseline | Machine artifacts |
| روز ۱۷–۲۰ | Manual/AT protocol و RC run | Run manifests |
| روز ۲۱–۲۳ | مشارکت کاربر در Scope و با رضایت | User evidence |
| روز ۲۴–۲۶ | Triage، root cause و اصلاح | Finding register |
| روز ۲۷–۲۸ | Retest، exception و feedback dry run | Closure/waiver evidence |
| روز ۲۹ | Statement و Claim review | User/claim artifacts |
| روز ۳۰ | Gate، Monitoring و retrospective | Release Memo + next cycle |
ضدالگوهای برنامه تست دسترسپذیری
- سبزنامیدن محصول بر اساس امتیاز Lighthouse یا یک ابزار؛
- تکرار درصد ثابت کشف خودکار بدون Test Basis؛
- نامیدن
inapplicableبهعنوان Pass؛ - تغییر Rule set بدون ثبت نسخه و Baseline؛
- اجرای فقط صفحهٔ Home و تعمیم به کل سایت؛
- حذف Error، timeout، auth و responsive states از نمونه؛
- نیمهکارهگذاشتن Complete process؛
- ادعای AA بدون Scope، تاریخ و فناوریهای متکی؛
- فرض اینکه AA هدف جهانی همهٔ محصولات است؛
- تلقی ACT Rule یا Technique بهعنوان کل معیار؛
- استفاده از WCAG-EM ۲ Draft بدون برچسب Draft؛
- تست Screen Reader و نامیدن آن شبیهسازی نابینایی؛
- تعمیم یک AT/browser به همهٔ ترکیبها؛
- استفاده از Persona بهجای مشارکت افراد؛
- تعمیم نظر یک شرکتکننده به همهٔ معلولیتها؛
- جایگزینی مطالعه کاربر با Conformance یا برعکس؛
- ثبت Diagnosis پزشکی غیرضروری؛
- ضبط نامحدود جلسه و استفادهٔ ثانویه؛
- Severity برابر با Level معیار؛
- رفع instance و رهاکردن Component/root cause؛
- Baseline debt بدون مالک و Milestone؛
- Waiver دائمی یا منقضی؛
- اعتماد به سند فروشنده برای نسخهٔ دیگری از Third party؛
- فراموشکردن CMS، PDF، Email، Media و ترجمه؛
- Accessibility Statement فنی و بدون راه تماس؛
- کانال بازخورد غیرقابل دسترس یا بیمالک؛
- Claim جدید با Evidence Build قدیمی؛
- Dashboard بر اساس Count/Score بدون Barrier impact؛
- انتشار بدون Coverage gap، Monitoring و Expiry؛
- سپردن همهٔ مسئولیت به یک قهرمان A11y.
چکلیست ساخت برنامه تست دسترسپذیری
- Policy ID، مالک و Approver داریم.
- استاندارد، نسخه، سطح و وضعیت منبع ثبت است.
- Applicability قانونی/قراردادی ارجاع دارد.
- Scope شامل Product، Host، Channel و Language است.
- Role و Variantهای UI ثبت شدهاند.
- Complete processها گراف دارند.
- Full page و responsive states حفظ میشوند.
- Third party و embedded origin در Inventory است.
- PDF، Email، Media و Mobile فراموش نشدهاند.
- Template، Component و Content type فهرست شدهاند.
- Error، empty، loading، timeout و success State دارند.
- Sample rationale و Population روشن است.
- Structured و random supplement در صورت روش لازم ثبتاند.
- Coverage gap آشکار است.
- Test Basis normative/informative تفکیک شده است.
- Test Case applicability و oracle دارد.
- ACT Rule ID/status/version ثبت است.
- Tool engine و Rule set hash نگهداری میشود.
- Pass/Fail/Inapplicable/CantTell جدا هستند.
- Manual remainder هر Rule معلوم است.
- CI لایهٔ authoring/component/PR/RC دارد.
- Baseline debt مالک و Milestone دارد.
- Manual protocol قابل تکرار است.
- AT run شامل OS/browser/AT/version/settings است.
- AT Matrix بر اساس کاربر و support است.
- Accessibility support برای Feature مورد اتکا شاهد دارد.
- Component evidence از composition evidence جداست.
- Content authoring و CMS کنترل دارند.
- فارسی/RTL/mixed language در Matrix است.
- مشارکت کاربر مکمل Conformance است.
- شرکتکننده نمایندهٔ همه فرض نمیشود.
- Consent، recording، access و deletion تعریف شدهاند.
- Finding اثر کاربر و requirement ref دارد.
- Severity از Level معیار جداست.
- Root cause سطح Token/Component/Composition/Process دارد.
- Definition of Done شامل Retest و migration است.
- Waiver مالک، alternative، disclosure و expiry دارد.
- Third-party evidence با Build واقعی منطبق است.
- Evaluation report، Claim، Statement و Memo جدا هستند.
- Claim اجزای الزامی WCAG را بازبینی میکند.
- Statement به زبان کاربر و دارای Known limits است.
- Feedback channel قابل دسترس و دارای SLA است.
- Gate بر Complete process و Evidence completeness است.
- Evidence freshness با Change risk سنجیده میشود.
- Production monitoring جای Human evaluation نیست.
- Metric بر Barrier، age، recurrence و closure است.
- Release Memo Gap، Exception و Expiry دارد.
- دقیقاً پنج FAQ و Meta پیش از انتشار کنترل شدهاند.
جمعبندی: دسترسپذیری یک Evidence loop است
برنامهٔ بالغ از ابزار یا ممیزی سالانه آغاز و تمام نمیشود. Policy و نسخهٔ معیار را به Scope و Complete Process وصل میکند، Inventory و Sample قابل دفاع میسازد، Automation را با Manual/AT/User evidence ترکیب میکند، Barrier را تا Root cause و Retest دنبال میکند، Exception را منقضی میکند و Statement/Feedback/Monitoring را برای کاربر زنده نگه میدارد. نتیجه نه وعدهٔ «برای همه بینقص»، بلکه تصمیمی محدود، شفاف و قابل بازبینی است.
سؤالات متداول برنامه تست دسترسپذیری
آیا صفرشدن خطاهای ابزار یعنی محصول با WCAG منطبق است؟
خیر. ابزار فقط Rules و Stateهایی را که اجرا شدهاند میسنجد؛ بخشی از معیارها به قضاوت انسانی، Context و فرایند کامل نیاز دارند. نتیجه باید Tool/Rule version، Applicability، Inapplicable/CantTell، Scope و Manual remainder را نشان دهد. Claim انطباق شرایط جداگانهٔ WCAG را میخواهد.
تفاوت WCAG ۲.۲، WCAG-EM و ACT Rules چیست؟
WCAG ۲.۲ معیارها و شرایط Conformance وب را تعریف میکند. WCAG-EM ۱.۰ یک روش ساختاریافتهٔ informative برای ارزیابی Conformance وبسایت است و الزام تازهای اضافه نمیکند. ACT Rules قواعد informative و فناوریمحور برای شفافتر و هماهنگترشدن آزمون برخی جنبهها هستند؛ هیچکدام را نباید بدون Scope و Status جای دیگری نشاند.
آیا تست با کاربران دارای معلولیت جای ممیزی WCAG را میگیرد؟
خیر. مشارکت کاربران موانع و تجربهٔ واقعی در Task/Context مشخص را آشکار میکند، اما چند فرد نمیتوانند Conformance همهٔ معیارها یا تجربهٔ همهٔ افراد را ثابت کنند. Expert conformance review نیز جای رفتار کاربر را نمیگیرد. برنامهٔ معتبر این دو را مکمل میداند و محدودیت نمونه را گزارش میکند.
برای هر Release چه تست دسترسپذیری لازم است؟
یک عدد ثابت وجود ندارد. Change impact، Complete process، Component، State، زبان، Third party و Policy تعیین میکنند چه لایهای لازم است. معمولاً lint/component/PR automation، تست دستی تغییرات و مسیرهای بحرانی، AT Matrix ریسکمحور و بازبینی دورهای عمیق ترکیب میشوند؛ Gapها باید در Release Memo ثبت شوند.
چه زمانی Release Gate باید HOLD بدهد؟
وقتی فرایند یا State بحرانی بدون شاهد مانده؛ Barrier مسدودکننده یا خطرناک باز است؛ Evidence با Build/Rule/AT هدف همخوان نیست؛ استثنا منقضی یا بیمالک است؛ مسیر کمک قابل دسترس نیست؛ یا Claim/Statement بیش از شواهد وعده میدهد. HOLD به Scope و Policy وابسته است و باید دلیل، مالک، اقدام و Retest داشته باشد.
