Jump to content

إرشادات تيسير الوصول التي يتعين على مطوري البرمجيات اتباعها

From mediawiki.org
This page is a translated version of the page Accessibility guide for developers and the translation is 54% complete.
Languages:

إن مسألة تيسير الوصول ذات أهمية بالغة لمستخدمينا ويمكننا تحسين مستوى تيسير الوصول لو نظرنا بعين الاعتبار إلى بضع أفكار وقواعد أساسية. إن مسألة تيسير الوصول تصبح صعبة المنال منذ أنه لا توجد معايير قياسية فنية ثابتة ويقبلها الجميع ينتج عنها نتائج متساوية ولكل المستخدمين. لا تسرد هذه الصفحة أو تناقش مشاكل تيسير وصول بعينها موجودة في برمجيات ميدياويكي. تحاول هذه الصفحة التركيز على خيارات التقنية وكذا ما يجب فعله وتجنب فعله لتلافي حدوث مشاكل تتعلق بتيسير الوصول.

من ناحية تطوير البرمجيات، أرى أن هذه الصفحة يجب أن تصبح دليل قواعد نتبعه:

  • حاول تيسير الاستخدام لكافة المستخدمين (ويعني هذا كلهم دون استثناء)
  • حاول البحث عن سبيل للتغلب على مسائل تيسير الوصول لو كان هذا ممكنا، إلا أن هذا يجب ألا يكون مهما كلّف الأمر
  • يجب علينا أن نتبع سبيل التحسين التدريجي بديلا عن اتباع سبيل تقليل الإمكانات الذي يراعي الجميع.
  • تنفيذ أمور ذات مسوّغ تقني

كيفية عمل أمور تيسير الوصول

بعض المفاهيم الهامة التي يجب عليك أن تنظر إليها بعين الاعتبار.

مقاييس تيسير الوصول تستعين بأشكال كثيرة

إن تيسير الوصول يتناول تشكيلة مختلفة من الأمور، لذا يرجى النظر بعين الاعتبار لما يلي:

  • أن يكون أمر ما يسير الاستيعاب: يعني هذا أن يكون يسير الاستيعاب من نواحي النص والمظهر والمنطق وحينما يكون جزءا من كل
  • يحتاج بعض المستخدمين لاستخدام قارئ للشاشة لتيسير التفاعل، ألا أن ثمة أمور أخرى أكثر انتشارا من هذه وهي: عدسة مكبرة أو رفع مستوى التباين أو استخدام محرك يحول النصوص إلى كلام منطوق أو إعدادات سي إس إس مخصصة أو نوع خاص من لوحات المفاتيح أو أجهزة الإدخال.
  • يجب أن تكون في المتناول أي سريعة الاستجابة وقليلة التكلفة ومتوفرة في المنطقة الجغرافية وبلغة المستخدم ونوع العتاد المطلوب لها وخلافه.

بعبارة موجزة، لا يجوز اختصار تيسير الوصول في مجرد تيسير الوصول على لوحة المفاتيح أو مجرد تيسير الوصول إلى قارئ للشاشة. غالبا ما نصب جهودنا على هذين الاثنين لأنهما في العادة يقعان ضحية للإغفال. إلا أن هذه المسائل يمكن حلها وغالبا ما تقدم أساسا لأية أنواع أخرى من التحسينات الممكن تنفيذها.

تميل بعض من مسائل تيسير الوصول إلى أن تكون مشاكل في تصميم المنتج أو خيارات استراتيجية أو اختيار الجمهور المستهدف أو خلافه. منذ أن هذه الجوانب يصعب تسجيلها كتابة في قواعد مكتوبة تنطبق بوجه عمومي على منظومة ميدياويكي بوجه عام، هي خارج نطاق تغطية هذه الوثيقة.

استخدام لوحة المفاتيح في التنقل

ربما نطلق على هذا الأمر «keyboard navigation»، إلا أنه يعني في الواقع: لا تركز على استخدام جهاز تأشير (لوحة تعمل باللمس أو فأرة).

  • إن استخدام لوحة المفاتيح في التنقل يستند إلى الاستعانة بالتركيز وتنفيذ الأعمال باستخدام لوحة مفاتيح الجهاز المستخدم.
  • العناصر التي يمكن استخدام زر التبويب «Tab» للذهاب إليها يمكن التركيز عليها، بينما أن العناصر التي يمكن التركيز عليها لا يمكن استخدام زر التبويب للذهاب إليها.
  • كل شيء يمكن لك أن تفعله مستخدما الفأرة يجب أن يكون ممكنا باستخدام لوحة المفاتيح.
  • يمكن لقارئات الشاشة استخدام معلومات التصفح باستخدام لوحة المفاتيح في تحسين خبرة استخدامها.

