HTML Semantic و Accessible Structure

ممکن است صفحه کاملاً درست دیده شود ولی structure اشتباه داشته باشد

یک checkout page شیک را تصور کنید. title فقط یک <div> بزرگ و bold است. navigation از generic containerهای clickable ساخته شده. متن label از نظر بصری کنار input قرار دارد اما association برنامه‌پذیر ندارد. payment optionها با فاصله و رنگ group شده‌اند ولی DOM این relationship را بیان نمی‌کند. کاربر sighted با mouse شاید بدون مشکل کار کند، اما structure برای screen reader، user stylesheet یا حالت بدون CSS قابل اتکا نیست.

این درس Semantic Structure & Accessibility Evidence Record v1 و یک local executable lab می‌سازد. قرارداد محدود است: وقتی native semantic HTML معنی را درست بیان می‌کند از آن استفاده کنید، relationshipها را programmatically determinable نگه دارید و structure را مستقل از ظاهر verify کنید.

HTML مالک structure است؛ ظاهر CSS proof ساختاری نیست

hard prerequisite یعنی WEBF-002 را فقط با یک rule حمل کنید: CSS می‌تواند generic element را شبیه heading، landmark، label یا button نشان دهد، اما appearance semantics برنامه‌پذیر element را تغییر نمی‌دهد.

این درس ادعا نمی‌کند semantic HTML به‌تنهایی WCAG conformance را تضمین می‌کند. تمام ARIA patternها، رفتار همه screen readerها یا همه accessibility criterionها هم در scope نیستند. مالکیت این صفحه semantic structure، name/relationship و evidence یک feature محدود است.

زنجیره reasoning: visual intent → DOM semantics → relationship → evidence

WCAG 2.2 Success Criterion 1.3.1 می‌خواهد information، structure و relationshipهایی که از presentation فهمیده می‌شوند به‌صورت programmatic قابل تشخیص باشند یا در text در دسترس قرار گیرند. [S-WCAG-131]

پس این زنجیره را دنبال کنید:

1. Visual intent: design چه رابطه‌ای را به کاربر نشان می‌دهد؟
2. DOM semantics: کدام native element یا ARIA role توجیه‌شده همان relationship را بیان می‌کند؟
3. Accessible relationship/name: control، group، landmark، heading، table یا figure چگونه identity برنامه‌پذیر می‌گیرد؟
4. Verification evidence: DOM inspection، accessibility-tree observation، deterministic check یا assistive-technology test چه چیزی را نشان می‌دهد؟

این chain از «ظاهرش درست است» قوی‌تر است و جلوی خطای مخالف را هم می‌گیرد: اضافه کردن role به همه‌چیز الزاماً accessibility را بهتر نمی‌کند.

هرجا native semantics مناسب است از همان شروع کنید

heading را برای document hierarchy استفاده کنید، نه font size. <nav> برای navigation region، <main> برای primary content، <article> برای content مستقل در جایی که آن معنا وجود دارد و <form> برای form است. action را با native <button> بسازید نه generic clickable container. visible <label> را با control مرتبط کنید. وقتی چند control یک group مفهومی هستند، <fieldset> و <legend> relationship بومی و قابل‌فهمی می‌دهند.

ARIA Authoring Practices در guidance مربوط به accessible name، استفاده از native HTML naming technique مثل <label> را در صورت امکان ترجیح می‌دهد. landmark guidance نیز mapping elementهایی مثل <nav> و <main> را نشان می‌دهد. [S-WAI-APG-PRACTICES]

Native semantics testing را حذف نمی‌کند؛ فقط semantic behavior کمتری را مجبور می‌شوید دستی بازسازی کنید.

Semantic structure collection تگ‌ها نیست؛ مدل relationship است

heading hierarchy سازمان content را بیان می‌کند. design می‌تواند با CSS یک <h2> را از <h1> بزرگ‌تر نشان دهد، اما styling نباید hierarchy را تعیین کند. برعکس، استفاده از heading فقط برای bold text structure جعلی می‌سازد.

landmark باید region معنادار را مشخص کند. تعداد بیشتر همیشه بهتر نیست. regionهای تکراری یا بدون label مناسب navigation را noisy می‌کنند. <nav> خودش navigation semantics دارد؛ افزودن role="navigation" معمولاً redundant است و معنای جدیدی اضافه نمی‌کند.

Form relationship باید بیرون از visual proximity هم باقی بماند. placeholder جای persistent label قابل‌اتکا نیست. radio/checkboxهای مرتبط غالباً group name می‌خواهند و <fieldset> + <legend> این association را native ارائه می‌دهد.

ARIA زمانی ارزش دارد که HTML native نتواند semantic یا interaction موردنیاز را بیان کند. ARIA decoration نیست و نباید بدون دلیل جای semantic درست native را بگیرد.

مثال حل‌شده: article، topic navigation و feedback form

یک article page div-heavy داریم: top row لینک topicها را نگه می‌دارد، article title generic container بزرگ است و email field فقط متن کناری دارد بدون <label> association.

Repair محدود:

