როგორ გავხადოთ ვებსაიტი ხელმისაწვდომი: WCAG 2.2 საწყისი გზამკვლევი

ვებსაიტის ხელმისაწვდომად გასაკეთებლად ააშენეთ ისე, რომ ადამიანებმა შეძლონ მისი გამოყენება კლავიატურით, ეკრანის მკითხველით, მასშტაბირებით ან სვიჩ-მოწყობილობით, და არა მხოლოდ თაგუნათი: გამოიყენეთ რეალური HTML ელემენტები ღილაკებისთვის, ბმულებისთვის, სათაურებისა და ფორმის ეტიკეტებისთვის, მიანიჭეთ სურათებს შინაარსობრივი alt ტექსტი, შეინარჩუნეთ მაღალი ტექსტის კონტრასტი და გახადეთ ფოკუსი ხილული. სამიზნე სტანდარტია WCAG 2.2 Level AA. ავტომატური შემმოწმებლები პრობლემის ნაწილს პოულობენ; ათწუთიანი ტესტი კლავიატურით და ეკრანის მკითხველით დანარჩენის დიდ ნაწილს.

რას ნიშნავს „ხელმისაწვდომი“ პრაქტიკაში

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

საცნობარო სტანდარტია W3C-ის Web Content Accessibility Guidelines (WCAG). 2026 წლის სექტემბრის მდგომარეობით, მიმდინარე ვერსია არის WCAG 2.2 (გამოქვეყნდა 2023 წლის ოქტომბერში, განახლდა 2024 წლის დეკემბერში); WCAG 3 ადრეული მონახაზია. WCAG ოთხ პრინციპზეა აგებული — შინაარსი უნდა იყოს აღსაქმელი, მართვადი, გასაგები და მდგრადი — და სამ შესაბამისობის დონეს აქვს:

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

ვარიანტები: როგორ მივაღწიოთ

პატარა საიტებისთვის უმეტესად პირველი ორი საკმარისია: უთხარით AI-ს, რომ თავიდანვე ხელმისაწვდომად ააშენოს, შემდეგ გაუშვამდე აუდიტი ჩაატაროთ.

გასწორებები, რომლებიც ყველაზე მნიშვნელოვანია

გამოიყენეთ სწორი HTML ელემენტები

ხელმისაწვდომობის უმეტესობა სწორი HTML-ით უფასოდ მოდის. <button> ფოკუსირებადია, მუშაობს Enter-სა და Space-ით და ღილაკად ცხადდება. <div> დაწკაპუნების დამმუშავებლით კი არცერთს არ აკეთებს. AI-ის მიერ დაგენერირებული კოდი ზოგჯერ ყველაფრისთვის სტილიზებულ div-ებს იყენებს; მოითხოვეთ სემანტიკური ელემენტები:

• <button> მოქმედებებისთვის, <a href> ნავიგაციისთვის
• თითო გვერდზე ერთი <h1>, შემდეგ <h2>, <h3> რიგით — ეკრანის მკითხველის მომხმარებლები სათაურებს შორის გადადიან
• ლენდმარკები: <header>, <nav>, <main>, <footer>
• <label>, დაკავშირებული ყოველ ფორმის ველთან
• გვერდის ენა <html lang="en">-ში

ARIA ატრიბუტები გამოიყენეთ მხოლოდ მაშინ, როცა არცერთი ნატიური ელემენტი არ ერგება — მაგალითად, საკუთარი ტაბების ნაკრებისთვის ან combobox-ისთვის. არასწორი ARIA უარესია, ვიდრე არარსებობა.

კლავიატურით წვდომა და ხილული ფოკუსი

ყველაფერი, რაც თაგუნათი შეიძლება, უნდა მუშაობდეს მხოლოდ კლავიატურით (WCAG 2.1.1). გაიარეთ გვერდი Tab-ით: ყოველი ბმული, ღილაკი და ველი ლოგიკური რიგით უნდა იყოს მიწვდომი და ყოველთვის უნდა ჩანდეს, სად არის ფოკუსი (2.4.7 Focus Visible). WCAG 2.2-მა დაამატა, რომ ფოკუსირებული ელემენტი არ უნდა იყოს მთლიანად დაფარული ჩამაგრებული სათაურებით ან ქუქი-ბანერებით (2.4.11, Level AA).

