सुलभ वेब बटनों के लिए एक छोटी, राय-आधारित चेकलिस्ट

बटन सुलभता सलाह की समस्या

बटन सुलभता से जुड़ी अधिकांश गाइडेंस दो खेमों में बँट जाती है: या तो यह 40 पन्नों की WCAG व्याख्या होती है जिसे कोई नहीं पढ़ता, या यह "बटनों को सुलभ बनाएँ" जैसा अस्पष्ट सुझाव होता है जिसमें कोई लागू करने योग्य कदम नहीं होता। गुरुवार को कोई फीचर शिप करते समय इनमें से कोई भी मदद नहीं करता।

यह चेकलिस्ट उन पाँच सबसे आम बटन सुलभता विफलताओं को कवर करती है जो हमें प्रोडक्शन में दिखती हैं। यह आपको WCAG विशेषज्ञ नहीं बनाएगी, लेकिन यह उन समस्याओं को पकड़ लेगी जो सच में उपयोगकर्ताओं को प्रभावित करती हैं।

1. बटनों के लिए button एलिमेंट का उपयोग करें

यदि वह बटन की तरह काम करता है, तो उसे <button> एलिमेंट होना चाहिए। onclick वाला <div> नहीं, role="button" वाला <span> नहीं, और href="#" तथा preventDefault वाला <a> नहीं।

<button> एलिमेंट आपको कीबोर्ड नेविगेशन, फोकस मैनेजमेंट और स्क्रीन रीडर घोषणाएँ अपने-आप देता है। जब आप <div> का उपयोग करते हैं, तो आप यह सब शून्य से फिर बना रहे होते हैं — और आप इसमें गलती करेंगे।

केवल अपवाद: यदि कार्रवाई किसी नए पेज पर ले जाती है या URL बदलती है, तो <a> एलिमेंट का उपयोग करें। लिंक और बटन अर्थ के स्तर पर अलग होते हैं। स्क्रीन रीडर उपयोगकर्ता एलिमेंट प्रकार के आधार पर नेविगेट करते हैं, और वे अपेक्षा करते हैं कि बटन कार्रवाई करें और लिंक नेविगेट करें।

2. हिट टार्गेट को कम से कम 44×44 पिक्सेल बनाएँ

WCAG 2.5.5 (Level AAA) के अनुसार इंटरैक्टिव एलिमेंट का न्यूनतम टार्गेट आकार 44×44 CSS पिक्सेल होना चाहिए। यह दृश्य आकार के बारे में नहीं है — यह क्लिक किए जा सकने वाले क्षेत्र के बारे में है।

आप पर्याप्त padding वाला छोटा दृश्य बटन रख सकते हैं, या pseudo-element के साथ हिट टार्गेट बढ़ा सकते हैं। मायने यह रखता है कि उपयोगकर्ता को बहुत सटीक निशाना न लगाना पड़े।

मोबाइल उपयोगकर्ता, मोटर अक्षमताओं वाले लोग, और चलते-फिरते डिवाइस इस्तेमाल करने वाला कोई भी व्यक्ति छोटे टार्गेट चूक जाएगा। 24×24 पिक्सेल का आइकन बटन साफ-सुथरा लग सकता है, लेकिन यह उपयोगिता की विफलता है।

3. ऐसे दृश्यमान फोकस स्टेट दें जो केवल ब्राउज़र डिफ़ॉल्ट न हों

ब्राउज़र की डिफ़ॉल्ट फोकस रिंग कुछ न होने से बेहतर है, लेकिन यह ब्राउज़रों में असंगत होती है और कुछ बैकग्राउंड पर अक्सर अदृश्य हो जाती है। आपको ऐसा custom focus state चाहिए जो आपके design system में काम करे।

एक अच्छे focus indicator में तीन गुण होते हैं:

• उच्च contrast: आसपास के रंगों के मुकाबले कम से कम 3:1
• दृश्यमान offset: बटन की अपनी border या background से छिपा हुआ नहीं
• सुसंगत shape: उपयोगकर्ता आपके interface में इसे focus indicator के रूप में पहचान सकें

outline: none को कुछ बेहतर से बदले बिना न हटाएँ। और focus states को इतना सूक्ष्म न बनाएँ कि आदर्श रोशनी में केवल आप ही उन्हें देख सकें।

