पहुंचीयता

docs.scrimba.com

लोग विभिन्न तरीकों से वेब तक पहुंचते हैं। कुछ एक स्क्रीन को देखते हैं और माउस हिलाते हैं। कुछ स्क्रीन नहीं देख सकते और इसे ज़ोर से पढ़ा जाता है सुनते हैं। कुछ कभी माउस को छूते नहीं हैं और कीबोर्ड, या आवाज़, या एक स्विच के साथ जो वे दबाते हैं उसके साथ एक पृष्ठ के माध्यम से चलते हैं। पहुंचीयता पृष्ठ बनाने का अभ्यास है जिसे सभी उपयोग कर सकें, और इसका अधिकांश भाग HTML को उस तरह लिखने तक आता है जैसा कि इसका अर्थ है।

पहुंचीयता क्यों महत्वपूर्ण है

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

एक इमारत के बारे में सोचो जिसके पास सीढ़ियों के साथ एक रैंप है। रैंप उन लोगों की मदद करता है जो सीढ़ियों को संभाल नहीं सकते, और यह किसी को भी कुछ नहीं लेता है जो कर सकते हैं। सुलभ HTML वही विचार है: यह पृष्ठ को अधिक लोगों के लिए खोलता है बिना किसी के लिए इसे बदतर बनाए।

आश्वस्त करने वाला हिस्सा यह है कि HTML शुरुआत में सुलभ है। आप सही तत्व का उपयोग करके सामग्री के प्रत्येक टुकड़े के लिए अधिकांश तरीके से वहां मुफ्त में पहुंचते हैं।

पहुंचीयता, अक्सर a11y के लिए संक्षिप्त (एक "a", फिर ग्यारह अक्षर, फिर एक "y"), आपके पृष्ठ को लोगों के वेब तक पहुंचने के तरीकों की पूरी सीमा में काम करने के बारे में है: स्क्रीन रीडर जो पृष्ठ बोलते हैं, कीबोर्ड-केवल नेविगेशन, आवाज़ नियंत्रण, स्क्रीन आवर्धन, और कम रंग या उच्च-विपरीत प्रदर्शन मोड।

व्यावहारिक फ्रेमिंग जो सबसे अधिक मदद करती है: HTML आपको शुरुआत की स्थिति के रूप में पहुंचीयता देता है, न कि कुछ ऐसा जो आप अंत में जोड़ते हैं। अधिकांश काम सही तत्व को चुनना और ब्राउज़र द्वारा पहले से किए गए को पूर्ववत नहीं करना है। विफलताएं कारणों के एक छोटे सेट से आती हैं: सामान्य तत्वों से पुनर्निर्मित कस्टम विजेट, कोई लेबल के बिना फॉर्म फील्ड, कमजोर रंग विपरीत, और व्यवहार जो केवल एक माउस के लिए प्रतिक्रिया करता है।

पहुंचीयता यह है कि सहायक तकनीक (सॉफ़्टवेयर या हार्डवेयर जो किसी को कंप्यूटर संचालित करने में मदद करता है, जैसे एक स्क्रीन रीडर जो पृष्ठ बोलता है, एक स्विच डिवाइस को क्लिक करने के बजाय दबाया जाता है, या आवाज़ नियंत्रण) का उपयोग करने वाले लोग आपके पृष्ठ को समझ सकते हैं, संचालित कर सकते हैं और समझ सकते हैं। संदर्भ मानक WCAG है, वेब सामग्री पहुंचीयता दिशानिर्देश, चार सिद्धांतों के चारों ओर संगठित: सामग्री को समझदारी, संचालन योग्य, समझदारी और मजबूत होना चाहिए।

दो परिणाम पकड़ने के लायक हैं। पहला, वही अच्छी तरह से बनी हुई संरचना जो सहायक तकनीक पर निर्भर करती है वह भी वह है जो खोज इंजन और अन्य मशीनें DOM से पढ़ते हैं (ब्राउज़र की पृष्ठ की इन-मेमोरी मॉडल), इसलिए पहुंचीयता और SEO एक ही दिशा में खींचते हैं प्रतिस्पर्धा करने के बजाय आपके समय के लिए। दूसरा, कई जगहों पर पहुंचीयता सार्वजनिक सामने वाली साइटों के लिए एक कानूनी आवश्यकता है, अच्छा नहीं। सभी के बारे में सोचने का उपयोगी तरीका: एक सुलभ पृष्ठ अधिकतर एक सही तरीके से निर्मित है। इस अध्याय में लगभग सब कुछ मानक HTML है जिसका उद्देश्य है।

