Accessible Multimedia Learning UX

وقتی «کپشن دارد» با «قابل‌دسترسی است» اشتباه گرفته می‌شود

یک درس چندرسانه‌ای را تصور کن: ویدئوی روایی، transcript تعاملی، کنترل پخش word-synced و یک slide deck. ظاهر همه‌چیز حرفه‌ای است و ویدئو هم caption دارد. اما caption صدای غیرگفتاری مهم را حذف کرده، بعد از seek کردن focus به جای نامعلومی می‌پرد، و یک diagram فقط به‌صورت بصری توضیح داده شده است. اگر QA فقط سؤال کند «کپشن روشن می‌شود؟»، سه barrier واقعی را از دست می‌دهد.

در این درس Accessible Multimedia Experience Audit Contract v1 را می‌سازیم؛ قراردادی که availability را از accessibility جدا می‌کند. هر تجربه باید media type، هدف محتوا، وضعیت caption/transcript/audio description/text alternative، مسیر keyboard و focus، contrast، resize/reflow، pause/stop، barrier، مرجع WCAG، severity، remediation owner و verification state روشن داشته باشد. قوی‌ترین حالت مثبت این درس release خودکار نیست؛ وقتی evidence کافی است، نتیجه MULTIMEDIA_ACCESS_REVIEW_REQUIRED است. اگر evidence حیاتی مفقود یا barrier بحرانی unresolved باشد، سیستم باید fail-closed بماند.

مسیر درس و مرز مالکیت

MKN-011 مالک Accessible Multimedia Learning UX است. MKN-007 پیش‌نیاز سخت و MKN-010 پیش‌نیاز نرم است. MKN-010 درباره TTS، Forced Alignment و Word Sync است؛ این درس کیفیت alignment یا speech generation را دوباره آموزش نمی‌دهد. MKN-012 درباره pipeline ساخت visual/slide است؛ این درس هم طراحی اسلاید را جذب نمی‌کند. موضوع ما تجربهٔ دسترسی به رسانه و کنترل‌های آن است.

سه مسیر یادگیری به یک evidence bar مشترک می‌رسند. در Foundation، field map و یک سناریوی حل‌شده داریم. در Repair، فقط evidence dimension شکسته را پیدا و همان gate را دوباره اجرا می‌کنیم. در Experienced، باید بتوانی بدون label آماده، severity و تصمیم bounded را از شواهد دفاع کنی.

Checkpointها: F1 مرز lesson + یک non-goal؛ F2 رد یک shortcut با evidence منفی؛ F3 recompute کامل برای تجربهٔ audio-first روی موبایل با hardware keyboard.

مدل ذهنی: inventory → access need → criterion/evidence → test → severity → repair/exception → verification

جریان اصلی این است:

content inventory → access needs → WCAG/evidence mapping → media + interaction tests → barrier severity → remediate or governed exception → independent verification → review/hold

این flow عمداً چند نوع evidence را مخلوط نمی‌کند. برای audio/video می‌پرسیم آیا معنی گفتاری و غیرگفتاری در caption/transcript یا alternative مناسب وجود دارد. برای visual information می‌پرسیم آیا اطلاعات لازم از راه description یا متن معادل منتقل می‌شود. برای interaction می‌پرسیم آیا keyboard path کامل، focus order قابل پیش‌بینی و seek/play/pause بدون trap است. برای presentation می‌پرسیم contrast و reflow در context هدف واقعاً آزموده شده‌اند یا فقط فرض شده‌اند.

هر UNKNOWN، BARRIER، HOLD یا REVIEW_REQUIRED یک state معتبر است. contract نباید evidence ناقص را به PASS تبدیل کند فقط چون محصول «تقریباً کار می‌کند».

قرارداد پایه: هفده بُعد شواهد

ابعاد اصلی contract عبارت‌اند از: experience_id، media_type، content_purpose، caption_state، transcript_state، audio_description_state، text_alternative_state، keyboard_path، focus_order_state، contrast_check، resize_reflow_state، pause_stop_control، error_or_barrier، wcag_ref، severity، remediation_owner و verification_state.

Invariantهای حداقلی:

1. نوع رسانه و purpose مشخص‌اند؛ معیار درست را از روی feature label حدس نمی‌زنیم.
2. برای synchronized media، caption باید speech و اطلاعات صوتی غیرگفتاری لازم برای فهم را پوشش دهد.
3. transcript جای همهٔ نیازهای synchronized media را خودکار نمی‌گیرد؛ نقش آن باید مشخص باشد.
4. visual information مهم باید text/description یا مسیر معادل قابل‌استفاده داشته باشد.
5. keyboard access فقط «قابل tab شدن» نیست؛ مسیر کامل و focus بعد از تغییر state باید بررسی شود.
6. contrast و reflow روی target context evidence می‌خواهند، نه screenshot review.
7. pause/stop/control برای motion یا media باید explicit باشد وقتی criterion مربوط است.
8. هر barrier severity دارد، اما severity mapping داخلی MAKNOW است نه متن WCAG.
9. هر remediation یا exception یک owner و verification state دارد.
10. changed context تصمیم قبلی را با خود حمل نمی‌کند؛ باید recompute شود.