ხშირი შეცდომები: მენიუები, რომლებიც მხოლოდ ჰოვერზე იხსნება, მოდალები, რომლებიც ფოკუსს არ ინახავენ ან Escape-ით არ იხურება, და CSS-ში outline: none მისი შემცვლელის გარეშე.

ტექსტური ალტერნატივები

ყოველ შინაარსობრივ სურათს სჭირდება alt ტექსტი, რომელიც კონტექსტში აღწერს, რას აჩვენებს („შეფი აწყობს დეგუსტაციის მენიუს“, და არა „image1.jpg“). დეკორატიულ სურათებს ეძლევა ცარიელი alt="", რომ ეკრანის მკითხველმა გამოტოვოს ისინი. მხოლოდ ხატულიანი ღილაკებისთვის საჭიროა ხელმისაწვდომი სახელი („დახურვა“, „ძიება“). ვიდეოს სჭირდება სუბტიტრები; აუდიოს — ტრანსკრიპტი.

ფერი და კონტრასტი

WCAG 2.2 AA ითხოვს კონტრასტის კოეფიციენტს მინიმუმ 4.5:1 ჩვეულებრივი ტექსტისთვის და 3:1 დიდი ტექსტისთვის (1.4.3), და 3:1-ს ინტერფეისის ნაწილებისთვის, როგორებიცაა შეყვანის საზღვრები და მნიშვნელოვანი ხატულები (1.4.11). ღია ნაცრისფერი placeholder ტექსტი და ფერმკრთალი ღილაკები ჩვეულებრივი შეცდომებია. ასევე არასდროს გამოიყენოთ მხოლოდ ფერი მნიშვნელობის გადმოსაცემად — არასწორ ველზე წითელ საზღვარს შეცდომის შეტყობინებაც სჭირდება.

ზომის შეცვლა და გადაფორმება

ტექსტი უნდა რჩებოდეს გამოსადეგი 200%-მდე მასშტაბირებისას (1.4.4), ხოლო შინაარსი უნდა მუშაობდეს 320 CSS პიქსელის სიგანეზე ჰორიზონტალური გადახვევის გარეშე (1.4.10). სწორად ადაპტირებადი განლაგება ამის უმეტესობას ფარავს.

სამიზნეები, ფორმები და შეცდომები

• სამიზნის ზომა: WCAG 2.2 AA ითხოვს მაჩვენებლის სამიზნეებს მინიმუმ 24 × 24 CSS პიქსელს, ან პატარებს შორის საკმარის დაშორებას (2.5.8). დიდი უფრო კომფორტულია ტელეფონზე.
• ფორმები: ხილული ეტიკეტები (არა მხოლოდ placeholder), მკაფიო ინსტრუქციები და შეცდომის შეტყობინებები, რომლებიც ამბობს, რა არის არასწორი და როგორ გამოსწორდეს, ველის გვერდით.
• შესვლა: ადამიანებს არ აიძულოთ, თავსატეხი ამოხსნან ან კოდი გადაწერონ ალტერნატივის გარეშე; დაუშვით პაროლების მმართველები და ჩასმა (3.3.8 Accessible Authentication).

მუშა მოთხოვნები

ააშენე ეს საიტი WCAG 2.2 Level AA-ს დასაკმაყოფილებლად: სემანტიკური HTML-ის ლენდმარკები, გვერდზე ერთი h1 რიგრიგობით სათაურებით, რეალური ღილაკისა და ბმულის ელემენტები, ეტიკეტები ყოველ ფორმის ველზე, ხილული ფოკუსის სტილები, ტექსტის კონტრასტი მინიმუმ 4.5:1, alt ტექსტი შინაარსობრივ სურათებზე და alt="" დეკორატიულებზე, და html lang დაყენებული.

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

მობილური მენიუ კლავიატურით არ მუშაობს. გახადე ის ღილაკად aria-expanded-ით, გახსნისას გადაიტანე ფოკუსი მენიუში, დახურე Escape-ით და დააბრუნე ფოკუსი ღილაკზე.

ნაბიჯ-ნაბიჯ

1. გაუშვით ავტომატური შემოწმება. Lighthouse-ის Accessibility სექცია Chrome DevTools-ში ან axe ბრაუზერის გაფართოება ყოველ მთავარ გვერდზე. გაასწორეთ ყველაფერი, რასაც ის აჩვენებს.
2. გამორთეთ თაგუნა. გაიარეთ თითოეული გვერდი Tab-ით და დაასრულეთ ყველა მთავარი ამოცანა — რეგისტრაცია, ძიება, გადახდა. ჩაინიშნეთ ყველაფერი, რაც ვერ მიგიწვდებათ, სადაც ფოკუსი არ ჩანს ან საიდანაც ვერ გამოდიხართ.
3. მასშტაბირება 200%-მდე და ფანჯრის დავიწროება ტელეფონის სიგანემდე. არაფერი არ უნდა იყოს მოჭრილი ან ჰორიზონტალურად გადახვევას არ მოითხოვდეს.
4. სცადეთ ეკრანის მკითხველი ათი წუთის განმავლობაში: VoiceOver Mac-ზე და iPhone-ზე, TalkBack Android-ზე ან NVDA Windows-ზე (უფასო). მოუსმინეთ სათაურებს, ბმულებსა და ფორმის ველებს. „ღილაკი“ სახელის გარეშე, ან „ბმული, დააწკაპუნე აქ“, ნიშნავს სამუშაოს.
5. შეამოწმეთ კონტრასტი ტექსტისთვის, ღილაკებისა და ველებისთვის კონტრასტის შემმოწმებლით.
6. გაასწორეთ, შემდეგ ხელახლა შეამოწმეთ იგივე ამოცანები.
7. გამოაქვეყნეთ ხელმისაწვდომობის განცხადება, რომელშიც ნათქვამია, რა სტანდარტს ისახავთ მიზნად და როგორ მოახსენოთ პრობლემები — და უპასუხეთ ამ მოხსენებებს.

გავრცელებული შეცდომები

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

ხელმისაწვდომობის შემოწმების სია

• ავტომატური შემოწმება (Lighthouse ან axe) სუფთაა მთავარ გვერდებზე
• ყოველი ამოცანა შესრულდება მხოლოდ კლავიატურით
• ფოკუსი ყოველთვის ჩანს და არ იმალება ჩამაგრებულ ელემენტებს მიღმა
• სემანტიკური სათაურები, ლენდმარკები, ღილაკები და ბმულები; დაყენებული lang
• შინაარსობრივი alt ტექსტი; დეკორატიულ სურათებზე alt=""; ვიდეოზე სუბტიტრები
• ტექსტის კონტრასტი ≥ 4.5:1 (დიდ ტექსტზე ≥ 3:1); ინტერფეისის ნაწილები ≥ 3:1
• მუშაობს 200% მასშტაბზე და 320 px სიგანეზე
• ყველა ფორმის ველს აქვს ხილული ეტიკეტი და მკაფიო შეცდომის შეტყობინებები
• ხელმისაწვდომობის განცხადება, რომელშიც ნათქვამია, როგორ მოხსენდეს პრობლემები

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

ხელმისაწვდომობა Mythex-ზე

Mythex აშენებს იმ სტანდარტით, რომელსაც მოსთხოვთ, ამიტომ პირველ მოთხოვნაში და შემდგომ შეტყობინებებში ჩაწერეთ „WCAG 2.2 AA“. შეგიძლიათ გამოიყენოთ Preview-ის ტელეფონის ზომის ჩარჩო, რათა პატარა ეკრანები შეამოწმოთ (Preview და Code), მაგრამ კლავიატურის, მასშტაბირებისა და ეკრანის მკითხველის ტესტი საუკეთესოდ მუშაობს გამოქვეყნებულ URL-ზე ან პრევიუზე, რომელიც საკუთარ ჩანართში გაქვთ გახსნილი. სთხოვეთ აგენტს გვერდის აუდიტი, გაასწორეთ ნაპოვნი პრობლემები და შემდეგ თავად შეამოწმეთ გასწორებები — ავტომატური გავლა დასაწყისია, არა საბოლოო დასტური.

კითხვები