Språk och felmeddelanden

 

Syntolkning: En påskskål med fruktsallad. Två vita kaniner håller i skålen, den ena är klädd i klänning och den andra i byxor och tröja. Skålen står på en beige duk. 

Under föregående vecka hade vi lektioner med Johan Kling från Funka och det var den sista veckan innan påsklovet. Vi pratade vidare om WCAG (Web Content Accessibility Guidelines) och hade uppgifter om tre nya framgångskriterier, ett om språk och två om felmeddelanden.

 

Måndag

Under vår förra vecka med Johan pratade vi om att vi ville se en överblick över de olika framgångskriterierna i WCAG, men även över de kriterier som vi ska lära oss. I måndags fick vi se ett Excelldokument med en tabell över alla kriterierna. En kolumn i tabellen visade vilka kriterier vi gått igenom hittills, samt vilka vi ska lära oss under de kommande veckorna. När Funka granskar hemsidor går de igenom 80 kriterier, målet är att vi ska kunna granska 14 av dem.

Vi pratade om de kriterier vi redan gått igenom och därefter presenterade Johan det som komma skall.

Formulär och felmeddelanden: Vi kommer prata om felmeddelanden och hur dessa visas för användaren. Om användaren ska skriva in sin mejladress i ett formulär, men glömmer snabel-a, så kommer man inte vidare. Då finns det två punkter, det ska dels vara tydligt att ett fel har uppstått, men webbplatsägaren ska också hjälpa användaren att göra rätt. Ett exempel är att det står i felmeddelandet att fältet för en e-postadress inte är korrekt ifyllt. Vi vet nämligen att alla e-postadresser innehållet snabel-a.

Titlar: På varje HTML-sida finns det ett element som heter Title. I elementet ska sidan kort beskrivas och i slutet av beskrivningen börnamnet på själva webbplatsen stå. Exempel ”Kultur och fritid – Västerviks kommun”. Detta system används mycket av exempelvis Google, för att få fram bra sökresultat. För oss som använder skärmläsare är det titeln som läses upp först när vi går in på en sida.

Tangentbordsstyrning: Innehåll ska presenteras i en logisk ordning för personer som navigerar med tangentbordet. Detta är viktigt eftersom man själv inte kan bestämma vilken ordning innehållet ska presenteras i.

HTML-kod: Den ska validera korrekt.

 

De olika framgångskriterierna i WCAG är indelade i kapitel

·         Generellt

·         HTML och CSS: Kapitlet innehåller tre framgångskriterier. Det första handlar om att använda HTML och CSS när man bygger hemsidor, det är viktigt att inte använda andra system som inte är tillgängliga för olika användargrupper. Det andra kriteriet handlar om att följa HTML. Det är en standard och alla HTML-sidor ska se ut på ett visst sätt. Det sista kriteriet handlar om att läsordningen ska vara logisk. Detta är viktigt för personer som navigerar med tangentbord, eftersom man själv inte kan välja i vilken ordning innehållet presenteras.

·         Responsivitet – Gränssnittet ska anpassa sig utefter olika skärmstorlekar.

·         Navigation och länkar – Exempelvis hur man tar sig runt på en webbplats med hjälp av tabb-tangenten. I detta kapitel ingår det att användaren ska kunna hoppa över grupperat innehåll, vilket vi arbetade med häromveckan.

·         Färger och presentation – Kapitlet innehåller punkterna om kontrast som vi arbetade med tidigare, men också punkten om titlar.

·         Struktur och formatering – Här finns punkter om rubriker, men kapitlet innefattar också stycken, listor och annat.

·         Bilder – Det handlar om att det ska finnas alternativtexter till bilder, men också att text inte ska vara gömd i bilder.

·         Formulär – Kapitlet innehåller elva punkter, bland annat de två punkterna om felmeddelanden som vi ska gå igenom senare i veckan.

·         Tabeller – Rubriker i tabeller ska vara angivna, så även i vilken ordning de olika cellerna ska läsas.