• topic linkها داخل <nav aria-label="Article topics">؛
• primary content داخل <main> و خود article داخل <article>؛
• title واقعی <h1> و subsectionها <h2> طبق hierarchy؛
• feedback submission داخل <form>؛
• <label for="feedback-email">Email</label> متصل به <input id="feedback-email">؛
• submit action یک native <button>.

بعد DOM را بدون تکیه به CSS inspect کنید. با حذف stylesheet هم structure باید قابل توضیح بماند.

Mutation probe اعتماد کاذب را آشکار می‌کند

Mutation A — heading واقعی با generic container styled جایگزین شود. appearance تقریباً همان می‌ماند ولی programmatic heading از hierarchy حذف می‌شود.

Mutation B — label relationship حذف شود. متن هنوز کنار field دیده می‌شود اما input ممکن است intended accessible name را از دست بدهد.

Mutation C — landmark roleهای redundant همه‌جا اضافه شوند. role تکراری روی native landmark یا تبدیل هر panel به landmark می‌تواند structure غیرضروری یا مبهم بسازد.

Lab این‌ها را failure deliberate می‌بیند. checker باید خرابی را detect کند و repair باید بدون redesign بی‌ربط CSS/JavaScript evidence را برگرداند.

برای برنامه‌نویس باتجربه: rendered DOM را inspect کنید، نه اسم component را

componentای با نام Heading، NavBar یا Field تضمین نمی‌کند HTML output همان semantics را داشته باشد. design-system wrapper ممکن است همه‌چیز را generic container render کند. SSR هم می‌تواند markup زیبایی بسازد که label/hierarchy ضعیف دارد. پس component abstraction باید در DOM boundary output contract داشته باشد.

در review، rendered element، implicit/explicit role، accessible name، relationship، heading level و label landmarkهای تکراری را بررسی کنید. component source evidence مفیدی است، اما contract واقعی assistive technology همان DOM کاربر است.

Native element، ARIA retrofit یا generic container؟

وقتی native element معنای content/interaction را درست بیان می‌کند همان را انتخاب کنید. وقتی semantic یا interaction pattern لازم با HTML native کافی نیست، ARIA را با behavior contract کامل آن به کار ببرید. اگر هیچ semantic relationship خاصی وجود ندارد generic container مناسب است.

semantic tag را فقط برای بالا بردن lint score استفاده نکنید. <section> بدون purpose معنادار همیشه بهتر از <div> نیست. heading level باید hierarchy را دنبال کند، نه font size. semantics مدل meaning است.

Executable Lab: fixture div-heavy را repair کنید

WEB009-LAB1 را اجرا کنید. starter عمداً از نظر بصری قابل قبول و از نظر structure ضعیف است. وظیفه repair article + navigation + form است بدون تغییر غیرضروری visual contract.

learner-visible checker requirementهای public را بررسی می‌کند: primary/main structure، heading hierarchy، navigation region معنادار، explicit form label، group relationship و native action control. بعد mutationهای deliberate را اجرا کنید و نشان دهید حداقل یک broken heading/label/landmark condition detect می‌شود. در changed-context fixture همان reasoning را منتقل کنید، نه اینکه فقط tagها را copy کنید.

implementation evidence، observed DOM behavior، mutation result، repair result، transfer result و یک residual limitation را در Semantic Structure & Accessibility Evidence Record v1 ثبت کنید.

Evidence باید از style change جان سالم ببرد

screenshot پاس‌شده proof programmatic structure نیست. چند evidence dimension لازم است:

• implementation artifact: HTML واقعی شما؛
• observable DOM/browser behavior: element، role، label، relationship و hierarchy؛
• failure mutation: نسخه deliberate broken که checker آن را detect کند؛
• repair result: نسخه اصلاح‌شده checkهای محدود را پاس کند؛
• changed-context transfer: page متفاوت همان principleهای semantic را حفظ کند؛
• residual limitation: مثلاً این lab complete WCAG conformance یا behavior همه AT/browserها را ثابت نمی‌کند.

یک automated tool به‌تنهایی مجوز ادعای full accessibility نیست؛ فقط یکی از evidence sourceهاست.

Transfer مستقل: checkout را بدون تکیه به styling repair کنید

transfer به checkout visually polished برمی‌گردد که عمدتاً generic container دارد، fieldها فقط با visible text شناخته می‌شوند و heading style از document structure جداست. Evidence Record را برای repair کامل کنید. native element، name/group relationship و landmark boundary را justify کنید. یک deliberate mutation و evidence تشخیص آن را ثبت کنید و حداقل یک accessibility claim را بنویسید که از این exercise به‌تنهایی نمی‌توان نتیجه گرفت.

مرز standard و guidance

WCAG 2.2 SC 1.3.1 outcome normative مربوط به information/structure/relationshipهای programmatically determinable را می‌دهد. Understanding guidance intent و exampleهای structure را توضیح می‌دهد. ARIA APG current practice برای landmark و accessible name را می‌دهد و در صورت امکان native HTML naming technique را ترجیح می‌دهد. این sourceها ادعا نمی‌کنند semantic HTML به‌تنهایی WCAG conformance را تضمین می‌کند، landmark/heading بیشتر همیشه بهتر است یا ARIA باید جای native HTML درست را بگیرد.