मॉड्यूल 21 · मोबाइल टेस्टिंग

मोबाइल एक्सेसिबिलिटी

Mutqan Soft QA टीम द्वारा · · 23 मिनट · मध्यम

Mobile accessibility testing यह जाँचती है कि disabilities वाले लोग किसी Android या iOS app को अपने phone में built-in assistive technologies और settings के साथ इस्तेमाल कर पाते हैं या नहीं: TalkBack और VoiceOver screen readers, voice control, switch access, बड़ा text, ज़्यादा contrast और कम motion। Accessibility testing guide में आपने जो WCAG 2.2 success criteria देखे, वे app screens पर भी लागू होते हैं, और Android व Apple उनके ऊपर अपनी platform guidance जोड़ते हैं।

एक ठोस उदाहरण: एक दृष्टिहीन user VoiceOver चालू करके shopping app खोलती है, quantity control तक पहुँचती है और सिर्फ़ "button" सुनती है। उसे पता नहीं चलता कि यह item जोड़ता है या हटाता है, इसलिए वह order पूरा नहीं कर पाती। वही icon tap करने वाले देख सकने वाले tester को कुछ गलत नहीं दिखता — इसीलिए इस lesson के checks screen reader और system settings चालू करके किए जाते हैं।

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

बहुत से लोगों के लिए phone ही मुख्य computer है, और कई disabled users उस पर इसीलिए निर्भर हैं क्योंकि assistive technology उसमें built-in है। जब app उसे ignore करता है, तो नतीजा cosmetic defect नहीं बल्कि रुका हुआ task होता है: ऐसा payment जो confirm नहीं हो सकता, ऐसा form जो submit नहीं हो सकता। कई markets में accessibility एक legal या contractual requirement भी है, जैसे public-sector apps के लिए, और European Union में European Accessibility Act के तहत e-commerce और consumer banking जैसी services के लिए।

Tester के लिए, ज़्यादातर mobile accessibility defects कुछ दोहराए जाने वाले patterns से आते हैं: बिना नाम वाले icon buttons, fixed size में text, छोटे targets, सिर्फ़ gesture से होने वाले actions और dark mode में fail होने वाले colours। हर नई screen पर screen reader और system settings के साथ एक छोटा pass इन्हें तब पकड़ लेता है जब ये एक line के fixes होते हैं; release के बाद वही patterns app की हर screen में फैल चुके होते हैं।

TalkBack और VoiceOver: क्या सुनना है

Android पर TalkBack और iOS पर VoiceOver touch के काम करने का तरीका बदल देते हैं। एक tap element को select करके उसे बोलकर पढ़ता है, कहीं भी double tap selected element को activate करता है, दाएँ या बाएँ swipe अगले या पिछले element पर ले जाता है, और scroll करने के लिए TalkBack में दो और VoiceOver में तीन उँगलियाँ लगती हैं। इनमें से किसी को चालू करने से पहले accessibility shortcut set करें (Android पर दोनों volume keys दबाकर रखना, iPhone पर side या Home button का triple click), ताकि आप उसे फिर बंद कर सकें, और built-in tutorial एक बार पूरा करें।

फिर हर screen में ऊपर से, एक-एक swipe करके चलें, और जो सुनते हैं उसकी तुलना जो देखते हैं उससे करें। Developers बोला जाने वाला text platform properties से set करते हैं, जैसे Android पर contentDescription और iOS पर accessibilityLabel, accessibilityValue और accessibilityTraits, इसलिए ज़्यादातर defects किसी एक missing या गलत property पर आकर रुकते हैं।

  • Name: हर control का छोटा, सार्थक accessible name हो। सिर्फ़ icon वाले buttons, जैसे plus, minus, heart या share, सबसे आम failure हैं (4.1.2 Name, Role, Value; सार्थक images के लिए 1.1.1 Non-text Content)।
  • Role और state: आप सुनते हैं कि element क्या है (button, switch, checkbox, tab) और उसकी state क्या है (on, selected, expanded, disabled), और action लेने पर state बदलती है।
  • Value: quantity बदलने या slider खिसकाने के बाद नई value announce होती है।
  • Order और grouping: swipe order visual और logical order के अनुसार चलता है (Arabic में right to left), और product card एक item की तरह पढ़ा जाता है, चार टुकड़ों में नहीं।
  • Focus और messages: dialog खुलने पर focus उसके अंदर जाता है और बंद होने पर उसे खोलने वाले control पर लौटता है, और "Added to cart" जैसे messages announce होते हैं (4.1.3 Status Messages)।
  • Voice users: Android पर Voice Access या iOS पर Voice Control के साथ user visible label बोलता है, इसलिए spoken name में visible text होना चाहिए (2.5.3 Label in Name)।