·         Script & wai-aria – Aria står för Accessibility Rich Internet Applications. Här ingår det bland annat att tillgängliggöra interaktiva webbplatser där det händer något på sidan när man som användare klickar på en knapp, utan att det sker någon sidomvandling. Exempelvis om man handlar på nätet och klickar på en köp-knapp. Då brukar det synas i ett hörn att en produkt lagts till i varukorgen. Detta måste vara tydligt för skärmläsaranvändare, det kan inte bara synas visuellt. Med wai-aria kan programmeraren också berätta för skärmläsaranvändare om en meny som går att fälla ut är utfälld eller hopfälld. Wai-aria är väldigt omfattande och innehåller många olika funktioner.

·         Automatiska händelser – Pop-ups ska inte dyka upp utan att man själv aktiverar det. Ofta dyker det upp en ruta om att betygsätta en webbplats precis när man kommit in på den. Det är helt onödigt, det går inte att betygsätta en webbplats man precis loggat in på för första gången. Därför är det bättre att ha en knapp där användaren själv kan klicka fram enkäten. Det är förvirrande för många användare när rutor dyker upp utan förvarning. I kapitlet ingår det att användare får tillräckligt med tid för att fylla i olika formulär, man ska inte riskera att bli automatiskt utkastad innan man är färdig. Man ska få varningar när tiden är på väg att ta slut. Om man ändå blir utkastad ska det man gjort dittills sparas automatiskt.

·         Ramar –Tidigare fanns det något som hette frameset i HTML, vilket gjorde att webbplatserna hade mycket ramar. Med hjälp av ramarna delades webbplatserna upp i olika områden. Ramar finns inte alls i samma utsträckning längre, det ända som finns är I-frame. Det handlar om att använda en yta på sin webbplats, för att lägga dit innehåll från en annan webbplats. Detta är vanligt förekommande på kommunhemsidor, där de har en yta med lediga jobb som är hämtad från Arbetsförmedlingen. Funkar rekommenderar dock att länka till Arbetsförmedlingens webbplats istället. I-frames brukar vara svåra att anpassa efter olika skärmar, det som kallas Responsivitet. Det vanligaste tillfället då I-frame används är när man ska lägga in en video från exempelvis YouTube på en annan webbplats. Då är tillgänglighetskravet att det ska finnas en beskrivande titel på vad den inbäddade sidan innehåller.

·         Sökfunktioner – På alla större webbplatser ska det finnas minst två sätt att hitta information. Det vanligaste är att det finns en meny, men det ska också finnas ett sökfält, en webbkarta eller en a-ö lista.

·         Dokument och andra medieformat – Detta kapitel handlar bland annat om att webbplatser inte ska ha något bakgrundsljud, eftersom det försvårar för skärmläsaranvändare. Om man tvunget vill ha det så ska det enkelt gå att stänga av, eller så ska det sluta automatiskt efter tre sekunder. Kapitlet innehåller också punkter om poddar, personer med nedsatt hörsel ska kunna ta del av dem via text. Film ska alltid vara textad på samma språk som det talade språket, likadant med livesändningar. I WCAG finns det alltså ett kriterium som säger att livesändningar ska vara textade, men det är däremot ett undantag i den svenska DOS-lagen (Lagen om tillgänglighet till digital offentlig service). Funktioner för automatisk textning utvecklas hela tiden, vilket gör det enklare att texta livesändningar i större utsträckning. Verktygen blir bättre desto mer vi använder dem. Även om det inte är ett lagkrav så är det bra att texta livesändningar.

·         Klarspråk och begriplighet – Man ska inte använda begrepp som ”knappen till höger”, för skärmläsaranvändare finns det inget höger, eftersom vi inte använder någon datormus och inte ser skärmen. Dessa begrepp brukar dessutom inte stämma när vi har responsiva webbplatser, eftersom samma webbplats ser olika ut på datorn och mobilen. Visuella beskrivningar som är kopplade till exempelvis färger, eller ljudbaserade beskrivningar ska inte användas. Ett väldigt dåligt exempel är ”klicka på den röda knappen när musiken tystnar”. I detta kapitel finns också det kriterium som ni kan läsa om här nedan, nämligen att sidans huvudsakliga språk ska vara angivet i koden. Det finns också en underpunkt, nämligen att man ska identifiera avvikelser i det huvudsakliga språket, såsom en engelsk boktitel i en svensk text.