4. ऐसे बटन लेबल लिखें जो संदर्भ से बाहर भी समझ में आएँ

स्क्रीन रीडर उपयोगकर्ता अक्सर बटनों के बीच कूदकर नेविगेट करते हैं। जब वे ऐसा करते हैं, तो उन्हें आसपास के संदर्भ के बिना बटन लेबलों की सूची सुनाई देती है।

उस सूची में "और जानें" लेबल वाला बटन बेकार है। "यहाँ क्लिक करें" या "सबमिट" भी ऐसा ही है। लेबल को कार्रवाई का वर्णन करना चाहिए: "सुलभता चेकलिस्ट डाउनलोड करें", "अपडेट्स के लिए सदस्यता लें", "यह टिप्पणी हटाएँ"।

यदि आपके डिजाइन को छोटे दृश्य लेबल की आवश्यकता है, तो वर्णनात्मक विकल्प देने के लिए aria-label का उपयोग करें। लेकिन बेहतर समाधान ऐसे लेबल लिखना है जो सभी के लिए काम करें।

केवल-आइकन बटनों के लिए aria-label अनिवार्य है। सिर्फ magnifying glass icon वाले बटन को aria-label="Search" या समकक्ष text चाहिए। आइकन स्क्रीन रीडर के लिए सुलभ नहीं होता।

5. पर्याप्त रंग contrast सुनिश्चित करें

WCAG 2.1 सामान्य text के लिए कम से कम 4.5:1 और बड़े text (18pt या 14pt bold) के लिए 3:1 contrast ratio की माँग करता है। बटन लेबल आमतौर पर सामान्य text होते हैं।

सफेद बटन पर हल्का gray text विफल होता है। हल्के blue background पर फीका blue विफल होता है। ये संयोजन परिष्कृत लग सकते हैं, लेकिन वे कम दृष्टि, color blindness वाले उपयोगकर्ताओं या तेज धूप में स्क्रीन देखने वाले किसी भी व्यक्ति को बाहर कर देते हैं।

डिजाइन के दौरान contrast checker का उपयोग करें, लॉन्च के बाद नहीं। प्रोडक्शन में contrast समस्याएँ ठीक करना महँगा होता है क्योंकि इसके लिए अक्सर design system में बदलाव चाहिए होते हैं।

यदि आप image processing tools के साथ काम कर रहे हैं, तो client-side processing सुलभ visual assets बनाते समय privacy बनाए रखने में मदद कर सकती है — खासकर color combinations की testing या preview states generate करते समय।

यह चेकलिस्ट क्या कवर नहीं करती

यह सूची जानबूझकर अधूरी है। यह disabled state semantics, loading states, error handling, या split buttons अथवा dropdown triggers जैसे complex button patterns को कवर नहीं करती। उन patterns को अपनी अलग guidance चाहिए।

यह इस व्यापक प्रश्न को भी कवर नहीं करती कि बटन कब उपयोग करें और अन्य interactive elements कब। इसके लिए आपको semantic HTML और accessibility tree समझनी होगी — ऐसे विषय जिन पर अलग लेख होने चाहिए।

यह जो कवर करती है वह है आसान लक्ष्य: वे गलतियाँ जो लगभग हर code review में दिखती हैं, जो सबसे अधिक उपयोगकर्ताओं को प्रभावित करती हैं, और जिन्हें development के दौरान ठीक करना सबसे आसान होता है।

इसे अपने workflow में कैसे शामिल करें

Accessibility checklists तभी काम करती हैं जब वे development process का हिस्सा हों, बाद में जोड़ी गई चीज़ न हों। इसे संभव बनाने का तरीका यह है:

डिजाइन में: अपनी design files में focus states और hit target annotations जोड़ें। इन्हें developers के अनुमान पर न छोड़ें।

code review में: <button> elements, icon buttons पर aria-label, और focus state CSS जाँचें। इन्हें जल्दी पहचाना जा सकता है।

testing में: keyboard के साथ अपने interface में tab करें। यदि आप किसी बटन तक नहीं पहुँच सकते या नहीं देख सकते कि focus कहाँ है, तो आपके उपयोगकर्ता भी नहीं देख पाएँगे।

documentation में: अपनी component library में button accessibility requirements शामिल करें। सही काम करना गलत काम करने से आसान बनाएँ।