Touch target size, text size और contrast

WCAG 2.2 targets के लिए न्यूनतम सीमा तय करता है: 2.5.8 Target Size (Minimum), level AA, कम से कम 24 × 24 CSS pixels माँगता है, या छोटे target के चारों ओर पर्याप्त जगह; 2.5.5 Target Size (Enhanced), level AAA, 44 × 44 माँगता है। Platforms density-independent units में मापते हैं, Android पर dp और iOS पर points, जिनका physical size हर screen density पर लगभग एक जैसा रहता है, और वे इससे ज़्यादा की सलाह देते हैं: Android पर कम से कम 48 × 48 dp, और Apple की Human Interface Guidelines में iOS के लिए 44 × 44 points का default control size, और 28 × 28 का minimum। Device width पर layout होने वाले mobile web page में browser एक CSS pixel को Android पर एक dp और iOS पर एक point के बराबर draw करता है, इसलिए numbers की सीधी तुलना होती है। Drawn icon नहीं, touch area मापें: हर तरफ़ 12 dp padding वाले 24 dp icon का target 48 dp है।

जिन users को बड़ा text चाहिए, वे उसे पूरे phone के लिए एक बार set करते हैं: Android पर font size setting (Android 14 से 200% तक) और iOS पर Dynamic Type, जिसके larger accessibility sizes 200% से भी आगे जाते हैं। 1.4.4 Resize Text (AA) माँगता है कि text बिना content या functionality खोए 200% तक बढ़ सके। Text setting का पालन तभी करता है जब app scalable units इस्तेमाल करे: Android पर sp (ऐसे dp जो font size setting के साथ भी बढ़ते हैं) और iOS पर Dynamic Type text styles; dp या fixed points में set text छोटा ही रहता है। सबसे बड़े sizes पर clipped या truncated labels, overlapping text, screen से बाहर धकेले गए buttons और scroll न होने वाली screens देखें।

Contrast 1.4.3 Contrast (Minimum) के अनुसार है: normal text के लिए 4.5:1 और large text (कम से कम 18 point, या 14 point bold) के लिए 3:1। WCAG का मतलब typographic points से है, जिन्हें Understanding WCAG लगभग 24 और 18.5 CSS pixels बताता है, इसलिए WCAG के अनुसार 18 dp या 18 iOS points का text अभी large नहीं है; Apple की HIG अपने 18 points से 3:1 लागू करती है, इसलिए team के साथ तय करें कि आप कौन-सी सीमा टेस्ट करेंगे। 1.4.11 Non-text Contrast icons, field borders और controls की visual state के लिए 3:1 माँगता है। हर screen को light और dark दोनों mode में मापें: grey #616161 white पर 6.19:1 तक पहुँचता है लेकिन dark background #121212 पर सिर्फ़ 3.02:1, यानी एक theme में pass होने वाला colour दूसरी में fail हो सकता है।

आज़माएँ: कलर कन्वर्टर

Touch screen पर pointer, gesture और orientation criteria