·         Webbtillgänglighetsdirektivet (WAD)– Detta kapitel innehåller sådant som inte finns i WCAG, men som finns i lagen, vilken i Sverige heter DOS-lagen (Lagen om tillgänglighet till digital offentlig service). Det handlar om att varje webbplats ska ha en tillgänglighetsredogörelse där de redogör för eventuella brister, varför de finns och hur/när de ska åtgärdas. Webbplatsägaren ska erbjuda ett alternativt format för det som är otillgängligt. Redogörelsen ska vara begriplig, så att ”vanliga” användare förstår. Genom redogörelsen ska man kunna komma i kontakt med webbplatsägaren för att ge feedback. Det ska finnas en länk till DIGG (Sveriges tillsynsmyndighet), där man kan anmäla webbplatser för bristande tillgänglighet. Det är dock viktigt att gå via webbplatsägaren först. Är man inte nöjd med deras svar så ska man vända sig till DIGG. Alla dokument på en webbplats ska också vara tillgängliga.

 

Framgångskriteriet 3.1.1 i WCAG

Detta kriterium handlar om att sidans huvudsakliga språk ska vara angivet i koden och det är ett kriterium på nivå A. Det huvudsakliga språket ska anges för alla sidor på hemsidan, detta är viktigt om sidorna finns på flera olika språk. Kriteriet är av stor vikt för personer med skärmläsare, för att rätt röst ska läsa rätt språk. Om exempelvis en engelsk röst går in och försöker läsa svensk text så blir det väldigt svårt att förstå. Detta blir konsekvensen om språket inte är rätt angivet i koden.

Detta är lätt för programmerarna att göra, det är ett så kallat langatribut som ska in i koden och attributet ska ha rätt värde, EN för engelska och SV för svenska till exempel.

 

Uppgift - 3.1.1

Uppgiften till onsdagens lektion löd som följande:

·         Gå in på fem webbplatser

·         Minst en kommun, en myndighet, ett elbolag och en turistbyrå

·         Titta på startsidan och en undersida

·         Gå in i källkoden och se om langattributet är korrekt

·         Koden finner du genom att högerklicka på hemsidan, eller (på PC) genom att använda snabbkommandot Ctrl + U. Langattributet brukar finnas på rad två i koden.

Godkänt:
Langattributet finns och har rätt värde.

Underkänt
Langattributet finns men har fel värde.
Langattributet finns inte.

 

Resultat:

·         Försäkringskassan
Startsida: Godkänt
https://forsakringskassan.se/
Coronaviruset – det här gäller: Godkänt
https://forsakringskassan.se/privatpers/coronaviruset-det-har-galler

·         Diskrimineringsombudsmannen
Startsida (svenska): Godkänt
https://www.do.se/
Startsida (tyska): Godkänt
https://www.do.se/choose-language/deutsch-tyska
Förskola, skola, högskola: Godkänt
https://www.do.se/forskola-skola-hogskola-ska-forebygga-diskriminering

·         Helsingborgs kommun
Startsida (svenska): Godkänt
https://helsingborg.se/
Startsida (engelska): Underkänt. Det står SV i langattributet, trots att sidan är på engelska.
https://helsingborg-se.translate.goog/?_x_tr_sl=sv&_x_tr_tl=en&_x_tr_hl=sv
Trafik och stadsplanering (svenska): Godkänt
https://helsingborg.se/trafik-och-stadsplanering/
Trafik och stadsplanering (engelska): Underkänt. Det står SV i langattributet.
https://helsingborg-se.translate.goog/trafik-och-stadsplanering/?_x_tr_sl=sv&_x_tr_tl=en&_x_tr_hl=sv