قارئات الشاشة

  • تستخدم قارئات الشاشة «مؤشر» مختلف الذي يتبع في العادة الترتيب المنطقي لنموذج كائن المستند (DOM).
  • ينزع التركيز إلى اتباع مؤشر قارئ الشاشة والعكس بالعكس، إلا أنهما ليسا متشابهين
    • يمكنك متابعة العنصر محل التركيز عن طريق تحديد تعبير مباشر في كروم [١]
  • يستخدم قارئ الشاشة واجهات برمجة التطبيقات الخاصة «بتيسير الوصول»، التي يمكنك أن تعتبرها «طريقة عرض» إدخال وإخراج تضاف إلى نموذج كائن المستند المعتاد.
  • إن آريا هي تعليقات خاصة بنموذج كائن المستند تعزز أو تتعامل مع كيفية تحويل منطق نموذج كائن المستند إلى واجهات برمجة التطبيقات الخاصة بتيسير الوصول. إنها ليست بديلًا عن كتابة إتش تي إم إل أو جافا سكريبت مضبوطين. يتحقق التصفح باستخدام لوحة المفاتيح ببساطة بفضل ترتيب نموذج كائن المستند المنطقي! للمزيد عن آريا اذهب إلى تفسير منظمة w3.org وكذلك تفسير MDN.
  • لا ينحصر قارئ الشاشة بالتنقل مستخدمًا تنظيم نموذج كائن المستند المنطقي، إنه ليس إلا السبيل الافتراضي.
    • يمكن لقارئ الشاشة قراءة ما هو موجود أسفل مؤشر الفأرة على سبيل المثال
    • تستخدم خاصية VoiceOver الموجودة في أجهزة iOS مؤشر شاشة يتغير موضعه باستخدام موضع الإصبع والإيماءات على الشاشة التي تعمل باللمس.
    • تحتوي أغلب برمجيات قراءة الشاشة على أوضاع إبحار إضافية، حيث يمكنك السرد والإبحار مستخدمًا مناطق بارزة أو جدول محتويات مولّد آليًا أو «علامات مرجعية» يحددها المستخدم في أي صفحة.
  • من نقطة سبل الإبحار المتعددة سالفة الذكر، اتبع التالي: توجد بداية وتوجد نهاية، وأيضًا يمين ويسار وأعلى وأسفل. يجب عليك ألا تتكل على هذه في اتصالاتك كثيرًا، وكذلك أنت لا تحتاج لإنكار وجودها كلية أيضًا. لا تخلط بين الإمكانات البصرية للمستخدم وبين إدراك المسافات الذي قد يقدمه قارئ الشاشة للمستخدم. مثال:
    1. جملة طويلة [صورة] تعرضها الصورة السالفة... Still acceptable
    2. جملة طويلة [صورة] [صورة] تعرضها الصورة اليسرى، والصورة اليمنى تعرض... Still acceptable
    3. جملة طويلة [صورة] [صورة] تعرضها الصورة اليمنى، والصورة اليسرى تعرض... Not acceptable
    4. جملة طويلة [صورة] [صورة] تعرضها الصورة السالفة... Not acceptable
    5. جملة طويلة [صورة] [صورة] [صورة] تعرضها الصورة اليسرى، والصورة اليمنى تعرض... Not acceptable
    6. جملة طويلة [صورة] [صورة] لشيء مختلف تمامًا. تعرضها الصورة اليسرى، والصورة اليمنى تعرض... Definitely not acceptable

إرشادات تطوير البرمجيات

توجد معايير قياسية متعددة تتناول مسألة تيسير الوصول إلا أنها جميعها تقريبًا، رغم أنها تحدد المشاكل تحديدًا مناسبًا، تعاني من مصاعب كبيرة حينما يتعلق الأمر بتقديم حلول فنية (يكثر بينها وجود «سبل حل مؤقتة غير سارة»). كان هذا الأمر سببًا لوجود كم كبير من الخلاف في المجتمعات. لهذا السبب، يجب علينا تحديد الأمور التي لا خلاف عليها التي يجب علينا ببساطة أن ننفذها دائمًا (أو ألا ننفذها أبدًا) وسبب ذلك. يسهل كثيرًا الوصول إلى أهداف محددة لو فصلنا الأمور التي لا خلاف عليها عن الأمور المسببة للخلاف.

استخدمها دائما أو قدمها للمستخدم دائما

عناصر إتش تي إم إل نحوية ملائمة
استخدم عناصر إتش تي إم إل لأغراضها المحددة. على سبيل المثال:
  • استخدام ‎<button> لا ‎<div> أو ‎<span> أو ‎<a> في حالة مداولات النقر
  • لو شعرت أنك بحاجة لاستخدام خط عريض مع نص، فكر جديًا إن لم يكن من الأفضل استخدام عنوان أو عنصر strong