Junoपहुंचीयता क्यों महत्वपूर्ण है पहुंचीयता का अर्थ है सभी आपके पृष्ठ का उपयोग कर सकते हैं, वे जो भी हों और वे वहां कैसे जाएं। अच्छा हिस्सा यह है कि HTML आपको अधिकांश मुफ्त में देता है जब आप काम के लिए सही तत्व चुनते हैं। एक रैंप की कल्पना करो सीढ़ियों के आगे: अधिक लोग अंदर जाते हैं, और कोई भी बदतर नहीं है।

Junoपहुंचीयता क्यों महत्वपूर्ण है पहुंचीयता स्क्रीन रीडर, कीबोर्ड, बढ़ाई, और बीच में सभी के लिए काम करने वाला है। आप एक अच्छी जगह से शुरुआत करते हैं क्योंकि HTML बॉक्स से बाहर सुलभ है, इसलिए अधिकांश विफलताएं कस्टम विजेट और लापता लेबल के साथ पूर्ववत करने से आती हैं। सही तत्वों के साथ बनाएं और आप पहले से ही वहां अधिकांश तरीके हैं।

Junoपहुंचीयता क्यों महत्वपूर्ण है मानक WCAG है और इसके चार सिद्धांत हैं: समझदारी, संचालन योग्य, समझदारी, मजबूत। वही संरचना जो एक स्क्रीन रीडर को मदद करती है एक खोज क्रॉलर को DOM पढ़ने में मदद करती है, इसलिए यह आपके समय पर एक अलग कर नहीं है। बाकी अध्याय को सामान्य HTML के रूप में मानें जिसका अर्थ है, क्योंकि यह वही है।

शब्दार्थ HTML नींव के रूप में

पहुंचीयता के लिए आप सबसे प्रभावी एकमात्र चीज़ है एक तत्व का उपयोग करना जो सामग्री के अर्थ से मेल खाता है, न कि एक सामान्य जो सही दिखने के लिए स्टाइल किया गया है।

शब्दार्थ HTML का अर्थ है सामग्री क्या है के लिए एक टैग चुनना, यह कैसे दिखता है इसके लिए नहीं। एक शीर्षक <h1> से <h6> का उपयोग करता है। एक बटन <button> का उपयोग करता है। एक लिंक <a> का उपयोग करता है। एक सूची <ul> या <ol> का उपयोग करता है। इनमें से प्रत्येक अर्थ ले आता है जो एक स्क्रीन रीडर घोषित कर सकता है, इसलिए एक श्रोता जानता है "यह एक बटन है" या "यह एक शीर्षक है" इसे देखे बिना।

यह घर चलने पर बॉक्स को लेबल करने की तरह है। "रसोई" चिह्नित एक बॉक्स जो भी इसे करता है वह मदद करता है, केवल व्यक्ति जो इसे पैक करता है नहीं। शब्दार्थ टैग आपकी सामग्री को उसी तरह लेबल करते हैं, इसलिए ब्राउज़र और सहायक तकनीक जानते हैं कि प्रत्येक भाग क्या है।

व्यावहारिक रूप से इसका मतलब है <button> तक पहुंचना जब आप एक बटन चाहते हैं, न कि एक <div> आप एक की तरह स्टाइल किया। <div> को समान दिख बनाया जा सकता है, लेकिन यह कहता है कि यह क्या है। शब्दार्थ HTML अध्याय पूरे सेट के माध्यम से जाता है।

शब्दार्थ तत्व व्यवहार और अर्थ के साथ पहले से जुड़े आते हैं। एक <button> focusable है, Enter और Space का जवाब देता है, और एक बटन के रूप में घोषित किया जाता है। एक <nav> एक नेविगेशन क्षेत्र को चिह्नित करता है। शीर्षक <h1> से <h6> एक रूपरेखा बनाते हैं जो एक स्क्रीन रीडर उपयोगकर्ता के माध्यम से कूद सकता है, जिस तरह एक दृष्ट पाठक एक अनुभाग के लिए skim करता है।

नियम जो सबसे अधिक परेशानी बचाता है: अपना निर्माण करने से पहले नेटिव तत्व का उपयोग करें। एक <div role="button" tabindex="0"> एक क्लिक हैंडलर के साथ काम करने के लिए बनाया जा सकता है, लेकिन आप फोकस, कीबोर्ड समर्थन, और भूमिका को हाथ से पुनः कार्यान्वित कर रहे हैं, और उन टुकड़ों में से एक फिसलने का प्रवृत्ति है। एक वास्तविक <button> आपको सब कुछ एक बार में देता है। भूमिका तत्व (<header>, <nav>, <main>, <aside>, <footer>) पृष्ठ पैमाने पर समान काम करते हैं: वे एक स्क्रीन रीडर उपयोगकर्ता को एक क्षेत्र को सीधे छोड़ने देते हैं इसके बजाय इसके ऊपर सब कुछ सुनना। शब्दार्थ HTML अध्याय प्रत्येक को कवर करता है।