·         Öresundskraft
Startsida: Godkänt. Langattributet finns dock på rad sex i koden, eftersom rad 2 - 5 är tomma.
https://www.oresundskraft.se/
Regeringens förslag om förlängt elprisstöd för hushåll i mellersta och södra Sverige: Godkänt. Även här finns langattributet på rad sex.
https://www.oresundskraft.se/sa-paverkar-regeringens-elprisstod-dig/regeringens-forslag-om-elprisstod-for-hushall-i-mellersta-och-sodra-sverige/

·         Visit Helsingborg
Startsida (svenska): Godkänt.  
https://visithelsingborg.com/
Startsida (engelska): Godkänt.
Det finns ett problem gällande att byta språk. I navigeringen finns symbolen av en svensk flagga och när man håller pilen över den så fälls en meny ut där man kan byta flagga (språk). Jag förstår dock inte hur man ska göra detta med hjälp av skärmläsare. När jag har tangentbordsfokus på flaggan så säger den ”svenska länk grafik”, inget om att jag kan byta språk. När jag klickar på flaggan laddas sidan om på svenska, jag får ingen möjlighet att byta språk.
https://visithelsingborg.com/?lang=en
Se & Göra: Godkänt.
https://visithelsingborg.com/se-gora/

 

Onsdag

I onsdags började vi med att gå igenom uppgiften om språk och hur det hade gått för oss. För de flesta hade det gått bra och många hemsidor vi besökte hade gjort bra ifrån sig, vi hittade bara några enstaka fel. Under genomgången fick vi tid att ställa frågor och Johan förklarade att langattributet kan mätas med automatiskt test, om testet både kan titta i koden och läsa språket. Det finns en underpunkt inom framgångskriteriet om språk och det innebär att programmeraren ska identifiera undantag i språket, exempelvis en engelsk boktitel i en svensk text.

Vi pratade om Excelldokumentet vi fick i måndags och Johan sa att vi själva fick bestämma om det var några andra framgångskriterier vi ville lägga fokus på, istället för de han hade valt ut till oss. Vi tyckte dock det kändes bra och vi ville inte ändra på något.

Vi fördjupade oss inom kapitlet i WCAG som handlar om responsivitet, vilket innebär att webbplatserna ska anpassa sig utifrån vilken typ av skärm man använder, såsom dator, mobil eller surfplatta. I kapitlet ingår följande fyra punkter:

·         All information och alla funktioner ska finnas oavsett vilken skärm som används. Det behöver inte se likadant ut, men det ska vara samma innehåll.

·         Användaren ska inte behöva skrolla i två ledder, alltså inte både lodrätt och vågrätt.

·         Webbplatsen ska tåla förstoring upp till 200% och det gäller alla typer av skärmar.

·         Webbplatser ska kunna användas i både stående och liggande läge. Detta kan vara viktigt för personer med motoriska svårigheter. Om man har sin surfplatta fastspänd på sin rullstol så kan man bara ha den i liggande läge. Vissa appar, exempelvis Instagram och Facebook, är låsta i ett stående läge, vilket är en brist inom WCAG.

Bygger man webbplatser som går att förstora så blir de också responsiva, eftersom de fungerar för olika skärmstorlekar.

Förstorad text brukar underlätta för personer med lässvårigheter, bokstäverna blir större, det blir färre ord på varje rad och man får ett större avstånd mellan både bokstäver och rader. Det är dock viktigt att komma ihåg att alla individer är olika, därför är det bra om man kan göra personliga inställningar för exempelvis radavstånd. Bakgrundsfärg och textfärg spelar ofta stor roll för dessa användare, eftersom en bra kontrast är viktig. Gällande radlängd så tycker Funka att 55 tecken per rad är lagom, de brukar godkänna maximalt 80. Även när man skriver lättläst text är korta rader att föredra.

