वेब डेवलपर के लिए सुलभता

सुलभता सुविधाओं को बेहतर बनाने से, आपकी साइट को सभी के लिए ज़्यादा बेहतर बनाया जा सकता है.

ऐसी साइटें बनाना ज़रूरी है जिनमें बिना किसी भेदभाव के सभी को शामिल किया जा सके और जिनका इस्तेमाल कोई भी कर सके. दिव्यांग बच्चों के लिए कम से कम छह मुख्य चीज़ों को ऑप्टिमाइज़ किया जा सकता है: विज़ुअल, सुनने की क्षमता, चलने-फिरने की क्षमता, जानकारी, बोली, और न्यूरल. भले ही आप वेब सुलभता के लिए नए हैं, फिर भी कई टूल और संसाधन इसमें आपकी मदद कर सकते हैं.

एक अरब से ज़्यादा लोग किसी न किसी तरह की दिव्यांगता के साथ जी रहे हैं.

ऐक्सेस करने के लिए, साइटों को अलग-अलग स्क्रीन साइज़ और स्क्रीन रीडर जैसे अलग-अलग तरह के इनपुट के साथ कई डिवाइस पर काम करना होगा. इसके अलावा, साइटों का इस्तेमाल दिव्यांग उपयोगकर्ताओं के साथ-साथ ज़्यादा से ज़्यादा उपयोगकर्ताओं के लिए किया जा सकता है.

यहां कुछ ऐसी गड़बड़ियां दी गई हैं जो आपके उपयोगकर्ताओं को हो सकती हैं:

दिखने से जुड़ी समस्याओं में, रंगों में फ़र्क़ करने से लेकर साफ़ तौर पर न दिखना जैसी समस्याएं होती हैं.

• पक्का करें कि टेक्स्ट कॉन्टेंट, कंट्रास्ट रेशियो के कम से कम थ्रेशोल्ड को पूरा करता हो.
• सिर्फ़ रंग का इस्तेमाल करके जानकारी शेयर करने से बचें. साथ ही, यह पक्का करें कि टेक्स्ट का resizable बदला जा सकता हो.
• पक्का करें कि यूज़र इंटरफ़ेस के सभी कॉम्पोनेंट का इस्तेमाल, स्क्रीन रीडर, कॉन्टेंट को बड़ा करके दिखाने, और ब्रेल डिसप्ले जैसी सहायक टेक्नोलॉजी के साथ किया जा सकता है. इससे यह पक्का करना ज़रूरी होता है कि यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को इस तरह से मार्कअप किया गया हो कि सुलभता एपीआई प्रोग्राम की मदद से किसी भी एलिमेंट की role, state, value, और title तय कर सकें.

मेरी ज़िंदगी कम दृष्टि में है और मैं अक्सर साइटों, उनके DevTools, और टर्मिनल पर ज़ूम इन करता हूं. ज़ूम की सुविधा डेवलपर के कामों की सूची में सबसे ऊपर नहीं होती है, लेकिन यह मेरे जैसे उपयोगकर्ताओं के लिए बहुत मायने रखता है.

कान से जुड़ी समस्याएं का मतलब है कि किसी व्यक्ति को पेज से आने वाली आवाज़ सुनने में समस्याएं हो सकती हैं.

• ऐसे सभी कॉन्टेंट के लिए टेक्स्ट के विकल्प दें जो पूरी तरह से टेक्स्ट न हो.
• जांच करें कि आपके यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट, आवाज़ के बिना अब भी काम कर रहे हैं या नहीं.

चलने-फिरने से जुड़ी समस्याओं में माउस, कीबोर्ड या टचस्क्रीन का इस्तेमाल न कर पाना शामिल है.

