آریا: سم یا پادزهر؟

آرون لونتال
Aaron Leventhal

ARIA به نویسندگان وب اجازه می دهد واقعیتی جایگزین ایجاد کنند که فقط توسط صفحه خوان ها دیده می شود.

گاهی اوقات لازم است در مورد آنچه در محتوای وب اتفاق می‌افتد، حقیقت یا حتی «دروغ» کامل را برای خوانندگان صفحه نمایش توضیح دهیم. به عنوان مثال، "تمرکز واقعاً اینجاست!" یا "این واقعا یک نوار لغزنده است!". مانند این است که یادداشت های چسبناک جادویی را در بالای ابزارها و ویجت های روی میز کار خود اضافه کنید. این یادداشت‌های چسبناک جادویی باعث می‌شود که همه آنچه روی آن نوشته شده را باور کنند.

هنگامی که یک یادداشت جادویی وجود دارد، یا بر باور ما در مورد اینکه هر ابزار چیست یا انجام می دهد، غلبه می کند. به عنوان مثال، اگر ARIA را اضافه کنید که بیان می کند "این چیزی که اینجاست یک تفنگ چسب است!". حتی اگر یک جعبه آبی خالی نشسته است، یادداشت چسبناک جادویی به ما می گوید که این یک تفنگ چسب است. همچنین می توانیم اضافه کنیم، "و 30٪ پر است!". صفحه خوان اکنون گزارش می دهد که یک تفنگ چسب کامل 30٪ وجود دارد.

معادل وب این است که یک div ساده با یک تصویر در داخل آن بگیرید و از ARIA برای گفتن اینکه یک نوار لغزنده با مقدار 30 از 100 div استفاده کنید. فقط به صفحه خوان می گوید که یکی است.

ARIA بر ظاهر یک صفحه وب یا رفتار کاربر ماوس یا صفحه کلید تأثیر نمی گذارد. فقط کاربران فناوری های کمکی متوجه تاثیر ARIA می شوند. توسعه دهندگان وب می توانند هر گونه ARIA دلخواه را بدون تأثیرگذاری بر کاربرانی که از فناوری کمکی استفاده نمی کنند اضافه کنند.

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

ARIA چگونه کار می کند؟

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

در اینجا برخی از کاربردهای رایج ARIA آورده شده است.

  • اجزای خاصی را اضافه کنید که در HTML وجود ندارند، مانند تکمیل خودکار، درخت یا صفحه گسترده.
  • اجزایی را اضافه کنید که در HTML وجود دارد، اما نویسنده تصمیم گرفت آنها را دوباره اختراع کند، احتمالاً به این دلیل که می خواستند رفتار یا ظاهر عنصر استاندارد را تغییر دهند. به عنوان مثال، یک عنصر HTML <input type="range"> اساساً یک نوار لغزنده است، اما نویسندگان می‌خواهند آن را متفاوت جلوه دهند.
    • در بیشتر موارد، این می تواند با CSS حل شود. با این حال، برای range ، CSS ناخوشایند است. نویسندگان می توانند نوار لغزنده خود را بسازند و role="slider" با aria-valuenow استفاده کنند تا به صفحه کلید بگویند مقدار فعلی چقدر است.
  • شامل مناطق زنده برای اطلاع رسانی به خوانندگان صفحه در مورد تغییرات مرتبط در یک منطقه از صفحه.
  • نشانه‌هایی مانند سرفصل‌ها ایجاد کنید. نشانه‌ها به کاربران صفحه‌خوان کمک می‌کنند آنچه را که می‌خواهند سریع‌تر پیدا کنند. نشانه‌ها می‌توانند شامل کل منطقه مرتبط باشند. به عنوان مثال، "این کانتینر منطقه اصلی صفحه است" و "این کانتینر اینجا یک پانل ناوبری است".

چرا آریا؟

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

فرض کنید فروشگاه اینترنتی محلی تمام ویجت های مورد نیاز ما را نمی فروشد. اما، ما مک گیور هستیم. ما فقط می توانیم ویجت های خود را از ویجت های دیگر اختراع کنیم! این بسیار شبیه به یک نویسنده وب است که نیاز به ایجاد نوار منو دارد.

در حالی که عنصر <nav> وجود دارد، نوارهای منو اغلب با استفاده از div، تصاویر، دکمه‌ها، کنترل‌کننده‌های کلیک، دستگیره‌های فشار کلید و ARIA با هم ترکیب می‌شوند.

پشتیبانی از کاربران ماوس

بیایید با هم یک نوار منو درست کنیم. ما دسته ای از آیتم ها را در عناصر جعبه عمومی به نام div نشان می دهیم. هر زمان که کاربر ما روی یک div کلیک می کند، دستور مربوطه را اجرا می کند. جالب است، برای افرادی که ماوس کلیک می کنند کار می کند!

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

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