शब्दार्थ HTML नींव है क्योंकि ब्राउज़र प्रत्येक शब्दार्थ तत्व को एक भूमिका में मैप करता है पहुंचीयता वृक्ष में (पृष्ठ का सरलीकृत संस्करण जो सहायक तकनीक पढ़ता है, नीचे ARIA अनुभाग में पूरी तरह से वर्णित)। एक <button> बटन भूमिका, अपनी फोकस व्यवहार, और अपनी कीबोर्ड हैंडलिंग प्राप्त करता है आपके से कोई काम के साथ नहीं। इसे <div> से पुनर्निर्मित करें और आप उस में से कोई भी विरासत नहीं: आप अब focusability, key हैंडलिंग, और घोषित भूमिका स्वयं हैं, और हर गैप किसी के लिए एक दोष है।

दो आदतें अधिकांश वजन ले आती हैं। शीर्षक स्तरों को एक वास्तविक संरचना दें: पृष्ठ के लिए एक <h1>, फिर <h2> और <h3> नेस्टेड स्तर छोड़े बिना, क्योंकि स्क्रीन रीडर उपयोगकर्ता शीर्षक के द्वारा नेविगेट करते हैं और <h2> से <h4> तक एक कूद एक खंड को पढ़ता है जो गायब हो गया है। और भूमिका तत्वों (<main>, <nav>, <header>, <footer>, <aside>) का उपयोग करें ताकि पृष्ठ नेविगेट करने योग्य क्षेत्रों को प्रकट करे। विफलता मोड को पहचानना है "div सूप", एक पृष्ठ लगभग पूरी तरह से <div> और <span> से इकट्ठा किया जाता है: यह पूरी तरह से रेंडर करता है और सहायक तकनीक को लगभग कुछ भी उजागर करता है, क्योंकि वे दो तत्व कोई भूमिका बिल्कुल नहीं ले आते हैं।

Junoशब्दार्थ HTML नींव के रूप में टैग के लिए चुनें कि सामग्री क्या है, यह कैसे दिखता है नहीं: <button> एक बटन के लिए, <h1> एक शीर्षक के लिए, <a> एक लिंक के लिए। प्रत्येक पहले से ही एक स्क्रीन रीडर को बताता है कि यह क्या है, इसलिए आप यह मुफ्त में प्राप्त करते हैं। एक स्टाइल की गई <div> समान दिख सकती है और फिर भी कुछ नहीं कहती।

Junoशब्दार्थ HTML नींव के रूप में नेटिव तत्व फोकस, कीबोर्ड समर्थन, और एक घोषित भूमिका के साथ आते हैं पहले से ही तार में, इसलिए एक <button> एक <div> को हराता है जो एक की तरह दिखावा कर रहा है। असली तत्व का उपयोग करने से पहले इसे फिर से बनाएं, और <nav> और <main> जैसे भूमिका पर झुकें ताकि लोग चारों ओर छोड़ दें। यह सब है वहाँ सही है।

Junoशब्दार्थ HTML नींव के रूप में हर शब्दार्थ तत्व पहुंचीयता वृक्ष में एक भूमिका के लिए मैप करता है, इसलिए <button> आपको भूमिका, फोकस, और चाबी एक साथ देता है, जबकि एक <div> आपको सभी तीन के लिए एक बिल देता है। शीर्षक को क्रम में रखें कोई छोड़ी गई स्तरों के साथ नहीं, क्योंकि लोग उनके द्वारा नेविगेट करते हैं। Div सूप ठीक से प्रस्तुत करता है और सहायक तकनीक को कुछ भी नहीं बताता है, जो पूरी समस्या है इसके साथ।

पाठ विकल्प, लेबल, फोकस, और कीबोर्ड

कुछ सामग्री अपने लिए बात नहीं कर सकती। एक चित्र एक स्क्रीन रीडर के लिए अदृश्य है जब तक आप इसे वर्णन नहीं करते। एक फॉर्म फील्ड तब तक एक अनुमान है जब तक इसे लेबल नहीं किया जाता। और एक पृष्ठ जो केवल माउस के लिए प्रतिक्रिया करता है उन सभी को छोड़ देता है जो एक का उपयोग नहीं करते। ये चार क्षेत्र हैं जहां थोड़ी सी देखभाल लंबा रास्ता जाता है।

कुछ विश्वसनीय आदतें अधिकांश को कवर करती हैं:

• छवियों को alt पाठ की आवश्यकता है। alt विशेषता किसी को जो नहीं देख सकता है उसके लिए एक चित्र का वर्णन करता है। यदि चित्र केवल सजावटी है, तो एक खाली alt="" स्क्रीन रीडर को इसे छोड़ने के लिए कहता है।

<img src="red-fox.jpg" alt="लाल बालिस्टर बर्फ में सोया हुआ।">