En av mina klasskamrater frågade Johan vilket framgångskriterium som är lättast respektive svårast att uppfylla. Johan förklarade då att kriteriet om språk är lätt att uppnå, det är bara ett attribut som ska in i koden. Om man däremot har en webbplats med många otillgängliga filmer så blir det både svårare, dyrare och mer tidskrävande att fixa, framför allt om de både behöver textas och syntolkas. Idag finns det dock automatisk textning och den utvecklas hela tiden. Använder man det behöver man bara gå in och ändra småfel i efterhand, istället för att skriva hela texten manuellt. Det är dyrt att syntolka filmer, därför har inte alla mindre webbplatser råd att göra det. Film är bra för många användare, därför tycker inte Funka att webbplatser ska ta bort filmer som inte är helt tillgängliga. Då är det bättre att informera om det i tillgänglighetsredogörelsen, samt förklara varför felet inte är åtgärdat. DIGG (Sveriges tillsynsmyndighet) kan ge böter för allvarliga tillgänglighetsbrister. Johan påstår dock att vi är långt ifrån böter i Sverige, det är bra att webbplatserna är uppmärksamma på sina brister och gör bättre till nästa gång.

Det finns två olika versioner av textning gällande video. Den ena texten är fast och den andra kan man stänga av och sätta på. Gällande den sistnämnda finns det ett krav på att man ska kunna ändra storlek på texten. Idag finns det inget krav på upplösning, men däremot finns det ett krav på att ljud och bild ska vara synkat, vilket är viktigt för personer som läser på läppar.

 

Framgångskriteriet 3.3.1 i WCAG

När ett fel uppstår ska det visas tydligt för användaren. Om det finns en möjlighet att göra fel, exempelvis i ett formulär, så kommer vissa användare göra fel. Det är då viktigt att användaren får veta att något gått snett. Detta är ett framgångskriterium på nivå A. Felet ska beskrivas vid fältet där det uppstått. Felmeddelandet ska vara visuellt tydligt, gärna visas med en ikon. Det får inte bara visas med färg, exempelvis att fältet för en e-postadress blir rödmarkerat. Det fungerar inte för de som har färgblindhet.

 

Uppgift – 3.3.1

·         Gå in på fem olika webbplatser

·         Minst en kommun, en myndighet, ett elbolag och en turistbyrå

·         Leta efter formulär, exempelvis kontaktformulär. De brukar finnas under ”Kontakt”, i sidfoten eller tillgänglighetsredogörelsen.

·         Lämna formuläret tomt och prova skicka in det.

·         Kontrollera om felmeddelanden fungerar som de ska

 

Godkänt

1.      Felmeddelandet presenteras med text och information om att ett fel har inträffat förmedlas vid varje enskilt fält.

2.      Felmeddelandet är knutet till det fält där felet inträffat. Både för seende och för skärmläsaranvändare. Det innebär att även om man inte ser så ska det vara tydligt var felet inträffat, genom att man automatiskt får tangentbordsfokus på det aktuella fältet.

3.      Felmeddelandet visas tydligt visuellt, inte enbart med en skiftande färg.

För oss som använder skärmläsare är det svårt att granska punkt 3, eftersom det handlar om hur det ser ut rent visuellt. När jag utförde denna uppgift hade jag tillgång till seende stöttning, så jag kunde granska även denna punkt.

På vissa webbplatser får vi skärmläsaranvändare förmodligen pila upp till fältet som inte är korrekt ifyllt, vi kommer inte dit automatiskt. När vi behöver leta efter felet så är det underkänt på punkt 2, att meddelandet ska vara knutet till respektive fält. Punkten innebär att alla användare ska kunna förstå var felet uppstått, oavsett om man navigerar med hjälp av synen eller om man använder skärmläsare.

 

Resultat:

·         Försäkringskassan
Godkänt (punkt 1, 2 och 3)
I tillgänglighetsredogörelsen finns ett formulär för att rapportera brister. Alla kontaktuppgifter är frivilliga, men däremot är det obligatoriskt att fylla i vad som inte fungerar. När man klickar på skicka utan att fylla i detta fält kastas man längst upp i formuläret, där man får information om vad man inte fyllt i. Detta händer även för oss som använder skärmläsare. Under informationen finns en länk, klickar man på den så hamnar man direkt vid fältet som ska fyllas i, annars kan man pila/skrolla för att komma dit. Vid fältet finns också information om att det måste fyllas i, texten är röd och framför texten syns en varningssymbol. Direkt när man börjar skriva i fältet så försvinner felmeddelandet.
https://forsakringskassan.se/om-webbplatsen/tillganglighet/tillganglighetsredogorelse/anmal-brister-i-var-digitala-tillganglighet#/

