Mobil tətbiq əlçatanlığı dizaynı o deməkdir ki, istifadəçi tətbiqin əsas işlərini öz cihaz ayarları, görmə, hərəkət, eşitmə və ya diqqət ehtiyaclarından asılı olmayaraq tamamlaya bilir. Bu, ayrıca “əlçatanlıq rejimi” deyil: giriş, axtarış, ödəniş, sifariş yaratmaq və təsdiqləmə kimi əsas axınların keyfiyyət meyarıdır. Mətn böyüdüləndə düymə ekranın kənarına çıxırsa, VoiceOver və ya TalkBack nəzarəti düzgün izah etmirsə, yaxud xəta yalnız qırmızı rənglə göstərilirsə, interfeys real şəraitdə istifadə oluna bilən deyil.
Ən yaxşı nəticə əlçatanlığı dizayn, native implementasiya və keyfiyyət yoxlamasına erkən daxil etməklə əldə olunur. POLADO-da UI/UX və məhsul dizaynı işi çərçivəsində bunu istifadəçi axınları, komponent qaydaları və qəbul kriteriyaları ilə planlaşdırmaq mümkündür; sonradan ekranları tələsik “düzəltmək” daha bahalı olur.
Əlçatanlığı yoxlama siyahısı yox, axının tamamlanması kimi düşünün
Kontrast nisbəti və minimum toxunuş ölçüsü vacibdir, amma təkbaşına uğur demək deyil. İstifadəçi aşağıdakı zənciri ardıcıl yerinə yetirə bilməlidir:
- nə etməli olduğunu başa düşmək;
- uyğun nəzarəti tapmaq;
- nəzarəti rahat aktivləşdirmək;
- sistemin vəziyyət dəyişimini anlamaq;
- xəta olduqda onu düzəltmək;
- uğurlu nəticənin təsdiqini almaq.
Məsələn, pul köçürməsi ekranında məbləğ sahəsi, valyuta seçimi, komissiya məlumatı və “təsdiqlə” düyməsi vizual olaraq səliqəli görünə bilər. Lakin ekran oxuyucusu komissiyanın dəyişdiyini elan etmirsə və ya böyük mətn ölçüsündə təsdiq düyməsi görünməz hissəyə keçirsə, axın etibarlı deyil. Bu yanaşma yalnız daimi əlilliyi olan insanlar üçün deyil; parlaq günəşdə ekrana baxan, bir əllə hərəkətdə olan, eynəksiz qalan və ya müvəqqəti əl zədəsi yaşayan istifadəçilər üçün də məhsulu yaxşılaşdırır.
Mətn böyüməsi ilə layout-un davranışını dizayn edin
iOS-da Dynamic Type, Android-də isə sistem şrift miqyası istifadəçinin oxu rahatlığı üçün mətnin ölçüsünü artırır. Dizayn faylında bir ekranın standart mətnlə yaxşı görünməsi kifayət deyil. Böyük ölçülərdə başlıq, qiymət, status və düymə etiketi birlikdə daha çox sahə tələb edir.
Praktik qaydalar
- Mətn konteynerinə sabit hündürlük verməyin; məzmunun şaquli böyüməsinə imkan yaradın.
- Uzun başlıqları əsassız kəsməyin. Xüsusilə məbləğ, tarix, xəta və status kimi kritik informasiyanı tam oxunaqlı saxlayın.
- İki sütunlu sətirlərdə məzmun sıxlaşanda bir sütuna keçid, mətnin alt sətirə düşməsi və ya ayrıca detal ekranı kimi davranışı əvvəlcədən müəyyən edin.
- İkonu mətnin yeganə daşıyıcısı etməyin. Məsələn, yalnız rəngli “i” işarəsi əvəzinə “Komissiya haqqında” kimi aydın etiket verin.
- iOS və Android üçün sistem tipografiya imkanlarından istifadə edin; xüsusi şrift seçilirsə, böyük ölçülərdə oxunaqlılığını ayrıca yoxlayın.
Buradakı məqsəd hər ekrana daha çox element sığdırmaq deyil. Məqsəd istifadəçinin öz ayarını dəyişmədən məzmunu oxuyub qərar verməsidir. Apple, interfeysin böyük əlçatanlıq mətn ölçülərində yenidən axaraq kəsilmə və üst-üstə düşmənin qarşısını almasını test etməyi tövsiyə edir.
Kontrast, rəng və toxunuş hədəfləri
Kontrast brend rəng palitrasından ayrıca qərar deyil. Mətn fon üzərində, ikon isə səth üzərində kifayət qədər seçilməlidir. Adi mətn üçün 4.5:1, iri mətn üçün 3:1 tez-tez istifadə olunan baza həddidir; mətn olmayan UI elementləri üçün də 3:1 hədəfi praktik başlanğıcdır. Ancaq “keçdi” nəticəsi ilə kifayətlənməyin: açıq günəşdə, qaranlıq rejimdə, seçilmiş və deaktiv vəziyyətlərdə də yoxlayın.
Rəng tək siqnal olmamalıdır. Uğursuz sahə üçün qırmızı çərçivəyə əlavə olaraq mətnli izah, xəta ikonu və fokusla görünən əlaqə təqdim edin. “Qırmızı olanları düzəldin” əvəzinə “Kart nömrəsində 16 rəqəm olmalıdır” deyin.
Toxunuş üçün görünən ikon kiçik qala bilər, lakin interaktiv sahə kifayət qədər böyük və qonşu nəzarətlərdən ayrılmış olmalıdır. Android hər interaktiv element üçün ən azı 48dp × 48dp toxunuş sahəsini tövsiyə edir. WCAG 2.2 isə minimum ölçü və ya kifayət qədər aralıq prinsipini izah edir. Xüsusilə silmək, ödəmək və ya geri dönməz əməliyyatlar kimi yüksək riskli hərəkətlərdə daha böyük hədəf və təsdiq addımı seçin.
Ekran oxuyucusu üçün semantika, etiket və fokus ardıcıllığı
VoiceOver və TalkBack vizual koordinatları yox, tətbiqin əlçatanlıq semantikasını oxuyur. Buna görə dizayner və developer birlikdə hər komponentin rolunu, adını, vəziyyətini və hərəkətini müəyyən etməlidir.
- Düzgün rol: keçid düymə kimi, dəyişdirici switch kimi, seçilmiş tab seçilmiş vəziyyətdə təqdim edilməlidir.
- Mənalı ad: “Düymə” və ya “Şəkil” deyil, “Filtrləri aç”, “Sifarişi paylaş”, “Seçilmiş plan: Pro” kimi kontekstli mətn istifadə edin.
- Vəziyyət və dəyər: seçilib-seçilmədiyi, aktiv/deaktiv olduğu, səbətdəki say və ya yüklənmə vəziyyəti səsləndirilməlidir.
- Məntiqi fokus: fokus ekranda oxuma istiqamətində və istifadəçi tapşırığının ardıcıllığında hərəkət etməlidir. Vizual düzülüş dəyişibsə, oxunuş ardıcıllığını ayrıca test edin.
- Dekorativ elementlər: məlumat verməyən illüstrasiya və separatorları fokus zəncirinə salmayın.
Custom komponentlər ən çox risk yaradan hissədir. Standart native nəzarət uyğun gəlirsə, onu seçmək semantika, fokus və platforma davranışı baxımından daha etibarlıdır. Xüsusi slider, kart və ya aşağıdan açılan panel istifadə olunursa, onun ekran oxuyucusu ilə necə elan ediləcəyi prototip mərhələsində təsvir olunmalıdır.
Formalar, xəta mesajları və hərəkət seçimləri
Forma yalnız məlumat toplama ekranı deyil, dialoqdur. Hər sahənin daimi etiketi, uyğun klaviatura tipi, nümunə formatı və aydın məcburilik göstəricisi olmalıdır. Placeholder mətni etiketin əvəzi deyil: istifadəçi yazmağa başlayan kimi yoxa çıxır və çox vaxt zəif kontrastlı olur.
Submit sonrası xətanı sahənin yanında göstərin, ekranda qısa xəta xülasəsi verin və ekran oxuyucusu istifadəçisi üçün dəyişən statusu elan edin. Server xətasını istifadəçiyə “400” və ya “invalid request” kimi texniki dil ilə ötürməyin. Eyni məlumatı təkrar daxil etdirməmək, məzmunu itirmədən düzəliş imkanı vermək və göndərişin baş verdiyini açıq təsdiqləmək konversiya üçün də vacibdir.
Hərəkət, sürüşdürmə və cihazı silkələmə kimi interaksiyalara alternativ təqdim edin. Drag-and-drop əməliyyatının yanında “Yuxarı köçür” və “Aşağı köçür” nəzarətləri, swipe ilə silmənin yanında görünən menyu seçimi olmalıdır. Sistem “Reduce Motion” seçimini aktiv etdikdə dekorativ keçidləri azaltmaq və ya dərhal nəticə göstərmək istifadəçiyə daha rahat təcrübə verir.
Real cihazlarda mobil app UX test planı
Avtomatlaşdırılmış yoxlamalar faydalıdır, amma əsas axını tamamlayan insan testinin əvəzi deyil. Hər reliz üçün kritik ssenariləri test matrisinə çevirin: qeydiyyat, giriş, axtarış, əsas əməliyyat, ödəniş və ya sorğu, xəta düzəlişi və çıxış.
- iOS-da ən böyük əlçatanlıq mətn ölçüsü, Bold Text, Increase Contrast və Reduce Motion ilə əsas tapşırıqları yoxlayın.
- Fiziki iPhone-da VoiceOver ilə ekranı vizual köməyə etibar etmədən tamamlayın; simulator bu təcrübəni tam əvəz etmir.
- Android-də böyük şrift miqyası, TalkBack, tünd/açıq mövzu və lazım olduqda Switch Access ilə eyni ssenarini yoxlayın.
- Accessibility Inspector və Android Accessibility Scanner kimi alətlərdən etiket, kontrast və toxunuş problemi üçün erkən siqnal kimi istifadə edin.
- UI testlərinə avtomatik əlçatanlıq yoxlamalarını əlavə edin, amma xəbərdarlıqları dizayn qərarı ilə qiymətləndirin.
- Tapılan problemi “ekran xətası” kimi deyil, təsirlənən tapşırıq, cihaz ayarı, platforma, gözlənilən və faktiki nəticə ilə qeyd edin.
Yeni native məhsul və ya mövcud tətbiqin yenilənməsi üçün mobil tətbiqlərin hazırlanması və məhsul dizaynı işini bir plan altında qurmaq əlçatanlıq risklərini implementasiya bağlanmadan aşkar etməyə kömək edir. Mobil məhsul nümunələri üçün Car City layihəsinə baxa, konkret axınlarınız üzrə ilkin müzakirə üçün POLADO ilə əlaqə saxlaya bilərsiniz.