همه اینها تقریباً غیرقابل دسترس است، همانطور که برای بسیاری از چیزهای وب معمول است.

صفحه کلید نوار منو ما را در دسترس قرار دهید

بیایید دسترسی به صفحه کلید را اضافه کنیم. این فقط به تغییرات HTML نیاز دارد و نه ARIA. به یاد داشته باشید که ARIA بر جنبه های اصلی مانند ظاهر، ماوس یا صفحه کلید برای کاربران بدون فناوری های کمکی تأثیری نمی گذارد.

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

  • اگر کاربر یک کلید پیکان را فشار می‌دهد، بیایید به نقشه‌های نوار منوی داخلی خود نگاه کنیم و تصمیم بگیریم که آیتم جدید فعال منو چه باشد. ما تمام نقاط برجسته فعلی را پاک می کنیم و آیتم منوی جدید را برجسته می کنیم تا کاربر بینا به صورت بصری بداند که کجا هستند. سپس صفحه وب باید event.preventDefault() را فراخوانی کند تا از انجام عمل معمولی مرورگر جلوگیری کند (در این مورد صفحه را پیمایش کند).
  • اگر کاربر کلید Enter را فشار دهد، می‌توانیم با آن مانند یک کلیک رفتار کنیم و عمل مناسب را انجام دهیم (یا حتی منوی دیگری را باز کنیم).
  • اگر کاربر کلیدی را فشار داد که باید کار دیگری انجام دهد، آن را به صفحه بازگردانید. برای مثال، نوار منوی ما به کلید Tab نیاز ندارد، پس آن را به عقب برگردانید! درست کردن این کار سخت است. برای مثال، نوار منو به کلیدهای جهت دار نیاز دارد، اما نه Alt + Arrow یا Command + Arrow. اینها میانبرهایی برای حرکت به صفحه قبلی و بعدی در تاریخچه وب برگه مرورگر شما هستند. اگر نویسنده مراقب نباشد، نوار منو آن ها را می خورد. این نوع باگ زیاد اتفاق می افتد و ما هنوز با ARIA شروع نکرده ایم!

دسترسی صفحه‌خوان به نوار منوی ما

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

اما این عادلانه نیست! نوار منو برای کاربر بینا به خوبی عمل می کند.

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

اولین دروغ ARIA ما ویژگی aria-activedescendant است. مشخصه را روی شناسه آیتم منوی فعال تنظیم کنید، مراقب باشید هر زمان که تغییر کرد آن را به روز کنید. به عنوان مثال، aria-activedescendant="settings-menuitem" . این باعث می شود که صفحه خوان مورد فعال ARIA ما را به عنوان فوکوس در نظر بگیرد که با صدای بلند خوانده می شود یا روی نمایشگر بریل نشان داده می شود.

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

با استفاده از aria-activedescendant برای اشاره از نوار منوی متمرکز به یک آیتم منوی خاص، صفحه خوان اکنون می داند کاربر کجا حرکت کرده است، اما هیچ چیز دیگری در مورد شیء نیست. اصلا این چیز div چیست؟ اینجاست که ویژگی role وارد می‌شود. ما role="menubar" در عنصر حاوی برای کل چیز استفاده می‌کنیم، سپس role="menu" در گروه‌های آیتم‌ها و role="menuitem" در ... drumroll ... منوی فردی استفاده می‌کنیم. موارد

و اگر آیتم منو بتواند به منوی کودک منتهی شود چه؟ کاربر باید این را بداند. برای یک کاربر بینا، ممکن است تصویر کوچکی از یک مثلث در انتهای منو وجود داشته باشد، اما صفحه خوان حداقل در این مرحله نمی داند چگونه به طور خودکار تصاویر را بخواند. می‌توانیم aria-expanded="false" را روی هر آیتم منوی قابل گسترش اضافه کنیم تا نشان دهیم چیزی وجود دارد که می‌توان آن را گسترش داد، و آن را گسترش نمی‌دهد. علاوه بر این، نویسنده باید role="none" روی مثلث img قرار دهد تا نشان دهد که فقط برای اهداف زیبایی است. این کار باعث می‌شود صفحه‌خوان نتواند درباره تصویر چیزی بگوید که اضافی باشد.

رفع اشکالات صفحه کلید

