ARIA: ज़हर या ऐंटीडोट?

स्क्रीन रीडर के लिए झूठ बोलना सुलभता की प्रक्रिया को कैसे ठीक करता है, जब वह उसमें नमक घुलता नहीं है!

ARIA क्या है?

ARIA की मदद से, वेब लेखकों को एक वैकल्पिक वास्तविकता बनाने की सुविधा मिलती है, जो सिर्फ़ स्क्रीन रीडर को दिखती है 🤥

कभी-कभी वेब कॉन्टेंट में क्या हो रहा है, इस बारे में स्क्रीन रीडर को सच्चाई के बारे में बताना या सीधे "झूठी" जानकारी देना ज़रूरी होता है. उदाहरण के लिए, "यहां पर फ़ोकस है!" या "यह एक स्लाइडर है!". यह अपने वर्कबेंच पर टूल और विजेट पर जादुई स्टिकी नोट जोड़ने जैसा है. इन जादुई स्टिकी नोट से सबको भरोसा होता है कि इन पर क्या लिखा है.

जब भी कोई जादुई स्टिकी नोट मौजूद होता है, तो वह या तो हर टूल के बारे में हमारी सोच या टूल के बारे में कुछ जानकारी को बदल देता है. उदाहरण: "यहां एक ग्लू गन है!". हालांकि, वह अब भी काम करने की जगह पर एक खाली नीला बॉक्स है, लेकिन उसके स्टिकी नोट से हमें लगेगा कि यह एक ग्लू गन है. हम यह भी जोड़ सकते हैं, "और यह 30% भर गया है!". स्क्रीन रीडर अब यह रिपोर्ट करेगा कि 10% तक ग्लू गन है.

इसके समान वेब में एक सादा बॉक्स एलिमेंट (डिव) लिया जाता है, जिसके अंदर एक इमेज होती है, और यह बताने के लिए ARIA का इस्तेमाल किया जाता है कि यह एक स्लाइडर है, जिसकी वैल्यू 100 में से 30 है.

ARIA क्या नहीं है?

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

आपने इसे सही पढ़ा: ARIA असल में कीबोर्ड फ़ोकस या टैब के क्रम के लिए कुछ नहीं करता. यह काम एचटीएमएल में किया जाता है. कभी-कभी JavaScript के हिस्सों को जोड़कर इसमें बदलाव किया जाता है.

ARIA कैसे काम करता है?

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

ARIA क्यों?

हम कभी भी अपने उपयोगकर्ताओं से झूठ क्यों बोलना चाहेंगे!?

मान लें कि स्थानीय वेब स्टोर में वे सभी विजेट नहीं बेचे जाते जिनकी हमें ज़रूरत होती है. हालांकि, हम हैं MacGyver. हम दूसरे विजेट से अपने ही विजेट का आविष्कार कर सकते हैं! एफ़डब्ल्यूआईडब्ल्यू, MacGyver की सात सबसे ज़्यादा इस्तेमाल की जाने वाली चीज़ें स्विस आर्मी के चाकू, गम, जूते की स्ट्रिंग, माचिस, पेपर क्लिप, जन्मदिन की मोमबत्तियां, और डक्ट टेप हैं. वह बम बनाने के साथ-साथ, ऐसी दूसरी चीज़ें बनाने के लिए भी इनका इस्तेमाल करता है जो अभी नहीं दिख रही हैं. यह काफ़ी हद तक उस वेब लेखक की तरह है जिसे मेन्यू बार बनाने की ज़रूरत होती है. मेन्यू बार इतने उपयोगी होते हैं कि आपके हिसाब से वे एचटीएमएल का हिस्सा हो सकते हैं, लेकिन ऐसा नहीं है. ठीक है! आपको नहीं लगता कि लेखक लिंक और बटन से खुश होंगे? इसलिए, लेखक अपने पसंदीदा टूल का इस्तेमाल करके किसी एक फ़ॉर्मैट को एक साथ जोड़ देगा: divs, इमेज, स्टाइल, क्लिक हैंडलर, कीप्रेस हैंडलर, स्पिट, और ARIA.

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

