مقدمه‌ای بر درخت دسترس‌پذیری
تصور کنید که درحال ساختن یک واسط کاربر فقط برای کاربران صفحه‌خوان هستید. در اینجا، اصلاً لازم نیست واسط کاربر دیداری ایجاد کنید، بلکه فقط کافی است اطلاعات کافی برای استفاده صفحه‌خوان ارائه دهید.
آنچه ایجاد می‌کنید نوعی API است که ساختار صفحه را توصیف می‌کند، مشابه DOM API، اما می‌توانید با اطلاعات کمتر و گره‌های کمتری کار را پیش ببرید، زیرا بسیاری از این اطلاعات فقط برای ارائه بصری مفید است. ممکن است چیزی شبیه این باشد.
این اساساً همان چیزی است که مرورگر درواقع به صفحه‌خوان ارائه می‌دهد. مرورگر درخت DOM را می‌گیرد و آن را به شکلی تغییر می‌دهد که برای فناوری کمکی مفید باشد. ما به این درخت اصلاح‌شده درخت دسترس‌پذیری می‌گوییم.
می‌توانید درخت دسترس‌پذیری را کمی شبیه به یک صفحه وب قدیمی از دهه ۹۰ تصور کنید: چند تصویر، تعداد زیادی پیوند، شاید یک فیلد و یک دکمه.
اسکن بصری صفحه مانند این مورد، تجربه‌ای مشابه آنچه کاربر صفحه‌خوان دریافت می‌کند به شما می‌دهد. رابط وجود دارد، اما ساده و مستقیم است، بسیار شبیه به رابط درخت دسترس‌پذیری.
درخت دسترس‌پذیری چیزی است که اکثر فناوری‌های کمکی با آن تعامل دارند. جریان به این صورت است.
- برنامه‌ای (مرورگر یا برنامه دیگر) نسخه معنایی واسط کاربر خود را ازطریق API دراختیار فناوری کمکی قرار می‌دهد.
- فناوری کمکی ممکن است از اطلاعاتی که ازطریق API می‌خواند برای ایجاد ارائه میانای کاربر جایگزین برای کاربر استفاده کند. برای مثال، صفحه‌خوان واسطی ایجاد می‌کند که در آن کاربر نمایشی گفتاری از برنامه را می‌شنود.
- فناوری کمکی همچنین ممکن است به کاربر اجازه دهد به روشی متفاوت با برنامه تعامل داشته باشد. برای مثال، اکثر صفحه‌خوان‌ها قلاب‌هایی ارائه می‌دهند که به کاربر اجازه می‌دهد به‌راحتی کلیک موشواره یا ضربه انگشت را شبیه‌سازی کند.
- فناوری کمکی قصد کاربر (مانند «کلیک») را ازطریق Accessibility API به برنامه منتقل می‌کند. سپس برنامه مسئولیت دارد که کنش را به‌طور مناسب در زمینه واسط کاربر اصلی تفسیر کند.
برای مرورگرهای وب، یک مرحله اضافی در هر جهت وجود دارد، زیرا مرورگر درواقع پلاتفرمی برای برنامه‌های وب است که در داخل آن اجرا می‌شوند. بنابراین مرورگر باید برنامه وب را به درخت دسترس‌پذیری ترجمه کند و مطمئن شود که رویدادهای مناسب در جاوا اسکریپت براساس کنش‌های کاربر که از فناوری کمکی دریافت می‌شود، اجرا می‌شوند.
اما این‌ها همه مسئولیت مرورگر است. وظیفه ما به‌عنوان توسعه‌دهندگان وب این است که از این موضوع آگاه باشیم و صفحه‌های وبی را توسعه دهیم که از این فرایند برای ایجاد تجربه‌ای دسترس‌پذیر برای کاربرانمان بهره می‌برند.
این کار را با اطمینان از اینکه معناشناسی صفحه‌هایمان را به‌درستی بیان می‌کنیم انجام می‌دهیم: مطمئن می‌شویم که عناصر مهم در صفحه نقش‌ها، وضعیت‌ها، و ویژگی‌های دسترس‌پذیر صحیح دارند، و نام‌ها و شرح‌های دسترس‌پذیر را مشخص می‌کنیم. سپس مرورگر می‌تواند به فناوری کمکی اجازه دهد به آن اطلاعات دسترسی پیدا کند تا تجربه سفارشی‌شده‌ای ایجاد کند.
معناشناسی در HTML بومی
مرورگر می‌تواند درخت DOM را به درخت دسترس‌پذیری تبدیل کند زیرا بخش زیادی از DOM دارای معنای معنایی ضمنی است. یعنی DOM از عناصر HTML بومی استفاده می‌کند که توسط مرورگرها شناسایی می‌شوند و به‌طور قابل‌پیش‌بینی در پلاتفرم‌های مختلف کار می‌کنند. بنابراین، دسترس‌پذیری برای عناصر HTML بومی مانند پیوندها یا دکمه‌ها به‌طور خودکار انجام می‌شود. می‌توانیم با نوشتن HTML که معناشناسی عناصر صفحه‌مان را بیان می‌کند، از این دسترس‌پذیری داخلی بهره ببریم.
اما گاهی‌اوقات از عناصری استفاده می‌کنیم که شبیه عناصر بومی هستند ولی بومی نیستند. برای مثال، این «دکمه» اصلاً دکمه نیست.
این دکمه ممکن است به روش‌های مختلفی در HTML ساخته شود؛ یکی از این روش‌ها در زیر نشان داده شده است.
<div class="button-ish">Give me tacos</div>
وقتی از عنصر دکمه واقعی استفاده نمی‌کنیم، صفحه‌خوان هیچ راهی برای دانستن اینکه روی چه چیزی قرار گرفته است ندارد. همچنین، باید کار اضافی افزودن tabindex را انجام دهیم تا آن را برای کاربران فقط صفحه‌کلید قابل‌استفاده کنیم، زیرا همان‌طور که اکنون کدگذاری شده است، فقط با موشواره قابل‌استفاده است.
به‌راحتی می‌توانیم این مشکل را بااستفاده از عنصر button معمولی به‌جای div برطرف کنیم.
استفاده از عنصر بومی همچنین این مزیت را دارد که تعاملات صفحه‌کلید را برای ما مدیریت می‌کند. و به‌خاطر داشته باشید که لازم نیست جلوه‌های بصری شیک خود را فقط به‌دلیل استفاده از عنصر بومی ازدست بدهید؛ می‌توانید عناصر بومی را به‌گونه‌ای سبک‌بندی کنید که به همان شکلی که می‌خواهید دیده شوند و همچنان معناشناسی و رفتار ضمنی را حفظ کنند.
پیش‌تر اشاره کردیم که صفحه‌خوان‌ها نقش، نام، وضعیت، و مقدار عنصر را اعلام می‌کنند. بااستفاده از عنصر معنایی مناسب، نقش، وضعیت، و مقدار پوشش داده می‌شوند، اما باید مطمئن شویم که نام عنصر را نیز قابل‌شناسایی کنیم.
به‌طور کلی، دو نوع نام وجود دارد:
- برچسب‌های نمایان که همه کاربران برای مرتبط کردن معنی با عنصر از آن استفاده می‌کنند، و
- جایگزین‌های نوشتاری که فقط زمانی استفاده می‌شوند که نیازی به برچسب دیداری نباشد.
برای عناصر سطح نوشتار، لازم نیست کاری انجام دهیم، زیرا طبق تعریف، محتوای نوشتاری خواهد داشت. اما برای عناصر ورودی یا کنترلی، و محتوای دیداری مثل تصاویر، باید مطمئن شویم که نامی را مشخص می‌کنیم. درواقع، ارائه جایگزین‌های نوشتاری برای هر محتوای غیرنوشتاری اولین مورد در بازبینه WebAIM است.
یک راه برای انجام این کار این است که از توصیه آن‌ها پیروی کنید که «ورودی‌های فرم دارای برچسب‌های نوشتاری مرتبط باشند.» دو روش برای مرتبط کردن برچسب با عنصر فرم، مثل چارگوش انتخاب، وجود دارد. هریک از این روش‌ها باعث می‌شود نوشتار برچسب نیز به هدف کلیک برای چارگوش انتخاب تبدیل شود، که برای کاربران موشواره یا نمایشگر لمسی نیز مفید است. برای مرتبط کردن برچسب با عنصر، یا
- عنصر ورودی را داخل عنصر برچسب قرار دهید
<label>
<input type="checkbox">Receive promotional offers?
</label>یا
- از مشخصه
forبرچسب استفاده کنید و بهidعنصر ارجاع دهید
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
وقتی چارگوش انتخاب به‌درستی برچسب‌گذاری شده باشد، صفحه‌خوان می‌تواند گزارش دهد که این عنصر نقش چارگوش انتخاب را دارد، در وضعیت علامت‌زده است، و نام آن «دریافت پیشنهادهای تبلیغاتی؟» است.