WCAG 2.2 की guideline 2.5 Input Modalities touch screens को ध्यान में रखकर लिखी गई है, और pointer और motion accessibility वाला lesson इसके criteria गहराई से सिखाता है। Screen reader users यही समस्या दूसरी तरफ़ से झेलते हैं: TalkBack या VoiceOver चालू होने पर swipe app तक पहुँचने के बजाय focus को आगे बढ़ाता है, इसलिए gesture actions accessibility actions के रूप में भी मिलने चाहिए, जिन्हें VoiceOver अपने rotor में Actions के अंदर और TalkBack अपने actions menu में दिखाता है। Phone पर हर criterion एक ठोस test बन जाता है:

  • 2.5.1 Pointer Gestures (A): multipoint या path-based gesture से होने वाला हर काम, जैसे zoom के लिए pinch, delete के लिए swipe या cards के बीच swipe, एक उँगली से और बिना path के भी हो सके, जैसे single taps: plus और minus buttons, Delete button, next और previous buttons।
  • 2.5.7 Dragging Movements (AA): list को reorder करना, map खिसकाना या slider thumb खिसकाना dragging के बिना भी हो सके, जैसे move up और move down buttons, pan buttons या slider track पर tap से।
  • 2.5.2 Pointer Cancellation (A): action उँगली उठने पर हो, छूने पर नहीं। किसी button को दबाएँ, उँगली उससे बाहर खिसकाएँ और उठाएँ: कुछ नहीं होना चाहिए, या action के बाद उसे undo करने का तरीका हो। Standard platform buttons ऐसे ही काम करते हैं; custom touch handlers अक्सर नहीं।
  • 2.5.4 Motion Actuation (A): phone हिलाने या झुकाने से चलने वाले feature के लिए screen पर control भी हो, और motion response बंद किया जा सके ताकि हाथ का कंपन या चलती wheelchair उसे गलती से trigger न करे।
  • 1.3.4 Orientation (AA): screens portrait और landscape दोनों में काम करें, जब तक कोई एक orientation essential न हो, जैसे piano keyboard app। जिनका phone wheelchair या bed mount पर fixed है, वे उसे घुमा नहीं सकते।

Platform checkers और वे क्या नहीं परख सकते

हर platform का एक free checker है। Android का Accessibility Scanner app आप जिस screen पर हैं उसे scan करता है और missing content labels, छोटे touch targets, clickable items और कम text व image contrast के लिए fixes सुझाता है। Xcode का Accessibility Inspector iOS Simulator में चल रहे app के किसी भी element का label, value और traits दिखाता है, एक audit चलाता है जो missing descriptions, छोटे hit regions, कम contrast, clipped text और Dynamic Type support न होने जैसे issues report करता है, और उसमें colour contrast calculator भी है। इसी तरह के checks UI tests के अंदर भी चल सकते हैं: Espresso में AccessibilityChecks.enable() और XCUITest में performAccessibilityAudit()।

ये tools एक बार में एक screen state पर rules जाँचते हैं; meaning नहीं परखते। वे बिना नाम का button ढूँढ लेते हैं, लेकिन गलत नाम नहीं। वे नहीं बता सकते कि reading order समझ में आता है या नहीं, swipe का विकल्प है या नहीं, dialog बंद होने के बाद focus कहाँ जाता है, या सबसे बड़े text size पर लंबा form अब भी काम करता है या नहीं। Mechanical defects जल्दी पकड़ने का काम इन्हें दें, और अपना manual समय screen reader pass, settings और gesture checks पर लगाएँ।

Mobile accessibility के नौ checks, उनके WCAG 2.2 criteria और Android व iOS पर उन्हें चलाने का तरीका: checkers names, target size और contrast flag करते हैं; order, gestures, motion और orientation इंसान परखता है।
CheckWCAG 2.2AndroidiOS
बोला गया name, role और state4.1.2A · Name, Role, ValueScanner missing labels flag करता है; TalkBack बताता है कि नाम सार्थक है या नहींInspector audit missing descriptions flag करता है; VoiceOver बताता है कि नाम सार्थक है या नहीं
Reading और focus order1.3.2 · 2.4.3A · Meaningful Sequence, Focus Orderसुनकर: TalkBack के साथ पूरी screen में swipe करेंसुनकर: VoiceOver के साथ पूरी screen में swipe करें
Touch target size2.5.8AA · कम से कम 24 × 24 CSS pxScanner 48 × 48 dp से छोटे targets flag करता हैInspector audit छोटे hit regions flag करता है; HIG default: 44 × 44 pt
Text size1.4.4AA · Resize Text 200% तकदेखकर: font size अधिकतम पर, फिर clipped text देखेंInspector audit बिना Dynamic Type वाला text flag करता है; फिर larger sizes जाँचें
Contrast1.4.3 · 1.4.11AA · text 4.5:1, large text और icons 3:1Scanner कम text और image contrast flag करता है; dark mode में दोहराएँInspector audit और contrast calculator; dark mode में दोहराएँ
Gesture और drag के विकल्प2.5.1 · 2.5.7A · AA · Pointer Gestures, Dragging Movementsहाथ से: tap वाला विकल्प है; TalkBack उसे actions menu में देता हैहाथ से: tap वाला विकल्प है; VoiceOver उसे rotor में Actions के अंदर देता है
Pointer cancellation2.5.2A · Pointer Cancellationहाथ से: दबाएँ, उँगली बाहर खिसकाएँ, उठाएँ; कुछ नहीं होताहाथ से: वही दबाना, बाहर खिसकाना और उठाना
Shake और tilt2.5.4A · Motion Actuationहाथ से: screen पर control वही काम करता है, और motion बंद किया जा सकता हैहाथ से: Android की तरह, Settings में Shake to Undo बंद करके भी
Orientation1.3.4AA · Orientationहाथ से: auto-rotate चालू रखकर घुमाएँ; screen साथ घूमती हैहाथ से: Portrait Orientation Lock बंद रखकर घुमाएँ; screen साथ घूमती है
  • Platform checker report करता है; इंसान फिर भी confirm करता है
  • कोई checker तय नहीं करता: सुनकर या हाथ से टेस्ट करें