• अपने यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट के कॉन्टेंट को कीबोर्ड से फ़ंक्शनल तौर पर ऐक्सेस करने लायक बनाएं. ऐसा उन कार्रवाइयों के लिए करें जिनके लिए माउस का इस्तेमाल किया जा सकता है.
• पक्का करें कि पेजों को सहायक टेक्नोलॉजी के लिए सही तरीके से मार्कअप किया गया हो. इन टेक्नोलॉजी में स्क्रीन रीडर, वॉइस कंट्रोल सॉफ़्टवेयर, और फ़िज़िकल स्विच कंट्रोल शामिल हैं. ये टेक्नोलॉजी एक ही एपीआई का इस्तेमाल करती हैं.

समझने से जुड़ी समस्याओं का मतलब है कि उपयोगकर्ता को टेक्स्ट पढ़ने में मदद के लिए सहायक टेक्नोलॉजी की ज़रूरत हो सकती है. इसलिए, यह पक्का करना ज़रूरी है कि टेक्स्ट के विकल्प मौजूद हों.

• ऐनिमेशन का इस्तेमाल करते समय सावधानी बरतें. ऐसे वीडियो और ऐनिमेशन का इस्तेमाल न करें जिन्हें दोहराया या फ़्लैश किया जाता हो. इनसे कुछ लोगों को समस्याएं हो सकती हैं.

  prefers-reduced-motion सीएसएस मीडिया क्वेरी की मदद से, उन लोगों के लिए ऐनिमेशन और अपने-आप चलने वाले वीडियो सीमित किए जा सकते हैं जिन्हें कम मोशन पसंद है:

  /*
  If the user expresses a preference for reduced motion, don't use animations on buttons.
  */
  @media (prefers-reduced-motion: reduce) {
    button {
      animation: none;
    }
  }
  

• समय पर आधारित इंटरैक्शन से बचें.

ऐसा लग सकता है कि इस बारे में कई बातें पता हैं, लेकिन हम आपके यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट की सुलभता का आकलन करने और उसे बेहतर बनाने की प्रोसेस के बारे में बात करेंगे.

विज़ुअल सहायता के लिए, GOV.UK सुलभता टीम ने डिजिटल पोस्टर के लिए सुलभता करें और क्या न करें की एक सीरीज़ बनाई है. इनका इस्तेमाल करके, अपनी टीम के साथ सबसे सही तरीके शेयर किए जा सकते हैं.

यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट की सुलभता को मेज़र करना

सुलभता के लिए अपने पेज के यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट का ऑडिट करते समय, खुद से पूछें:

• क्या यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को सिर्फ़ कीबोर्ड के साथ इस्तेमाल किया जा सकता है?

  क्या कॉम्पोनेंट, फ़ोकस को मैनेज करता है और फ़ोकस ट्रैप से बचने की कोशिश करता है? क्या यह सही कीबोर्ड इवेंट का जवाब दे सकता है?

• क्या स्क्रीन रीडर के साथ यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट का इस्तेमाल किया जा सकता है?

  क्या आपने विज़ुअल तौर पर दी गई किसी जानकारी के लिए, टेक्स्ट के विकल्प दिए हैं? क्या आपने ARIA का इस्तेमाल करके सिमैंटिक जानकारी जोड़ी है?

• क्या आपका यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट बिना आवाज़ के काम कर सकता है?

  अपने स्पीकर बंद करें और अपने इस्तेमाल के उदाहरण देखें.

• क्या आपका यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट, रंग के बिना काम कर सकता है?

  पक्का करें कि जो लोग रंग नहीं देख सकते वे आपके यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट का इस्तेमाल कर सकते हों. कलर ब्लाइंडनेस को सिम्युलेशन करने में मदद करने वाला एक टूल है. यह एक Chrome एक्सटेंशन है, जिसे Colorblindly कहते हैं. (उपलब्ध सभी चार तरह के कलर ब्लाइंडनेस सिम्युलेशन आज़माएं.) ऐसा हो सकता है कि Daltonize एक्सटेंशन में भी आपकी दिलचस्पी हो. यह एक्सटेंशन भी आपके काम का है.

• क्या आपका यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट, हाई-कंट्रास्ट मोड के चालू होने पर काम कर सकता है?

  सभी मॉडर्न ऑपरेटिंग सिस्टम, हाई कंट्रास्ट मोड के साथ काम करते हैं. हाई कंट्रास्ट एक Chrome एक्सटेंशन है जो यहां आपकी मदद कर सकता है.

स्टैंडर्ड कंट्रोल (जैसे कि <button> और <select>) में ब्राउज़र में सुलभता सुविधाएं पहले से मौजूद होती हैं. उन पर Tab बटन का इस्तेमाल करके फ़ोकस किया जा सकता है. साथ ही, वे कीबोर्ड इवेंट (जैसे, Enter, Space, और ऐरो बटन) का इस्तेमाल करते हैं. साथ ही, इनमें सुलभता टूल में इस्तेमाल की जाने वाली सिमैंटिक भूमिकाएं, स्थितियां, और प्रॉपर्टी होती हैं. साथ ही, उनकी डिफ़ॉल्ट स्टाइल, सुलभता से जुड़ी ज़रूरी शर्तों के मुताबिक होनी चाहिए.

कस्टम यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट (इनमें <button> जैसे स्टैंडर्ड एलिमेंट को शामिल नहीं करने वाले कॉम्पोनेंट शामिल होते हैं) में सुलभता सुविधाएं पहले से मौजूद नहीं होती हैं. इसलिए, आपको यह जानकारी देनी होगी. सुलभता लागू करते समय शुरू करने का एक अच्छा तरीका यह है कि आप कॉम्पोनेंट की तुलना किसी मिलते-जुलते स्टैंडर्ड एलिमेंट से करें (या कई स्टैंडर्ड एलिमेंट के कॉम्बिनेशन से, जो इस बात पर निर्भर करता है कि आपका कॉम्पोनेंट कितना जटिल है).

ज़्यादातर ब्राउज़र डेवलपर टूल, किसी पेज के सुलभता ट्री की जांच करने की सुविधा देते हैं. Chrome DevTools में यह एलिमेंट पैनल में मौजूद सुलभता टैब में उपलब्ध है.

Firefox में एक सुलभता पैनल भी होता है.

Safari, एलिमेंट पैनल के नोड टैब में सुलभता की जानकारी दिखाता है.

इस सूची में कुछ ऐसे सवाल दिए गए हैं जिन्हें यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को ज़्यादा आसानी से ऐक्सेस करने वाला बनाने के दौरान खुद से पूछा जा सकता है.

कीबोर्ड फ़ोकस को बेहतर बनाएं

आम तौर पर, यह पक्का करें कि आपके यूआई कॉम्पोनेंट की सभी सुविधाओं को कीबोर्ड से ऐक्सेस किया जा सके. अपना उपयोगकर्ता अनुभव डिज़ाइन करते समय, सोच लें कि कीबोर्ड के साथ एलिमेंट का इस्तेमाल किस तरह किया जाएगा. साथ ही, कीबोर्ड इंटरैक्शन का एक जैसा सेट ढूंढें.

सबसे पहले, पक्का करें कि आपके पास हर कॉम्पोनेंट के लिए सही फ़ोकस टारगेट हो. उदाहरण के लिए, मेन्यू जैसा कोई कॉम्प्लेक्स कॉम्पोनेंट किसी पेज पर एक फ़ोकस टारगेट हो सकता है. हालांकि, फ़ोकस को खुद ही मैनेज करना चाहिए, ताकि ऐक्टिव मेन्यू आइटम पर हमेशा फ़ोकस रखा जा सके.

Tabindex का इस्तेमाल करना

एलिमेंट और यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट के लिए, tabindex एट्रिब्यूट का इस्तेमाल करके कीबोर्ड फ़ोकस जोड़ा जा सकता है. सिर्फ़ कीबोर्ड और सहायक टेक्नोलॉजी का इस्तेमाल करने वाले लोगों को एलिमेंट पर कीबोर्ड फ़ोकस करने की सुविधा होनी चाहिए, ताकि वे एलिमेंट से इंटरैक्ट कर सकें.