• फॉर्म फील्ड को लेबल की आवश्यकता है। एक <label> आगंतुक और स्क्रीन रीडर दोनों को बताता है कि एक फील्ड में क्या टाइप करना है।

<label for="email">ईमेल पता</label>
<input id="email" type="email">

• बटन और लिंक को स्पष्ट पाठ की आवश्यकता है। अकेले "और अधिक पढ़ें" संदर्भ के बाहर पढ़ने पर अस्पष्ट है; "टिकट की कीमतों के बारे में अधिक पढ़ें" अपने आप में समझ में आता है।
• कीबोर्ड क्रम पढ़ने के आदेश से मेल खाना चाहिए। कोई Tab दबाकर पृष्ठ के माध्यम से जाता है जिस क्रम में तत्व आपके HTML में दिखाई देते हैं, इसलिए उस क्रम को समझदारी रखें।

छवियां और मीडिया और फॉर्म और इनपुट अध्याय alt पाठ और लेबल पर गहराई से जाते हैं।

हर फॉर्म नियंत्रण को एक <label> के साथ जोड़ो। विश्वसनीय तरीका लेबल के for विशेषता को इनपुट के id के साथ मिलान करना है:

<label for="postcode">पिन कोड</label>
<input id="postcode" type="text" name="postcode">

अब लेबल पर क्लिक करने से फील्ड फोकस होता है, और एक स्क्रीन रीडर लेबल की घोषणा करता है जब फील्ड फोकस प्राप्त करता है। फॉर्म और इनपुट अध्याय विविधताओं को कवर करता है।

Alt पाठ के लिए, उद्देश्य का वर्णन करें, पिक्सल नहीं: alt="कंपनी लोगो" रंगों और आकारों की एक सूची को हरा देता है, और एक सजावटी चित्र एक खाली alt="" लेता है इसलिए इसे एक फाइल नाम के रूप में पढ़ने के बजाय छोड़ दिया जाता है।

फोकस क्रम DOM में तत्वों के क्रम का अनुसरण करता है, इसलिए आपके स्रोत क्रम को दृश्य पढ़ने के क्रम से मेल खाते हुए रखें। सकारात्मक tabindex मानों से बचें (tabindex="1" और ऊपर); वे एक अलग टैब अनुक्रम आविष्कार करते हैं जो सही रखना मुश्किल है। एक कस्टम नियंत्रण को प्राकृतिक क्रम में जोड़ने के लिए tabindex="0" का उपयोग करें, और tabindex="-1" कुछ focusable बनाने के लिए स्क्रिप्ट द्वारा लेकिन टैब द्वारा नहीं।

कीबोर्ड operability के लिए नियम छोटा है: जो कुछ भी आप एक माउस के साथ कर सकते हैं उसे कीबोर्ड के साथ काम करना चाहिए। यदि एक क्लिक एक मेनू खोलता है, तो Enter को भी करना चाहिए। और एक दृश्यमान फोकस आउटलाइन रखें ताकि कीबोर्ड उपयोगकर्ता यह देख सकें कि वे कहां हैं। रंग विपरीत यहाँ भी महत्वपूर्ण है: WCAG सामान्य पाठ और इसकी पृष्ठभूमि के बीच कम से कम 4.5:1 के विपरीत अनुपात के लिए पूछता है, और कभी अकेले रंग पर अर्थ निर्भर नहीं करते, क्योंकि सभी समान रंगों को भेद नहीं करते हैं।

ये चार क्षेत्र सभी जगह हैं जहां DOM को उस अर्थ को ले जाना होगा जो दृश्य लेआउट एक दृष्ट माउस उपयोगकर्ता के लिए ले आता है।

लेबल। एक <label> एक नियंत्रण से for/id द्वारा जुड़ा, या इनपुट को लपेटकर, उस नियंत्रण को अपना सुलभ नाम देता है (पाठ सहायक तकनीक एक तत्व के लिए घोषित करता है)। कोई लेबल के साथ, एक स्क्रीन रीडर फील्ड के प्रकार को पढ़ता है और इसके उद्देश्य के बारे में कुछ नहीं। Placeholder पाठ एक लेबल नहीं है: यह इनपुट पर गायब हो जाता है और असंगत रूप से घोषित किया जाता है।

पाठ विकल्प। alt एक <img> का सुलभ नाम है। इसे उद्देश्य द्वारा लिखें, उपस्थिति नहीं। एक सजावटी चित्र alt="" लेता है (खाली, वर्तमान लेकिन खाली) इसलिए इसे सुलभता वृक्ष से dropped किया जाता है; alt को पूरी तरह से छोड़ना अलग है, और कुछ स्क्रीन रीडर फाइल नाम को पढ़ने के लिए वापस आते हैं, जो किसी की मदद नहीं करता है।

