Mobilanpassad webbplats: innehåll, funktion och testning

Mobilanpassning omfattar både hur innehållet visas och om besökaren kan använda det. Kontrollera därför erbjudande, läsbarhet och funktion i samma genomgång.

Vad skiljer responsiv design från mobilanpassning?

Responsiv design låter samma sida anpassa presentationen efter skärmens storlek. Mobilanpassning behöver dessutom prövas genom verkliga uppgifter, till exempel att läsa villkor och skicka en förfrågan. En layout som byter antal kolumner visar alltså hur sidan reagerar på bredden; ett funktionstest visar om besökaren kan använda den. Googles vägledning om mobila webbplatser beskriver responsiv design som en lösning med samma HTML och URL för olika enheter.

Vilken information behöver finnas även på mobil?

Prisvillkor, erbjudande och kontaktväg ska inte försvinna när layouten blir smalare. Google använder mobilversionens innehåll som grund vid mobile-first-indexering. Läs Googles vägledning.

En kompakt presentation kan använda tydliga sektioner eller öppningsbara delar, men innehållet måste fortfarande gå att nå och förstå.

En annan mobil layout får inte innebära att huvudinformationen saknas. En stängd flik kan visa innehåll som redan finns tillgängligt i sidan. Det är något annat än att hämta huvudtexten först efter ett klick. Google rekommenderar att huvudinnehållet inte laddas enbart efter en användarhandling. Kontrollera därför både vad besökaren kan öppna och vilket innehåll sökmotorn kan bearbeta.

Hur kontrollerar ni läsbarheten på en liten skärm?

Läs den verkliga texten i en smal vy och med förstoring; kontrollera att informationen går att följa utan att klippas bort. Långa rubriker, länkar, prisvillkor och svenska sammansättningar behöver provas med riktigt innehåll. En kort platshållartext kan dölja problemet.

• Brödtexten ska gå att läsa utan att ni måste följa varje rad med sidledes scrollning.
• Förstoring får inte göra kontaktvägen eller ett obligatoriskt fält oåtkomligt.
• Tabeller och diagram behöver ett begripligt sätt att läsas även när de kräver mer utrymme.
• Text i en bild behöver en tillgänglig motsvarighet när den förmedlar viktig information.

W3C:s kriterium Reflow beskriver hur innehåll ska kunna presenteras vid en bredd motsvarande 320 CSS-pixlar utan förlust av information eller funktion. Undantag finns för delar som behöver tvådimensionell layout för sin betydelse eller användning. En sådan breddkontroll är en avgränsad kontroll, inte ett intyg om att hela webbplatsen uppfyller WCAG.

Testa hela vägen från att hitta rätt information till att slutföra ärendet. Använd den uppgift som webbplatsen faktiskt ska stödja. För en tjänstewebbplats kan kontrollen se ut så här:

1. Hitta en relevant tjänst från startsidan.
2. Läs omfattning och prisvillkor.
3. Följ länken till rätt kontaktväg.
4. Fyll i formuläret och granska felmeddelanden.
5. Kontrollera vad som händer efter lyckad sändning.

Testa även tangentbord, förstoring och olika innehållslängder. Att sidan får plats i en skärmbild är inte tillräckligt.

Hur testar ni ett kontaktformulär på mobilen?

Testa både felaktig och korrekt inmatning och kontrollera bekräftelsen samt att ärendet når rätt mottagare. Illustrativt exempel: skicka ett testärende med ett avsiktligt fel i e-postfältet. Felmeddelandet ska visa vad som behöver rättas, och uppgifter som redan är ifyllda ska kunna kontrolleras. Rätta felet och kontrollera därefter både bekräftelsen på sidan och att ärendet nådde avsedd mottagare.

Hur dokumenterar ni ett mobilfel?

Dokumentera URL, enhet, webbläsare, handling och faktiskt utfall. Ange också vilket resultat ni förväntade er. Exempel på fel är en knapp som döljs bakom en annan komponent, brödtext som kräver sidledes scrollning eller ett formulärfel som bara markeras med färg. En skärmbild visar symptomet; beskrivningen gör det möjligt att upprepa testet.