मेन्यू बार का उदाहरण

माउस क्लिक करने वाले लोगों की मदद करना

आइए, मिलकर एक मेन्यू बार बनाते हैं. हम जेनरिक बॉक्स एलिमेंट में कई आइटम दिखाते हैं, जिन्हें divs कहा जाता है. जब भी हमारा उपयोगकर्ता किसी div पर क्लिक करता है, तो वह उससे जुड़े कमांड को एक्ज़ीक्यूट कर देता है. बढ़िया, यह माउस क्लिक करने वाले लोगों के लिए काम करता है!

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

मेन्यू के कुछ आइटम, माता-पिता के लिए होते हैं. ये बच्चों के लिए सबमेन्यू पैदा करते हैं. जब भी उपयोगकर्ता इनमें से किसी पर कर्सर घुमाता है, तो हम एक ऐनिमेशन शुरू करते हैं जो चाइल्ड सबमेन्यू को स्लाइड करता है.

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

हमारे मेन्यू बार कीबोर्ड को सुलभ बनाना

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

जिस तरह कोई वेब पेज माउस पर प्रतिक्रिया दे सकता है, उसी तरह वह कीबोर्ड को भी जवाब दे सकता है. हमारा JavaScript आने वाले सभी कीस्ट्रोक को सुनेगा और तय करेगा कि कीप्रेस मददगार है या नहीं. अगर नहीं, तो वह उसे पेज पर वापस किसी ऐसी मछली की तरह फेंक देता है जो खाने के लिए बहुत छोटी है. हमारे नियम कुछ ऐसे हैं:

• अगर उपयोगकर्ता कोई ऐरो बटन दबाता है, तो हम मेन्यू बार के अपने इंटरनल ब्लूप्रिंट देखते हैं और तय करते हैं कि नया ऐक्टिव मेन्यू आइटम क्या होना चाहिए. हम मौजूदा हाइलाइट को हटा देंगे और नए मेन्यू आइटम को हाइलाइट करेंगे, ताकि देखने वाला उपयोगकर्ता विज़ुअल तौर पर यह जान सके कि वह कहां है. इसके बाद, वेब पेज को event.preventDefault() को कॉल करना चाहिए, ताकि ब्राउज़र को सामान्य कार्रवाई करने से रोका जा सके (इस मामले में, पेज स्क्रोल करना).
• अगर उपयोगकर्ता Enter बटन दबाता है, तो हम इसे एक क्लिक के तौर पर देख सकते हैं और सही कार्रवाई कर सकते हैं (या कोई दूसरा मेन्यू भी खोल सकते हैं).
• अगर उपयोगकर्ता कोई ऐसा बटन दबाता है जो कुछ और करना चाहिए, तो उसे न खाएं! इसे पेज पर वापस उसी तरह ले जाएं जिस तरह प्रकृति ने. उदाहरण के लिए, हमारे मेन्यू बार को Tab बटन की ज़रूरत नहीं है, इसलिए इसे वापस कर दें! यह सही होना मुश्किल होता है और लेखक अक्सर इसे गलत बना देते हैं. उदाहरण के लिए, मेन्यू बार में ऐरो बटन की ज़रूरत होनी चाहिए, लेकिन Alt+Arrow या Command+ऐरो की नहीं. वे आपके ब्राउज़र टैब के वेब इतिहास में पिछले/अगले पेज पर ले जाने के लिए शॉर्टकट हैं. अगर लेखक सावधान नहीं है, तो मेन्यू बार उसे खा जाएगा. इस तरह का बग बहुत बार होता है, और हमने अभी तक ARIA के साथ शुरुआत भी नहीं की है!

हमारे मेन्यू बार को स्क्रीन रीडर ऐक्सेस करने की सुविधा

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

लेकिन यह सही नहीं है! मेन्यू बार उन लोगों के लिए ठीक से काम करता है जो देख सकते हैं.

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

हमारा पहला है, अहम, ARIA झूठ है, aria-activedescendant एट्रिब्यूट का इस्तेमाल करना है और उसे मौजूदा ऐक्टिव मेन्यूआइटम के आईडी पर सेट करना है. साथ ही, ध्यान रखें कि इसमें बदलाव होने पर इसे अपडेट करना भी ज़रूरी है. उदाहरण के लिए, aria-activedescendant="settings-menuitem". इस छोटे से सफ़ेद झूठ की वजह से स्क्रीन रीडर हमारे ARIA ऐक्टिव आइटम पर फ़ोकस करता है, जिसे ज़ोर से पढ़कर सुनाया जाता है या ब्रेल डिसप्ले पर दिखाया जाता है.

aria-activedescendant पर वापस जाएं. स्क्रीन रीडर का इस्तेमाल करके, फ़ोकस किए गए मेन्यू बार से किसी खास मेन्यू आइटम पर पहुंचा जा सकता है. इससे स्क्रीन रीडर को पता चलता है कि उपयोगकर्ता ने कहां मूव किया है. हालांकि, ऑब्जेक्ट के बारे में और कुछ नहीं पता. फिर भी यह डीव चीज़ क्या है? ऐसी ही स्थिति में भूमिका एट्रिब्यूट का इस्तेमाल होता है. हम पूरी चीज़ के लिए वाले एलिमेंट में role="menubar" का इस्तेमाल करते हैं. इसके बाद, आइटम के ग्रुप के लिए role="menu" का इस्तेमाल करते हैं और role="menuitem" को ... ड्रमरोल ... हर मेन्यू आइटम के लिए इस्तेमाल करते हैं.

क्या होगा अगर मेन्यू आइटम से बच्चों को मुख्य मेन्यू आइटम मिल सकता है? उपयोगकर्ता को यह सही मालूम होना चाहिए? कम से कम इस समय, स्क्रीन रीडर को यह नहीं पता होता कि इमेज को अपने-आप कैसे पढ़ा जाए. हम हर मेन्यू आइटम में aria-expanded="false" को जोड़ सकते हैं, ताकि यह पता चल सके कि 1) कुछ ऐसा है जिसे बड़ा किया जा सकता है और 2) फ़िलहाल, उसे बड़ा नहीं किया जा सकता. साथ ही, लेखक को इमेज के त्रिभुज पर role="none" लगाना चाहिए, ताकि यह पता चल सके कि यह सिर्फ़ दिखावा करने के मकसद से है. इससे स्क्रीन रीडर उस इमेज के बारे में ऐसी कोई भी बात नहीं कर पाता जो ग़ैर-ज़रूरी है और हो सकता है कि वह परेशान करने वाली हो.

गड़बड़ियों से निपटना

कीबोर्ड बग (HTML!)

हालांकि, कीबोर्ड का ऐक्सेस, कोर एचटीएमएल का एक हिस्सा है, लेकिन लेखक हर समय इसे खराब कर देते हैं, क्योंकि या तो वे कीबोर्ड नेविगेशन का उतना इस्तेमाल नहीं करते हैं या फिर सही होने की बहुत बारीकियां होती हैं.

गड़बड़ियों के उदाहरण:

• चेकबॉक्स, टॉगल करने के लिए स्पेसबार का इस्तेमाल करता है, लेकिन लेखक preventDefault() को कॉल करना भूल गया. अब स्पेसबार, चेकबॉक्स और पेज डाउन, दोनों को टॉगल करेगा. यह स्पेसबार के लिए डिफ़ॉल्ट ब्राउज़र बिहेवियर है.
• ARIA मोडल डायलॉग, टैब नेविगेशन के अंदर उसे फंसना चाहता है और लेखक सीधे ब्राउज़र के ज़रिए Control+Tab को अनुमति देना भूल जाता है. अब, Control+Tab सिर्फ़ डायलॉग बॉक्स में नेविगेट किया जा सकता है. साथ ही, यह ब्राउज़र में टैब को सही तरीके से स्विच नहीं करता है. ओह.
• लेखक एक चुने हुए विकल्प की सूची बनाता है और उसे ऊपर/नीचे लागू करता है, लेकिन होम/end/pageup/pagedown या फ़र्स्ट लेटर नेविगेशन लागू नहीं करता.

लेखकों को जाने-पहचाने पैटर्न का पालन करना चाहिए. ज़्यादा जानकारी के लिए, संसाधन सेक्शन देखें.

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

कीबोर्ड की गड़बड़ियां हमेशा वेब कॉन्टेंट में गड़बड़ी होती हैं. खास तौर पर, यह उनकी एचटीएमएल और JavaScript में गड़बड़ी होती है, न कि ARIA में.

ARIA बग: इतने सारे क्यों हैं?

ऐसी कई, कई जगहें हैं जहां लेखकों के लिए ARIA गलत है और हर वजह से या तो पूरी तरह से ब्रेक हो सकता है या मामूली अंतर आ सकता है. बारीकियां शायद ज़्यादा खराब होती हैं, क्योंकि लेखक प्रकाशित करने से पहले उनमें से ज़्यादातर को नहीं पकड़ता है.

अगर लेखक एक अनुभवी स्क्रीन रीडर उपयोगकर्ता नहीं है, तो ARIA में कुछ गलत होगा. हमारे मेन्यू बार के उदाहरण में, लेखक को ऐसा लग सकता है कि "मेन्यू" की भूमिका सही होने पर "विकल्प" की भूमिका का इस्तेमाल किया जाना चाहिए. वे aria-expanded का इस्तेमाल करना भूल सकते हैं, सही समय पर aria-activedescendant को सेट और साफ़ करना भूल सकते हैं या दूसरे मेन्यू वाला मेन्यू बार रखना भूल सकते हैं. और मेन्यू आइटम की संख्या का क्या? आम तौर पर, मेन्यू आइटम को स्क्रीन रीडर की मदद से "5 में से 3 आइटम" जैसा कुछ दिखाया जाता है, ताकि उपयोगकर्ता को पता चल सके कि वे कहां हैं. आम तौर पर, ब्राउज़र इसे अपने-आप गिनता है. हालांकि, कुछ मामलों में, कुछ ब्राउज़र - स्क्रीन रीडर के कॉम्बिनेशन में, गलत संख्याओं की गिनती हो सकती है. ऐसे में, लेखक को इन संख्याओं को aria-posinset और aria-setsize से बदलना होगा.

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

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

खास जानकारी

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

ARIA मार्कअप लेयर को बदलने वाला एक आसान विकल्प है. जब कोई स्क्रीन रीडर पूछता है कि क्या हो रहा है और अगर ARIA मौजूद है, तो उसे असली सच के बजाय, सच का ARIA वर्शन मिलता है.

पहला अतिरिक्त संसाधन: अतिरिक्त संसाधन

कीबोर्ड की जानकारी और कोड के उदाहरणों के साथ हाइब्रिड रेफ़रंस

• W3C के ARIA ऑथरिंग तरीके: यह हर उदाहरण की अहम कीबोर्ड नेविगेशन विशेषताओं का दस्तावेज़ बनाता है. साथ ही, काम करने वाला JS/CSS/ARIA कोड उपलब्ध कराता है. ये उदाहरण, सिर्फ़ उन चीज़ों के बारे में हैं जो आपके लिए सबसे ज़्यादा काम की हैं. इनमें मोबाइल डेटा शामिल नहीं है.

परिशिष्ट 2: ARIA का सबसे ज़्यादा इस्तेमाल किस लिए किया जाता है?

क्योंकि ARIA छोटे या बड़े सच को बदल सकता है या पूरा कर सकता है, आम तौर पर यह ऐसी बातें कहने के लिए इस्तेमाल होता है जो स्क्रीन रीडर को पसंद आती है.

यहां ARIA के कुछ सामान्य इस्तेमाल बताए गए हैं.