फोकस। फोकस क्रम DOM क्रम है जब तक आप इसे ओवरराइड नहीं करते, और सकारात्मक tabindex लगभग हमेशा एक गलती है क्योंकि यह एक दूसरा टैब अनुक्रम बनाता है जिसे आप फिर दृश्य लेआउट के विरुद्ध बनाए रखना है। एक कस्टम नियंत्रण को प्राकृतिक क्रम में फोल्ड करने के लिए tabindex="0" का उपयोग करें और एक तत्व को केवल स्क्रिप्ट द्वारा focusable बनाने के लिए tabindex="-1" का उपयोग करें, जो आपको एक action के बाद फोकस को स्थानांतरित करने की आवश्यकता होती है। एक दृश्यमान फोकस संकेतक रखें: कभी भी outline: none को बदली के बिना सेट न करें, या कीबोर्ड उपयोगकर्ता अपनी स्थिति का ट्रैक खो देते हैं। एक कीबोर्ड जाल के लिए भी देखें (फोकस जो एक कीबोर्ड उपयोगकर्ता को स्थानांतरित कर सकता है लेकिन बाहर नहीं), जो WCAG विशेष रूप से कहता है।

कीबोर्ड और विपरीत। हर operation को कीबोर्ड द्वारा पहुंचने योग्य और संचालन योग्य होना चाहिए, एक तार्किक क्रम में। विपरीत के लिए, WCAG AA शरीर पाठ पर 4.5:1 और बड़े पाठ पर 3:1 और एक नियंत्रण की दृश्य सीमा पर पूछता है, और अर्थ को कभी भी अकेले रंग पर सवार नहीं होना चाहिए। एक आवश्यक क्षेत्र केवल लाल में चिह्नित उन सभी के लिए अदृश्य है जो अंतर को नहीं समझते हैं; इसे पाठ या एक icon के साथ जोड़ी।

Junoपाठ विकल्प, लेबल, फोकस, और कीबोर्ड चार छोटी आदतें अधिकांश को ले आती हैं: छवियों को एक alt, फॉर्म फील्ड को एक <label>, बटन और लिंक पाठ जो अपने आप में समझ में आता है, और टैब क्रम को पढ़ने के आदेश से मेल खाता हुआ रखें। उनमें से कोई भी लंबा नहीं लेता। सजावटी छवियां एक खाली alt="" प्राप्त करती हैं इसलिए वे छोड़ दी जाती हैं।

Junoपाठ विकल्प, लेबल, फोकस, और कीबोर्ड मेल खाते for और id के साथ हर इनपुट को एक <label> तक ले जाएं, और alt द्वारा उद्देश्य लिखें, सजावटी के लिए खाली। फोकस क्रम को DOM क्रम के रूप में रखें और सकारात्मक tabindex को छोड़ें। याद रखने की लाइन: जो कुछ भी माउस कर सकता है कीबोर्ड को भी करना चाहिए, और अपना विपरीत 4.5:1 तक जांचें।

Junoपाठ विकल्प, लेबल, फोकस, और कीबोर्ड लेबल और alt एक तत्व का सुलभ नाम सेट करते हैं, इसलिए एक placeholder एक लेबल नहीं है और एक missing alt एक खाली नहीं है। फोकस को DOM क्रम में छोड़ें, सकारात्मक tabindex से बचें, और कभी भी फोकस आउटलाइन को बदली के साथ प्रतिस्थापित किए बिना न हटाएं। पाठ पर 4.5:1 को हिट करें और कभी भी रंग को एकमात्र संकेत न दें, या एक लाल-केवल आवश्यक मार्कर तक किसी को भी पहुंचता है जो लाल नहीं देख सकता है।

ARIA, और इसे पहले क्यों नहीं पहुंचना चाहिए

HTML विशेषताओं का एक सेट है जो विशेष रूप से पहुंचीयता के लिए बनाया गया है, जिसे ARIA कहा जाता है। यह सही जगह पर उपयोगी है, और यह प्लेटफॉर्म के सबसे गलत इस्तेमाल किए गए भागों में से एक है, इसलिए यह समझने के लायक है कि यह क्या करता है और कब इसे अकेला छोड़ना है।

ARIA Accessible Rich Internet Applications के लिए खड़ा है। यह अतिरिक्त विशेषताओं का एक सेट है जो आप एक तत्व में जोड़ सकते हैं सहायक तकनीक को इसके बारे में अधिक बताने के लिए। नाम इसे पहुंचने के लिए पहली tool की तरह लगता है, और यह आमतौर पर आखिरी है।

कारण सरल है: ARIA अधिकांश वर्णन कर सकता है, HTML पहले से ही अपने आप कहता है। एक <button> पहले से ही एक बटन के रूप में घोषित किया जाता है। इसमें role="button" जोड़ना कुछ भी नहीं बदलता है। यदि आप अपने आप को एक तत्व की व्याख्या करने के लिए ARIA जोड़ते हुए पाते हैं, तो यह आमतौर पर एक संकेत है कि प्लेन HTML तत्व में स्वैप करने का समय है जो पहले से ही कहता है।

एक चलते बॉक्स में एक स्टिकी नोट की कल्पना करो। यदि बॉक्स पहले से ही "रसोई" मुद्रित है, तो "रसोई" पढ़ने वाली एक स्टिकी नोट केवल अव्यवस्था जोड़ता है। उस बॉक्स के लिए नोट बचाएं जिसका अपना लेबल नहीं है। ARIA पृष्ठ के उन हिस्सों के लिए है जो HTML के पास कोई तत्व नहीं है, जो यह लगता है कि दुर्लभ है।

ARIA एक तत्व में तीन प्रकार की जानकारी जोड़ता है: भूमिकाएं (यह क्या है, like role="dialog"), राज्य (इसकी वर्तमान स्थिति, जैसे aria-expanded="false"), और गुण (अतिरिक्त संबंध, जैसे aria-describedby कुछ मदद पाठ की ओर इशारा करते हुए)। स्क्रीन रीडर इन्हें कस्टम विजेट की घोषणा करने के लिए उपयोग करते हैं जिनके पास नेटिव HTML समकक्ष नहीं है, जैसे एक टैब पैनल या एक स्लाइडर।

प्रमुख मार्गदर्शन ARIA का पहला नियम है: ARIA का उपयोग न करें यदि एक नेटिव तत्व पहले से ही काम करता है। एक नेटिव <button> <div role="button"> को हर बार हराता है, क्योंकि नेटिव तत्व व्यवहार लाता है और ARIA विशेषता केवल एक लेबल लाता है। बदतर, एक गलत या पुरानी ARIA विशेषता कोई नहीं होने से बदतर है, क्योंकि यह अन्यथा ब्राउज़र कहेगा को ओवरराइड करता है। गलत तत्व पर aria-hidden="true" डालें और आप स्क्रीन रीडर उपयोगकर्ताओं से असली सामग्री छिपाते हैं जबकि यह स्क्रीन पर दृश्यमान बैठता है। ARIA तक पहुंचें जब आप एक विजेट बनाते हैं जो HTML के पास कोई तत्व नहीं है, और फिर विशेषताओं का आविष्कार करने के बजाय एक स्थापित पैटर्न का पालन करें।

उस चीज़ के साथ शुरुआत करें जो ARIA संपादित करता है। सुलभता वृक्ष एक समानांतर संरचना है जो ब्राउज़र DOM के साथ-साथ बनाता है। प्रत्येक तत्व के लिए यह एक भूमिका (तत्व क्या है: बटन, लिंक, शीर्षक), इसके राज्य और गुण (स्थितियां और संबंध, जैसे aria-expanded, aria-checked, या disabled), और इसका सुलभ नाम और विवरण (पाठ जो घोषित किया जाता है) रिकॉर्ड करता है। सहायक तकनीक इस वृक्ष को पढ़ता है, न कि आपके CSS को और न ही कच्चे HTML को।

ARIA उस वृक्ष को सीधे संपादित करने के लिए शब्दावली है: भूमिकाएं (role="tablist"), राज्य जो समय के साथ बदलते हैं (aria-selected="true"), और गुण जो अधिक स्थिर संबंधों का वर्णन करते हैं (aria-labelledby, aria-controls)। ARIA का पहला नियम यह है कि यदि एक नेटिव HTML तत्व या विशेषता पहले से ही आपको भूमिका, राज्य, या गुण देता है जिसकी आपको आवश्यकता है, इसे उपयोग करें और कोई ARIA न जोड़ें। कारण यह है कि ARIA केवल सुलभता वृक्ष को बदलता है और अपने आप में कोई व्यवहार नहीं जोड़ता है। एक <div> पर role="button" इसे एक बटन कहने के लिए एक स्क्रीन रीडर बनाता है, लेकिन यह कोई focusability, कोई Enter या Space हैंडलिंग, और कोई disabled समर्थन देता है। आप स्वयं प्रत्येक को जोड़ देंगे, और जिस दिन आप एक को भूल जाते हैं उस दिन आपके पास एक नियंत्रण है जो एक बटन की घोषणा करता है लेकिन एक की तरह कार्य नहीं करता है, जो एक ईमानदार <div> से बदतर है।

कुछ नियम ARIA को नुकसान पहुंचाने से रखते हैं जो इसे रोकने का मतलब है। नेटिव तत्वों को पसंद करें। नेटिव semantics को ओवरराइड न करें (एक <button> पर role="heading" नहीं)। एक subtree के अंदर interactive तत्वों को aria-hidden="true" चिह्नित न करें, या आप focusable नियंत्रण बनाते हैं जो एक स्क्रीन रीडर नहीं देख सकता। और अपने JavaScript के साथ राज्य को सिंक्रोनाइज़ रखें, क्योंकि एक पुराना aria-expanded उपयोगकर्ता को झूठ बोलता है। जब आपको ARIA की आवश्यकता होती है, तो WAI-ARIA लेखन practices से बनाएं, सामान्य विजेट के लिए प्रकाशित पैटर्न, शुरुआत से विशेषताओं की रचना करने के बजाय। इसमें से कुछ को भी परीक्षण करने के लिए, ब्राउज़र की सुलभता inspector दिए गए तत्व के लिए computed भूमिका, नाम, और राज्य दिखाता है, जो सहायक तकनीक को प्राप्त होगा।

JunoARIA, और इसे पहले क्यों नहीं पहुंचना चाहिए ARIA अतिरिक्त विशेषताओं का एक सेट है जो सहायक तकनीक को एक तत्व का वर्णन करते हैं। यह पहली चीज़ पहुंचने की तरह लगता है और यह आमतौर पर आखिरी है, क्योंकि एक असली <button> पहले से ही कहता है कि यह एक बटन है। ARIA को उस दुर्लभ हिस्से के लिए बचाएं जो HTML के पास कोई तत्व नहीं है, और बाकी सब कुछ सादा रखें।

JunoARIA, और इसे पहले क्यों नहीं पहुंचना चाहिए ARIA कस्टम विजेट के लिए भूमिकाएं, राज्य, और गुण जोड़ता है जो HTML के पास कोई तत्व नहीं है। ARIA का पहला नियम यह है कि skip जब एक नेटिव तत्व पहले से ही काम करता है, क्योंकि एक गलत या पुरानी विशेषता कोई नहीं होने से बदतर है। यदि आप एक <button> को एक बटन के रूप में लेबल कर रहे हैं, रोकें और बटन का उपयोग करें।

JunoARIA, और इसे पहले क्यों नहीं पहुंचना चाहिए ARIA सुलभता वृक्ष संपादित करता है: भूमिकाएं, राज्य, और गुण, और कुछ नहीं, इसलिए यह कभी व्यवहार नहीं जोड़ता। यह ARIA के पहले नियम के लिए पूरा कारण है, क्योंकि एक <div> पर role="button" एक बटन की घोषणा करता है जिसके पास कोई keys नहीं और कोई फोकस नहीं जब तक आप उन्हें बनाते हैं। अपने JavaScript के साथ राज्य को सिंक्रोनाइज़ रखें, और जब आपको एक विजेट की आवश्यकता हो तो विशेषताओं का आविष्कार करने के बजाय एक प्रकाशित पैटर्न की प्रतिलिपि करें।

एक त्वरित स्व-ऑडिट

आपको सबसे आम समस्याओं को पकड़ने के लिए विशेषज्ञ सॉफ़्टवेयर की आवश्यकता नहीं है। आपकी मशीन पर पहले से मौजूद tools के साथ कुछ चेक अधिकांश को ढूंढते हैं, और यह केवल कुछ मिनट चलाने के लिए लेता है।

यहाँ एक छोटी सूची है जो आप किसी भी पृष्ठ पर चला सकते हैं:

• माउस को एक तरफ रखें और Tab दबाएं। क्या आप हर लिंक और बटन तक पहुंच सकते हैं, एक क्रम में जो समझदारी है? क्या आप उन्हें Enter के साथ सक्रिय कर सकते हैं?
• क्या हर चित्र में एक alt विशेषता है?
• क्या हर फॉर्म फील्ड के पास एक <label> है?
• क्या आपके बटन और लिंक अभी भी समझ में आते हैं जब अपने आप में पढ़ा जाता है?
• क्या पाठ इसकी पृष्ठभूमि के विरुद्ध स्पष्ट पढ़ने के लिए है?

अपने खुद के पृष्ठ पर इन्हें चलाना त्वरित है, और यह समस्याओं को पकड़ता है जो लोग सबसे अधिक मारते हैं। यदि Tab कहीं फंस जाता है, या एक चित्र के पास कोई alt नहीं है, तो आपने कुछ ऐसा पाया है जो ठीक करने के लायक है।

अपने वर्कफ़्लो में एक दोहराए जाने योग्य पास बनाएं:

1. कीबोर्ड। पूरे पृष्ठ के माध्यम से Tab। हर interactive तत्व को पहुंचने योग्य होना चाहिए, एक समझदारी के क्रम में, एक दृश्यमान फोकस indicator के साथ, और Enter या Space के साथ operable। यदि फोकस गायब हो जाता है या फंस जाता है, तो कुछ और करने से पहले इसे ठीक करें।
2. शीर्षक और भूमिकाएं। पुष्टि करें कि एक <h1> है, कि शीर्षक स्तरों को छोड़ते नहीं हैं, और मुख्य क्षेत्र <main>, <nav>, और अन्य भूमिकाओं का उपयोग करते हैं।
3. नाम। हर चित्र के पास एक alt है, हर नियंत्रण के पास एक लेबल है, और हर लिंक और बटन संदर्भ के बाहर स्पष्ट पढ़ता है।
4. विपरीत। अपने ब्राउज़र के dev tools में पाठ के विरुद्ध अपनी पृष्ठभूमि को चेक करें, जो अनुपात की रिपोर्ट करते हैं और कुछ भी ध्वज करते हैं जो विफल होता है।

