पॉइंटर और मोशन एक्सेसिबिलिटी

यह क्यों ज़रूरी है

जब कोई function सिर्फ़ किसी gesture के पीछे हो, तो जो लोग वह gesture नहीं कर सकते वे पूरा function खो देते हैं, सिर्फ़ कोई सुविधा नहीं। इनमें tremor या हाथों की सीमित पकड़ वाले लोग, एक उँगली या mouth stick से screen छूने वाले लोग, eye tracking या head pointer इस्तेमाल करने वाले लोग, और वे लोग शामिल हैं जिनका tablet wheelchair पर एक तय orientation में लगा है। गलती से हुआ activation भी नुकसान करता है: अगर Delete उँगली के screen छूते ही चल जाए, तो एक चूक data मिटा देती है।

Product के लिए, ये सभी criteria WCAG 2.2 Level AA conformance के लिए ज़रूरी हैं, यानी उस level के लिए जिसे ज़्यादातर organisations और contracts लक्ष्य बनाते हैं, और 2.5.7 Dragging Movements 2.2 में नया है, इसलिए WCAG 2.1 के आधार पर approve हुए designs शायद कभी इसके लिए जाँचे ही नहीं गए। Tester के लिए ये defects आसानी से छूट जाते हैं: desktop पर mouse से, या आपके अपने phone पर, gesture आपके लिए काम करता है। आपको जानबूझकर उन लोगों के लिए टेस्ट करना होता है जो वह gesture नहीं कर सकते।

Pointer gestures और pointer cancellation (2.5.1, 2.5.2)

2.5.1 Pointer Gestures (Level A) multipoint gestures को कवर करता है, जिनमें एक साथ दो या ज़्यादा उँगलियाँ चाहिए (zoom के लिए pinch, two-finger swipe), और path-based gestures को, जिनमें सिर्फ़ शुरुआत और अंत नहीं बल्कि movement का रास्ता मायने रखता है (किसी तय दिशा में swipe, कोई shape बनाना)। ऐसा हर function single pointer से, बिना path के, भी चलना चाहिए: tap, click, double tap या long press। Pinch-to-zoom वाला map pass होता है अगर उसमें + और − बटन भी हों; सिर्फ़ swipe से चलने वाला carousel fail होता है। अपवाद वह gesture है जो essential हो, जैसे अपना signature बनाना, जहाँ path ही input है; लेकिन अगर drawing सिर्फ़ किसी बात की स्वीकृति के लिए है, तो एक बटन काफ़ी है, इसलिए वह essential नहीं। यह criterion सिर्फ़ उन gestures पर लागू होता है जिन्हें पेज ख़ुद interpret करता है: browser का अपना pinch zoom और screen reader के gestures इसके दायरे से बाहर हैं।

2.5.2 Pointer Cancellation (Level A) गलती से होने वाले activation से बचाता है। Single pointer से चलने वाले हर function के लिए इनमें से कम से कम एक बात सही होनी चाहिए: down-event (जिस पल बटन या उँगली नीचे जाती है) function का कोई हिस्सा नहीं चलाता; function up-event पर पूरा होता है और पूरा होने से पहले abort या बाद में undo किया जा सकता है; up-event, down-event के हर असर को उलट देता है; या down-event पर पूरा होना essential है। Native buttons और links पहले से सही व्यवहार करते हैं: click छोड़ने के बाद fire होता है, इसलिए दबाना, control से बाहर खिसकना और छोड़ना कुछ नहीं करता। Defect तब आता है जब developer action को pointerdown, mousedown या touchstart से जोड़ देता है। On-screen keyboard या keypad की key दबाना essential माना जाता है।

• Gestures: feature के हर swipe, pinch, two-finger और drawing interaction की list बनाएँ, फिर हर एक का single-pointer तरीका खोजें और उसे सच में इस्तेमाल करें।
• Cancellation: action करने वाले हर control पर दबाएँ, pointer या उँगली को उससे बाहर ले जाएँ और छोड़ें; कुछ नहीं होना चाहिए। Delete और payment actions से शुरू करें।
• Drag and drop भी गिना जाता है: down-event पर item उठ जाना ठीक है, बशर्ते उसे किसी drop target के बाहर छोड़ने से move cancel हो जाए।

// Defect (2.5.2): the item is deleted the moment the pointer goes down
deleteButton.addEventListener('pointerdown', deleteItem);

// Expected: click fires after release, and not if the pointer slid off the button
deleteButton.addEventListener('click', deleteItem);

Dragging movements और target size (2.5.7, 2.5.8)