اگرچه دسترسی به صفحه کلید بخشی از HTML اصلی است، بازنویسی آن آسان است. به عنوان مثال:

  • یک چک باکس برای جابجایی از نوار فاصله استفاده می کند، اما نویسنده فراموش کرده است preventDefault() فراخوانی کند. اکنون Spacebar هم چک باکس را تغییر می‌دهد و هم صفحه را به پایین می‌برد، که رفتار پیش‌فرض مرورگر برای Spacebar است.
  • یک گفتگوی مدال ARIA می خواهد ناوبری برگه را در داخل آن به دام بیندازد. اگر نویسنده فراموش کند که به طور خاص به Control + Tab اجازه دهد تا یک برگه جدید را در حالی که در گفتگو است باز کنند، آنطور که انتظار می رود کار نخواهد کرد.
  • نویسنده یک لیست انتخاب ایجاد می کند و کلیدهای بالا و پایین را پیاده سازی می کند. با این حال، نویسنده هنوز نیاز به اضافه کردن صفحه اصلی، پایان، صفحه، صفحه پایین، یا ناوبری حرف اول دارد.

نویسندگان باید از الگوهای شناخته شده پیروی کنند. برای اطلاعات بیشتر بخش منابع را بررسی کنید.

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

اشکالات صفحه کلید تقریباً همیشه یک اشکال در محتوای وب، به ویژه در HTML و جاوا اسکریپت آنها هستند، نه در ARIA.

چرا اینقدر زیاد هستند؟

راه های زیادی وجود دارد که نویسنده می تواند ARIA را اشتباه بگیرد. هر اشتباه منجر به شکستگی کامل یا تفاوت های ظریف می شود. مشکلات ظریف ممکن است بدتر باشند، زیرا بعید است نویسنده قبل از انتشار آنها را بگیرد.

به هر حال، مگر اینکه نویسنده یک کاربر با تجربه صفحه‌خوان باشد، مشکلی در ARIA پیش خواهد رفت. در مثال نوار منوی ما، نویسنده می‌تواند فکر کند که نقش «گزینه» زمانی استفاده می‌شود که «منو آیتم» درست باشد. آنها ممکن است فراموش کنند که از aria-expanded استفاده کنند، فراموش کنند aria-activedescendant در زمان های مناسب تنظیم و پاک کنند، یا فراموش کنند که یک نوار منو حاوی منوهای دیگر داشته باشند. و در مورد تعداد آیتم های منو چطور؟ معمولا آیتم های منو توسط صفحه خوان ها با چیزی شبیه به "مورد 3 از 5" ارائه می شوند تا کاربر بداند کجا هستند. این به طور کلی توسط مرورگر به طور خودکار شمارش می شود، اما در برخی موارد، و در برخی از ترکیبات مرورگر - صفحه خوان، ممکن است اعداد اشتباه محاسبه شوند و نویسنده باید این اعداد را با aria-posinset و aria-setsize لغو کند.

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

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

خلاصه

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

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

منابع اضافی

ARIA Authoring Practices W3C ویژگی‌های مهم پیمایش صفحه کلید هر نمونه را مستند می‌کند و جاوا اسکریپت، CSS و ARIA را ارائه می‌دهد. مثال‌ها بر آنچه امروز کار می‌کند متمرکز شده‌اند و موبایل را پوشش نمی‌دهند.

API Accessibility چیست؟

API دسترسی به این معناست که چگونه یک صفحه‌خوان یا سایر فناوری‌های کمکی می‌دانند چه چیزی در صفحه است و چه اتفاقی می‌افتد. به عنوان مثال می توان به MSAA، IA2 و UIA اشاره کرد. دو بخش برای API دسترسی وجود دارد:

  • یک "درخت" از اشیا که نشان دهنده یک سلسله مراتب ظرف است. به عنوان مثال، یک سند می تواند شامل دسته ای از پاراگراف ها باشد. یک پاراگراف می تواند دارای متن، تصاویر، پیوندها و تزئینات متنی باشد. هر مورد در درخت شی می‌تواند دارای ویژگی‌هایی مانند نقش (من چیست؟)، نام یا برچسب، مقدار وارد شده توسط کاربر، توضیحات و حالت‌های بولی مانند قابل تمرکز، متمرکز، مورد نیاز، بررسی شده باشد. ARIA می تواند هر یک از این ویژگی ها را لغو کند.
    • صفحه‌خوان‌ها از درخت برای کمک به کاربران برای حرکت در حالت بافر مجازی استفاده می‌کنند، مانند «لطفاً به عنوان بعدی بروید».
  • مجموعه ای از رویدادها که تغییرات درخت را توصیف می کنند، مانند "اکنون تمرکز اینجاست!". صفحه‌خوان از رویدادها استفاده می‌کند تا به کاربر بگوید چه اتفاقی افتاده است. وقتی نشانه‌گذاری مهم HTML یا ARIA تغییر می‌کند، رویدادی فعال می‌شود تا به صفحه‌خوان بگوید چیزی تغییر کرده است.

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