ARIA و HTML

اکثر توسعه‌دهندگان با زبان نشانه‌گذاری استاندارد وب مدرن، یعنی زبان نشانه‌گذاری ابرمتن (HTML)، آشنا هستند. با این حال، ممکن است کمتر با برنامه‌های غنی اینترنتی قابل دسترس (ARIA) (که قبلاً WAI-ARIA نامیده می‌شد) آشنا باشید: اینکه چیست، چگونه استفاده می‌شود و چه زمانی - و چه زمانی - نباید از آن استفاده کرد.

HTML و ARIA نقش مهمی در دسترسی‌پذیر کردن محصولات دیجیتال دارند، به خصوص در مورد فناوری‌های کمکی (AT) مانند صفحه‌خوان‌ها. هر دو برای تبدیل محتوا به فرمت‌های جایگزین مانند بریل یا متن به گفتار (TTS) استفاده می‌شوند.

تاریخچه مختصری از ARIA، دلیل اهمیت آن و بهترین زمان و نحوه استفاده از آن را مرور کنید.

مقدمه‌ای بر آریا

ARIA اولین بار در سال ۲۰۰۸ توسط گروه ابتکار دسترسی به وب (WAI) توسعه داده شد - زیرمجموعه‌ای از کنسرسیوم جهانی وب (W3C) که اینترنت را اداره و تنظیم می‌کند.

ARIA یک زبان برنامه‌نویسی واقعی نیست، بلکه مجموعه‌ای از ویژگی‌هایی است که می‌توانید به عناصر HTML اضافه کنید تا قابلیت دسترسی آنها را افزایش دهید. این ویژگی‌ها با استفاده از APIهای دسترسی موجود در مرورگرهای مدرن، نقش، وضعیت و ویژگی را به فناوری‌های کمکی منتقل می‌کنند. این ارتباط از طریق درخت دسترسی اتفاق می‌افتد.

« WAI-ARIA ، مجموعه برنامه‌های کاربردی غنی و قابل دسترس اینترنتی، روشی را برای دسترسی بیشتر افراد دارای معلولیت به محتوای وب و برنامه‌های کاربردی وب تعریف می‌کند. این مجموعه به ویژه به محتوای پویا و کنترل‌های رابط کاربری پیشرفته توسعه‌یافته با HTML، جاوا اسکریپت و فناوری‌های مرتبط کمک می‌کند.»

گروه WAI

درخت دسترسی

ARIA کد نادرست یا ناقص را اصلاح می‌کند تا با تغییر، نمایش و افزایش بخش‌هایی از درخت دسترسی، تجربه بهتری را برای کاربران AT ایجاد کند.

درخت دسترسی توسط مرورگر و بر اساس درخت استاندارد مدل شیء سند (DOM) ایجاد می‌شود. مانند درخت DOM، درخت دسترسی شامل اشیاء نشان دهنده تمام عناصر نشانه گذاری، ویژگی‌ها و گره‌های متنی است. درخت دسترسی همچنین توسط APIهای دسترسی خاص پلتفرم برای ارائه نمایشی که فناوری‌های کمکی می‌توانند آن را درک کنند، استفاده می‌شود.

ARIA به خودی خود عملکرد یا ظاهر بصری یک عنصر را تغییر نمی‌دهد. این بدان معناست که فقط کاربران AT متوجه تفاوت‌های بین یک محصول دیجیتال دارای ARIA و یک محصول بدون آن می‌شوند. همچنین این بدان معناست که فقط توسعه‌دهندگان مسئول ایجاد کد مناسب و تغییرات سبک‌دهی برای دسترسی هرچه بیشتر به یک عنصر هستند.

سه ویژگی اصلی ARIA عبارتند از نقش‌ها، ویژگی‌ها و حالت‌ها/مقدارها.

نقش‌ها تعریف می‌کنند که یک عنصر در صفحه یا برنامه چیست یا چه کاری انجام می‌دهد.

<div role="button">Self-destruct</div>

ویژگی‌ها (properties) ویژگی‌ها یا روابط با یک شیء را بیان می‌کنند.

<div role="button" aria-describedby="more-info">Self-destruct</div>

<div id="more-info">This page will self-destruct in 10 seconds.</div>

حالت‌ها و مقادیر ، شرایط فعلی یا مقادیر داده مرتبط با عنصر را تعریف می‌کنند.

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>

<div id="more-info">
  This page will self-destruct in 10 seconds.
