aiAPPaccessibilityQAმობილური აპი

მობილური აპის accessibility-ის მიღების ტესტის ჩარჩო

როგორ ჩაიწეროს ახალი iOS და Android აპის accessibility შემოწმება, დამხმარე ტექნოლოგიები, ხარვეზის დონეები და მიღების მტკიცებულება.

aiNOWProduct teamგანახლდა 26 სექტემბერი, 2026წაკითხვის დრო: 9 წთ

აპის ხელმისაწვდომობის მიღების ტესტი მომხმარებლის ძირითად გზაზე ჩაატარეთ VoiceOver-ითა და TalkBack-ით. თითოეულ სცენარს მიუთითეთ მოწყობილობა, მოსალოდნელი ქცევა და ხარვეზის გამოსწორების მტკიცებულება.

საკუთარი ეკრანებისა და მომხმარებლის გზის შესაფასებლად aiAPP-ის პროექტის განხილვაში აღწერეთ, ვის უნდა მოემსახუროს აპი და რომელი მოქმედებაა კრიტიკული.

ხელმისაწვდომობის მიღების საზღვარი

მიღება ნიშნავს შეთანხმებულ პირობაზე შემოწმებას. ეს არ არის მხოლოდ ღილაკის ფერის ან შრიფტის გადახედვა. მყიდველმა უნდა აღწეროს, როგორ პოულობს ადამიანი ძირითად მოქმედებას, როგორ იგებს კონტროლის დანიშნულებას, როგორ ამჩნევს შეცდომას და როგორ ბრუნდება პროცესში. ასეთი მოთხოვნა დიზაინერს, დეველოპერსა და ტესტერს ერთსა და იმავე შედეგზე ამუშავებს.

W3C აღწერს WCAG-ის გამოყენებას მობილურ კონტექსტში. Apple აქვეყნებს VoiceOver-ის შეფასების კრიტერიუმებს, Android-ის დოკუმენტაცია კი ტესტირების გზებს. კონკრეტული აპის მიღება რეალურ ეკრანებსა და მომხმარებლის გზებზე ჩატარებული ტესტით გადაწყვიტეთ.

სატესტო მომხმარებლის გზები

დაიწყეთ იმ გზით, რომლის შეწყვეტაც ბიზნესისთვის ძვირია ან მომხმარებლისთვის არსებით დაბრკოლებას ქმნის. მაგალითად, ეს შეიძლება იყოს ანგარიშის შექმნა, შეკვეთის დადასტურება, ჯავშნის გაუქმება, გადახდის სტატუსის ნახვა ან დახმარების მოთხოვნა. თითოეულ გზას დაურთეთ საწყისი მდგომარეობა, მოქმედებების თანმიმდევრობა, შეცდომის სცენარი და წარმატების მკაფიო ნიშანი.

შესვლა და რეგისტრაცია: ველები, ავტორიზაციის შეცდომა, პაროლის აღდგენა და შეტყობინების წაკითხვა.
ძირითადი მოქმედება: კონტროლების პოვნა, ფოკუსის თანმიმდევრობა, არჩევანის შეცვლა და დადასტურება.
შეცდომა: ველის პრობლემის დაკავშირება, ტექსტის წაკითხვა და გამოსწორების შემდეგ გზის გაგრძელება.
დახმარება: მხარდაჭერის არხის აღმოჩენა, შეტყობინების გაგზავნა და პასუხის სტატუსი.

მოთხოვნების ჩეკლისტი გამოიყენეთ ყველა გზის ჩამოსაწერად, შემდეგ კი ხელმისაწვდომობის ცალკე მიღების ჩანაწერი დაურთეთ თითოეულ კრიტიკულ გზას.

VoiceOver-ისა და TalkBack-ის შემოწმება

ეკრანის წამკითხველით შემოწმება იწყება არა აპის გახსნით, არამედ მომხმარებლის მიზნის დასახელებით. ტესტერმა უნდა შეძლოს ეკრანზე გადასვლა, ელემენტების თანმიმდევრობით გაგება, ღილაკის მოქმედების ამოცნობა და შედეგის მოსმენა. თუ კონტროლს მხოლოდ ფერი ან მდებარეობა განასხვავებს, წამკითხველის მომხმარებელი საჭირო ინფორმაციას ვერ მიიღებს.

iOS-ზე ჩაწერეთ VoiceOver-ის ჟესტებით გავლილი სცენარი და შეამოწმეთ ელემენტის სახელი, როლი, მდგომარეობა, მნიშვნელობა და მოქმედება. Android-ზე ანალოგიურად აღწერეთ TalkBack-ის ფოკუსი და წაკითხვის რიგი. ორივე პლატფორმაზე ერთი და იგივე ტექსტი შეიძლება განსხვავებულად გამოცხადდეს, ამიტომ მხოლოდ დეველოპერის emulator-ის შედეგით მიღება არ გადაწყვიტოთ.