·         Diskrimineringsombudsmannen
Godkänt (punkt 1, 2 och 3)
På sidan finns ett formulär för att rapportera tillgänglighetsbrister. Formuläret hittas via en knapp längst till höger på datorskärmen. Jag hade svårt att hitta den med hjälp av skärmläsare, men lyckades med hjälp av förstoring. I formuläret finns inga fält för personuppgifter, däremot är det obligatoriskt att skriva vad det är som inte fungerar. När man försöker skicka in formuläret utan att ha fyllt i fältet läses felmeddelandet upp för den som använder talsyntes. Därefter får man pila upp till det aktuella fältet. Som skärmläsaranvändare hamnar man inte automatiskt på det aktuella fältet, men man får tydlig information om att ett fel har uppstått samt var. Det är godkänt, men det hade varit bättre om man hamnat direkt på fältet. Vid fältet finns informationstexten, den är röd och har en varningssymbol framför sig. Själva formuläret är godkänt på alla punkter, men vägen dit är svår för skärmläsaranvändare och dessutom visas det i en pop-up, vilket inte är det optimala.
https://www.do.se/

·         Ystads kommun
Godkänt (punkt 1 och 2)
Underkänt (punkt 3)
På Ystads kommun finns ett formulär att fylla i för felanmälningar. Det är obligatoriskt att fylla i vilket område ärendet gäller. När man försöker skicka in formuläret utan att välja område kastas man tillbaka till det fältet, även vi som använder skärmläsare. Informationen står tydligt under fältet, men den är röd och utmärker sig inte på något annat sätt.
https://online.infracontrol.com/Public/IssueForm/113/Default

·         Öresundskraft
Godkänt (punkt 1)
Underkänt (punkt 2 och 3)
På Öresundskraft finns ett formulär för att kontakta kundservice. Formuläret är uppdelat på olika sidor, först ska man fylla i om man är privatperson eller företagare, sedan ska man beskriva vad ärendet gäller och till sist ska man fylla i sina personuppgifter och kontaktuppgifter. Har man inte fyllt i alla fält kan man inte gå vidare. Det står ett felmeddelande med information under de fält som inte är ifyllda, men det kommuniceras inte till skärmläsaranvändare. Texten i felmeddelandet är rosa och den utmärker sig inte på något annat sätt. Formuläret finns längst ner på en sida som handlar om kontakt. Varje gång jag går vidare till nästa steg behöver jag (som använder skärmläsare) tabba mig igenom hela sidan för att komma till formuläret. Detta är inget fel i själva formuläret, men däremot är det ett fel gällande tangentbordsfokus, vilket är ett annat framgångskriterium inom WCAG.
https://www.oresundskraft.se/kundservice/kontakta-oss/

·         Svenska turistföreningen
Underkänt (punkt 1, 2 och 3)
Här finns ett formulär för att kontakta medlemsservice och de flesta fälten är obligatoriska. När man klickar på att skicka in utan att ha fyllt i något så dyker det upp en text under skicka-knappen som talar om att man måste fylla i alla obligatoriska fält. Denna text läses upp för skärmläsaranvändare, men den är inte kopplad till respektive fält, vilket gör att den bryter mot både punkt 1 och 2. Texten är svart och är placerad i en ljusrosa ruta, den har dock ingen ikon som utmärker den. Den rosa rutan räcker inte, eftersom den inte indikerar att det handlar om ett felmeddelande. Ramen runt varje fält ändras från ljusgrå till röd, men det är också bara en färgskiftning.
https://www.svenskaturistforeningen.se/om-stf/kontakta-oss/

 

Framgångskriteriet 3.3.3 i WCAG