بنية ترويسة منطقية
يتعين أن تحتوي الصفحات دائمًا على بنية ترويسة منطقية متسقة. الترويسات هي واحدة من أدوات الإبحار الأساسية التي يستعين بها مستخدمي قارئات الشاشة.
  1. يجب ألا توجد أية فجوات في تداخل مستويات العناوين. (إذن لا H2->H4.)
  2. يجب أن تكون العناوين وصفية
  3. يجب أن تكون العناوين فريدة داخل مستواها الخاص بها. (يجب ألا يوجد اثنين من H3 بذات المحتوى تحت نفس H2 القسم)
  4. يجب الفصل بين الإبحار والمحتوى
نعت alt للصور ذات القيم المفيدة
لو كان ثمة صورة الغرض منها الزينة، استخدم قيمة خالية صريحة لنعت «alt»؛ بل الأفضل من ذلك، حولها إلى صورة خلفية بنمط سي إس إس.
عادة ما يأتي الوصف البديل للصورة قبل نعت عنوان الصور بل وأيضًا قبل نعت العنوان للوصلات الشبكية التي تحيط بأي صورة.
نعت title للوصلات الشبكية
تعرض هذه عادة في صفة تلميحات على الشاشة.
استخدم العناوين فقط لو كانت مختلفة عن نص الوصلة الشبكية.
لا تقرأ قارئات الشاشة أغلب عناوين الوصلات الشبكية، إلا لو كان قارئ الشاشة قد ضبط تحديدًا بهذه الطريقة.
نعوت lang وdir وhreflang
يسمح استخدام lang وhreflang باختيار صوت ملائم في قارئات الشاشة، ويختار تصويب الهجاء الصحيح في المتصفحات وخلافه
تباين كافٍ
تحقق دائمًا من ألوانك للتأكد من وجود تباين كافٍ. في حالة النصوص، يتطلب الأمر وجود تباين عالي للنصوص صغيرة الحجم (بسبب خاصية تنعيم الحواف).
التركيز لأغراض الإبحار باستخدام لوحة المفاتيح
إياك أن تزيل المخطط من عناصر يمكن التركيز عليها إلا لو حدد مخططك بنفسك لحالة :focus.
  • لا تستخدم outline: 0 خلاف ذلك.
  • لو حددت أية فئات زائفة، مثل :hover أو :active، يرجى أيضًا تحديد أسلوب :focus.
الإبحار باستخدام لوحة المفاتيح
يجب أن تكون العناصر التفاعلية داخل الصفحة قابلة للإبحار فيها باستخدام لوحة المفاتيح. يرجى التأكد من تمكين الإبحار باستخدام مفتاح الجدولة في متصفحك ويسمح لك أن تتحكم في كل عنصر تفاعلي دون الحاجة لاستخدام جهاز تأشير.
  1. استخدم tabIndex: 0 كي تجعل العناصر متاحة للوحة المفاتيح، وهي العناصر التي ليست متاحة للوحة المفاتيح ضمنيًا (أي شيء عدا ‎<a>, ‎<area>, ‎<button>, ‎<input>, ‎<object>, ‎<select>, ‎<textarea>).
    1. في هذه الحالة أضف أيضًا مداول ضغط مفتاح لمفتاح الإدخال (keyCode 13) وكذلك مفتاح المسطرة/المسافة (keyCode 32).
  2. استخدم tabindex: -1 لحذف العناصر من تيسير الوصول. (استخدام هذا مع الوصلات التي بمثابة عناوين لتصرفات داخل ‎<li>...‎</li> على سبيل المثال)
  3. سوف توجه العناصر يسيرة الوصول باستخدام لوحة المفاتيح حالات ضغط الإدخال/المسطرة إلى مداول النقر
الحوارات الخ

عندما لا يتم رعاية ميزات سهولة الاستخدام بشكل جيد، تكون المحادثات من أكثر العناصر صوبة في الاستخدام لجهاز قارئ الشاشة ومستخدمي لوحة المفاتيح. اقض بعض الوقت على هذا

  • The element that opens the dialog should have aria-haspopup
  • يجب أن تملك المحادثة نفسها role=[dialog | alertdialog | tooltip]
  • The dialog should be inserted in DOM order,[1] or aria owns/controls needs to specify this relation between opening element and dialog
  • When opening the dialog, remember last focused element and shift focus to the first focusable tabbable element inside the dialog
  • When the dialog is modal, make it impossible to interact with the rest of the page
    • Capture clicks outside the dialog and ignore them or let them dismiss the dialog
    • Make sure you cannot tab to links or input elements outside of dialog
    • Make elements outside of the dialog unreachable for screen reader, by using aria-hidden
  • Make sure there is a close mode (Esc key and a focusable close button with a descriptive title)
  • Closing should return the (keyboard) focus to the original focus point that you stored when you opened the dialog. For screen readers to return to the same point, be sure to specify the right owner of the dialog, if you have not inserted the dialog in DOM order.
  • Read up: Aria modals, Aria modal dialog, ARIA nonmodal dialog, ARIA tooltips.
WCAG 2.1 guidelines
Follow wherever possible
And its accompanying documents:

محاذير

  • There is common advice to use left: -1000px to push something (often the labels of icon buttons) out of the viewport for visual users and still have it in the accessibility DOM. text-indent: -9999px is variant of this. This is BAD advice.
    • This breaks our RTL rendering in several browsers. Specifically in rtl mode it creates a large canvas left of the viewport and scrollbars, much as +1000px would create in ltr mode. (If needed, top: -1000px is preferred over left: -1000px to avoid this).
    • VoiceOver on mobile is unable to use this text as a fallback, since it is a 'positional' screen reader. You cannot move your finger over this text and thus the text will not be read either. (aria-label is often the better choice).
    • Lastly, this enlarges the render surface needed to calculate the final webpage and this can impact performance [٢] on mobile devices.
    • Insightful overview of 'hide text offscreen' tricks are given by Jonathan Snook.
  • Things should not be repeated often. If you have a 100 links on a page that can open a dialog, then don't add 100 labels to those 100 links telling the user that it can be used to open a dialog. Telling a user how to use/what to do with the interface is a good thing, doing it consistently is simply annoying. Find a different way to explain it once (an aria-live=polite might be an idea in this case ?).
  • <a href="#">Hide</a> with an onclick handler. VO reads such JS as "internal link Hide". Use a proper button, or <a role="button" tabindex="0">Hide</a>, with 'Space' and 'Enter' key handlers in the onclick. But no href attribute.
  • Do not nest interactive functionality inside another interactive element (links or buttons inside links). This confuses screen readers.

تلافى

Unicode symbols
Most assistive technologies are not good with symbols. Therefore, try to avoid characters such as ↑, →‎ or more complex characters, because many screen reader won't understand them. If they are required, try to wrap with a span element with the title attribute, so that the title attribute can communicate the implicit meaning within the context to the reader.
Small fonts
Legibility is preferred. If you make something so small that it is hard to read, do you even need it to begin with? Also avoid small fonts with low or mediocre contrast values (even if they fall inside the WCAG guidelines, small sizes require more explicit contrast then large sizes, especially with anti aliasing enabled).
Unusually large fonts
If you make text much larger than normal, it can become similarly hard to read (unless it's very short). This applies mostly to body text, or anything that takes up more than a couple lines. But the larger the text is, the more lines it will take up.
tabIndex > 0
DOM order is preferred wherever possible. DOM order provides context for the actions.
Workaround
Traditionally, accomplishing 'full' accessibility has required a lot of workarounds for html itself, the browsers and even specific screenreader software. However these workarounds often come with side effects, make use of bugs or unspecified behavior and inevitably create technical debt.
MediaWiki, because of the users it seeks to serve, the amount of code, it's (lack) of funding, etc tends to prefer future proof code over code that easily breaks. As such it generally avoids workarounds even if that might sometimes limit the accessibility we can deliver. Decisions on this are often influenced by the relative audience of the feature in MediaWiki. If something is ubiquitous for all users a workaround is more warrented than if the feature affected is only used by a tiny part of the audience (for instance, reading a page vs modifying the configuration of the installation).

فكر جديا فيما يلي

  • ARIA Roles
    • If a div or span behaves like an actual button use role="button". also role="dialog" and role="alert"
    • Be careful with roles. For instance, don't add role="button" to a ‎<th> element, since the ‎<th> element has an implicit role="columnheader", which will be overwritten. Instead use nested elements. Similarly for ‎<li> which has an implicit role="listitem"
    • If a button creates a popupdialog, use aria-haspopup.
    • Use aria-labelled-by for contexts where this is not fully logical by itself (so everywhere except for labels in forms and headers in tables).
  • Avoid tables for layout purposes and test on smaller screen widths.
  • hide stuff: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
  • skip/jump to links

انظر أيضا

مراجع

  1. ↑ See DOM order at w3.org and Style order Property at w3schools.org
Retrieved from "https://www.mediawiki.org/w/index.php?title=Accessibility_guide_for_developers/ar&oldid=6421219"