</div>

اگرچه می‌توان از هر سه عنصر ARIA در یک خط کد استفاده کرد، اما این کار الزامی نیست. در عوض، نقش‌ها، ویژگی‌ها، حالت‌ها یا مقادیر ARIA را تا زمانی که به هدف نهایی دسترسی‌پذیری خود برسید، لایه‌بندی کنید. گنجاندن صحیح ARIA در پایگاه کد شما تضمین می‌کند که کاربران AT تمام اطلاعات مورد نیاز خود را برای استفاده موفقیت‌آمیز و عادلانه از وب‌سایت، برنامه یا سایر محصولات دیجیتال شما خواهند داشت.

اخیراً، Chrome DevTools روشی برای مشاهده‌ی کل درخت دسترسی ایجاد کرده است که درک تأثیر کد بر دسترسی را برای توسعه‌دهندگان آسان‌تر می‌کند.

چه زمانی از ARIA استفاده کنیم

در سال ۲۰۱۴، W3C رسماً توصیه‌نامه HTML5 را منتشر کرد. با این انتشار، تغییرات بزرگی از جمله اضافه شدن عناصر راهنما مانند <main> ، <header> ، <footer> ، <aside> ، <nav> و ویژگی‌هایی مانند hidden و required ایجاد شد. با این عناصر و ویژگی‌های جدید HTML5، همراه با افزایش پشتیبانی مرورگرها، بخش‌های خاصی از ARIA اکنون اهمیت کمتری دارند.

وقتی مرورگر از یک تگ HTML با نقش ضمنی با معادل ARIA پشتیبانی می‌کند، معمولاً نیازی به اضافه کردن ARIA به عنصر نیست. با این حال، ARIA هنوز شامل نقش‌ها، حالت‌ها و ویژگی‌های بسیاری است که در هیچ نسخه‌ای از HTML در دسترس نیستند. این ویژگی‌ها فعلاً مفید باقی می‌مانند.

این ما را به سوال نهایی می‌رساند: چه زمانی باید از ARIA استفاده کنید؟ خوشبختانه گروه WAI پنج قانون ARIA را تدوین کرده است تا به شما در تصمیم‌گیری در مورد نحوه‌ی دسترسی‌پذیری عناصر کمک کند.

قانون ۱: از ARIA استفاده نکنید

بله، درست خواندید. اضافه کردن ARIA به یک عنصر ذاتاً آن را قابل دسترس‌تر نمی‌کند. گزارش سالانه‌ی دسترسی‌پذیری WebAIM Million نشان داد که صفحات اصلی دارای ARIA به طور متوسط ​​۷۰٪ خطاهای شناسایی‌شده‌ی بیشتری نسبت به صفحات بدون ARIA دارند، که عمدتاً به دلیل پیاده‌سازی نادرست ویژگی‌های ARIA است.

استثناهایی برای این قانون وجود دارد. ARIA زمانی مورد نیاز است که یک عنصر HTML از قابلیت دسترسی پشتیبانی نمی‌کند. این می‌تواند به این دلیل باشد که طراحی اجازه دسترسی به یک عنصر HTML خاص را نمی‌دهد یا ویژگی یا رفتار مورد نظر در HTML موجود نیست. با این حال، این موقعیت‌ها باید نادر باشند.

<a role="button">Submit</a>

<button>Submit</button>

وقتی شک دارید، از عناصر HTML معنایی استفاده کنید.

قانون ۲: ARIA (غیرضروری) را به HTML اضافه نکنید

در بیشتر موارد، عناصر HTML به خوبی کار می‌کنند و نیازی به اضافه کردن ARIA اضافی به آنها نیست. در واقع، توسعه‌دهندگانی که از ARIA استفاده می‌کنند، اغلب مجبورند کد اضافی اضافه کنند تا عناصر را در مورد عناصر تعاملی، کاربردی کنند.

<h2 role="tab">Heading tab</h2>

<div role="tab"><h2>Heading tab</h2></div>

وقتی از عناصر HTML به شکلی که در نظر گرفته شده استفاده می‌کنید، کار کمتری انجام می‌دهید و کدی با عملکرد بهتر خواهید داشت.

قانون ۳: همیشه از ناوبری کیبورد پشتیبانی کنید