बिल्ट-इन इंटरैक्टिव एलिमेंट (जैसे, <button>) पर पूरी तरह से फ़ोकस किया जा सकता है. इसलिए, उन्हें tabindex एट्रिब्यूट की ज़रूरत नहीं होती है. उन्हें टैब में अपनी जगह बदलने की ज़रूरत होती है.

tabindex वैल्यू तीन तरह की होती हैं:

• tabindex="0" सबसे सामान्य है और एलिमेंट को नैचुरल टैब ऑर्डर (DOM ऑर्डर में तय किया गया) में रखता है.
• tabindex की वैल्यू 0 से ज़्यादा होने पर, एलिमेंट को मैन्युअल टैब क्रम में रखा जाता है. पेज पर पॉज़िटिव tabindex वैल्यू वाले सभी एलिमेंट, नैचुरल टैब क्रम में एलिमेंट से पहले, संख्या के क्रम में देखे जाते हैं.
• tabindex की वैल्यू -1 के बराबर होने पर, एलिमेंट को प्रोग्राम के हिसाब से फ़ोकस किया जा सकता है, लेकिन टैब के क्रम में नहीं.

कस्टम यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट के लिए, हमेशा 0 या -1 की tabindex वैल्यू का इस्तेमाल करें. ऐसा इसलिए, क्योंकि किसी पेज पर, एलिमेंट का क्रम पहले से तय नहीं किया जा सकता. -1 का tabindex मान खास तौर पर जटिल कॉम्पोनेंट में फ़ोकस को मैनेज करने के लिए फ़ायदेमंद होता है.

पक्का करें कि फ़ोकस हमेशा दिखता हो, चाहे डिफ़ॉल्ट फ़ोकस रिंग स्टाइल का इस्तेमाल किया गया हो या आसानी से समझ में आने वाली कस्टम फ़ोकस स्टाइल लागू करके ऐसा किया जा रहा हो. याद रखें कि कीबोर्ड इस्तेमाल करने वाले लोगों को न फंसे—वे फ़ोकस को सिर्फ़ कीबोर्ड का इस्तेमाल करके एलिमेंट से दूर ले जा सकेंगे.

ऑटोफ़ोकस सुविधा का इस्तेमाल करना

एचटीएमएल ऑटोफ़ोकस एट्रिब्यूट की मदद से, लेखक यह तय कर सकता है कि पेज लोड होने पर, किसी खास एलिमेंट पर अपने-आप फ़ोकस होना चाहिए. autofocus पहले से ही वेब फ़ॉर्म के सभी कंट्रोल के साथ काम करता है. इसमें बटन भी शामिल हैं. अपने कस्टम यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट में ऑटोफ़ोकस एलिमेंट के लिए, focus() वाला तरीका अपनाएं. यह तरीका उन सभी एचटीएमएल एलिमेंट पर काम करता है जिन्हें फ़ोकस किया जा सकता है (उदाहरण के लिए, document.querySelector('myButton').focus()).

कीबोर्ड इंटरैक्शन जोड़ें

जब आपके यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट पर फ़ोकस हो जाए, तब सही कीबोर्ड इवेंट को हैंडल करके, कॉम्पोनेंट पर फ़ोकस होने पर, कीबोर्ड इंटरैक्शन के बारे में बेहतर तरीके से बताएं. उदाहरण के लिए, उपयोगकर्ता को मेन्यू के विकल्प चुनने के लिए, ऐरो बटन का इस्तेमाल करने और बटन चालू करने के लिए Space या Enter इस्तेमाल करने की अनुमति दें. ARIA के डिज़ाइन पैटर्न की गाइड में कुछ दिशा-निर्देश दिए गए हैं.