توضیح عمیق: FACT، INFERENCE و DESIGN را جدا نگه دار

WCAG 2.2 — FACT. WCAG 2.2 معیارهای آزمون‌پذیر و technology-independent ارائه می‌کند و چهار اصل Perceivable، Operable، Understandable و Robust را مبنا می‌گیرد. در media، معیارهای time-based media شامل alternativeهای prerecorded audio/video، captions و audio description هستند. در interaction نیز keyboard access، focus order، contrast، resize/reflow و pause/stop نمونه‌هایی از معیارهای مرتبط‌اند.

W3C WAI multimedia guidance — FACT. WAI توضیح می‌دهد caption باید نسخهٔ متنی speech و non-speech audio لازم را منتقل کند؛ transcript نسخهٔ متنی اطلاعات صوتی است و description اطلاعات بصری لازم برای فهم را فراهم می‌کند. در presentation نیز توصیه می‌شود اطلاعات بصری مهم توصیف و material accessible ارائه شود.

Product interpretation — INFERENCE. از این facts نتیجه می‌گیریم که یک player با caption toggle به‌تنهایی evidence کافی برای تجربهٔ آموزشی نیست. لازم است رسانه، alternative، interaction state و presentation context جدا بررسی شوند.

MAKNOW release policy — DESIGN. اینکه barrier چه severityای دارد، چه چیزی release-blocking است، exception چه workflowی دارد و چه ownerی باید remediation را ببندد، authority داخلی پروژه است. استاندارد خارجی نباید به‌عنوان مجوز خودکار برای این تصمیم‌ها جا زده شود.

مثال‌های حل‌شده: baseline، shortcut اشتباه و transfer

Baseline. تجربه EXP-VID-01 یک narrated video + transcript + word-synced seek control دارد. caption گفتار را پوشش می‌دهد ولی [alarm sounds] که برای فهم سناریو لازم است حذف شده؛ بعد از seek، focus از transcript row فعال خارج می‌شود؛ diagram جمع‌بندی هم alternative ندارد. نتیجه HOLD_CRITICAL_ACCESS_BARRIERS است. وجود transcript نمی‌تواند caption ناقص، focus failure یا visual-only meaning را پاک کند.

Wrong approach. تیم فقط non-speech cue را حذف می‌کند تا caption «تمیزتر» شود. این تغییر caption_state را از COMPLETE_REVIEWED به INCOMPLETE_NON_SPEECH می‌برد و state باید HOLD_CAPTION_COMPLETENESS شود. shortcut دقیقاً چون ظاهراً کوچک است خطرناک است.

Transfer. همان lesson به audio-first experience روی screen باریک با 200% text و hardware keyboard تبدیل می‌شود. در این context ممکن است audio description برای visual اصلی NOT_APPLICABLE شود، اما transcript readability، focus order، reflow و کنترل‌های playback اهمیت بیشتری پیدا می‌کنند. baseline PASS یا HOLD oracle نیست؛ نتیجه باید از evidence جدید دوباره ساخته شود و در fixture سالم به MULTIMEDIA_ACCESS_REVIEW_REQUIRED برسد.

Failure Modeهایی که باید fail-closed شوند

این حالت‌ها نباید به release-ready تعبیر شوند:

• caption وجود دارد اما speech یا non-speech information لازم ناقص است؛
• transcript مفقود یا stale است در حالی که contract آن را evidence لازم می‌داند؛
• visual instructional فقط با رنگ/شکل یا تصویر منتقل شده و text alternative ندارد؛
• keyboard path بخشی از player را دور می‌زند یا trap ایجاد می‌کند؛
• focus بعد از seek، modal یا state change به محل نامعتبر می‌رود؛
• contrast یا reflow UNKNOWN است ولی تصمیم PASS صادر می‌شود؛
• pause/stop کنترل لازم وجود ندارد؛
• severity بالا ثبت شده ولی remediation owner خالی است؛
• exception ادعا می‌شود اما approval/owner/reason قابل‌ردیابی نیست؛
• transfer از desktop به mobile فقط status قبلی را copy می‌کند.

در این درس HOLD شکست سیستم نیست؛ نشان می‌دهد contract اجازه نداده uncertainty به success تبدیل شود.

گزینه‌ها و Trade-offها: caption، transcript، description و alternative presentation

Caption برای synchronized media ضروری است وقتی criterion مربوط می‌شود و timing/context را کنار تصویر نگه می‌دارد؛ اما transcript طولانی را مثل caption به زمان قفل نمی‌کند و برای جست‌وجو و مرور سریع بهتر است. Transcript برای متن‌خوانی و دسترسی asynchronous مفید است، ولی همیشه جای caption یا description را نمی‌گیرد. Audio description معنی بصری را به audio path می‌آورد، اما برای instructional video می‌توان گاهی از integrated description در narration اصلی استفاده کرد. Text alternative/long description برای diagram یا chart مفید است، ولی باید meaning آموزشی را منتقل کند نه صرفاً appearance را.

