Accessibility guide for developers/hi

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

विकास के मामले में, मेरे खयाल से हमारी नियम पुस्तिका यही होनी चाहिए:


 * हमारे सदस्यों को सक्षम बनाने की कोशिश करना (और सदस्य यानी सभी सदस्य)
 * संभव हो तो सरल उपयोग के सभी समस्याओं का समाधान ढूँढ़ने की कोशिश करना, पर किसी भी कीमत पर नहीं
 * हमें उचित कमी की जगह प्रगतिशील वृद्धि का पथ चुनना चाहिए।
 * तकनीकी रूप से अनुकूल होने वाली चीज़ों को लागू करना



सरल उपयोग काम कैसे करता है
कुछ ज़रूरी चीज़ें हैं जिन्हें आपको याद रखना चाहिए।



विभिन्न रूपों में सरल उपयोग के रास्तें
सरल उपयोग कई चीज़ों से संबंधित है, कृपया इन्हें ध्यान में रखें:


 * ऐसा कुछ जो आसानी से समझा जा सकता है: पाठ के रूप से, दृश्य रूप से, बोध के रूप से, और कठिनता के रूप से।
 * कुछ सदस्यों को इंटरैक्ट करने के लिए स्क्रीन पाठक की आवश्यकता होती है, पर समानतः आवश्यक ही: लूप, ऊँचा कॉन्ट्रास्ट, एक टेक्स्ट-से-वार्ता इंजन, अनुकूलित CSS सेटिंग, या एक विशेष कीबोर्ड/इनपुट डिवाइस है।
 * यह उपयोग करने में आसान होना चाहिए; जवाबदेही, सामर्थ्य, स्थान, भाषा, हार्डवेयर, आदि।

यानी, सरल उपयोग का मतलब 'न सिर्फ' कीबोर्ड से सरल उपयोग 'या सिर्फ' स्क्रीन पाठक से सरल उपयोग है। हम एक्सर इन दोनों पर ही नज़र डालते हैं क्योंकि उन्हें हमेशा से अनदेखा कर दिया गया है। पर इन समस्याओं का समाधान मौजूद है और यही किसी दूसरे सुधार का आधार बनते हैं।

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



कीबोर्ड संचारण
हम इसे कीबोर्ड संचारण कहते हैं, पर इसका असली मतलब है: पॉइंटर डिवाइस (टच, माउस) पर निर्भरता को कम करना।


 * कीबोर्ड संचारण का उद्देश्य है अपने कीबोर्ड से फोकस को नियंत्रित करना और कार्य एक्ज़ेक्यूट करना।
 * टैब का पता करने वाले एलिमेंड फोकस का भी पता करते हैं, पर फोकस का पता करने वाला हर एलिमेंट टैब का पता नहीं करता।
 * वह सब कुछ एक कीबोर्ड से करना संभव होना चाहिए जो आप माउस से करते हैं।
 * कीबोर्ड संचारण जानकारी से स्क्रीन पाठक अपने अनुभव को और बेहतर बना सकते हैं।



स्क्रीन पाठक

 * एक स्क्रीन पाठक पर एक अलग 'कर्सर' का इस्तेमाल होता है, जो आम तौर पर DOM के तार्किक संरचना को बनाता है।
 * ध्यान हमेशा स्क्रीन पाठक के कर्सर पर होता है, और इसका उलटा भी सच है, मगर वे अलग-अलग चीज़ें हैं
 * एक स्क्रीन पाठक 'सरल उपयोग' API-ओं का इस्तेमाल करता है, जिसे आप साधारण DOM के बाहर एक इनपुट/आउटपुट 'दृश्य' समझ सकते हैं।
 * ARIA, DOM पर कुछ टिप्पणियाँ हैं जो इस बात को सुधारते हैं कि DOM तर्क को किस तरह से सरल उपयोग API-ओं में बदला जाता है। यह सही HTML और जावास्क्रिप्ट रखने का कोई विकल्प नहीं है। कीबोर्ड पर नेविगेशन सिर्फ तार्किक DOM क्रम से ही की जा सकती है! ARIA के बारे में अधिक जानकारी के लिए w3.org पर व्याख्या और MDN पर व्याख्या देखें।
 * एक स्क्रीन पाठक सिर्फ तार्किक DOM संरचना की मदद से नेविगेट नहीं करता, यह तो बस डिफ़ॉल्ट है।
 * उदाहरणस्वरूप, एक स्क्रीन पाठक माउस के कर्सर का भी इस्तेमाल कर सकता है।
 * iOS के VoiceOver पर एक स्क्रीन पाठक का इस्तेमाल होता है जिसे अँगूठे के स्थान और टच स्क्रीन पर इशारों की मदद से चलाया जा सकता है।
 * ज़्यादातर स्क्रीन पाठक सॉफ़्टवेयर पर अतिरिक्त मोड्स होते हैं, जिससे आप मुख्य क्षेत्रों को, एक स्वचालित रूप से बनाए गए विषय सूची को, और पृष्ठ के अंदर सदस्य द्वारा जोड़े गए 'बुकमार्क्स' को सूचीबद्ध करके उन पर आ-जा सकते हैं।
 * From the above point of multiple navigation methods, follows: There is a beginning and an end, but also left, right, top and bottom. You should not rely on these in your communication too much, but you don't need to fully deny their existence either. Do not confuse the visual capabilities of the user with spatial awareness that the screen reader might be able to convey to the user. Example:
 * a long sentence [image] the above image shows...
 * a long sentence [image][image] the left image shows, the right image shows...
 * a long sentence [image][image] the right image shows, the left image shows...
 * a long sentence [image][image] the above image shows...
 * a long sentence [image][image][image] the left image shows, the right image shows...
 * a long sentence [image][image] something totally different. the left image shows, the right image shows...