आखिर में, पक्का करें कि आपके कीबोर्ड शॉर्टकट खोजे जा सकें. एक सामान्य तरीका यह है कि उपयोगकर्ता को शॉर्टकट मौजूद होने की जानकारी देने के लिए कीबोर्ड शॉर्टकट लेजेंड (स्क्रीन पर टेक्स्ट) का इस्तेमाल किया जाए. उदाहरण के लिए, "? आपके कीबोर्ड शॉर्टकट के लिए " होता है." इसके अलावा, इस तरह के टूलटिप का इस्तेमाल, उपयोगकर्ता को शॉर्टकट के बारे में बताने के लिए किया जा सकता है.

फ़ोकस मैनेज करने की अहमियत को बढ़ा-चढ़ाकर नहीं बताया जा सकता. इसका एक अहम उदाहरण नेविगेशन पैनल है. अगर पेज पर यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट जोड़ा जाता है, तो आपको फ़ोकस को उसके अंदर मौजूद किसी एलिमेंट पर लगाना होगा. ऐसा न करने पर, लोगों को पेज पर पहुंचने के लिए पूरे पेज पर टैब करना पड़ सकता है. इससे निराशा हो सकती है, इसलिए अपने पेज के कीबोर्ड नेविगेट किए जा सकने वाले सभी कॉम्पोनेंट पर फ़ोकस ज़रूर कर लें.

// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

स्क्रीन रीडर का सही तरीके से इस्तेमाल करना

करीब 1% से 2% लोग स्क्रीन रीडर का इस्तेमाल करते हैं. क्या आपके पास सभी ज़रूरी जानकारी को समझने और स्क्रीन रीडर और कीबोर्ड का इस्तेमाल करके कॉम्पोनेंट के साथ इंटरैक्ट करने का विकल्प है?

यहां दिए गए सवालों से, आपको स्क्रीन रीडर की सुलभता सुविधाओं के बारे में पता चलेगा.

क्या सभी कॉम्पोनेंट और इमेज में, टेक्स्ट के ऐसे विकल्प मौजूद हैं जो काम के हैं?

जहां भी किसी इंटरैक्टिव कॉम्पोनेंट के नाम या मकसद के बारे में जानकारी विज़ुअल के तौर पर दी जाती है, तो ऐसे टेक्स्ट का विकल्प दें जिसे ऐक्सेस किया जा सके.

उदाहरण के लिए, अगर आपका <fancy-menu> यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट सिर्फ़ यह बताने के लिए गियर आइकॉन दिखाता है कि यह सेटिंग मेन्यू है, तो उसे ऐक्सेस किए जा सकने वाले टेक्स्ट विकल्प की ज़रूरत होगी. जैसे, "सेटिंग" जो भी यही जानकारी दे. कॉन्टेक्स्ट के हिसाब से, आपके पास शैडो डीओएम में alt एट्रिब्यूट, aria-label एट्रिब्यूट, aria-labelledby एट्रिब्यूट या सामान्य टेक्स्ट का इस्तेमाल करके टेक्स्ट का विकल्प देने का विकल्प होता है. आपको सामान्य तकनीकी सलाह WebAIM की झटपट जानकारी में मिलेगी.

इमेज दिखाने वाले किसी भी यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट में उस इमेज के लिए वैकल्पिक टेक्स्ट देने का एक तरीका होना चाहिए, जो alt एट्रिब्यूट के जैसा होता.

क्या आपके कॉम्पोनेंट, सिमैंटिक जानकारी देते हैं?

सहायक टेक्नोलॉजी, सिमैंटिक जानकारी देती है. इस जानकारी को आम तौर पर फ़ॉर्मैटिंग, कर्सर की स्टाइल या पोज़िशन जैसे विज़ुअल संकेतों की मदद से, देखे जा सकने वाले उपयोगकर्ताओं को दिखाया जाता है. स्टैंडर्ड एलिमेंट में यह सिमैंटिक जानकारी ब्राउज़र में पहले से मौजूद होती है, लेकिन कस्टम कॉम्पोनेंट के लिए इस जानकारी को जोड़ने के लिए, आपको ARIA का इस्तेमाल करना होगा.