यदि आप production issues debug कर रहे हैं, तो HTTP headers और redirects inspect करने के tools यह समझने में मदद कर सकते हैं कि assistive technologies आपके markup को कैसे interpret कर रही हैं — खासकर navigation के बाद focus management troubleshoot करते समय।

इस काम को छोड़ने की लागत

असुलभ बटन केवल WCAG compliance में विफल नहीं होते — वे workflows तोड़ देते हैं। जो उपयोगकर्ता submit button क्लिक नहीं कर सकता, वह form पूरा नहीं कर सकता। जो उपयोगकर्ता focus states नहीं देख सकता, वह keyboard से navigate नहीं कर सकता। जो उपयोगकर्ता button text को background से अलग नहीं कर सकता, वह label नहीं पढ़ सकता।

ये edge cases नहीं हैं। वैश्विक आबादी के लगभग 15% लोगों में किसी न किसी प्रकार की disability है, और temporary impairments (टूटा हुआ mouse, तेज धूप, बच्चे को गोद में रखना) अंततः सभी को प्रभावित करते हैं।

अच्छी खबर यह है कि button accessibility अधिकतर solved problems हैं। आपको नए patterns invent करने या browser support का इंतज़ार करने की ज़रूरत नहीं है। आपको बस platform का सही उपयोग करना है और अपने काम का testing करना है।

मुख्य बातें

• बटनों के लिए <button> elements और navigation के लिए <a> elements का उपयोग करें — assistive technology के लिए semantic difference मायने रखता है
• motor impairments और mobile users को ध्यान में रखते हुए hit targets कम से कम 44×44 CSS pixels सुनिश्चित करें
• ऐसे दृश्यमान, high-contrast focus states दें जो आपके design system में हर जगह काम करें
• ऐसे button labels लिखें जो अलग से पढ़े जाने पर भी समझ में आएँ, और icon-only buttons के लिए aria-label का उपयोग करें
• महँगे retrofits से बचने के लिए color contrast launch के बाद नहीं, design के दौरान जाँचें

FAQ

Q: यदि मैं keyboard handlers जोड़ दूँ, तो क्या मैं <div> पर role="button" उपयोग कर सकता हूँ?

A: कर सकते हैं, लेकिन आपको नहीं करना चाहिए। आपको Enter, Space, focus management और disabled states को manually handle करना होगा — और आप अनिवार्य रूप से कुछ न कुछ छोड़ देंगे। <button> element यह सब default रूप से सही करता है। इसे उपयोग करें।

Q: उन बटनों का क्या जो state toggle करते हैं, जैसे play/pause button?

A: current state दिखाने के लिए aria-pressed="true" या aria-pressed="false" का उपयोग करें। button label को उस action को भी reflect करना चाहिए जो click करने पर होगा (playing होने पर "Pause", paused होने पर "Play"), current state को नहीं। स्क्रीन रीडर उपयोगकर्ताओं को यह जानना होता है कि बटन क्या करेगा, यह नहीं कि system किस state में है।

Q: क्या disabled buttons को contrast requirements पूरा करना चाहिए?

A: WCAG 2.1 disabled controls को contrast requirements (1.4.3) से छूट देता है, लेकिन यह विवादास्पद है। खराब contrast वाले disabled buttons सभी के लिए perceive करना कठिन होते हैं। यदि आप disabled button दिखाने जा रहे हैं, तो उसे readable बनाएँ। इससे भी बेहतर, उसे hide करें या समझाएँ कि वह disabled क्यों है।

Q: screen reader के बिना मैं button accessibility कैसे test करूँ?

A: अपना keyboard उपयोग करें। interface में tab करें और verify करें कि आप हर button तक पहुँच सकते हैं, focus कहाँ है देख सकते हैं, और Enter या Space से buttons activate कर सकते हैं। यह अधिकांश समस्याएँ पकड़ लेता है। गहन testing के लिए, computed role और label जाँचने हेतु Chrome या Firefox DevTools में accessibility inspector का उपयोग करें।

Q: aria-label और aria-labelledby में क्या अंतर है?

A: aria-label सीधे text string देता है। aria-labelledby किसी दूसरे element के ID को reference करता है जिसका text content label बन जाता है। जब label text DOM में पहले से कहीं और मौजूद हो, तो aria-labelledby का उपयोग करें। जब आपको ऐसा label देना हो जो screen पर visible नहीं है, तो aria-label का उपयोग करें।

स्रोत

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM