جافا سكريبت وإمكانية الوصول

Question

باعتباري مطور ويب، فإن عددًا من المشاريع التي أعمل عليها تقع تحت المظلات الحكومية وبالتالي تخضع لها 508 إمكانية الوصول القوانين وأحيانا إمكانية الوصول إلى W3C القواعد الارشادية.إلى أي مدى يمكن استخدام JavaScript مع تلبية هذه المتطلبات؟

على هذا المنوال، إلى أي مدى يتم استخدام JavaScript، وتحديدًا AJAX واستخدام حزم مثل jQuery للقيام بأشياء مثل عرض مربعات الحوار المشروطة والنوافذ المنبثقة وما إلى ذلك.مدعومة ببرامج إمكانية الوصول الحديثة مثل JAWS وOrca وما إلى ذلك؟في الماضي ، ذهبت القاعدة مثل "إذا لم تنجح في Lynx ، فلن تعمل مع قارئ الشاشة". هل هذا لا يزال صحيحًا ، أم أنه كان هناك المزيد من التقدم في هذه المناطق؟

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

Answer 1

إذا كانت إمكانية الوصول هي اهتمامك الأساسي، فابدأ دائمًا موقع ويب باستخدام HTML المتوافق مع المعايير (اختر تعريف نوع المستند والتزم به).إذا كان تطبيق ويب (عمليات إرسال النماذج، وما إلى ذلك)، فتأكد من أن النماذج ستعمل باستخدام HTTP GET وPOST فقط.بمجرد الانتهاء من إنشاء موقع ويب/تطبيق كامل، يمكنك إضافة أجزاء من CSS وJavaScript طالما أن الموقع لا يزال يعمل، مع إيقاف تشغيل أحدهما أو كليهما.

المفهوم الأكثر أهمية هنا هو تحسين تدريجي.أنت تضيف أجراس وصفارات إضافية باستخدام CSS/JavaScript، ولكن موقع الويب/التطبيق الخاص بك سيعمل بشكل جيد تمامًا بدون أيضاً.

أداة عظيمة للاختبار 508, واي, ، إيقاف تشغيل CSS، إيقاف تشغيل JavaScript، حاول استخدام مطور ويب البرنامج المساعد لمتصفح فايرفوكس.

Answer 2

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

إذا كنت تضع إمكانية الوصول في الاعتبار وكنت تختبر بشكل صحيح كلتا حالتي الاستخدام (JavaScript مقابل JavaScript).بخلاف جافا سكريبت) يجب أن تكون قادرًا على كتابة التطبيقات التي تلبي احتياجات كلا الجمهورين.

مثال ($(document).ready تم حذفه من أجل الوضوح والإيجاز:

<script>
  $("#hello").click(function(){
    alert("Hi");
  });
</script>
<a href="/say_hello.htm" id="hello">Say Hello</a>

مثال تافه ولكن هذا في الأساس لن يقوم بتقييم حدث النقر فوق JavaScript إلا إذا كان JavaScript مدعومًا.وإلا، فسيعمل مثل الرابط العادي وينتقل إلى say_hello.htm - وظيفتك كمطور هي التأكد من معالجة كلا النتيجتين بشكل مناسب.

امل ان يساعد!

Answer 3

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

ومع نضوج AJAX، بدأت تظهر طرق لجعله متاحًا.انظر في واي-اريا للأساليب الحديثة لتسهيل الوصول إلى AJAX، و جوجل أكسجاكس للحصول على طريقة جيدة لتنفيذه.

---

Answer 4

يرى

• http://juicystudio.com/article/make-ajax-work-with-screen-readers.php
• http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php
• http://www.paciellogroup.com/blog/?p=15
• http://www-03.ibm.com/able/resources/ajaxaccessibility.html

يمكنك أيضًا إلقاء نظرة على FlashAid، على الرغم من أنه ليس الحل الأمثل.(ولكن، إذا استخدمت التحسين التدريجي واستخدمت AJAX فقط عندما كان Flash موجودًا ولم يكن المستخدم يستخدم واجهة برمجة تطبيقات إمكانية الوصول، فقد يكون لديك حل معقول...للنوافذ.)

على المدى الطويل WAI-ARIA هو الحل.إنه مدعوم إلى حد ما في JAWS 10 (بيتا) وFirevox، لكنه بالتأكيد ليس كافيًا لجميع مستخدمي اليوم.

Answer 5

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

إحدى الطرق للقيام بذلك لإعادة استخدام التعليمات البرمجية الخاصة بك، هي جعل صفحتك "البسيطة" تستدعي "وظيفة" (أو أي شيء تستخدمه لمنطق جانب الخادم) يمكن استدعاؤه بنفسه، مما يؤدي إلى إرجاع JSON أو XML.

على سبيل المثال:/static/myform.asp (في جانب الخادم "، يتضمن" نفس المنطق مثل /ajax/myform.asp) وبهذه الطريقة كنت تستخدم ASP كقوالب Django.

بالطبع، باستخدام إطار عمل الجرس والصفارات كامل الميزات، يمكنك جعل هذا الأمر أسهل كثيرًا (فكر في وجود "قالب" html وxml لنفس العرض في Django)، ولكن تنطبق نفس الفكرة.

بعد القيام بذلك، فإن التكرار على جميع نقاط الارتساء في المستند الجاهز باستخدام jQuery وإضافة أحداث onclick باستخدام الرابط الخاص بنقطة الارتساء، واستبدال /static/ajax/ يمكن أن يجعل حياتك أسهل.

هل يمكن لأي شخص أن يفكر في أسباب كون هذا عبئًا كبيرًا؟أود أن أعرف ما إذا كان هناك أي خلل خطير في "فكرة التصميم" هذه.

Answer 6

أعتقد أن الإجابة المقبولة، رغم أنها جيدة بالنسبة لوقتها، أصبحت الآن قديمة.(حرفيًا كان عمره عقدًا من الزمان وقت كتابة هذه الإجابة.تم الانتهاء من WCAG 2.1 منذ بضعة أسابيع...)

ال ممارسات أنماط تصميم تأليف W3C WAI يتضمن المستند أمثلة مختلفة لعناصر واجهة المستخدم الشائعة التي يتطلب جافا سكريبت من أجل توصيل الدلالات والحالات والأدوار الصحيحة للتقنيات المساعدة.

يمكن إتاحة الوصول إلى AJAX، طالما أنك حريص على إعطاء قارئي الشاشة أدلة دلالية ذات صلة حول ما سيكون عليه التحديث داخل الصفحة قبل أن يقوم المستخدم بتنشيطه.قد تحتاج أيضًا إلى إخطار قارئ الشاشة بما تغير فعليًا بعد ذلك، على سبيل المثال.قد تعلن منطقة aria-live أنه "تم تحميل 20 عنصرًا جديدًا" أو أي شيء آخر.يتم تحقيق ذلك باستخدام جافا سكريبت.

إذا توقفت معرفتك بإمكانية الوصول عند "التحسين التدريجي"، وكنت ترى الإجابة المقبولة أعلاه كأساس منطقي لهذا الموقف، فقد تكون في حاجة إلى التحديث.الأمور تتحرك بسرعة هذه الأيام.