आम तौर पर, माउस क्लिक या कर्सर घुमाने पर होने वाले इवेंट को सुनने वाले कॉम्पोनेंट के लिए, कीबोर्ड इवेंट की खास तरह की ऑडियंस और ARIA की भूमिका होनी चाहिए. जैसे, ARIA स्टेटस और एट्रिब्यूट भी.

उदाहरण के लिए, कस्टम <fancy-slider> यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट, स्लाइडर की ARIA भूमिका ले सकता है, जिसमें कुछ मिलते-जुलते ARIA एट्रिब्यूट हैं: aria-valuenow, aria-valuemin, और aria-valuemax. इन एट्रिब्यूट को अपने कस्टम कॉम्पोनेंट की ज़रूरी प्रॉपर्टी के साथ बाइंड करके, सहायक टेक्नोलॉजी के उपयोगकर्ताओं को एलिमेंट के साथ इंटरैक्ट करने, उसकी वैल्यू बदलने, और एलिमेंट के विज़ुअल प्रज़ेंटेशन में भी उसके हिसाब से बदलाव करने की अनुमति दी जा सकती है.

<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

क्या उपयोगकर्ता रंग के बिना सब कुछ समझ सकते हैं?

रंग का इस्तेमाल सिर्फ़ जानकारी देने के तरीके के तौर पर नहीं किया जाना चाहिए. जैसे, किसी स्थिति की जानकारी देना, उपयोगकर्ता से जवाब देने के लिए कहना या डेटा को विज़ुअलाइज़ करना. उदाहरण के लिए, अगर आपके पास पाई चार्ट है, तो हर स्लाइस के लिए लेबल और वैल्यू दें, ताकि दृष्टि बाधित उपयोगकर्ता भी जानकारी को समझ सकें. भले ही, उन्हें यह न पता हो कि स्लाइस कहां से शुरू और खत्म होते हैं:

क्या इसमें सही कंट्रास्ट है?

आपके कॉम्पोनेंट में दिखने वाला कोई भी टेक्स्ट कॉन्टेंट, डब्ल्यूसीएजी एए लेवल के कम से कम कंट्रास्ट थ्रेशोल्ड के मुताबिक होना चाहिए. ऐसी हाई-कंट्रास्ट थीम उपलब्ध कराएं जो एएए के ज़्यादा थ्रेशोल्ड को पूरा करती हो. साथ ही, पक्का करें कि अगर उपयोगकर्ताओं को कस्टम कंट्रास्ट या अलग-अलग रंगों की ज़रूरत हो, तो उपयोगकर्ता एजेंट स्टाइल शीट इस्तेमाल की जा सकती हैं. अपने कॉम्पोनेंट को डिज़ाइन करते समय, कलर कंट्रास्ट चेकर का इस्तेमाल किया जा सकता है.

क्या कॉन्टेंट को एक जगह से दूसरी जगह ले जाना या फ़्लैश करना सुरक्षित और रोका जा सकता है?

उपयोगकर्ताओं के पास पांच सेकंड से ज़्यादा समय तक हिलने-डुलने, स्क्रोल करने या ब्लिंक करने वाले कॉन्टेंट को रोकने, बंद करने या छिपाने की सुविधा होनी चाहिए. आम तौर पर, कॉन्टेंट को फ़्लैश करने से बचें.

अगर किसी कॉन्टेंट को फ़्लैश करना ज़रूरी है, तो पक्का करें कि वह एक सेकंड में तीन बार से ज़्यादा फ़्लैश न हो.

सुलभता टूल और जांच

अपनी साइट की सुलभता का आकलन करने और उसके कॉम्पोनेंट का आकलन करने के लिए, 100 से ज़्यादा टूल उपलब्ध हैं. कुछ टूल ऑटोमेटेड होते हैं, जबकि कुछ टूल को मैन्युअल तौर पर टेस्ट करने की ज़रूरत होती है.

यहां कुछ ऐसी जानकारी दी गई है जिन पर आपको विचार करना चाहिए:

• Axe आपके पसंदीदा फ़्रेमवर्क या ब्राउज़र के लिए, अपने-आप सुलभता टेस्ट करने की सुविधा देता है. Axe Puppeteer का इस्तेमाल, अपने-आप होने वाले सुलभता टेस्ट लिखने के लिए किया जा सकता है.

• Lighthouse सुलभता ऑडिट सुविधा से, सुलभता से जुड़ी सामान्य समस्याओं का पता लगाने में मदद मिलती है. सुलभता स्कोर, कुल उपयोगकर्ताओं के असर के आकलन के आधार पर सभी सुलभता ऑडिट का औसत है. लगातार इंटिग्रेशन की मदद से सुलभता की निगरानी करने के लिए, Lighthouse CI देखें.

  

• Tenon.io का इस्तेमाल सुलभता से जुड़ी आम समस्याओं की जांच करने के लिए किया जा सकता है. Tenon को बिल्ड टूल, ब्राउज़र (एक्सटेंशन के ज़रिए), और यहां तक कि टेक्स्ट एडिटर के लिए भी इंटिग्रेट करने की सुविधा मिलती है.

• कॉम्पोनेंट की सुलभता समस्याओं को हाइलाइट करने के लिए, लाइब्रेरी और फ़्रेमवर्क के हिसाब से बने कई टूल उपलब्ध हैं. उदाहरण के लिए, अपने एडिटर में 'रिऐक्ट कॉम्पोनेंट' से जुड़ी सुलभता समस्याओं को हाइलाइट करने के लिए eslint-plugin-jsx-a11y का इस्तेमाल करें.

  

  अगर आप Angular का इस्तेमाल करते हैं, तो codelyizer इन-एडिटर सुलभता ऑडिट भी देता है:

  

सहायक टेक्नोलॉजी की मदद से काम करना

• सुलभता जांचने वाले टूल (Mac) या Windows Automation API टेस्टिंग टूल और AccProbe (Windows) का इस्तेमाल करके, यह जांच की जा सकती है कि सहायक टेक्नोलॉजी, वेब कॉन्टेंट को कैसे देखते हैं. about://accessibility पर नेविगेट करके, Chrome की तरफ़ से बनाया गया सुलभता ट्री भी देखा जा सकता है.
• Mac पर स्क्रीन रीडर की सुविधा की जांच करने का सबसे अच्छा तरीका VoiceOver का इस्तेमाल करना है. इसे चालू या बंद करने के लिए ⌘F5, पेज पर जाने के लिए Ctrl+Option ←→, और सुलभता ट्री को ऊपर और नीचे ले जाने के लिए Ctrl+Shift+Option + ↑↓ का इस्तेमाल करें. ज़्यादा जानकारी वाले निर्देशों के लिए, VoiceOver के निर्देशों की पूरी सूची और VoiceOver वेब कमांड की सूची देखें.

• Windows पर, NVDA एक मुफ़्त, ओपन सोर्स स्क्रीन रीडर है. हालांकि, देखने वाले लोगों के लिए इसमें बहुत सी चीज़ें सीखने को मिलती हैं.

  

• ChromeOS में पहले से मौजूद स्क्रीनरीडर मौजूद है.

वेब पर सुलभता को बेहतर बनाने के लिए, हमें अभी बहुत कुछ करना है. वेब कैलेंडर के मुताबिक:

• हर पांच में से चार साइटों में ऐसा टेक्स्ट होता है जो बैकग्राउंड के साथ मिलता-जुलता होता है. इस वजह से, इन्हें पढ़ा नहीं जा सकता.
• 49.91% पेजों में अब भी अपनी कुछ इमेज के लिए alt एट्रिब्यूट नहीं हैं.
• बटन या लिंक का इस्तेमाल करने वाले सिर्फ़ 24% पेजों में लेबल शामिल होते हैं.
• सिर्फ़ 22.33% पेजों में ही अपने सभी फ़ॉर्म इनपुट के लिए लेबल मिलते हैं.

हम ऐसा अनुभव बनाने के लिए बहुत कुछ कर सकते हैं, जिसका ऐक्सेस सभी के पास हो.