När det finns möjlighet ska aktören förklara för användaren hur felen kan åtgärdas. Om användaren glömmer snabel-a i sin e-postadress kan meddelandet lyda ”Vänligen fyll i en korrekt e-postadress”. Aktören ska beskriva så tydligt som möjligt vad som är fel och hur användaren kan åtgärda felet. Detta är ett framgångskriterium på nivå AA.

 

 

Bonusuppgift – 3.3.3

·         Gå in på fem webbplatser.

·         Minst en kommun, en myndighet, ett elbolag och en turistbyrå.

·         Leta upp ett formulär, exempelvis kontaktformulär. Dessa brukar finnas under ”kontakt”, i sidfoten eller i tillgänglighetsredogörelsen.

·         Se om framgångskriteriet 3.3.3 är uppfyllt.

Godkänt
Om möjligt får besökaren hjälp med hur ett fel ska åtgärdas.

Underkänt
Trots möjlighet finns ingen hjälp för besökaren med hur felet ska åtgärdas.

 

Resultat:

·         Ystads kommun
Godkänt
I formuläret för felanmälan på Ystads kommun väljer jag en kategori, jag väljer att bli kontaktad via e-post och sedan skriver jag enbart mitt förnamn i fältet för e-post. Då får jag ett meddelande som lyder ”Du måste fylla i en giltig e-postadress”. Jag får informationen direkt, utan att pila mig till fältet.
https://online.infracontrol.com/Public/IssueForm/113/Default

·         Öresundskraft
Godkänt
I formuläret för att kontakta kundtjänst på Öresundskraft väljer jag att vara privatperson och sedan beskriver jag mitt ärende. När jag ska fylla i min e-postadress skriver jag endast mitt förnamn och då lyder felmeddelandet ”Fältet E-post måste vara en giltig e-postadress”. Jag behöver dock pila för att hitta meddelandet, det dyker inte upp automatiskt.
https://www.oresundskraft.se/kundservice/kontakta-oss/

·         Svenska turistföreningen
Godkänt, men på gränsen till underkänt
Jag fyller i alla obligatoriska fält i formuläret för kontakt, men skriver bara mitt förnamn i fältet för e-post. När jag försöker skicka in formuläret så händer ingenting  (enligt min skärmläsare). När jag pilar upp får jag reda på att det står ”Non valid email format” i fältet för e-post. Detta är ett felmeddelande från webbläsaren. Programmeraren har informerat om att det är ett fält för e-post, men har inte bestämt något eget felmeddelande. Meddelandet står i fältet och raderar det jag själv skrivit. Det är mycket bättre att ha felmeddelandet i anslutning till fältet. Ibland syns meddelandet och ibland inte. Fyller jag i de övriga fälten så syns meddelandet, är alla fält tomma så syns det inte. Det finns alltså ett felmeddelande som hjälper användaren att fylla i en korrekt e-post, så punkten är godkänd, men det finns så många fel runtomkring. Felmeddelandet är på engelska på en svensk sida, det är ett meddelande från webbläsaren och inte från programmeraren, det raderar den e-post man själv skrivit och det syns bara i vissa situationer.

https://www.svenskaturistforeningen.se/om-stf/kontakta-oss/

Det var svårt att hitta webbplatser som erbjuder kontakt via formulär, därför blev det bara tre webbplatser på denna uppgift. I formulären hos Försäkringskassan och Diskrimineringsombudsmannen är fältet för e-post frivilligt. Detta fält är annars ett bra sätt att testa felmeddelanden, eftersom vi vet hur en e-postadress ska vara utformad. De fält som var obligatoriska i dessa formulär var fälten för att beskriva sitt ärende. Detta kan man göra hur man vill, det finns inget rätt eller fel och därför kan inte webbplatsägaren skicka ut något meddelande om att något fel behöver åtgärdas.

 

Fredag

Under fredagens lektion gick vi igenom uppgifterna om felmeddelanden och Johan gav svar på frågor som hade dykt upp under veckan.

 

 

Glad påsk till er alla!🐣

/Emelie