• ऐसे विशेष विजेट जो एचटीएमएल में मौजूद नहीं होते, जैसे कि मेन्यू बार, ऑटोकंप्लीट, ट्री या स्प्रेडशीट
• ऐसे विजेट जो एचटीएमएल में मौजूद होते हैं, लेकिन लेखक ने अपने खुद के विजेट का आविष्कार किया. इसकी वजह यह हो सकती है कि उन्हें सामान्य विजेट के व्यवहार या लुक में बदलाव करना होता हो. उदाहरण के लिए, एचटीएमएल <input type="range"> एलिमेंट आम तौर पर एक स्लाइडर होता है, लेकिन लेखक इसे अलग दिखाना चाहते हैं. ज़्यादातर चीज़ों के लिए, सीएसएस का इस्तेमाल किया जा सकता है, लेकिन input type="range" के लिए सीएसएस मुश्किल है. लेखक अपना स्लाइडर बना सकता है और उस पर aria-valuenow के साथ role="slider" का इस्तेमाल करके, मौजूदा वैल्यू बता सकता है.
• लाइव रीजन, स्क्रीन रीडर को "पेज के इस हिस्से में, ऐसी कोई भी चीज़ बताते हैं जिसके बारे में उपयोगकर्ता को बताना फ़ायदेमंद है."
• लैंडमार्क (अब एचटीएमएल के समान हैं). ये कुछ हद तक हेडिंग की तरह होते हैं. इनसे स्क्रीन रीडर के उपयोगकर्ताओं को अपनी पसंद की चीज़ें तेज़ी से ढूंढने में मदद मिलती है. हालांकि, वे इस मामले में अलग होते हैं कि इनमें पूरा संबंधित इलाका शामिल होता है. उदाहरण के लिए, "यह कंटेनर पेज का मुख्य एरिया है" और "यहां मौजूद यह कंटेनर एक नेविगेशन पैनल है".

तीसरा अतिरिक्त: Accessibility API क्या है?

Accessibility API की मदद से स्क्रीन रीडर या अन्य AT को यह पता चलता है कि पेज पर क्या है और अभी क्या हो रहा है. उदाहरण के लिए, MSAA, IA2, और यूज़र इंटरफ़ेस (यूआईए). बस Windows है! Accessibility API के दो हिस्से होते हैं:

• कंटेनर की हैरारकी को दिखाने वाले ऑब्जेक्ट का "पेड़". ये रशियन नेस्टिंग डॉल की तरह होते हैं, लेकिन हर डॉल में कई दूसरी गुड़िया हो सकती हैं. उदाहरण के लिए, किसी दस्तावेज़ में कई पैराग्राफ़ हो सकते हैं और पैराग्राफ़ में टेक्स्ट, इमेज, लिंक, बोल्डफ़ेस वगैरह हो सकते हैं. ऑब्जेक्ट ट्री में मौजूद हर आइटम में, भूमिका (मैं क्या हूं?), नाम/लेबल, उपयोगकर्ता की डाली गई वैल्यू, किसी ब्यौरे जैसी प्रॉपर्टी हो सकती हैं. साथ ही, फ़ोकस करने लायक, फ़ोकस किया गया, ज़रूरी, चुना गया जैसे बूलियन स्टेट भी हो सकते हैं. ARIA इनमें से किसी भी प्रॉपर्टी को बदल सकता है. स्क्रीन रीडर, लोगों को वर्चुअल बफ़र मोड में नेविगेट करने में मदद करने के लिए, ट्री का इस्तेमाल करता है. जैसे, "कृपया अगली हेडिंग पर जाएं".
• ऐसी घटनाओं की सीरीज़ जो ट्री में होने वाले बदलावों के बारे में बताती हैं, जैसे "फ़ोकस अब यहां खत्म हो गया है!". स्क्रीन रीडर, इवेंट का इस्तेमाल करके उपयोगकर्ता को बताता है कि अभी क्या हुआ है. जब ज़रूरी एचटीएमएल या ARIA मार्कअप में बदलाव होता है, तब स्क्रीन रीडर को यह बताने के लिए एक इवेंट चालू किया जाता है कि कुछ बदलाव हुआ है.

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