2.5.7 Dragging Movements (Level AA) WCAG 2.2 में नया है। Dragging movement का मतलब है किसी element पर दबाना, pointer को हिलाना और किसी दूसरे point पर छोड़ना, जहाँ सिर्फ़ शुरुआत और अंत के points मायने रखते हैं: list का क्रम बदलना, card को columns के बीच ले जाना, slider का thumb खिसकाना, map को pan करना। ऐसे हर function के लिए एक तरीका चाहिए जो single pointer actions से, बिना drag के, चले, जब तक dragging essential न हो या व्यवहार browser ख़ुद देता हो और author ने उसे न बदला हो।

ध्यान दें कि क्या नहीं गिना जाता: keyboard support। Arrow keys पर चलने वाला slider 2.1.1 Keyboard पूरा करता है, लेकिन head pointer या tremor के साथ mouse इस्तेमाल करने वाला व्यक्ति अब भी pointer user है और हो सकता है कि अब भी drag न कर पाए। Alternatives असली controls होने चाहिए जो 2.5.8 Target Size (Minimum) (Level AA) पूरा करें: कम से कम 24 × 24 CSS pixels, या पर्याप्त spacing, उन अपवादों के साथ जो visual accessibility guide में सिखाए गए हैं। Move down से सटा 16 pixel का Move up arrow एक failure को दूसरे failure से बदल देता है। Level AAA का 2.5.5 Target Size (Enhanced) 44 × 44 माँगता है।

• Sortable list: हर row पर Move up और Move down बटन, या Move to menu।
• Kanban board: card चुनें, फिर menu से target column चुनें या column पर tap करें।
• Slider: track पर tap या click से thumb उस value पर पहुँचे, या − और + बटन, या पास में एक number field।
• Map: pan के लिए arrow बटन, zoom के लिए + और − बटन।

Motion actuation और orientation (2.5.4, 1.3.4)

2.5.4 Motion Actuation (Level A) तब लागू होता है जब device को हिलाना (undo के लिए shake, scroll के लिए tilt) या camera के सामने user की movement (अगले पेज के लिए हाथ हिलाना) कोई function चलाती है। दो बातें ज़रूरी हैं: वही function एक साधारण on-screen control से भी उपलब्ध हो, और motion पर response बंद किया जा सके, ताकि tremor या हिचकोले खाती bus उसे trigger न कर दे। अपवाद हैं: accessibility supported interface के ज़रिए इस्तेमाल होने वाला motion (इसमें keyboard, mouse, touch screen या किसी assistive technology को चलाने की सामान्य हरकतें आती हैं), और वह motion जो activity के लिए essential है, जैसे step counter। यह input के रूप में motion है; screen पर animation और reduced-motion preference visual accessibility में कवर हो चुके हैं।

1.3.4 Orientation (Level AA) कहता है कि content अपना view और operation portrait या landscape में से किसी एक तक सीमित न करे, जब तक कोई ख़ास orientation essential न हो; WCAG के उदाहरणों में bank check, piano application, projector या television के लिए slides, और virtual reality content शामिल हैं। जिस व्यक्ति का tablet wheelchair पर fixed है, वह आपके पेज के हिसाब से उसे घुमा नहीं सकता। Orientation के साथ बदलने वाला layout ठीक और अपेक्षित है; failure वह पेज है जो काम करने से मना कर दे, सिर्फ़ "Please rotate your device" message दिखाए, या अपने content को 90 डिग्री घुमाकर दिखाए। टेस्ट करते समय पहले device का rotation lock बंद करें, वरना pass का कोई मतलब नहीं।

Where an orientation lock usually hides (search the code and config):

CSS       @media (orientation: landscape) { main { display: none; } }
JS        screen.orientation.lock('portrait')
Manifest  "orientation": "portrait"             (installed web app)
Android   android:screenOrientation="portrait"   (AndroidManifest.xml)
iOS       UISupportedInterfaceOrientations       (Info.plist, portrait only)

Mouse, touch device और device emulation से टेस्टिंग

तीनों inputs इस्तेमाल करें, क्योंकि हर एक अलग defects पकड़ता है। Desktop पर mouse से शुरू करें: यह सटीक है, इसलिए दिखाता है कि हर function का single-click रास्ता है या नहीं। Gestures, motion और rotation के लिए असली phone या tablet पर जाएँ। बीच में browser device emulation से phone-width layouts जल्दी जाँचें, लेकिन touch या sensors पर उसे आख़िरी फ़ैसला न मानें।

• Mouse: हर drag, swipe और pinch function सिर्फ़ single clicks से पूरा करें; action करने वाले हर control पर दबाएँ, बाहर खिसकें और छोड़ें; छोटे targets devtools में मापें।
• Touch device: हर gesture करें, फिर उसका tap alternative खोजकर इस्तेमाल करें; बटन छुएँ, उँगली बाहर खिसकाएँ और उठाएँ; जहाँ feature motion पर react करता है वहाँ device shake और tilt करें, फिर settings में motion response बंद करें; rotation lock बंद करें और हर screen पर, खुले dialogs समेत, device घुमाएँ।
• Device emulation: Chrome DevTools में device toolbar (Ctrl+Shift+M, Mac पर Cmd+Shift+M) phone viewport सेट करता है, mouse से touch simulate करता है और उसमें rotate बटन है; Sensors panel device orientation values सेट करता है। Firefox का Responsive Design Mode भी phone viewport, touch simulation और rotate बटन देता है। उन alternatives पर नज़र रखें जिन्हें phone layout छिपा देता है, जैसे carousel arrows जो किसी breakpoint (वह width जहाँ layout बदल जाता है) के नीचे गायब हो जाते हैं।
• Emulation की सीमाएँ: यह सिर्फ़ वह बदलता है जो पेज को बताया जाता है, जैसे viewport, touch events और, device preset चुनने पर, User-Agent string (वह text जिसमें browser अपना नाम, version और operating system बताता है); hardware नहीं बदलता। यह phone shake नहीं कर सकता, यह नहीं दिखाता कि असली उँगली छोटे target को कैसे ढकती है, और असली operating system का rotation व्यवहार अलग हो सकता है। Console से navigator.userAgent को User-Agent parser में paste करें, तो दिखेगा कि session phone होने का दावा कर रहा है जबकि वह desktop hardware पर चल रहा है। हर pass को कम से कम एक असली device पर confirm करें।
• हर result के साथ लिखें: device और OS, browser, इस्तेमाल हुआ input (mouse, उँगली या stylus), orientation और rotation lock की स्थिति। छोटी screen recording gesture defects को reproducible बनाती है।

आज़माएँ: User-Agent पार्सर आज़माएँ: टेस्ट केस जनरेटर

Worked example: task board की टेस्टिंग

एक team mobile-friendly task board ship करती है। Cards columns के बीच drag से जाते हैं, card पर बाईं ओर swipe उसे archive करता है, phone shake करने से आख़िरी बदलाव undo होता है, और card का delete icon touch पर react करता है।

Tester पिछले section का session चलाता है और जो pass हुआ वह भी दर्ज करता है: board का zoom pinch के साथ + और − बटन से भी चलता है (2.5.1), और column header के बटन 32 × 32 CSS pixels के हैं (2.5.8)। फिर tester ये defects लिखता है, हर एक के साथ criterion और expected व्यवहार:

• "Card को columns के बीच सिर्फ़ drag से ले जाया जा सकता है; कोई single-pointer तरीका नहीं": 2.5.7 (AA) fail। Expected: हर card पर Move to menu, या card चुनकर column पर tap।
• "Archive सिर्फ़ बाईं ओर swipe से उपलब्ध है": 2.5.1 (A) fail, क्योंकि swipe एक path-based gesture है। Expected: card menu में Archive item।
• "Shake to undo का कोई on-screen Undo नहीं और इसे बंद नहीं किया जा सकता": 2.5.4 (A) की दोनों शर्तों पर fail। Expected: हर बदलाव के बाद Undo बटन और shake बंद करने की setting।
• "Card touchstart पर delete हो जाता है; उँगली बाहर खिसकाने से cancel नहीं होता": 2.5.2 (A) fail। Expected: release पर delete, बेहतर हो कि Undo के साथ।
• "Tablets पर landscape में board rotate-to-portrait message दिखाता है": 1.3.4 (AA) fail; task board की कोई essential orientation नहीं है।

आज़माएँ: AI बग टाइटल जनरेटर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)WCAG 2.2 की हर guideline और success criterion की व्याख्या: उद्देश्य, किसे लाभ, उदाहरण और तकनीकें (नॉर्मेटिव नहीं)।
• How to Meet WCAG (Quick Reference)W3C Web Accessibility Initiative (WAI)WCAG 2.2 के हर success criterion की फ़िल्टर करने योग्य सूची, पर्याप्त तकनीकों और आम विफलताओं के साथ।
• What are browser developer tools? — MDNMDN Web Docs (Mozilla)ब्राउज़र में बने developer tools का परिचय — inspector, JavaScript console और debugger — टेस्ट करते समय पेज की जाँच के लिए।