تمام کنترل‌های ARIA تعاملی (غیرفعال نشده) باید با کیبورد قابل دسترسی باشند. می‌توانید tabindex="0" را به هر عنصری که نیاز به فوکوس دارد و معمولاً فوکوس کیبورد را دریافت نمی‌کند، اضافه کنید. تا حد امکان از استفاده از شاخص‌های تب با اعداد صحیح مثبت خودداری کنید تا از مشکلات احتمالی ترتیب فوکوس کیبورد جلوگیری شود.

<span role="button" tabindex="1">Submit</span>

<span role="button" tabindex="0">Submit</span>

قانون ۴: عناصر قابل فوکوس را پنهان نکنید

به عناصری که نیاز به فوکوس دارند - از جمله عناصری با tabindex= "0" role= "presentation" یا aria-hidden= "true" اضافه نکنید. وقتی این نقش‌ها و حالت‌ها را به عناصر اضافه می‌کنید، پیامی به AT ارسال می‌شود که این عناصر مهم نیستند و باید از آنها صرف نظر کرد. این می‌تواند منجر به سردرگمی یا اختلال در تلاش کاربران برای تعامل با یک عنصر شود.

<div aria-hidden="true">
  <button>Submit</button>
</div>

<div>
  <button>Submit</button>
</div>

قانون ۵: از نام‌های قابل دسترس برای عناصر تعاملی استفاده کنید

هدف از یک عنصر تعاملی باید قبل از اینکه کاربر بداند چگونه با آن تعامل داشته باشد، به او منتقل شود. اطمینان حاصل کنید که همه عناصر دارای نامی قابل دسترس برای افرادی هستند که از دستگاه‌های AT استفاده می‌کنند.

نام‌های قابل دسترس می‌توانند محتوایی باشند که توسط یک عنصر (در مورد <a> )، متن جایگزین یا یک برچسب احاطه شده‌اند.

برای هر یک از نمونه کدهای زیر، نام قابل دسترسی «چکمه‌های چرمی قرمز» است.

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>

<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>

<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

روش‌های زیادی برای بررسی نام قابل دسترس یک عنصر وجود دارد، از جمله بررسی درخت دسترسی با استفاده از Chrome DevTools یا آزمایش آن با یک صفحه‌خوان.

آریا در HTML

اگرچه استفاده از عناصر HTML به تنهایی بهترین روش است، عناصر ARIA را می‌توان در موقعیت‌های خاص اضافه کرد. به عنوان مثال، می‌توانید ARIA را با HTML در الگوهایی جفت کنید که به دلیل محدودیت‌های محیطی به سطح بالاتری از پشتیبانی AT نیاز دارند یا به عنوان یک روش جایگزین برای عناصر HTML که به طور کامل توسط همه مرورگرها پشتیبانی نمی‌شوند.

البته، توصیه‌هایی برای پیاده‌سازی ARIA در HTML وجود دارد. از همه مهم‌تر: نقش‌های پیش‌فرض HTML را نادیده نگیرید، افزونگی را کاهش دهید و از عوارض جانبی ناخواسته آگاه باشید.

به چند نمونه نگاهی بیندازید.

<a role="heading">Read more</a>

<a aria-label="Read more about some awesome article title">Read More</a>

<ul role="list">...</ul>

<ul>...</ul>

<details>
  <summary role="button">more information</summary>
  ...
</details>

<details>
  <summary>more information</summary>
  ...
</details>

پیچیدگی‌های ARIA

ARIA پیچیده است و هنگام استفاده از آن باید همیشه احتیاط کنید. در حالی که مثال‌های کد در این درس نسبتاً ساده هستند، ایجاد الگوهای سفارشی قابل دسترس می‌تواند به سرعت پیچیده شود.

نکات زیادی وجود دارد که باید به آنها توجه شود، از جمله اما نه محدود به: تعاملات صفحه کلید، رابط‌های لمسی، پشتیبانی AT/مرورگر، نیازهای ترجمه، محدودیت‌های محیطی، کد قدیمی و ترجیحات کاربر. کمی دانش کدنویسی در صورت استفاده نادرست می‌تواند مضر - یا صرفاً آزاردهنده - باشد.

گذشته از این هشدارها، دسترسی دیجیتال یک وضعیت همه یا هیچ نیست - این طیفی است که برخی از مناطق خاکستری مانند این را ممکن می‌سازد. بسته به شرایط، می‌توان چندین راه‌حل کدنویسی را "صحیح" دانست. آنچه مهم است این است که شما به یادگیری، آزمایش و تلاش برای بازتر کردن دنیای دیجیتال خود برای همه ادامه دهید.