Automated checkers जैसे Chrome dev tools में Lighthouse panel या axe ब्राउज़र एक्सटेंशन मुद्दों का एक उपयोगी हिस्सा पकड़ते हैं, लेकिन केवल एक हिस्सा। वे निर्णय नहीं कर सकते हैं कि क्या alt पाठ सार्थक है या क्या टैब order समझदारी है, इसलिए manual कीबोर्ड पास आवश्यक रहता है।

एक काम करने वाली ऑडिट automated और manual passes को जोड़ती है, क्योंकि automation केवल जमीन का हिस्सा कवर करता है: tooling विश्वसनीय रूप से missing alt, missing लेबल, और विपरीत विफलताओं को ढूंढता है (WCAG मानदंड का लगभग एक तिहाई), और यह न्याय नहीं कर सकता है कि क्या alt पाठ सटीक है या tab order तार्किक है।

• Automated। पहली बार axe या Lighthouse चलाएं यांत्रिक विफलताओं को sweep करने के लिए।
• कीबोर्ड। माउस को एक तरफ रखें और Tab के माध्यम से, reachability, एक तार्किक क्रम, एक दृश्यमान फोकस ring, पूर्ण operability, और कोई जगह नहीं जहां फोकस वापस बाहर नहीं आ सकता की पुष्टि करते हुए। यह पास अकेले अधिकांश कस्टम-विजेट defects को सतह करता है।
• स्क्रीन रीडर। एक को चालू करें (VoiceOver macOS के साथ Cmd+F5 के माध्यम से आता है, NVDA Windows पर एक मुफ्त download है, TalkBack Android में built-in है) और कुछ मुख्य flows के माध्यम से सुनें। आप यह जांच रहे हैं कि नाम की घोषणा की जाती है, भूमिकाएं सही हैं, और state changes वास्तव में बोली जाती हैं।
• सुलभता वृक्ष। ब्राउज़र के dev tools किसी भी तत्व के लिए computed भूमिका, नाम, और state दिखाते हैं, जो आपको बताता है कि सहायक तकनीक वास्तव में क्या प्राप्त करेगी, इस बात से स्वतंत्र कि तत्व कैसे दिखता है।

Automated tools report green होने पर भी कीबोर्ड और स्क्रीन रीडर passes को चलाएं, क्योंकि जो चीज़ें वे चेक नहीं कर सकते हैं वह वह है जो एक असली व्यक्ति को पृष्ठ का उपयोग करते हुए सबसे अधिक प्रभावित करती है।

Junoएक त्वरित स्व-ऑडिट माउस को एक तरफ रखें और अपने पृष्ठ के माध्यम से Tab करें: क्या आप समझदारी के क्रम में सब कुछ तक पहुंच सकते हैं और उपयोग कर सकते हैं? फिर हर चित्र के पास एक alt है, हर फील्ड के पास एक <label> है, और पाठ अपनी पृष्ठभूमि के विरुद्ध स्पष्ट पढ़ता है। कुछ मिनट इसका अनुमान लगाते हैं समस्याओं को पकड़ो जो लोग सबसे अधिक मारते हैं।

Junoएक त्वरित स्व-ऑडिट इसे एक दिनचर्या बनाएं: reachability और order के लिए Tab करें, एक <h1> चेक करें और कोई skipped शीर्षक नहीं, छवियों और नियंत्रणों पर नाम की पुष्टि करें, और dev tools में विपरीत पढ़ें। axe और Lighthouse जैसे automated tools मदद करते हैं, लेकिन वे केवल इसका हिस्सा पकड़ते हैं, इसलिए हाथ से कीबोर्ड पास करते रहें।

Junoएक त्वरित स्व-ऑडिट Automation missing alt, missing लेबल, और विपरीत, WCAG के बारे में एक तिहाई पाता है, और अर्थ या क्रम के बारे में कुछ भी judge नहीं करता है। तो इसे एक कीबोर्ड पास के साथ जोड़ी, एक स्क्रीन रीडर के माध्यम से एक सुनो, और computed भूमिका और नाम के लिए सुलभता inspector में एक दिखो। चेक जो एक tool नहीं चला सकता है वह है जो सबसे अधिक मायने रखता है, इसलिए उन्हें स्वयं चलाएं भले ही रिपोर्ट हरी हो।