Vad ska kontrolleras i mobilmenyn?

Besökaren ska kunna öppna menyn, välja rätt sida och återgå till innehållet utan att tappa sin position eller åtkomst. Prova både tryck och tangentbord. Kontrollera att den öppna menyn inte täcker sin egen stängningsknapp och att länkarna har begripliga namn. Prova dessutom en djup sida som första ingång, inte bara startsidan.

Om menyn är byggd som en modal dialog behöver även fokus hanteras: tangentbordsfokus ska stanna i den öppna dialogen och normalt återgå till kontrollen som öppnade den när den stängs. Detta gäller den modaltypen, inte alla vanliga menyer. Se W3C:s dialogmönster.

Vad behöver formuläret visa före sändning?

Formuläret behöver tydliga fältnamn, begripliga krav och instruktioner där de behövs. Ange vilka fält som är obligatoriska och förklara ett nödvändigt format före ett misslyckat försök. En platshållare som försvinner när besökaren börjar skriva ersätter inte en synlig fältetikett. W3C:s vägledning om formulärinstruktioner förklarar skillnaden.

Ett felmeddelande behöver ange vilket fält som är fel och hur uppgiften kan rättas. Kontrollera även att meddelandet går att uppfatta utan att enbart tolka färg och att ett lyckat försök får en tydlig bekräftelse. W3C beskriver återkoppling efter formulärinmatning. Testa med avsedda testuppgifter och kontrollera mottagningen innan flödet bedöms som färdigt.

Hur kan ett konkret testärende beskrivas?

Beskriv handlingen, det förväntade resultatet och det observerade resultatet var för sig. Följande är en illustrativ mall att fylla i, inte resultat från ett utfört kundtest:

En sida kan se korrekt ut men ändå reagera trögt eller flytta innehåll när resurser laddas. Core Web Vitals ger ett underlag för delar av den upplevelsen.

Efter optimering behöver funktionerna kontrolleras igen.

Vad behöver testas när nätet eller telefonen är långsammare?

Kontrollera om besökaren fortfarande kan förstå sidans status och använda viktiga funktioner medan innehåll laddas. Prova att öppna menyn, börja fylla i ett formulär och läsa information längre ned på sidan under laddningen. Dokumentera om något saknas tillfälligt, flyttar sig eller inte reagerar. Utred orsaken innan ni tar bort innehåll som besökaren behöver.

Illustrativt exempel: ett formulär visar en väntesignal efter sändning men inga nya instruktioner om nätverksförfrågan misslyckas. Då behövs en kontrollerad väg tillbaka till ett nytt försök. Kontrollera hur samma flöde hanterar dubbeltryck så att besökaren förstår om ärendet redan skickats. Det är ett funktionellt testfall; ett snabbt laddningstest kan inte ensamt besvara det.

Ange vilka uppgifter och skärmstorlekar som ska kontrolleras och dokumentera verkliga fel. Låt godkänd design styra utseendet, men ge konkreta återkopplingar när innehåll eller funktion inte ryms.

Skriv in uppgifterna och vem som godkänner dem i kravspecifikationen för webbplatsen. Då går det att skilja ett fel mot ett avtalat krav från ett nytt önskemål.

När problemen kräver ändringar i struktur, innehåll eller komponenter behöver de ingå i webbprojektets krav. Läs om SOVRA Digitals webbutveckling och kontrollen av den överenskomna leveransen.

Räcker det att förminska webbläsarfönstret?

Nej. En simulerad mobilvy behöver kompletteras med relevanta verkliga enheter för att bedöma deras funktion. Chrome DevTools beskriver sin enhetssimulering som en approximation, eftersom koden fortfarande körs på datorn. Se begränsningarna i enhetsläget. Välj testmiljöer utifrån webbplatsens besökare och den överenskomna leveransen.

Dokumentera vilka kombinationer av enhet och webbläsare som faktiskt testades, vilka uppgifter som gick att slutföra och vilka fel som återstår. Prova relevant skärmorientering, förstoring och öppna tangentbord i formulären. Ett godkännande gäller dessa dokumenterade kontroller; det ska inte formuleras som att varje tänkbar telefon och situation är verifierad.