دروغ گفتن به صفحه‌خوان‌ها چگونه دسترسی را درمان می‌کند، وقتی نمک به آن نمی‌مالد!
ARIA چیست؟
ARIA به نویسندگان وب اجازه می‌دهد واقعیتی جایگزین ایجاد کنند که فقط توسط صفحه‌خوان‌ها دیده می‌شود
گاهی اوقات لازم است در مورد آنچه در محتوای وب اتفاق می‌افتد، حقیقت یا حتی «دروغ» کامل را برای خوانندگان صفحه نمایش توضیح دهیم. به عنوان مثال، "تمرکز واقعاً اینجاست!" یا "این واقعا یک نوار لغزنده است!". مانند این است که یادداشت های چسبناک جادویی را در بالای ابزارها و ویجت های روی میز کار خود اضافه کنید. این یادداشت‌های چسبناک جادویی باعث می‌شود که همه آنچه روی آن نوشته شده را باور کنند.
هر زمان که یک یادداشت جادویی وجود داشته باشد، یا بر باور ما در مورد چیستی هر ابزار یا چیزی در مورد ابزار غلبه می کند. به عنوان مثال: "این چیز در اینجا یک تفنگ چسب است!". حتی اگر هنوز در واقع یک جعبه آبی خالی است که روی میز کار نشسته است، یادداشت چسبناک جادویی ما را وادار می‌کند ببینیم که یک تفنگ چسب است. همچنین می توانیم اضافه کنیم، "و 30٪ پر است!". اکنون صفحه خوان گزارش می دهد که یک تفنگ چسب کامل 30٪ در آنجا وجود دارد.
معادل وب این است که یک عنصر جعبه ساده (یک div) با یک تصویر در داخل آن بگیرید و از ARIA برای گفتن اینکه یک لغزنده با مقدار 30 از 100 است استفاده کنید.
آریا چی نیست؟
ARIA روی ظاهر یک صفحه وب یا رفتار کاربر ماوس یا صفحه کلید تأثیری ندارد. فقط کاربران فناوری های کمکی متوجه تفاوت با ARIA می شوند. توسعه دهندگان وب می توانند هر گونه ARIA دلخواه را بدون تأثیرگذاری بر کاربرانی که از فناوری کمکی استفاده نمی کنند اضافه کنند.
درست خواندید: ARIA در واقع هیچ کاری برای فوکوس صفحه کلید یا ترتیب برگه ها انجام نمی دهد. همه اینها در HTML انجام می شود، گاهی اوقات با بیت هایی از جاوا اسکریپت بهینه سازی می شود.
ARIA چگونه کار می کند؟
یک صفحه خوان یا سایر فناوری های کمکی از مرورگرها برای اطلاعات در مورد هر عنصر درخواست می شود. وقتی ARIA روی یک عنصر وجود دارد، مرورگر اطلاعات را دریافت می‌کند و آنچه را که درباره آن عنصر به صفحه‌خوان می‌گوید تغییر می‌دهد.
چرا آریا؟
چرا همیشه می خواهیم به کاربران خود دروغ بگوییم!؟
فرض کنید فروشگاه اینترنتی محلی تمام ویجت های مورد نیاز ما را نمی فروشد. اما، ما مک گیور هستیم، لعنتی. ما فقط می توانیم ویجت های خود را از ویجت های دیگر اختراع کنیم! FWIW، هفت مورد پرکاربرد مک گیور عبارتند از: چاقوهای ارتش سوئیس، آدامس، بند کفش، کبریت، گیره کاغذ، شمع تولد، و نوار چسب. او از آنها برای ساختن بمب و چیزهای دیگر استفاده می کند که فقط در اطراف قرار نمی گیرند. این بسیار شبیه به یک نویسنده وب است که نیاز به ایجاد نوار منو دارد. نوارهای منو آنقدر مفید هستند که فکر می کنید بخشی از HTML هستند، اما اینطور نیست. اوه خوب! فکر نمی کردید نویسندگان از پیوندها و دکمه ها راضی باشند، نه؟ بنابراین نویسنده با استفاده از ابزارهای مورد علاقه خود یکی را با هم ترکیب می کند: divs، تصاویر، سبک، کنترل کننده کلیک، کنترل کننده فشار کلید، تف و ARIA.
گاهی اوقات، به جای استفاده از ARIA به حداکثر، ما فقط از آن به عنوان یک بهبود استفاده می کنیم. می‌تواند مفید باشد که کمی ARIA روی برخی از HTML که قبلاً کار می‌کند بپاشید. برای مثال، ممکن است بخواهیم یک کنترل فرم به یک هشدار پیام خطایی اشاره کند که به ورودی نامعتبر مربوط می شود. یا ممکن است بخواهیم نشان دهیم که یک جعبه متن برای جستجو است. این تغییرات کوچک می تواند وب سایت های معمولی را با صفحه خوان قابل استفاده تر کند.
نمونه نوار منو
حمایت از افراد کلیک کننده موس
بیایید با هم یک نوار منو درست کنیم. ما دسته ای از آیتم ها را در عناصر جعبه عمومی به نام div نشان می دهیم. هر زمان که کاربر ما روی یک div کلیک می کند، دستور مربوطه را اجرا می کند. جالب است، برای افرادی که ماوس کلیک می کنند کار می کند!
در ادامه آن را زیبا می کنیم. ما از CSS استفاده می‌کنیم، یعنی سبک‌ها، چیزها را به خوبی ردیف می‌کنیم و خطوط بصری را در اطراف آنها قرار می‌دهیم. ما آن را به اندازه کافی شبیه سایر نوارهای منو می کنیم که افراد دیدنی به طور مستقیم بدانند که یک نوار منو است و چگونه از آن استفاده کنند. نوار منوی ما حتی از رنگ پس‌زمینه متفاوتی برای هر آیتمی استفاده می‌کند که ماوس تمام شده است و بازخورد بصری مفیدی را به کاربر می‌دهد.
برخی از آیتم های منو والدین هستند. آنها زیر منوهای کودک را ایجاد می کنند. هر زمان که کاربر روی یکی از این ها قرار می گیرد، انیمیشنی را شروع می کنیم که از زیر منوی فرزند خارج می شود.
البته، همه اینها تقریباً غیرقابل دسترس است، همانطور که برای بسیاری از چیزهای وب معمول است، عمدتاً به این دلیل که جادوگران استانداردهای HTML هر چیزی را که یک نویسنده وب نیاز دارد اضافه نکرده اند. و حتی اگر این کار را انجام دهند، نویسندگان وب همیشه می خواهند نسخه ویژه خود را به هر حال اختراع کنند.
در دسترس قرار دادن صفحه کلید نوار منو ما
به عنوان اولین قدم به سمت دسترسی، اجازه دهید دسترسی به صفحه کلید را اضافه کنیم. این قسمت فقط از 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" روی هر آیتم منوی قابل ارتقا اضافه کنیم تا نشان دهیم که 1) چیزی وجود دارد که می‌توان آن را گسترش داد، و 2) در حال حاضر گسترش نمی‌یابد. به عنوان یک لمس اضافی، نویسنده باید role="none" روی مثلث img قرار دهد تا نشان دهد که فقط برای اهداف بهتری است. این باعث می‌شود صفحه‌خوان چیزی درباره تصویر بگوید که در بهترین حالت ممکن است اضافی و احتمالاً آزاردهنده باشد.
مقابله با اشکالات
اشکالات صفحه کلید (HTML!)
اگرچه دسترسی به صفحه‌کلید بخشی از HTML اصلی است، نویسندگان همیشه آن را به هم می‌زنند، یا به این دلیل که از پیمایش صفحه‌کلید زیاد استفاده نمی‌کنند، یا به این دلیل که تفاوت‌های ظریف زیادی برای درست کردن وجود دارد.
نمونه هایی از باگ ها:
- یک چک باکس برای جابجایی از نوار فاصله استفاده می کند، اما نویسنده فراموش کرده است
preventDefault()فراخوانی کند. اکنون Spacebar هم چک باکس را تغییر می‌دهد و هم صفحه را پایین می‌آورد، که رفتار پیش‌فرض مرورگر برای Spacebar است. - یک گفتگوی مدال ARIA می‌خواهد ناوبری برگه را در داخل آن به دام بیندازد، و نویسنده فراموش می‌کند که به طور خاص به Control + Tab اجازه ورود به مرورگر را بدهد. اکنون، Control + Tab فقط در گفتگوی آنها پیمایش می‌کند و آنطور که باید برگه‌ها را در مرورگر تغییر نمی‌دهد. اوه
- نویسنده یک لیست انتخابی ایجاد می کند و بالا/پایین را پیاده سازی می کند، اما پیمایش خانه/پایان/صفحه بالا/صفحه پایین یا ناوبری حرف اول را اجرا نمی کند.
نویسندگان باید از الگوهای شناخته شده پیروی کنند. برای اطلاعات بیشتر بخش منابع را بررسی کنید.
برای مشکلات دسترسی خالص به صفحه کلید، مفید است که بدون صفحه‌خوان یا با حالت مرورگر مجازی خاموش نیز امتحان کنید. صفحه‌خوان‌ها معمولاً برای کشف اشکالات صفحه‌کلید ضروری نیستند، و دسترسی به صفحه‌کلید در واقع با HTML پیاده‌سازی می‌شود، نه ARIA. از این گذشته، ARIA روی چیزهای اساسی مانند رفتار صفحه کلید یا ماوس تأثیر نمی گذارد، فقط به صفحه خوان در مورد آنچه در صفحه وب است، آنچه در حال حاضر متمرکز شده است و غیره دروغ می گوید.
اشکالات صفحه کلید تقریباً همیشه یک اشکال در محتوای وب، به ویژه در HTML و جاوا اسکریپت آنها هستند، نه در ARIA.
اشکالات ARIA: چرا این همه وجود دارد؟
مکان‌های بسیاری وجود دارد که نویسندگان می‌توانند ARIA را اشتباه بگیرند، و هر کدام به شکستگی کامل یا تفاوت‌های ظریف منجر می‌شوند. موارد ظریف احتمالا بدتر هستند، زیرا نویسنده قبل از انتشار بیشتر آنها را نمی گیرد.
به هر حال، مگر اینکه نویسنده یک کاربر با تجربه صفحه‌خوان باشد، مشکلی در ARIA پیش خواهد رفت. در مثال نوار منوی ما، نویسنده می‌تواند فکر کند که نقش «گزینه» زمانی استفاده می‌شود که «منو آیتم» درست باشد. آنها ممکن است فراموش کنند که از aria-expanded استفاده کنند، فراموش کنند aria-activedescendant در زمان های مناسب تنظیم و پاک کنند، یا فراموش کنند که یک نوار منو حاوی منوهای دیگر داشته باشند. و در مورد تعداد آیتم های منو چطور؟ معمولا آیتم های منو توسط صفحه خوان ها با چیزی شبیه به "مورد 3 از 5" ارائه می شوند تا کاربر بداند کجا هستند. این به طور کلی توسط مرورگر به طور خودکار شمارش می شود، اما در برخی موارد، و در برخی از ترکیبات مرورگر - صفحه خوان، ممکن است اعداد اشتباه محاسبه شوند و نویسنده باید این اعداد را با aria-posinset و aria-setsize لغو کند.
و این فقط نوارهای منو است. به چند نوع ویجت فکر کنید. اگر دوست دارید به مشخصات ARIA یا شیوه های نگارش نگاه کنید. برای هر الگو، ده‌ها راه وجود دارد که می‌توان از ARIA سوء استفاده کرد. ARIA به نویسندگان متکی است تا بدانند چه کاری انجام می دهند. با توجه به اینکه اکثر نویسندگان کاربر صفحه خوان نیستند، چه چیزی ممکن است اشتباه پیش برود؟
به عبارت دیگر، 100 درصد برای کاربران واقعی صفحه‌خوان ضروری است که ویجت‌های ARIA را قبل از اینکه قابل حمل در نظر گرفته شوند، امتحان کنند. تفاوت های ظریف زیادی وجود دارد. در حالت ایده‌آل، همه چیز با چندین ترکیب مختلف مرورگر-صفحه‌خوان امتحان می‌شود، زیرا به دلیل پیچیدگی‌های متعدد پیاده‌سازی، علاوه بر چند پیاده‌سازی ناقص است.
خلاصه
به طور خلاصه، جادوی ARIA می تواند برای لغو یا اضافه کردن هر چیزی و هر چیزی که HTML می گوید استفاده شود. می توان از آن برای انجام تغییرات جزئی در ارائه دسترسی یا ایجاد یک تجربه کامل استفاده کرد. به همین دلیل است که ARIA در دستان نویسندگان وب محلی دوستانه ما که معمولاً خودشان از صفحه‌خوان‌ها استفاده نمی‌کنند، بسیار قدرتمند و در عین حال خطرناک است.
ARIA فقط یک لایه نشانه گذاری نادیده گرفتن حقیقت است. وقتی یک صفحه‌خوان می‌پرسد چه اتفاقی می‌افتد، اگر ARIA وجود داشته باشد، نسخه ARIA حقیقت را به جای حقیقت واقعی واقعی دریافت می‌کند.
ضمیمه 1: منابع اضافی
مرجع ترکیبی با اطلاعات صفحه کلید و نمونه کد
- روش‌های ARIA نویسندگی W3C : این ویژگی‌های مهم پیمایش صفحه کلید هر نمونه را مستند می‌کند و کد JS/CSS/ARIA را ارائه می‌دهد. مثال‌ها بر آنچه امروز کار می‌کند متمرکز شده‌اند و موبایل را پوشش نمی‌دهند.
ضمیمه 2: ARIA بیشتر برای چه مواردی استفاده می شود؟
زیرا ARIA می تواند حقایق کوچک یا بزرگ را جایگزین یا تکمیل کند، که عموماً برای گفتن مطالبی که صفحه خوان به آن اهمیت می دهد مفید است.
در اینجا برخی از کاربردهای رایج ARIA آورده شده است.
- ابزارک‌های ویژه‌ای که در HTML وجود ندارند، مانند نوار منو، تکمیل خودکار، درخت یا صفحه‌گسترده
- ویجت هایی که در HTML وجود دارند، اما نویسنده به هر حال ابزارک خود را اختراع کرده است، احتمالاً به این دلیل که آنها باید رفتار یا ظاهر ویجت معمولی را تغییر دهند. به عنوان مثال، یک عنصر HTML
<input type="range">اساساً یک نوار لغزنده است، اما نویسندگان می‌خواهند آن را متفاوت جلوه دهند. برای بیشتر موارد، CSS را می توان استفاده کرد، اما برایinput type="range"، CSS نامناسب است. نویسنده می تواند اسلایدر خود را بسازد وrole="slider"روی آن باaria-valuenowاستفاده کند تا بگوید مقدار فعلی چقدر است. - مناطق زنده به خوانندگان صفحه می‌گویند: «در این قسمت از صفحه، هر چیزی که تغییر می‌کند ارزش گفتن به کاربر را دارد».
- نشانه‌ها (HTML اکنون معادل‌هایی دارد). اینها تا حدودی شبیه سرفصل ها هستند، زیرا به کاربران صفحه خوان کمک می کنند تا آنچه را که می خواهند سریعتر پیدا کنند. با این حال، آنها از این نظر متفاوت هستند که شامل کل منطقه مرتبط هستند. مانند "این کانتینر ناحیه اصلی صفحه است" و "این کانتینر اینجا یک پانل ناوبری است".
ضمیمه 3: API دسترسی چیست؟
یک API دسترسی به این معناست که چگونه یک صفحه‌خوان یا سایر AT می‌دانند چه چیزی در صفحه است و چه اتفاقی در حال حاضر روی می‌دهد. به عنوان مثال می توان به MSAA، IA2 و UIA اشاره کرد. و این فقط ویندوز است! دو بخش برای API دسترسی وجود دارد:
- یک "درخت" از اشیا که نشان دهنده یک سلسله مراتب ظرف است. اینها مانند عروسک های تودرتو روسی هستند، اما هر عروسک می تواند چندین عروسک دیگر را در خود جای دهد. به عنوان مثال، یک سند می‌تواند شامل دسته‌ای از پاراگراف‌ها باشد، و یک پاراگراف می‌تواند دارای متن، تصاویر، پیوندها، پررنگ‌ها و غیره باشد. هر مورد در درخت شی می‌تواند ویژگی‌هایی مانند یک نقش (من چیست؟)، یک نام/برچسب داشته باشد. ، یک مقدار وارد شده توسط کاربر، یک توضیحات، و همچنین حالت های بولی مانند قابل تمرکز، متمرکز، مورد نیاز، بررسی شده است. ARIA می تواند هر یک از این ویژگی ها را لغو کند. صفحه‌خوان از درخت برای کمک به کاربر در حرکت در حالت بافر مجازی استفاده می‌کند، مانند "لطفاً به عنوان بعدی بروید".
- مجموعه ای از رویدادها که تغییرات درخت را توصیف می کنند، مانند "اکنون تمرکز اینجاست!". صفحه‌خوان از رویدادها استفاده می‌کند تا به کاربر بگوید چه اتفاقی افتاده است. وقتی نشانه‌گذاری مهم HTML یا ARIA تغییر می‌کند، رویدادی فعال می‌شود تا به صفحه‌خوان بگوید چیزی تغییر کرده است.
معمولاً نویسندگان فقط از HTML استفاده می کنند که به خوبی به این APIهای دسترسی نگاشت می شود. هنگامی که HTML کافی نیست، ARIA استفاده می شود و مرورگر قبل از ارسال درخت شی یا رویدادها به صفحه خوان، معنای HTML را لغو می کند.