विकास के दिशानिर्देश
There are several standards around accessibility and honestly, almost all of them, although sound on identifying issues, still have significant problems when it comes to technical solutions (They have a high ratio of 'ugly workarounds'). This has been cause of much controversy in the communities. As such, we should identify uncontroversial stuff that we should simply always (or never) do and why. It's much easier to reach certain goals if we separate the uncontroversial stuff from the controversial stuff.



हमेशा उपयोग या प्रदान करें

 * Proper semantic HTML element : Use HTML elements for their intended purpose. For example,
 * Use and not  or  or  with a click handler
 * If you feel the need to bold something, consider if it is not more appropriate to use a header or a  element


 * Logical heading structure : All pages should always have a logical and consistent heading structure. Headings are one of the primary navigation tools used by screen reader users.
 * There should be no gaps in the nesting of the heading levels (So no H2->H4)
 * Headings should be descriptive
 * Headings should be unique within their own level. (There should not be two H3's with the same content under the same H2 section)
 * There should be separation between navigation and content


 * attribute for images with meaningful values : If an image is decorative, use an explicit empty value for the alt attribute; even better, turn it into a CSS background image.
 * the image alt usually takes precedence over the title attribute of images and even over the title attribute of links that wrap an image.


 * attribute for links : These are usually shown as the tooltips
 * Only use titles if they differ from the link text.
 * Most link titles are not actually spoken by screen readers, unless the reader has been explicitly configured this way.


 * ,  and   attributes : Using lang and hreflang enables selecting a proper voice in screen readers, picks the right spelling correction in browsers etc.


 * Sufficient contrast : Always check your colors for sufficient contrast. For text, a higher contrast is needed for smaller text (due to anti-aliasing).


 * Focus for keyboard navigation : Do not remove outline from focusable elements unless you define your own outline for the  state.
 * Don't use  otherwise.
 * If you define any pseudo class, like :hover or :active, please also define a  style.


 * Keyboard navigation :The tools should be navigable by keyboard. Please turn that on in your browser if you are a developer.
 * Use tabIndex: 0 to make elements keyboard accessible, which are not keyboard accessible implicitly (Anything but, , , , , , and ).
 * In this case also add a keydown handler responding to Enter (keyCode 13) and space (keyCode 32).
 * Use tabindex: -1 to remove elements from accessibility. (use this on links that are labels for the action inside an li for instance)
 * Elements that are implicitly keyboard accessible will forward enter/space keydown to the click handler


 * Dialogs etc

When not taking good care of accessibility, dialogs are some of the most inaccessible elements for screen reader and keyboard users. Spend some time on this.


 * The element that opens the dialog should have
 * The dialog itself should have
 * The dialog should be inserted in DOM order, or aria owns/controls needs to specify this relation between opening element and dialog
 * When opening the dialog, remember last focused element and shift focus to the first focusable tabbable element inside the dialog
 * When the dialog is modal, make it impossible to interact with the rest of the page
 * Capture clicks outside the dialog and ignore them or let them dismiss the dialog
 * Make sure you cannot tab to links or input elements outside of dialog
 * Make elements outside of the dialog unreachable for screen reader, by using aria-hidden
 * Make sure there is a close mode (esc key and a focusable close button with a descriptive title)
 * Closing should return the (keyboard) focus to the original focus point that you stored when you opened the dialog. For screen readers to return to the same point, be sure to specify the right owner of the dialog, if you have not inserted the dialog in DOM order.
 * Read up: Aria modals, Aria modal dialog, ARIA nonmodal dialog, ARIA tooltips.


 * WCAG 2.1 guidelines : Follow wherever possible
 * And its accompanying documents:
 * A guide to understanding and implementing Web Content Accessibility Guidelines 2.0
 * WCAG 2.1 supplement
 * Techniques and Failures for Web Content Accessibility Guidelines 2.0
 * WCAG 2.1 supplement



न करें

 * There is common advice to use  to push something (often the labels of icon buttons) out of the viewport for visual users and still have it in the accessibility DOM.   is variant of this. This is BAD advice.
 * This breaks our RTL rendering in several browsers. Specifically in rtl mode it creates a large canvas left of the viewport and scrollbars, much as +1000px would create in ltr mode. (If needed,  is preferred over   to avoid this).
 * VoiceOver on mobile is unable to use this text as a fallback, since it is a 'positional' screen reader. You cannot move your finger over this text and thus the text will not be read either. (aria-label is often the better choice).
 * Lastly, this enlarges the render surface needed to calculate the final webpage and this can impact performance on mobile devices.
 * Insightful overview of 'hide text offscreen' tricks are given by Jonathan Snook.
 * Things should not be repeated often. If you have a 100 links on a page that can open a dialog, then don't add 100 labels to those 100 links telling the user that it can be used to open a dialog. Telling a user how to use/what to do with the interface is a good thing, doing it consistently is simply annoying. Find a different way to explain it once (an  might be an idea in this case ?).
 * with an onclick handler. VO reads such JS as "internal link Hide". Use a proper button, or, with 'space' and 'enter' key handlers in the onclick. But no href attribute.

निवारण करें

 * Unicode symbols : Most assistive technologies are not good with symbols. Therefore, try to avoid characters such as ↑, →‎ or more complex characters, because many screen reader won't understand them. If they are required, try to wrap with a span element with the title attribute, so that the title attribute can communicate the implicit meaning within the context to the reader.
 * Small fonts : Legibility is preferred. If you make something so small that it is hard to read, do you even need it to begin with? Also avoid small fonts with low or mediocre contrast values (even if they fall inside the WCAG guidelines, small sizes require more explicit contrast then large sizes, especially with anti aliasing enabled).
 * Unusually large fonts : If you make text much larger than normal, it can become similarly hard to read (unless it's very short). This applies mostly to body text, or anything that takes up more than a couple lines. But the larger the text is, the more lines it will take up.
 * tabIndex > 0 : DOM order is preferred wherever possible. DOM order provides context for the actions.
 * Workarounds : Traditionally, accomplishing 'full' accessibility has required a lot of workarounds for html itself, the browsers and even specific screenreader software. However these workarounds often come with side effects, make use of bugs or unspecified behavior and inevitably create technical debt.
 * MediaWiki, because of the users it seeks to serve, the amount of code, it's (lack) of funding, etc tends to prefer future proof code over code that easily breaks. As such it generally avoids workarounds even if that might sometimes limit the accessibility we can deliver. Decisions on this are often influenced by the relative audience of the feature in MediaWiki. If something is ubiquitous for all users a workaround is more warrented than if the feature affected is only used by a tiny part of the audience (for instance, reading a page vs modifying the configuration of the installation).

ध्यान में लें

 * ARIA Roles
 * If a div or span behaves like an actual button use . also   and
 * Be careful with roles. For instance, don't add  to a  element, since the  element has an implicit , which will be overwritten. Instead use nested elements. Similarly for  which has an implicit
 * If a button creates a popupdialog, use.
 * Use  for contexts where this is not fully logical by itself (so everywhere except for labels in forms and headers in tables).
 * Avoid tables for layout purposes and test on smaller screen widths.
 * hide stuff: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
 * skip/jump to links



ये भी देखें

 * Wikimedia Design Style Guide: Accessibility principles
 * Open bugs and feature requests related to the accessibility in MediaWiki and other Wikimedia software
 * W3C Web Accessibility Initiative: Tips for Getting Started
 * W3C Web Accessibility Initiative: Web Accessibility Evaluation Tools List
 * Firefox Developer Tools: Accessibility Inspector
 * Chrome Developer Tools: Accessibility features
 * Accessibility and usability cleanup
 * Blogposts
 * Steps Towards an Accessible Web Form
 * Understanding WCAG Level
 * Software
 * WAVE, a Web accessibility evaluation tool
 * Accessibility simulation on MediaWiki. Experience a page as a color blind person would experience it.
 * https://www.deque.com/axe/ browser extension for accessibility auditing a page
 * https://www.powermapper.com/products/sortsite/checks/accessibility-checks/ webapp for accessibility auditing. See also https://www.powermapper.com/tests/
 * University of Cambridge - Impairment simulator software (Microsoft Windows only)