Адаптивни уеб инструменти за достъпност

Инструментите на взаимодействието

За хората, които разчитат на адаптивни уеб инструменти, за да навигират в интернет, начинът, по който се изгражда и представя съдържанието, е всичко. Дори най-усъвършенстваната помощна технология в света не може да прочете, обяви или управлява съдържание, което не съществува в достъпна форма. Бутон, който всъщност е стилизиран <div>, изображение без текстова алтернатива или персонализирано падащо меню без поддръжка на клавиатура е просто невидимо — или още по-лошо, задънена улица — за хората, които всеки ден зависят от тези инструменти.

QualiBooth ви помага да разберете две неща едновременно: как инструментите на потребителя действително интерпретират вашето съдържание и какво съдържание или структура липсва, е повредено или двусмислено. Именно тази комбинация отличава уебсайт, който технически се зарежда, от такъв, който наистина работи за всички.

Това ръководство преминава през основните категории помощни и адаптивни технологии, как всяка от тях очаква уебсайтът да се държи и какви практически стъпки можете да предприемете, за да изграждате заедно с тези инструменти, а не срещу тях. То също така прокарва ясна граница между истинската помощна технология и overlay-ите за достъпност — защото двете често се бъркат, а това объркване има реални последици за реални потребители.

Какво всъщност означават „адаптивни уеб инструменти”

Адаптивните уеб инструменти — по-често наричани помощни технологии (AT) — са софтуер и хардуер, които променят начина, по който човек възприема или управлява цифров интерфейс. Те не са добавки към вашия уебсайт; те са собствената среда на потребителя, конфигурирана според нуждите му и често използвана с часове на ден в хиляди сайтове.

Основните категории включват:

Екранни четци, които преобразуват съдържанието на екрана в синтезирана реч или обновяем брайл.
Увеличение на екрана, което уголемява и пренарежда част или целия дисплей.
Устройства за достъп чрез превключвател (switch) за хора, които не могат да използват стандартна клавиатура или мишка.
Гласово управление, което управлява интерфейса изцяло чрез гласови команди.
Вградени функции на браузъра и операционната система като режими с висок контраст, намалено движение и инструменти за четене.
Помощни средства за четене и разбиране, които опростяват, прочитат или преструктурират текста.

Всяко от тях разчита на една и съща основа: добре структурирана, семантична, управляема с клавиатура страница, която следва утвърдените стандарти. Когато изграждате според WCAG 2.2, вие създавате договора, от който зависи всеки от тези инструменти.

Екранни четци: структурата е интерфейсът

Екранните четци са най-известната помощна технология и за много екипи най-трудната за проектиране — именно защото визуалното оформление, което виждате, не ви казва почти нищо за това какво обявява екранният четец.

Най-широко използваните екранни четци са NVDA и JAWS под Windows, VoiceOver под macOS и iOS, и TalkBack под Android. Те не „виждат” вашата страница; те изграждат модел от дървото на достъпността, което се извлича от семантиката на вашия HTML и от всеки ARIA, който добавяте отгоре.

Какво се нуждаят екранните четци от вас

Истински семантични елементи. Използвайте <button>, <a>, <nav>, <main>, <h1>–<h6> и <table> за това, което представляват. Заглавието трябва да е заглавие, за да могат потребителите да прескачат между секциите; връзката трябва да е връзка, за да се появи в списъка с връзки.
Смислени текстови алтернативи. Всяко информативно изображение се нуждае от атрибут alt, който описва целта му. Декоративните изображения трябва да имат празен alt="", за да бъдат пропускани, вместо да се обявяват като шум.
Програмни етикети за контролите. Полетата на формуляри се нуждаят от свързани елементи <label>; бутоните само с икона се нуждаят от достъпно име чрез aria-label или визуално скрит текст.
Логична йерархия на заглавията. Заглавията са основният начин, по който потребителите на екранни четци преглеждат страница. Прескачането на нива или използването на заглавия само заради визуалния размер нарушава тази навигация.
Правилен ARIA — и само когато е необходимо. ARIA може да предава състояния (разгънато, избрано, деактивирано) и роли за персонализирани компоненти, но лошият ARIA е по-лош от никакъв. Първото правило на ARIA е да се използва нативен HTML, когато е възможно.

Често срещано объркване е разликата между екранен четец и обикновен синтез на реч. Инструментът за четене прочита текст; екранният четец излага и управлява целия интерфейс, включително контроли, състояния и навигация. Разглеждаме това разграничение задълбочено в синтез на реч спрямо екранни четци.

Тъй като автоматизираните инструменти могат да уловят само част от проблемите с екранните четци, единственият надежден начин да разберете как звучи вашият сайт е да го тествате така, както го правят потребителите. Нашето ръководство за тестване с екранен четец преминава през практическия работен процес, а специализираната оценка с екранен четец подлага най-важните ви потребителски пътеки на този процес с опитни тестери.

Увеличение на екрана: проектирайте за приближения изглед

Хората със слабо зрение често увеличават екрана някъде между 200% и 800% или повече, виждайки само малка част от страницата наведнъж. Някои използват увеличителя на операционната система; други разчитат на мащабиране в браузъра или на специализиран софтуер.

При силно увеличение решения за оформлението, за които никога не се замисляте, стават критични:

Пренареждане (reflow). Съдържанието трябва да се пренареди в една колона при 400% мащабиране (критерий за успех 1.4.10 на WCAG 2.2), за да не се налага потребителите да превъртат в две посоки, за да прочетат изречение.
Близост на свързаните елементи. Ако съобщение за грешка се появи далеч от полето, което описва, потребител с увеличение може никога да не ги види в един и същи изглед. Дръжте етикетите, полетата за въвеждане и обратната връзка заедно.
Видим фокус. Ясен индикатор за фокус с висок контраст позволява на потребител с увеличение да открие къде се намира, след като изгледът прескочи.
Без загуба на съдържание или функция. Нищо не трябва да бъде отрязано, припокрито или направено неработещо, когато текстът е увеличен до 200% (критерий за успех 1.4.4).

Увеличението възнаграждава чистите, адаптивни оформления и наказва дизайните с фиксирани пиксели и съдържанието, което зависи от hover.

Достъп чрез превключвател и управляемост с клавиатура

Устройствата с превключвател (switch) позволяват на хората да управляват компютър с един или два прости входа — бутон, устройство за вдишване и издишване или движение на главата — обикновено като преминават през интерактивните елементи един по един. Достъпът чрез превключвател се изгражда върху поддръжката на клавиатура: ако сайтът ви работи напълно от клавиатурата, той почти със сигурност работи и с превключватели.

Това прави пълната управляемост с клавиатура едно от нещата с най-голямо въздействие, които можете да направите правилно:

Всичко достъпно. Всеки интерактивен елемент трябва да може да получава фокус и да се управлява без мишка — връзки, бутони, контроли на формуляри, менюта, модални прозорци, карусели и персонализирани компоненти еднакво.
Видим, логичен ред на фокуса. Фокусът трябва да се движи през страницата в ред, който съответства на визуалния поток и потока на четене, а фокусираният елемент винаги трябва да е ясно обозначен.
Без капани за клавиатурата. Потребителите трябва да могат да преместват фокуса извън всеки компонент, включително вграден мултимедиен материал и диалогови прозорци.
Връзки за прескачане. Връзка „прескочи към основното съдържание” позволява на хората да заобиколят повтарящата се навигация, вместо да я преглеждат на всяка страница.

Ако клиент попълва формуляр, може ли да премине с Tab през всяко поле, да задейства падащо меню, да избере продукт и да изпрати — всичко без да докосва мишката? Ще си сътрудничи ли автоматичното попълване на браузъра с вашия маркъп? Това са въпросите, на които потребителите на превключватели и клавиатура отговарят за вашия сайт, независимо дали ги задавате или не.

Гласово управление: имената и видимите етикети имат значение

Инструментите за гласово управление като Dragon, Voice Control и Voice Access позволяват на потребителите да изговарят команди като „кликни Изпрати” или „превърти надолу”. За да работят тези команди, видимият етикет на контрол трябва да съответства на достъпното му име. Това е основата на критерий за успех 2.5.3 на WCAG 2.2, Етикет в името.

Практически насоки:

Достъпното име трябва да съдържа видимия текст. Ако бутон гласи „Изпрати съобщение”, не му давайте aria-label „Изпрати формуляр” — потребителят, който каже „кликни Изпрати съобщение”, ще бъде пренебрегнат.
Избягвайте контроли само с икона без текст или им дайте достъпно име, което съответства на вероятна изговорена команда.
Дръжте кликваемите цели достатъчно големи, за да се избират надеждно, което също удовлетворява критерия за размер на целта в WCAG 2.2.

Функции за достъпност на браузъра и операционната система

Не всички адаптивни инструменти са отделни продукти. Съвременните браузъри и операционни системи предлагат мощни вградени функции, които потребителите включват за цялата система, и вашият сайт трябва да ги зачита автоматично:

Намалено движение. Зачитайте медийната заявка prefers-reduced-motion, за да деактивирате или смекчите анимациите за потребители, които изпитват гадене или разсейване от движение.
Тъмен режим и висок контраст. Поддържайте prefers-color-scheme и Windows High Contrast / Forced Colors, така че интерфейсът ви да остане четим, без да се борите срещу настройките на потребителя.
Преоразмеряване на текста и мащабиране. Използвайте относителни единици, за да работи мащабирането на текста в браузъра, вместо да заключвате размерите в пиксели.
Режими за четене и инструменти за четене. Изгледите за четене на браузъра и инструменти като Immersive Reader свеждат страницата до основното ѝ съдържание — което работи много по-добре, когато вашият HTML е семантичен и без излишества.

Тези функции не струват нищо допълнително на потребителя и много малко на вас, но драстично подобряват комфорта за широка аудитория, включително хора без диагностицирани увреждания.

Инструменти за четене и разбиране

Инструментите за четене обслужват хора с дислексия, ADHD, когнитивни увреждания или ограничена грамотност на езика на страницата. Те включват разказвачи със синтез на реч, линийки за четене, осветяване на думи, инструменти за обобщаване и за превод.

За да работят добре с тях:

Пишете на ясен, добре организиран език с описателни заглавия и кратки абзаци.
Маркирайте страницата така, че основното съдържание да е ясно разпознаваемо и редът на четене да е правилен.
Избягвайте да предавате смисъл само чрез цвят, оформление или изображения — осигурете текстов еквивалент.
Уверете се, че езикът ви е деклариран (атрибут lang), за да използват разказването и преводът правилното произношение и правила.

Добрата структура на съдържанието помага на всички инструменти в тази статия наведнъж, защото всички те черпят от един и същ основен маркъп.

Истинска помощна технология срещу overlay-и за достъпност

Това е разграничението, което има най-голямо значение, и тук много организации грешат.

Истинската помощна технология — екранни четци, увеличители, достъп чрез превключвател, гласово управление — работи на устройството на потребителя, под негов контрол, и управлява вашия уебсайт чрез неговата семантика и поддръжка на клавиатура. Потребителят е прекарал години в конфигурирането ѝ. Вашата задача е просто да изградите страница, която тези инструменти могат да разберат.

Overlay-ите за достъпност са скриптове на трети страни, които добавяте към собствения си сайт и които обещават да го „направят достъпен” автоматично, обикновено чрез плаващ уиджет. Те не са заместител на помощната технология и не са решение за недостъпен сайт. Ето защо:

Те не могат да поправят основния код. Overlay-ите стоят върху страницата; те не могат надеждно да измислят липсващ alt текст, да поправят повредени структури на заглавията или да накарат <div> да се държи като истински бутон във всеки екранен четец.
Те често влизат в конфликт с истинската AT. Много потребители на екранни четци съобщават, че overlay-ите пречат на инструментите, на които вече разчитат, понякога правейки сайтовете по-трудни за използване, а не по-лесни.
Те създават фалшиво усещане за съответствие. Инсталирането на уиджет не удовлетворява WCAG 2.2, EAA или ADA. Заведени са дела срещу сайтове, които използват overlay-и, именно защото основните бариери са останали.
Те не отразяват реалния опит. Достъпността в крайна сметка се оценява от хората, които използват AT всеки ден — затова провеждаме одити от хора с увреждания, вместо да разчитаме на твърденията на скрипт.

Надеждният път е да поправите достъпността в кода и да я валидирате както с автоматизирано, така и с човешко тестване. Обясняваме тази философия по-подробно в какво означава истинската цифрова достъпност.

Практически работен процес за изграждане с адаптивни инструменти

Изграждането за помощни технологии не е еднократен проект; това е процес, който се вписва в начина, по който вече доставяте софтуер. Устойчивият подход обикновено съчетава четири неща:

Автоматизирано сканиране, рано и често. Инструменти като софтуер за сканиране на достъпността улавят голям обем проблеми на ниво код — липсващи етикети, неуспехи в контраста, повреден ARIA — преди да достигнат до продукция. Автоматизираните проверки са бързи и повторяеми, но покриват само част от картината.
Ръчно тестване и тестване с помощни технологии. Проблемите, които най-силно засягат реалните потребители — объркващ ред на фокуса, неясни обявявания, неизползваеми персонализирани компоненти — изискват човек. Нашето ръководство за ръчни одити на достъпността описва как това допълва автоматизацията.
Вграждане на достъпността във вашия екип. Третирането на достъпността като непрекъсната дисциплина, подкрепена от подобряване на процеса за достъпност, предотвратява бавния регрес, който се случва, когато поправките са единични.
Правилните инструменти за вашия стек. Инструментариумът за достъпност на QualiBooth обединява сканиране, наблюдение и отчитане, докато Agora и нашето community edition предлагат входни точки за екипи на различни етапи на зрялост.

Ако сте нови в терминологията в тази статия, речникът по достъпност е полезен спътник, докато прилагате тези практики.

Къде се вписва QualiBooth

QualiBooth открива проблеми на вашия съществуващ уебсайт и може също да сканира страниците, преди да станат публични, така че клиентите, използващи всеки адаптивен инструмент, да получат безпроблемно изживяване, което повишава използваемостта и лоялността към марката. Комбинираме автоматизирано откриване с оценка от опитни тестери и хора с увреждания, след което помагаме на екипа ви да превърне находките в трайни поправки — никога overlay, който маскира проблема.

Целта е ясна: уебсайт, който работи заедно с инструментите, на които вашите потребители вече се доверяват, при техните условия, всеки път, когато го посетят.

Готови ли сте да видите как се представя сайтът ви за истински помощни технологии? Стартирайте безплатно сканиране на достъпността, за да откриете бързи победи, заявете демо, за да видите QualiBooth в действие, или говорете с нашия екип за персонализиран ангажимент за консултации по достъпност.