არ შემოიფარგლოთ მთავარი ეკრანით. შეამოწმეთ მოდალური ფანჯარა, ჩამოსაშლელი არჩევანი, ცარიელი შედეგი, ჩატვირთვა, უარყოფილი უფლება და შეცდომის შეტყობინება. ყოველი მდგომარეობა უნდა იძლეოდეს შემდეგი მოქმედების გასაგებ გზას.

რა შეამოწმოთ ვიზუალურ და მოტორულ გამოყენებაში?

მომხმარებელს შეიძლება დასჭირდეს დიდი ტექსტი, გაზრდილი კონტრასტი, შემცირებული მოძრაობა ან შეხების განსხვავებული სიზუსტე. ამიტომ მიღების პირობებში ცალკე დაწერეთ, რა ხდება სისტემური პარამეტრის შეცვლისას. ტექსტი არ უნდა დაიფაროს, ღილაკი არ უნდა გაქრეს და მნიშვნელოვანი მნიშვნელობა მხოლოდ ფერით არ უნდა გამოიხატოს.

სფერო	კითხვის ფორმა	მტკიცებულება
ტექსტი	ზომის ზრდისას იკითხება და ჩანს მთელი შინაარსი?	ეკრანის ჩანაწერი და მოწყობილობის პარამეტრი
კონტრასტი	ტექსტი, ხატულა და ფოკუსი გამოირჩევა ფონისგან?	კონკრეტული ეკრანი და დიზაინის გადაწყვეტილება
ფოკუსი	მომდევნო მოქმედება პროგნოზირებადია?	VoiceOver ან TalkBack-ის სცენარი
შეხება	მოქმედება სრულდება შემთხვევითი დაჭერის გარეშე?	რეალურ მოწყობილობაზე შესრულებული ტესტი
მოძრაობა	ანიმაციის შემცირებისას არსებითი ინფორმაცია რჩება?	სისტემური პარამეტრით განმეორებული გზა

როგორ ჩამოაყალიბოთ ხარვეზისა და მიღების ჩანაწერი?

ხარვეზის აღწერაში არ დაწეროთ მხოლოდ „accessibility არ მუშაობს“. მიუთითეთ მომხმარებლის როლი, პლატფორმა, მოწყობილობა, საწყისი მდგომარეობა, მოქმედება, რეალური პასუხი, მოსალოდნელი პასუხი და გავლენა. დაურთეთ ჩანაწერი ან ეკრანის სურათი ისე, რომ პირადი მონაცემი არ გამჟღავნდეს.

ბლოკერი: ძირითადი გზა ვერ სრულდება ან მომხმარებელი შედეგს ვერ იგებს.
მაღალი გავლენა: გზა გრძელდება მხოლოდ დახმარებით ან მნიშვნელოვანი ინფორმაცია მიუწვდომელია.
საშუალო გავლენა: ალტერნატიული გზა არსებობს, მაგრამ დაბრკოლება განმეორებადია.
დაბალი გავლენა: ტექსტის, სახელის ან კონსისტენტურობის ხარვეზი, რომელიც გაუმჯობესებას მოითხოვს.

სიმძიმის კატეგორიები თქვენს პროდუქტთან უნდა დააკავშიროთ. ერთი კომპანიისთვის გადახდის ღილაკის მიუწვდომლობა შეიძლება release blocker იყოს, მეორისთვის კი კრიტიკული იყოს საწყისი რეგისტრაცია. კატეგორია წინასწარ შეათანხმეთ და მიღებისას არ შეცვალოთ მხოლოდ იმიტომ, რომ გამოსწორება რთულია.

რა ჰკითხოთ მომწოდებელს ტესტის წინ?

მომწოდებლისგან მოითხოვეთ არა ზოგადი დაპირება, არამედ შემოწმების გეგმა. ჰკითხეთ, რომელ მოწყობილობებზე და სისტემურ პარამეტრებზე გაივლის ტესტი, როგორ ჩაიწერება ეკრანის წამკითხველის შედეგი, ვინ ამოწმებს ტექსტის ცვლილებას და როგორ იმართება ნაპოვნი ხარვეზი. წინასწარ შეთანხმდით, რას ასწორებს გუნდი, რას ამოწმებს კლიენტი და რომელი საკითხი მესამე მხარის კომპონენტზეა დამოკიდებული.

დეველოპერის შერჩევის კრიტერიუმები დაგეხმარებათ ამ კითხვების მომწოდებლის გამოცდილებასთან დაკავშირებაში. კომერციულ განხილვაში არ მიიღოთ სიტყვა „სრული accessibility“ განმარტების გარეშე. დააკონკრეტეთ გზა, ტექნოლოგია, აუდიტის ფორმა და მიღების მტკიცებულება.

