Pieejamība, kas tiek pārbaudīta tikai reizi gadā, veicot vienreizēju manuālu pārskatīšanu, gandrīz vienmēr ātri pasliktinās — jebkurš neliels koda atjauninājums var sabojāt kaut ko, kas jau ir labots. Risinājums: iekļaujiet pieejamības testēšanu pašā izstrādes procesā (CI/CD) kā automatizētu darbību, lai problēmas tiktu uztvertas, pirms tās nonāk ražošanā. Šajā rakstā ir paskaidrots, kā.

Īsumā — par ko ir runāts šajā rakstā

  1. Kāpēc ar vienreizēju pārbaudi nepietiek?
  2. Ko var uztvert automatizētie rīki CI/CD konveijerā
  3. Kur joprojām ir nepieciešama manuāla pārbaude
  4. Kā to īstenot praksē

Kāpēc ar vienreizēju pārbaudi nepietiek?

Izstrādātāju komanda, kas piegādā atjauninājumus katru nedēļu vai dažreiz katru dienu, nevar paļauties uz ikgadēju pieejamības auditu, lai nodrošinātu pastāvīgu atbilstību. Jauns komponents, kas pievienots, nedomājot par pieejamību, vai CSS izmaiņas, kas nejauši samazina kontrastu, var sabojāt jau laboto pieejamību — un neviens to nepamana, kamēr lietotājs vai sūdzība to neatklāj. Tas pats princips attiecas arī uz dokumentiem — skatiet mūsu ceļvedikartot bieži sastopamās kļūdas.

Ko var uztvert automatizētie rīki CI/CD konveijerā

Rīki, piemēram, axe-core, Pa11y vai Lighthouse CI, var darboties automātiski katrā izvilkšanas pieprasījumā vai pirms katras izvietošanas — dažu sekunžu laikā tie pārbauda, ​​piemēram: krāsu kontrastu, nepareizus vai dublētus ARIA tagus, trūkstošo alternatīvo tekstu, trūkstošās veidlapas etiķetes un nepareizu virsrakstu secību. Ja pārbaude neizdodas, vilkšanas pieprasījuma apvienošana tiek automātiski bloķēta — tāpat kā parasta koda pārskatīšana vai nesekmīga vienības pārbaude.

💡 Praktisks padoms

Sāciet "brīdinājuma režīmā" (nebloķējot) dažas nedēļas, lai redzētu, cik problēmu jau pastāv kodu bāzē, un tikai pēc sākotnējās tīrīšanas pārvērtiet čeku par izvietošanas bloķētāju — tādējādi komanda "neiestrēgst", saskaroties ar simtiem kļūdu pirmajā dienā.

Kur joprojām ir nepieciešama manuāla pārbaude

Tāpat kā ar dokumentu testēšanu, automatizētie rīki CI/CD konveijerā uztver skaidras strukturālas problēmas, taču tie nevar spriest par faktisko lietotāja pieredzi: vai tastatūras navigācijai ir jēga, vai ekrāna lasītājs lapā "stāsta saskaņotu stāstu" vai arī pielāgots komponents (piemēram, karuselis vai modāls) ir patiesi lietojams reālajā dzīvē. Tāpēc ir vērts pašreizējās automatizētās pārbaudes savienot pārī ar periodisku manuālu auditu, piemēram, reizi ceturksnī.

Kā to īstenot praksē

  1. Izvēlieties testēšanas rīku, kas atbilst jūsu tehnoloģiju kopai (cirvju kodols lielākajai daļai JavaScript projektu, Lighthouse CI pārlūkprogrammu projektiem).
  2. Palaidiet to kā soli savā CI konveijerā — parasti kā GitHub darbību, GitLab CI darbu vai līdzvērtīgu darbību jebkurā CI/CD rīkā, ko izmantojat.
  3. Iestatiet skaidru atteices slieksni (piemēram, nav "kritisku" līmeņa problēmu katrā cirvja kodolā), pirms pārbaude kļūst par bloķētāju.
  4. Aizveriet arī savus PDF failus: ja jūsu organizācija automātiski ģenerē dokumentus (rēķinus, atskaites), apsveriet iespēju pievienot arī tiem automatizētu skenēšanu kā daļu no publicēšanas.

Vai vēlaties savam procesam pievienot arī automatizētu PDF testēšanu?

Mūsu rīks skenē PDF failus un katram dokumentam piešķir pieejamības punktu — varat to palaist kā periodisku pārbaudi kopā ar CI/CD procesu.

Skenējiet savu vietni bez maksas ←

Pēc skenēšanas varat arī padarīt atrastos dokumentus pieejamus tieši un bez maksas, izmantojotAccessiDoc.