Checkers के नाम Android के Accessibility Scanner और Xcode के Accessibility Inspector के अनुसार हैं; वे क्या flag करते हैं, यह versions के साथ बदल सकता है।

Worked example: दोनों platforms पर cart screen

एक shopping app का cart products को quantity stepper (minus और plus icons, जहाँ minus 1 पर रुक जाता है) के साथ दिखाता है, बाईं ओर swipe करने पर item हटाता है और Checkout button पर ख़त्म होता है। Tester Android phone पर TalkBack और iPhone पर VoiceOver से screen पर चलता है, फिर सबसे बड़े text size और dark mode में यही दोहराता है, platform checkers चलाता है और phone घुमाता है। हर finding उस criterion या guideline के साथ record होती है जिसमें वह fail होती है:

  • Minus और plus दोनों platforms पर बिना नाम के सिर्फ़ "button" announce होते हैं: 4.1.2। Expected: "मात्रा घटाएँ, नीली shirt" और "मात्रा बढ़ाएँ, नीली shirt"।
  • Plus पर tap के बाद नई quantity announce नहीं होती: 4.1.2, क्योंकि बदलाव screen reader तक नहीं पहुँचता।
  • Item हटाने का एकमात्र तरीका swipe to delete है, और custom swipe action के रूप में उपलब्ध नहीं है: 2.5.1। Expected: हर row में Remove button, जो accessibility action के रूप में भी मिले।
  • Stepper buttons 32 × 32 (Android पर dp, iOS पर points) के हैं: ये 2.5.8 पूरा करते हैं लेकिन Android के 48 dp और Apple के 44 points वाले default से छोटे हैं, और Accessibility Scanner इन्हें flag करता है। Team के तय किए target के मुकाबले report किया गया।
  • 200% font size पर price कट जाता है और Checkout label truncate हो जाता है: 1.4.4।
  • #616161 में लिखा "Free delivery" note white पर pass है लेकिन dark mode में 3.02:1 तक गिर जाता है: 1.4.3, सिर्फ़ dark mode में।
  • Screen portrait में locked है: 1.3.4, क्योंकि cart को किसी एक orientation की ज़रूरत नहीं।

आज़माएँ: टेस्ट केस जनरेटर आज़माएँ: पेयरवाइज़ टेस्टिंग जनरेटर

आम गलतियाँ

  • सिर्फ़ screen देखकर accessibility जाँचना: missing names और गलत announcements तब तक नहीं दिखते जब तक TalkBack या VoiceOver चालू न हो।
  • एक platform टेस्ट करके मान लेना कि दूसरा भी वैसा ही है: Android और iOS अलग properties इस्तेमाल करते हैं, भले app cross-platform framework से बना हो।
  • Accessibility Scanner या Accessibility Inspector के साफ़ result को सबूत मान लेना: checkers एक screen state पर rules जाँचते हैं, पूरा experience नहीं।
  • Touch area की जगह drawn icon मापना, या physical pixels को dp और points से मिला देना।
  • Text size और contrast सिर्फ़ default settings और light mode में टेस्ट करना।
  • सिर्फ़ gesture से होने वाले action को "works" कहकर बंद कर देना क्योंकि tester swipe कर सकता है: सवाल यह है कि single-tap विकल्प है या नहीं।

QA का नज़रिया

