Əlçatan sayt sifarişi: dizaynda hansı tələbləri yazmalı?

Əlçatan sayt sifarişi yalnız xüsusi bir düymə və ya ayrıca görünüş istəmək deyil. Ziyarətçi mətni böyüdə, siçansız işləyə və ekran oxuyucu ilə məlumatı anlaya bilməlidir. Bu işlər son anda əlavə olunan yoxlama kimi deyil, məzmun və dizayn tələblərinin bir hissəsi kimi planlaşdırılmalıdır.
Alıcı hər texniki qaydanı özü tətbiq etməyə məcbur deyil. Amma hansı istifadəçi işlərinin yoxlanacağını, məzmunu kimin hazırlayacağını və nəticənin necə göstəriləcəyini sifarişdə yaza bilər. Əlçatanlıq barədə ümumi vədi konkret sınaqlara çevirmək əsas addımdır.
Əvvəl istifadəçi tapşırıqlarını seçin
Ziyarətçinin saytda görəcəyi işləri yazın: xidməti tapmaq, əsas şərtləri oxumaq, formanı doldurmaq və cavabı başa düşmək. Sonra həmin işlərin müxtəlif istifadə yollarında necə tamamlanacağını soruşun.
Bunun üçün layihənin texniki tapşırığına ayrıca əlçatanlıq hissəsi əlavə edin. Hansı səhifə növləri və proseslər əhatə olunur? Yalnız ana səhifə, yoxsa müraciət yolu və yüklənən sənədlər də yoxlanılır? Məzmun sonradan dəyişəndə yoxlama məsuliyyəti kimdə qalır?
W3C WCAG 2.2 bu tələbləri müzakirə etmək üçün rəsmi istinad verir. Layihədə hədəf versiya, uyğunluq səviyyəsi və yoxlama əhatəsi konkret razılaşdırılmalıdır. Buradakı praktik siyahı tam uyğunluq qiymətləndirməsi və ya hüquqi təsdiq deyil.
Oxunaqlığı yalnız foto ilə yoxlamayın
Mətn və fon arasındakı kontrast, mətnin böyüdülməsi və müxtəlif ekran ölçüsündə quruluşun davranışı yoxlanmalıdır. Vacib məlumat yalnız rənglə ayrılmamalıdır: səhv sahənin qırmızı görünməsi ilə yanaşı, səhvin nə olduğu da anlaşılmalıdır.
Alıcı kimi dizaynın nümunə mətnlə yox, real başlıq və məlumatla göstərilməsini istəyin. Böyüdüləndə mətn kəsilir? Əsas düymə örtülür? Uzun xidmət adı səhifənin istifadəsini pozur? Bu nümunələr konkret düzəliş müzakirəsi yaradır.
Ümumi UX problemləri ilə əlçatanlıq tələbləri bəzən eyni istifadəçi çətinliyində birləşir. Bununla belə, gözəl və rahat görünən bir maket bütün istifadə yollarında işlədiyini sübut etmir.
Klaviatura və forma yolunu yazın
İstifadəçi siçansız menyuya, əlaqə formasına və göndəriş düyməsinə çata bilməlidir. Hansı elementin seçildiyi görünməli, ardıcıllıq istifadəçinin gördüyü işə uyğun olmalıdır. Açılan menyu və ya pəncərədən çıxış yolu da yoxlanılır.
Forma üçün tələb etdiyiniz davranışı sadə dildə yazın. Sahə adı başa düşülür, məcburi məlumat bəllidir, səhv olduqda düzəltmə yolu görünür. Göndərişdən sonra nəticə istifadəçiyə çatır. Bunu “forma işləyir” sətrindən ayrıca qəbul nümunəsinə çevirin.
Hipotetik nümunədə ziyarətçi xidmət seçir, telefon sahəsini boş saxlayır və göndərməyə çalışır. Sınaq onun səhvi tapıb düzəltməsini və yenidən göndərməsini əhatə edə bilər. Bu, real müştəri müraciəti yaradılmasını tələb etmir.
Məzmun alternativlərinə məsul şəxs verin
Şəkildəki məlumat üçün uyğun mətn alternativi, videoda çatdırılan məlumat üçün razılaşdırılmış alternativlər və sənədlərin istifadəsi ayrıca planlaşdırılır. Məzmunu təqdim edən şəxs həmin materialın məqsədini izah etməlidir. Hər fotoya eyni ümumi təsvir əlavə etmək faydalı həll deyil.
Sənədi yalnız şəkil kimi dərc edəcəksinizsə, oxucunun məlumatı başqa yolla necə alacağını soruşun. Bu qərar dizayn işi ilə yanaşı, mətn və sənəd hazırlığının əhatəsinə də təsir edir.
Nəticəni sübutla qəbul edin
Agentlikdən yoxlanmış səhifə və prosesləri, istifadə edilən üsulları, tapılmış problemləri və düzəliş vəziyyətini göstərən qeyd istəyin. W3C-nin ilkin yoxlamaları faydalı başlanğıcdır, lakin tam əlçatanlıq qiymətləndirməsini əvəz etmir. Tək avtomatik bal əsasında bütün sayt üçün qərar verməyin.
Sayt hazırlanması sifarişinə bu sınaqların əhatəsini və məzmun məsuliyyətini əlavə edin. Məqsəd texniki terminlərlə dolu sənəd deyil; müxtəlif istifadə yollarında işləyən və dəyişdikdə yenidən yoxlana bilən sayt üçün aydın tələbdir.