რა ნაბიჯებით მოამზადოთ მიღების ჩეკლისტი?

დაასახელეთ მომხმარებლის ძირითადი როლები და თითოეულისთვის კრიტიკული გზა.
ჩამოწერეთ ეკრანები, მდგომარეობები, შეცდომები და მხარდაჭერის არხი.
განსაზღვრეთ VoiceOver, TalkBack, ტექსტის ზომა, კონტრასტი და მოძრაობის პარამეტრები.
შეთანხმდით რეალურ მოწყობილობებზე, ჩანაწერის ფორმატსა და ხარვეზის სიმძიმეზე.
გაატარეთ წარმატებული და უარყოფილი სცენარები დეველოპერისა და კლიენტის მონაწილეობით.
დახურეთ მხოლოდ ის ხარვეზი, რომლის განმეორებითი ტესტიც გაქვთ შენახული.

ტესტის ფარგლები aiAPP-ის პროექტის განხილვაში გააგზავნეთ. სამუშაოს მიმდინარე ფორმატი ნახეთ შესაბამის გვერდზე, ხოლო ანგარიშებისა და მონაცემების საკითხები შეადარეთ უსაფრთხოების აღწერას.

რომელი შეცდომები აფუჭებს accessibility-ის მიღებას?

პირველი შეცდომაა accessibility-ის დატოვება release-ის ბოლო დღისთვის. მეორეა მხოლოდ ავტომატური სკანერის შედეგზე დაყრდნობა. ასეთი ინსტრუმენტი სასარგებლოა გამეორებადი პრობლემებისთვის, მაგრამ ვერ ცვლის მიზნობრივ გზაზე ადამიანის მიერ შესრულებულ სცენარს. მესამეა მხოლოდ iOS-ის ან მხოლოდ Android-ის შემოწმება. მეოთხეა ტექსტის თარგმნის, ცარიელი მდგომარეობისა და შეცდომის ეკრანის გამოტოვება.

ასევე პრობლემურია „WCAG-compliant“ როგორც უპირობო შედეგის ჩაწერა. სტანდარტი გვაძლევს პრინციპებსა და კრიტერიუმებს, მაგრამ თქვენი აპის ფუნქცია, მესამე მხარის კომპონენტები, მოწყობილობა და შინაარსი ცალკე უნდა შეფასდეს.

რას ვერ დაამტკიცებს accessibility-ის ტესტი?

ერთი ტესტის პაკეტი ვერ დაამტკიცებს, რომ აპი ყველა მომხმარებლისთვის, ყველა მოწყობილობაზე და ყველა დამხმარე ტექნოლოგიასთან ერთნაირად იმუშავებს. ტესტი ვერ ცვლის სამართლებრივ კონსულტაციას, მომხმარებელთა კვლევას ან მუდმივ გაუმჯობესებას. ახალი კონტენტი და ახალი ფუნქცია შეიძლება ახალ ბარიერს შექმნას.

ამიტომ მიღების ჩანაწერი განიხილეთ როგორც შეთანხმებული ხარისხის მტკიცებულება კონკრეტულ ფარგლებზე. შეინახეთ ტესტის გარემო, ცნობილი შეზღუდვები და ის საკითხები, რომლებიც მომდევნო ეტაპზე უნდა გადაიხედოს.

ხშირად დასმული კითხვები

საკმარისია თუ არა ავტომატური accessibility სკანერი?

არა. ავტომატური შემოწმება სასარგებლო დამხმარეა, მაგრამ მომხმარებლის გზაზე VoiceOver-ისა და TalkBack-ის გამოყენებას, ტექსტის გაგებასა და შეცდომის გამოსწორებას ცალკე ტესტი სჭირდება.

უნდა შემოწმდეს თუ არა ორივე პლატფორმა?

დიახ, თუ აპი iOS-სა და Android-ზე გამოდის. საერთო მოთხოვნა შეიძლება იგივე იყოს, მაგრამ ფოკუსი, შეტყობინება და სისტემური პარამეტრები პლატფორმის მიხედვით განსხვავდება.

ვინ ადგენს მიღების კრიტერიუმს?

კრიტერიუმი მყიდველმა და ტექნიკურმა გუნდმა ერთად უნდა დააკონკრეტონ მომხმარებლის გზის, მოწყობილობის, მოსალოდნელი ქცევისა და მტკიცებულების მიხედვით.

დაკავშირებული მასალა

გამოყენებული წყაროები

სარედაქციო შენიშვნა: ტექსტის მომზადებაში გამოყენებულია ხელოვნური ინტელექტი.