असली team में mobile accessibility refinement में शुरू होती है: icon buttons के नाम, target sizes और text styles को design और acceptance criteria का हिस्सा बनाने को कहें, और तय करें कि team किस स्तर के ख़िलाफ़ टेस्ट करती है; WCAG 2.2 level AA के साथ platform guidance एक आम चुनाव है। फिर हर नई screen को story done होने से पहले TalkBack, VoiceOver, सबसे बड़े text size और dark mode के साथ एक छोटा pass मिलता है। Settings जल्दी गुणा हो जाती हैं (platform, screen reader, text size, theme, orientation), इसलिए pairwise selection combinations कम रखता है, और जहाँ team के UI tests हैं वहाँ platform checks CI में चल सकते हैं।

अच्छी mobile accessibility bug report में device, OS version, assistive technology या setting और उसकी value (TalkBack, font size 200%, dark mode), steps, क्या announce हुआ या दिखा, क्या expected था और criterion लिखा होता है। जो बोला गया उसे capture करने के लिए TalkBack की developer settings में Display speech output या VoiceOver settings में Caption Panel चालू करें, और screen recording attach करें। Fix के बाद उसी setting के साथ retest करें और case को regression set में रखें: बाद का redesign label को उतनी ही आसानी से हटा सकता है जितनी आसानी से fix ने उसे जोड़ा था।

अभ्यास

Store locator screen का audit करें

आपका काम

एक retail app Android और iOS पर store locator screen जोड़ता है, जिसका वर्णन नीचे दिए developer notes में है। App चलाए बिना, जिन accessibility problems की आप उम्मीद करते हैं उनकी list बनाएँ, हर एक के लिए WCAG 2.2 criterion या platform guideline बताएँ, और लिखें कि device पर आप उसे कैसे confirm करेंगे।

फिर उन तीन findings के bug titles लिखें जिन्हें आप सबसे पहले report करेंगे।

सामग्री
Screen: StoreLocator (Android and iOS), locked to portrait

map            map view, full screen
               zoom: pinch only    move: drag only
storeCard      card at the bottom, swipe left/right to change store
btnCall        phone icon, no label, 36 x 36 dp / pt
               icon #FFFFFF on #4CAF50
txtHours       opening hours, textSize 12dp (Android), fixed 12 pt (iOS)
               #9E9E9E on #FFFFFF
btnDirections  text button "Directions", 120 x 48 dp / pt
               #FFFFFF on #1565C0
चरण
  1. Elements को एक-एक करके देखें और screen reader वाले सवाल पूछें: name, role, state और order।
  2. हर size, font unit और colour pair की तुलना इस lesson के numbers से करें, और contrast ratios निकालें।
  3. हर gesture और orientation lock को pointer, gesture और orientation criteria से जाँचें।
  4. हर finding के लिए लिखें कि आप उसे कैसे confirm करेंगे: TalkBack, VoiceOver, platform checker या हाथ से।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

btnCall: इसका नाम नहीं है, इसलिए TalkBack और VoiceOver सिर्फ़ "button" बोलते हैं (4.1.2); उस तक swipe करके confirm करें, और दोनों checkers missing label flag करते हैं। #4CAF50 पर white icon 2.78:1 है, 1.4.11 के 3:1 से कम। 36 × 36 पर यह 2.5.8 पूरा करता है, लेकिन Android के 48 dp और Apple के 44 points वाले default से छोटा है।

txtHours: white पर #9E9E9E 2.68:1 है, 4.5:1 से कम (1.4.3); इसे Color Converter या Inspector के contrast calculator से जाँचें। इसका size dp और points में fixed है, इसलिए यह font size या Dynamic Type setting के साथ नहीं बढ़ेगा (1.4.4); Android पर 200% और iOS पर larger accessibility sizes पर confirm करें।

Map: सिर्फ़ pinch से zoom 2.5.1 में fail होता है और सिर्फ़ drag से खिसकाना 2.5.7 में; zoom और pan buttons जोड़ें, और search वाली store list हर store तक पहुँचने का उपयोगी अतिरिक्त रास्ता है। storeCard: store बदलने का एकमात्र तरीका swipe है (2.5.1); next और previous buttons जोड़ें और उन्हें screen readers को actions के रूप में दें।

Portrait lock: 1.3.4 में fail, क्योंकि store locator को एक orientation की ज़रूरत नहीं; auto-rotate चालू रखकर phone घुमाकर confirm करें। btnDirections pass है: 120 × 48 काफ़ी बड़ा है और #1565C0 पर white 5.75:1 है; confirm करें कि यह "Directions, button" पढ़ा जाता है।

