Tangentbordstest av AI-byggd webbapp: steg för steg

1. Välj ett formulär och skriv förväntad ordning

Öppna den AI-byggda webbapp du ska granska i en vanlig webbläsare. Välj ett formulär som går att nå utan inloggning eller använd ett separat testkonto. Använd påhittade uppgifter om formuläret skickar data. I den här guiden är exemplet ett kontaktformulär med fälten Namn och E-post, knappen Skicka samt länken Hjälp som öppnar en stängbar dialog. Byt namnen mot din egen apps synliga etiketter innan du testar.

Skriv först ditt facit på en rad: Namn → E-post → Skicka → Hjälp. Ange också att dialogen ska gå att stänga med Escape och att fokus därefter ska hamna på Hjälp. Detta är ett föreslaget krav för exempelformuläret, inte en regel om att alla sidor måste ha just den ordningen. W3C:s förklaring av fokusordning kräver en ordning som bevarar mening och användbarhet; flera ordningar kan fungera.

Notera webbläsare, operativsystem, appversion eller commit och sidans adress. Ta gärna en skärmbild av formuläret före provet. Dessa uppgifter gör det lättare för nästa person att återskapa samma miljö. Om sidan ändrar innehåll beroende på inloggning eller skärmbredd, skriv även ned det.

2. Prova Tab och Shift+Tab utan mus

Ladda om sidan. Placera fokus vid början av innehållet med webbläsarens tangentbordsfunktion och lägg undan musen. Tryck Tab en gång i taget och skriv ned vilket element som får fokus. En startsida kan ha navigation och länkar före formuläret; börja därför loggen när du når första kontrollen i formuläret. Kontrollera att du kan nå varje fält, knapp och relevant länk, och att du kan lämna varje kontroll igen. W3C:s Easy Checks föreslår just dessa kontroller av tangentbordsåtkomst och synligt fokus.

Gå sedan tillbaka med Shift+Tab. För exempelformuläret är facit från Hjälp: Skicka → E-post → Namn. Om fokus hoppar från Namn till Skicka och inte når E-post, skriv det som en observerad avvikelse. Om det fastnar i en kontroll så att du inte kan fortsätta, dokumentera tangentsekvensen och var fokus blev kvar. En visuell layout kan se rätt ut även när ordningen i webbläsaren gör formuläret svårt att använda.

För varje steg, titta efter en synlig markering på det aktiva elementet. Den kan vara en ram, färgförändring eller annan tydlig indikator. Bedöm om du faktiskt kan se var du är på just din sida och bakgrund. W3C:s förklaring av synligt fokus beskriver flera möjliga former; ett test av en viss app måste utgå från vad användaren ser där.

3. Prova Enter, Escape och formulärfel

Tabba till Hjälp och tryck Enter. I vårt exempel ska dialogen öppnas och tangentbordet kunna nå dess innehåll. Tryck Escape. Facit för just den här dialogen är att den stängs och att fokus återgår till Hjälp. Om appen inte har en stängbar dialog, skriv ej tillämpligt för Escape i stället för att kalla det ett fel. Olika komponenter har olika beteenden; prova mot det beteende som appen faktiskt lovar.

Gå tillbaka till formuläret. Lämna E-post tomt, nå Skicka med Tab och aktivera med Enter. Skriv ned om formuläret ger ett begripligt felmeddelande, var meddelandet visas och var fokus hamnar. Fyll sedan i ett medvetet ogiltigt värde, till exempel feladress, och upprepa. W3C:s preliminära kontroll av formulär, etiketter och fel omfattar tangentbordsåtkomst och felhantering. Den ger underlag för provet men ersätter inte en fullständig granskning.

Om webbläsarens egen validering stoppar skickandet, ange det i loggen. Det är ett annat utfall än ett felmeddelande från appen efter ett serveranrop. Försök inte kringgå valideringen bara för att få ett förväntat fel. Dokumentera det beteende du faktiskt såg och skilj det från det du ville undersöka.

4. Skriv en reproducerbar fellogg

En användbar fellogg innehåller en kontroll per rad. Skriv både förväntat och faktiskt resultat. Lämna inte ord som ”fungerar inte” utan tangentsteg: en utvecklare behöver kunna upprepa avvikelsen och avgöra om rättningen träffar den. Följande exempel är en mall för en möjlig observation, inte ett test som AI-kreatör har kört:

Miljö: Chromium, Windows, appversion/commit: [fyll i]
Sida: [exakt adress]
Start: ladda om; tabba till Namn
Steg: Tab till E-post; Tab till Skicka; Shift+Tab
Förväntat: fokus återgår till E-post med synlig markering
Faktiskt: [fyll i vad du ser]
Bevis: [skärmbild eller kort skärminspelning, om tillåtet]
Återtest: [datum, version, samma steg, utfall]

Om det gäller ett felmeddelande, lägg till inmatningen och den synliga feltexten ordagrant. Notera om fokus flyttades eller stannade på Skicka. Ange hur ofta du kunde återskapa problemet, till exempel två av två försök i samma miljö, men skriv bara en siffra när du verkligen har gjort försöken. Detta skiljer verifierade observationer från ett antagande om koden.

5. Rätta en sak och återtesta samma steg

Ge felloggen till den som ändrar appen eller till kodassistenten. Be om en liten ändring och en förklaring av hur den påverkar just den observerade fokusordningen eller feltexten. Ändra inte facit i efterhand för att få provet att se godkänt ut. Behåll originalets steg och kör dem igen mot den nya versionen. Skriv version och utfall på raden Återtest.

Om du vill spara tangentsekvensen i ett automatiserat regressionstest stöder Playwrights keyboard.press bland annat Tab, Shift som modifierare, Enter och Escape. Ett sådant test kan kontrollera vilket element som har fokus efter varje tangenttryckning. Kör ändå det manuella provet för att se om fokusmarkeringen går att uppfatta visuellt; en kontroll av aktivt element ensam mäter inte det.

await page.keyboard.press('Tab');
await page.keyboard.press('Shift+Tab');
await page.keyboard.press('Enter');
await page.keyboard.press('Escape');

Avsluta med ett kort protokoll: vilka steg passerade, vilka avvikelser finns kvar och vilka formulär eller skärmlägen har du ännu inte provat? En passerad tangentsekvens är inte ett intyg om WCAG-efterlevnad. W3C beskriver sina Easy Checks som en första, begränsad genomgång där betydande hinder kan finnas kvar. Fortsätt med fler gränsfall i guiden om testning av AI-genererad kod och använd Trace Viewer-guiden om ett formulärfel behöver spåras genom nätverk och DOM.