Зашто аутоматизовано тестирање приступачности пропушта половину ваших проблема

Непријатна истина о аутоматизованом тестирању приступачности

Аутоматизовано тестирање приступачности једна је од најбољих навика које веб тим може да изгради. Оно открива недостајуће ознаке формулара, текст са слабим контрастом, неважећи ARIA, дуплиране ID-јеве, празну дугмад и друге недостатке који никада не би требало да стигну у продукцију.

Такође се редовно погрешно разуме.

Успешан аутоматизовани извештај о приступачности не значи да је страница приступачна. То значи да алат није пронашао онај подскуп проблема који уме да открије. Тај подскуп је вредан, али ограничен. Многи проблеми приступачности зависе од значења, редоследа, намере, контекста и људске интеракције. Софтвер може да прегледа markup. Не може поуздано да разуме да ли искуство функционише за особу која користи читач екрана, тастатуру, увећање, гласовну контролу, титлове или когнитивну подршку.

Зато тврдња да аутоматизовано тестирање пропушта око половине ваших проблема није цинична. Великодушна је. Неке категорије проблема могу се у великој мери аутоматизовати. Друге се једва могу аутоматизовати уопште.

Практичан одговор није да напустите аутоматизоване алате. Већ да их ставите на право место: рано, често и као део ширег процеса тестирања.

У чему су аутоматизовани тестови добри

Аутоматизовани алати су одлични у проналажењу детерминистичких грешака. Ако се правило може изразити као машински читљив услов, скенер га обично може проверити брзо и доследно.

Уобичајени примери укључују:

• Слике којима недостају alt атрибути
• Поља формулара без повезаних ознака
• Дугмад без приступачних назива
• Текст који не испуњава прагове контраста
• Неважеће ARIA атрибуте или улоге
• Нивое наслова који се прескачу на сумњив начин
• Landmark елементе који недостају или су дуплирани
• Линкове са празним приступачним називима
• Табеле без основне структуре

Ове провере вреди аутоматизовати јер људи нису добри у понављајућем прегледању. Нико не би требало ручно да скенира сваку страницу у потрази за недостајућим ознакама ако их алат може ухватити за милисекунде.

Аутоматизоване провере такође олакшавају разговор о приступачности у инжењерским процесима. Неуспешан тест у CI-ју је конкретан. Упозорење у pull request-у стиже на време. Линија тренда кроз шаблоне даје тиму нешто што може да унапреди.

Проблем почиње када тимови третирају ове провере као доказ приступачности, а не као доказ основне хигијене.

Где се аутоматизација ломи

Приступачност није само својство кода. Она је својство употребе.

Алат може да вам каже да ли слика има alt текст. Обично не може да вам каже да ли је тај alt текст користан. Слици производа можда је потребан детаљан опис на страници производа, никакав опис у декоративном hero елементу и потпуно другачији опис у чланку помоћи. Тачан одговор зависи од контекста. Зато су тимовима потребне уредничке смернице као што је прагматичан приступ alt тексту за слике, а не само правило у linter-у.

Исти проблем појављује се свуда.

Скенер може да потврди да свако дугме има приступачан назив. Не може увек да каже да ли тај назив има смисла. Страница са пет дугмади названих Submit може да прође основно правило, а да и даље буде мучна за кориснике читача екрана. Modal може имати исправне ARIA атрибуте, али погрешно заробити фокус. Прилагођени dropdown може изгледати усаглашено у статичком markup-у и отказати оног тренутка када неко покуша да га користи тастатуром.

Аутоматизација се тешко носи са питањима као што су:

• Да ли редослед фокуса одговара визуелном и логичком редоследу?
• Да ли се сваки задатак може завршити само тастатуром?
• Да ли су поруке о грешци конкретне, правовремене и повезане са пољима?
• Да ли страница и даље ради када се текст увећа или када се користи zoom?
• Да ли је редослед читања смислен за помоћне технологије?
• Да ли су упутства разумљива без ослањања на боју или положај?
• Да ли титлови, транскрипти и ознаке заиста преносе садржај?
• Да ли се компонента понаша предвидљиво у различитим стањима?

Ово нису рубни случајеви. Они су у средишту приступачности.

Лажна утеха високог резултата

Оцене приступачности су заводљиве јер неуредну тему сабијају у број. Контролна табла каже 98. Извештај приказује зелене ознаке. Издање делује безбедније.

Али оцена мери само оно што алат мери.

Ово је слично тестирању перформанси. Lighthouse извештај може открити важне проблеме, али није исто што и посматрати стварног корисника како се мучи кроз спор checkout на телефону средње класе. Ако ваш тим већ користи ревизије перформанси, важи исти начин размишљања: пажљиво прочитајте извештај, а затим приоритизујте налазе који утичу на стварне кориснике. О тој разлици писали смо у како читати Lighthouse извештај без панике.

Извештаји о приступачности захтевају исту уздржаност. Чист аутоматизовани скен је полазна тачка. Није сертификат.

Ризик је посебно висок када тимови покрећу скенирања само над статичким страницама. Савремени интерфејси имају стања: менији се отварају, фиоке клизе, toast поруке се појављују, поруке валидације се ажурирају, табови мењају панеле, филтери преписују садржај, а аутентификација мења све. Многи озбиљни недостаци приступачности живе у тим интеракцијама.

Ако ваш скенер види само почетни DOM, он пропушта производ.

Категорије које се најчешће пропуштају

1. Понашање тастатуре и фокуса

Приступ тастатуром један је од најјаснијих примера зашто аутоматизација није довољна.

Алат може да открије да ли је елемент фокусабилан. Може ухватити позитивне tabindex вредности или очигледне замке фокуса. Али не може поуздано да процени да ли редослед tab навигације делује кохерентно, да ли се фокус помера на право место после радње или да ли затворена компонента враћа фокус на окидач.

Потребан је човек који ће притискати Tab, Shift+Tab, Enter, Space, Escape и стрелице кроз стварни ток рада.

Ово је посебно важно за прилагођене контроле. Изворни HTML елементи бесплатно доносе године понашања приступачности. Поновна изградња дугмади, select елемената, checkbox-ова, менија и дијалога помоћу div-ова значи да ваш тим сада поседује то понашање. Ако прегледате интерактивне компоненте, почните од кратке контролне листе за приступачну веб дугмад и исту дисциплину проширите на сваку прилагођену контролу.

2. Смислени називи и описи

Аутоматизовани алати могу да открију одсуство. Много су слабији у откривању квалитета.

Линк назван Read more технички може имати приступачан назив. Дугме означено OK може бити валидно. Помоћни текст у формулару може бити присутан. Али да ли су смислени у контексту? Често нису.

Приступачни називи треба да кажу корисницима шта ће се догодити или шта елемент представља. То захтева расуђивање. Такође захтева тестирање са интерфејсом, а не само са кодом.

3. Руковање грешкама

Формулари су пуни проблема приступачности које скенери хватају само делимично.

Алат може означити поље без ознаке. Можда неће ухватити да се порука о валидацији појављује прекасно, нестаје пребрзо, не најављује се читачима екрана или каже Invalid input када би требало да каже Password must be at least 12 characters.

Добро руковање грешкама је дизајн интеракције. Потребно му је ручно тестирање и, идеално, корисничко тестирање.

4. Визуелно прилагођавање

WCAG укључује захтеве у вези са увећањем текста, reflow-ом, контрастом, размаком и неослањањем на један сензорни сигнал. Нешто од тога може се проверити аутоматски, али право питање је да ли интерфејс остаје употребљив под измењеним условима.

Пробајте 200% zoom. Пробајте промену величине текста у прегледачу. Пробајте режим високог контраста или forced colors. Пробајте уске ширине viewport-а. Пробајте reduced motion. Многи сајтови који изгледају дотерано на подразумеваним подешавањима брзо се ломе када корисници наметну своје преференције.

5. Јасноћа садржаја

Ниједан аутоматизовани алат за приступачност не може у потпуности да процени да ли је садржај разумљив.

Може означити недостајуће наслове или нејасан текст линка. Не може знати да ли страница јасно објашњава процес, да ли ознаке одговарају очекивањима корисника или да ли густ текст ствара непотребно когнитивно оптерећење.

Приступачност није само компатибилност са помоћним технологијама. Она је и смањивање трења за људе под стресом, људе који користе непознат језик, који се носе са ограничењима пажње или се крећу кроз сложене задатке.

Бољи процес тестирања

Уравнотежен процес приступачности има слојеве.

Покрећите аутоматизоване провере континуирано

Користите аутоматизоване тестове у развоју, pull request-овима, прегледима компоненти и CI-ју. Треба да буду досадни, брзи и ствар о којој се не преговара. Нове недостајуће ознаке и неважећи ARIA не би требало да чекају кварталну ревизију да би били откривени.

Третирајте ове грешке као грешке linting-а. Циљ није херојство; циљ је спречавање регресија.

Додајте ручно тестирање тастатуром

За сваки значајан кориснички ток тестирајте без миша. То укључује навигацију, претрагу, креирање налога, checkout, филтрирање, modal прозоре, меније и слање формулара.

У најмању руку, проверите:

• Сваки интерактивни елемент је доступан
• Фокус је видљив у сваком тренутку
• Редослед фокуса је логичан
• Очекивани тастери раде
• Escape затвара преклапајуће елементе који се могу затворити
• Фокусом се управља након отварања и затварања компоненти
• Не постоји замка тастатуре

Само ова навика хвата велику класу проблема које аутоматизована скенирања пропуштају.

Тестирајте бар једним читачем екрана

Не морате постати стручан корисник читача екрана да бисте научили корисне ствари. Потребна вам је скромност. Тестирање читачем екрана има криву учења, а почетници могу погрешно дијагностиковати проблеме.

Ипак, основно тестирање помоћу VoiceOver, NVDA или JAWS може открити покварене називе, збуњујући редослед читања, ненајављена ажурирања и проблеме са landmark елементима које скенер можда неће ухватити.

Упарите то са семантичким HTML-ом. Што више изворних елемената користите, то ваша приступачност постаје мање крхка.

Прегледајте садржај и стања

Проверите празна стања, стања учитавања, стања грешке, онемогућена стања, поруке о успеху и неуспехе дозвола. Грешке приступачности често се крију изван срећног пута.

Такође прегледајте стварне речи. Ознаке, наслови, упутства и поруке о грешци део су интерфејса.

Укључите кориснике са инвалидитетом када су улози високи

За критичне токове, ручни стручни преглед није довољан. Корисничко тестирање са учесницима са инвалидитетом проналази проблеме које тимови не предвиђају. Ово је посебно важно за јавне услуге, здравство, финансије, образовање и сваки ток у ком искључивање има озбиљне последице.

Аутоматизовано тестирање се скалира. Људско тестирање разуме.

Како одговорно тумачити аутоматизоване резултате

Не питајте: Да ли смо прошли?

Поставите боља питања:

• Које категорије проблема овај алат може да открије?
• Које шаблоне и стања је скенирао?
• Да ли је покренут после интеракција или само при почетном учитавању?
• Да ли су прекршаји груписани по основном узроку или се броје више пута?
• Које грешке спречавају кориснике да заврше задатке?
• Шта и даље захтева ручни преглед?

Овај оквир мења разговор. Аутоматизовани алати постају доказ, а не ауторитет.

Такође помаже тимовима да избегну заузетост без ефекта. Поправљање једне компоненте може уклонити стотине поновљених прекршаја. Насупрот томе, страница са само једним пријављеним проблемом и даље може садржати озбиљну замку тастатуре. Бројеви нису утицај.

Практичан стандард: аутоматизујте очигледно, ручно тестирајте искуство

Најбољи тимови за приступачност нису против алата. Они су против фантазије.

Аутоматизују оно што машине могу поуздано да открију. Ручно тестирају оно што зависи од понашања и значења. Користе стандарде као што је WCAG као заједничку основу, а не као замену за коришћење производа.

Ако је ваш тренутни процес само аутоматизовано скенирање пре лансирања, унапредите га овим редом:

1. Додајте аутоматизоване провере раније у развоју.
2. Ручно тестирајте тастатуром основне токове.
3. Прегледајте називе, ознаке, грешке и упутства.
4. Тестирајте уобичајене компоненте читачем екрана.
5. Укључите стручњаке и корисничко тестирање за високоризична путовања.

То није савршен процес. Реалистичан је. И пронаћи ће много више него што ће зелена оцена приступачности икада моћи.