Trade-off واقعی فقط «هزینه تولید» نیست. timing، cognitive load، screen size، player support، ترجیح learner و maintenance هم مهم‌اند. contract باید دقیقاً بگوید کدام alternative برای کدام purpose استفاده شده و verification چگونه انجام شده است.

پل Experienced: accessibility را state machine ببین، نه checklist پایان کار

در implementation حرفه‌ای، هر media experience یک state machine کوچک است. caption_state و transcript_state می‌توانند versioned باشند؛ keyboard_path و focus_order_state باید بعد از interactionهای مهم دوباره سنجیده شوند؛ verification_state باید مشخص کند چه کسی و روی کدام revision evidence را دیده است. یک تغییر player، seek behavior یا viewport می‌تواند فقط یک dimension را drift کند، ولی همان dimension ممکن است release را block کند.

اتوماسیون می‌تواند presence، schema، بعضی contrast measurements، focus traversal logs یا caption track وجود/نسخه را check کند. اما تشخیص اینکه description واقعاً meaning diagram را منتقل می‌کند یا non-speech audio برای فهم لازم است، معمولاً human judgment می‌خواهد. پس system باید automation را جای reviewer جا نزند.

تمرین هدایت‌شده و مستقل

Guided. baseline fixture را اجرا کن و سه barrier را جدا نام‌گذاری کن. اول فقط caption non-speech cue را repair کن؛ دوباره gate را اجرا کن و ببین focus/alt failures هنوز باقی‌اند. سپس focus را اصلاح کن و در مرحلهٔ آخر text alternative را اضافه کن. هدف این است که یک تغییر مبهم با عنوان «fix accessibility» چند علت متفاوت را پنهان نکند.

Independent. یک fixture تازه برای podcast + transcript + chapter controls بساز. audio_description_state را فقط در صورتی NOT_APPLICABLE بگذار که visual channel وجود ندارد و rationale قابل‌مشاهده باشد. بعد یک mutation ایجاد کن که transcript را stale می‌کند یا owner را از یک barrier high-severity حذف می‌کند؛ gate باید success را پس بزند.

Experienced. برای یک player واقعی، پیشنهاد بده کدام eventها باید focus evidence تولید کنند: initial play، seek، transcript-row activation، captions menu، fullscreen exit و error recovery. سپس مشخص کن کدام بخش‌ها deterministic test و کدام بخش‌ها human verification می‌خواهند.

Verification Evidence: چه چیزی باید قابل بازتولید باشد؟

بسته باید بدون hidden reasoning نشان دهد که Bible hash ثابت مانده، هر دو locale همهٔ ۱۳ semantic role را دارند، جدول سه سناریو تمام ۱۷ dimension را پوشش می‌دهد، Lab با fixtureهای synthetic آفلاین deterministic است، negative cases stateهای typed تولید می‌کنند، claimهای بیرونی به source ID واقعی متصل‌اند و transfer بدون baseline oracle recompute می‌شود.

Machine validation اثبات کیفیت انسانی نیست، ولی drift ساختاری را می‌گیرد. human reviewer باید بتواند از روی fixture و ruleها همان state را بازتولید کند و بفهمد چرا یک barrier blocker است یا چرا یک case فقط REVIEW_REQUIRED مانده است.

ارزیابی و Transfer: از desktop video به audio-first mobile

ارزیابی چهار لایه دارد. Retrieval از تو می‌خواهد مرز MKN-011 را توضیح بدهی. Application می‌خواهد contract baseline را بسازی. Diagnosis mutation «حذف non-speech information از caption» را بررسی می‌کند. Transfer modality را تغییر می‌دهد.

در transfer، screen کوچک و 200% text می‌تواند reflow را decisive کند؛ hardware keyboard مسیر focus را پررنگ‌تر می‌کند؛ audio-first شدن ممکن است بعضی visual requirements را تغییر دهد اما transcript و control semantics را حذف نمی‌کند. اگر فقط result desktop را کپی کنی، state HOLD_BASELINE_ORACLE_REUSE است.

قبولی یعنی بتوانی بگویی کدام evidence به‌دلیل تغییر context عوض شد و چرا تصمیم باید دوباره ساخته شود.

منابع، تازگی و مرز authority

منابع اصلی بیرونی این درس WCAG 2.2، W3C WAI Accessible Presentations و WAI Making Audio and Video Media Accessible هستند. در بازبینی 2026-09-13، WCAG 2.2 همچنان W3C Recommendation است و success criteria آزمون‌پذیر و technology-independent دارد؛ WAI نیز caption را شامل speech و non-speech audio لازم، transcript را نسخهٔ متنی اطلاعات صوتی، و description را راه انتقال اطلاعات بصری لازم معرفی می‌کند.

این منابع FACT boundary را می‌دهند. severity، remediation ownership، exception workflow و release state همچنان MAKNOW DESIGN authority هستند. اگر semantics منبع یا target platform materially تغییر کند، freshness review باید نسخهٔ جدید بسازد؛ Golden پذیرفته‌شده درجا mutate نمی‌شود.