Bug titles, उन defects से शुरू करके जो किसी task को रोकते हैं: "Store locator: call button का कोई accessible name नहीं (TalkBack, VoiceOver)"; "Store locator: store सिर्फ़ swipe से बदलता है, single-tap विकल्प नहीं (WCAG 2.5.1)"; "Store locator: opening hours text का contrast 2.68:1 है, 4.5:1 से कम (WCAG 1.4.3)"। पहले दो defects screen reader users को रोकते हैं: वे नहीं जान पाते कि कौन-सा button store को call करता है, और दूसरे store पर नहीं जा पाते। बाकी findings भी report करें, हर defect की अलग report में, जैसे opening hours text जो system font size के साथ scale नहीं होता।

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

क्या WCAG native mobile apps पर लागू होता है?

WCAG 2.2 web content के लिए लिखा गया है, लेकिन इसके success criteria आम तौर पर native apps पर भी लागू किए जाते हैं। W3C का note WCAG2ICT समझाता है कि web page न होने वाले software के लिए हर criterion को कैसे पढ़ें, और EN 301 549 जैसे standards WCAG पर आधारित requirements software पर लागू करते हैं, mobile apps समेत। Practice में teams apps को WCAG 2.2 level AA और Android व Apple की guidance के साथ टेस्ट करती हैं।

अगर app cross-platform framework से बना है, तो क्या TalkBack और VoiceOver दोनों चाहिए?

हाँ। Flutter और React Native जैसे frameworks अपने components को हर platform की accessibility properties से map करते हैं, और नतीजा अलग हो सकता है: VoiceOver जो नाम पढ़ता है वह TalkBack के लिए missing हो सकता है, या reading order बदल सकता है। कम से कम key journeys दोनों platforms पर टेस्ट करें।

क्या app में touch target के लिए 24 × 24 काफ़ी है?

यह WCAG 2.2 level AA का minimum है, इसलिए पर्याप्त जगह के बिना छोटा target fail होता है। Android 48 × 48 dp की सलाह देता है और Apple 44 × 44 points को default size बताता है, जिन्हें कंपन या सीमित dexterity वाले लोग ज़्यादा आसानी से छू पाते हैं। Team के साथ तय करें कि कौन-सी value acceptance criterion है, और deviations उसी के मुकाबले report करें।

क्या screen reader से टेस्ट करने के लिए मुझे उसका expert user होना ज़रूरी है?

नहीं। Basic gestures सीखें और उसी तरह टेस्ट करें जैसे users चलते हैं: जो दिखता है उसे tap करने के बजाय element से element तक swipe करें, क्योंकि tap उन items तक भी पहुँच सकता है जिन्हें swipe order छोड़ देता है। फिर भी अनुभवी disabled users ऐसी problems पकड़ते हैं जो testers से छूट जाती हैं, इसलिए जब हो सके उन्हें usability testing में शामिल करें।

संदर्भ

  • 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 की व्याख्या: उद्देश्य, किसे लाभ, उदाहरण और तकनीकें (नॉर्मेटिव नहीं)।
  • Test your app's accessibilityAndroid Developers (Google)Android ऐप की एक्सेसिबिलिटी को TalkBack जैसी सेवाओं से मैन्युअली और प्लेटफ़ॉर्म के टेस्टिंग टूल से ऑटोमेटेड तरीके से कैसे जाँचें।
  • Accessibility — Human Interface GuidelinesAppleiOS और अन्य प्लेटफ़ॉर्म के लिए Apple की एक्सेसिबिलिटी डिज़ाइन गाइडेंस: VoiceOver, Dynamic Type, कंट्रास्ट, टच टारगेट और मोशन।
टूल्स

Mutqan tools से अभ्यास करें

कलर कन्वर्टर

रंगों को HEX, RGB(A), HSL(A), HSB/HSV, CMYK और CSS नामित रंगों के बीच बदलें, लाइव प्रीव्यू के साथ।

यूटिलिटीज़

टेस्ट केस जनरेटर

फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।

टेस्ट डिज़ाइन

बहुभाषी टेस्ट डेटा जनरेटर

i18n और RTL/LTR मिश्रण जाँचने के लिए एक ही रिकॉर्ड कई भाषाओं (अंग्रेज़ी, अरबी, हिंदी और अन्य) में जनरेट करें।

टेस्ट डेटा

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा