 |
| Syntolkning: Bild på en matta av vitsippor. |
Efter påsklovet hade vi en kort vecka med Johan och Susanna
från Funka.
Onsdag
Under onsdagen hade vi lektion med Johan Kling, vår sista
lektion med honom. Vi började med att
prata om tillgänglighetsredogörelser och den uppgift vi skulle göra över
påsklovet. (Min uppgift publicerades här på bloggen innan detta inlägg)
Den 23 september 2018 trädde webbtillgänglighetsdirektivet i
kraft, vilket är ett EU-direktiv som handlar om digital tillgänglighet. Där
finns en del kriterier som ska följas. Beroende på när en webbplats skapades så
fick de olika lång tid på sig att tillgängliggöras. En ny hemsida som startade
efter 23 september 2018 skulle vara tillgänglig till 23 september 2019. Om webbsidan
däremot redan fanns när direktivet trädde i kraft så fick de två år på sig att
göra den tillgänglig. Mobilapplikationer skulle vara tillgängliga till 23 juni
2021.
Nu har alla dessa datum passerat, vilket innebär att alla
webbplatser inom den offentliga sektorn ska vara tillgängliga i största möjliga
mån. De ska ha en tillgänglighetsredogörelse där aktören redogör för de brister
som finns. Följande krav på tillgänglighetsredogörelser finns i
webbtillgänglighetsdirektivet:
·
Den ska vara i ett tillgängligt format. Exempel
på ett otillgängligt format kan vara ett otillgängligt PDF-dokument.
·
Den ska vara lätt att hitta.
·
Den ska finnas på en framträdande plats. Funkar rekommenderar
att placera den antingen i sidhuvudet eller i sidfoten. Det vanligaste är dock
att den finns i sidfoten. Antingen ska det finnas en länk direkt till redogörelsen,
eller ska den finnas under länken ”Om webbplatsen”. I appar finns inte sidhuvuden
och sidfötter på samma sätt. Då rekommenderar Funka att man ger användaren
möjlighet att läsa en tillgänglighetsredogörelse innan appen laddas ner.
De flesta webbplatser inom den offentliga sektorn har en
tillgänglighetsredogörelse, men Johan förklarade att kvalitén skiljer. Det
finns sex obligatoriska punkter i redogörelsen.
·
Vad? – Vilken webbplats gäller
redogörelsen och vilken organisation står bakom. Det ska också stå varför
redogörelsen finns, nämligen att det är ett krav i den svenska DOS-lagen (lagen
om tillgänglighet till digital offentlig service) att alla offentliga
webbplatser ska ha en sådan.
·
Kort status – I vilken omfattning lagen
om tillgänglighet uppfylls. Helt, delvis eller inte alls. Hittills har Johan
bara stött på webbplatser som delvis uppfyller kraven. För att vara helt
tillgänglig måste man kvalitetsgranska alla sidor som publiceras varje dag,
vilket är ett väldigt stort arbete.
·
Otillgängligt innehåll – Detta ska
beskrivas så att användaren kan förstå. Man ska beskriva vad som är
otillgängligt, på vilket sätt och hur det påverkar användarna. Man ska också
skriva om det finns någon plan för att åtgärda bristerna , antingen enskilt för
varje brist eller en generell plan för alla brister. Enkel svenska är att
föredra menar Funka. Om det finns alternativ till det otillgängliga innehållet ska
det framkomma. Exempelvis om en e-tjänst inte är tillgänglig så kan det finnas
en PDF-blankett med samma innehåll.
·
Om utlåtandet – Här ska det stå när den senaste granskningen gjordes. Det ska också stå när
redogörelsen senast uppdaterades, samt hur webbplatsen har granskats. Det kan handla om
att man gjort en självskattning eller tagit hjälp av tillgänglighetsexperter.
Förhoppningsvis uppdateras redogörelsen i takt med att brister åtgärdas.
Den ska uppdateras minst en gång om året.
·
Återkopplingsfunktion – Genom återkopplingen
kan användarna hjälpa aktörerna att bli bättre, men då krävs en funktion för
att komma i kontakt med aktören. Användaren ska ha möjlighet att vara anonym,
därför räcker det inte med en e-postadress - det måste finnas någon typ av
formulär. Funka rekommenderar att det finns kontaktuppgifter till de som är
ansvariga för tillgängligheten på webbplatsen samt information om hur de
hanterar återkopplingen, exempelvis inom hur många dagar man kan vänta sig
svar.
·
Klagomålsfunktion – Om man inte är nöjd
med responsen man får på sin återkoppling, eller inte får någon alls, så kan
man skicka in ett klagomål till DIGG (Sveriges tillsynsmyndighet). I
redogörelsen ska det finnas en länk till DIGG. Man ska dock alltid gå via
webbplatsägaren först.
Företag kan anlita Funka för att få hjälp med sin tillgänglighetsredogörelse,
men Funka skriver inte den åt dem. De kan hjälpa till att beskriva brister och
förklara vilka användargrupper som påverkas, men de kan inte göra
återkopplingsfunktionen eller bestämma när olika brister ska vara åtgärdade –
det måste aktören avgöra själv.
Funka är ett brett företag med många olika områden. De blir
ofta anlitade av aktörer för att granska deras webbplatser och se hur väl de
uppfyller lagkraven om tillgänglighet. De håller även utbildningar, antingen
öppna där alla är välkomna, eller specifika för vissa kunder. På sista tiden
har de också börjat spela in sina utbildningar så man kan ta del av dem i
efterhand. Många aktörer har bristande kunskap om tillgänglighet, genom de
inspelade utbildningarna hoppas Funka kunna nå så många som möjligt runtom i
Europa. De jobbar mycket med användartestning. De fixar PDF-dokument till
företag som inte har tid, pengar eller resurser att ordna
tillgänglighetsbrister och helt enkelt behöver hjälp. De har en del forsknings-
och innovationsprojekt, det handlar om att de får uppdrag från exempelvis EU-konventionen,
de delar ut forskningspengar för att Funka ska undersöka ett ämne djupare.
Dessa projekt kan Funka sedan använda för att hjälpa kunderna. Projekten kan
vara till nytta för många, men ofta kan Funka inte genomföra dem om och om igen
för varje kund, de behöver ekonomiskt stöd.
Fler framgångskriterier inom WCAG (Web Content
Accessibility Guidelines)
Under lektionen pratade vi om ytterligare några framgångskriterier
inom WCAG, detta var kriterier som Johan hade tänkt att vi skulle hinna göra
uppgifter på, men eftersom tiden inte räckte till så gick han igenom dem
muntligt med oss.
HTML och CSS
HTML är en standard som ska följas. Följs den inte så går
det inte att utveckla fungerande hjälpmedel, exempelvis skärmläsare. I WCAG
finns fyra fel som programmerarna inte får göra.
·
De får inte glömma att påbörja och avsluta ett element
på samma sätt. Har man en huvudrubrik ska det stå H1 innan rubriken, men också
efter rubriken.
·
Man får inte duplicera ID:t på ett element. Exempelvis
att två fält i ett formulär heter samma sak i koden. Webbplatsägaren behöver
kunna hämta värdet i de olika fälten. Ska de skicka ett mejl till en kund kan
det vara bra att hämta det kunden skrivit i fältet för namn. Om det då finns
två fält med ID:t Name så vet man inte vilket som stämmer.
·
Man får inte heller duplicera andra attribut på
ett element, exempelvis att en bild har två alternativtexter. Då vet den som är
blind och tar hjälp av alttexten inte vilken det är som stämmer.
·
Det sista felet är att man placerar olika element
fel, det finns regler för vilka element som får förekomma i andra element.
Tangentbordsnavigering
Tangentbordsnavigering innehåller två separata punkter. Den
första punkten handlar om att allt innehåll ska kunna nås med hjälp av
tangentbordet. För att testa detta kan man samarbeta en seende och en synskadad
person. Vi som använder skärmläsare är vana vid att navigera med hjälp av
tangentbord, men finns det något innehåll som inte går att få tangentbordsfokus
på så kommer vi inte märka det eftersom vi inte ser det.
Den andra punkten handlar om att tabbordningen ska vara
logisk. Personer som navigerar med hjälp av tangentbord tar sig fram med hjälp
av Tabb-tangenten. Man trycker Tabb för att hoppa framåt och Shift+Tabb för att
hoppa bakåt. Skärmläsare har många funktioner som gör det enklare att navigera,
men Tabb-tangenten är en väsentlig del. Tabbordningen ska alltså vara logisk,
innehållet ska presenteras i rätt ordning, även för den som inte kan använda en
datormus.
Landmarks
I källkoden kan programmeraren definiera vad som är
sidhuvud, huvudyta och sidfot, vilket är olika landmarks. Elementet för
sidhuvud heter Header, huvudytan heter Main och sidfoten heter Footer. Det
finns andra vanliga element, ett navigationsområde, som brukar finnas i
överkant på webbplatser, heter Nav i källkoden. Landmarks gör det möjligt för
exempelvis skärmläsaranvändare att hoppa mellan de olika delarna på sidan och
då blir det lättare att navigera. För att komma till landmarks trycker man R om
man använder skärmläsaren JAWS.
Sidtitlar
Alla sidor på en webbplats ska ha en unik och relevant
sidtitel. Det innebär exempelvis ”Bygglov – Ystads kommun” Titeln ska alltså
kort beskriva sidans innehåll samt nämna aktörens namn. Huvudrubriken på sidan ska gärna
överensstämma med sidtiteln. Titeln är det som läses upp först när man som
skärmläsaranvändare besöker en sida. Det är även titeln som syns när man markerar
en sida som favorit. Har man många flikar öppna i en webbläsare så är det
titlarna som syns på de olika flikarna. Det används också av sökmotorer för att
beskriva sidor, exempelvis sökresultaten på Google.
Johan förklarade att webbplatser generellt varit bra på att
lägga in sidtitlar, men nu har det blivit populärt att använda Single Page
Application (SPA) vilket skapar problem. Vanligtvis när man besöker en
webbplats så skickas man till en ny sida varje gång man klickar sig vidare från
startsidan. SPA innebär att det inte blir en ny sida, utan det är bara en del
av föregående sida som uppdateras. Trots detta måste programmeraren komma ihåg
att varje undersida ändå behöver ha en unik sidtitel. Även om det rent tekniskt
bara är en sida så är det många olika sidor för den som besöker webbplatsen.
Fredag
På fredagen hade vi lektion med Susanna från Funka. Vi
började med att gå igenom våra uppgifter om tillgänglighetsredogörelser, de av
oss som inte hade gjort det under onsdagen. Vi började prata om rubrikstruktur,
eftersom flera av de fel vi hade hittat handlade om att rubriker var på fel nivå.
En huvudrubrik ska vara på nivå 1, en underrubrik på nivå 2 och så vidare.
Stämmer inte detta så blir det otydligt för exempelvis skärmläsaranvändare. Om
en huvudrubrik är kodad på nivå 2 så tror vi att det finns innehåll ovanför det
som vi har missat eller inte kan ta del av, när det i själva verket är
huvudrubriken som är fel kodad.
Susanna förklarade att anledningen till att rubriker blir
fel kodade ofta är att formgivarna designar en hemsida utifrån vad de tycker
passar rent visuellt. Därefter gör programmerarna sitt arbete utifrån den
designen. Utgår de bara från det visuella och struntar i koden så skapar de
problem för många användare. Det är viktigt att formgivaren som designar,
utvecklaren som kopplar ihop designen med koden och webbredaktören har kunskap
om webbtillgänglighet. Annars kan det bli fel i alla led. Rubrikstrukturen är viktig
för alla användare, både visuellt och för de som använder skärmläsare, för att
det ska vara tydligt när man navigerar på sidan.
Formgivarnas behov av kunskap om webbtillgänglighet
Vi pratade vidare om varför formgivare som ritar webbplatser
behöver ha kunskap om webbtillgänglighet. Susanna förklarade att det finns
mycket inom webbtillgänglighet som inte är tekniska saker. Exempelvis får
länkar inte bara urskiljas med färg, utan måste vara exempelvis understrukna
eller kursiverade. Detta är en designfråga som formgivaren behöver ha koll på. Om
man är färgblind, har nedsatt syn eller kognitiv nedsättning så är det svårt
att förstå att det är en länk om den bara urskiljer sig med en skiftande färg. Länkar
och knappar ska inte vara placerade för tätt, om man använder en liten skärm
eller har motoriska svårigheter så är det svårt att klicka rätt. Kontrast är
också en designfråga, det ska vara bra kontrast mellan text och bakgrund.
Rubrikstrukturen är inte bara viktig för
skärmläsaranvändare, även för seende personer är det viktigt att rubrikerna har
en tydlig och logisk struktur. Detta kallas för formatering. Formatering med
olika rubriknivåer, en ingress , olika stycken och lagom radlängd underlättar
läsningen väldigt mycket. Typsnitt, radavstånd och storlek på text spelar också
stor roll för läsbarheten. Att läsa texter som inte är formaterade är svårt för
alla, men har man exempelvis dyslexi så blir det nästan omöjligt.
Susanna påpekade att det finns specifika checklistor för
olika roller, listan för formgivare innehåller mellan 20 och 30 punkter. Funka
har speciella utbildningar som riktar sig till just formgivare.
Praktik
Vi pratade en del med Susanna om vår praktik som börjar
måndagen den 2 maj. Planerna för praktiken har ändrats en del, Funkas ursprungliga
tanke var att dela upp klassen i grupper och låta varje grupp praktisera hos
varsin kommun. Kommunerna däremot vill ha alla våra olika perspektiv, och de
får helt enkelt bestämma. Därför ska vi granska enskilda delar hos kommunerna,
exempelvis videor och dokument. Alla vi i klassen kommer alltså arbeta med alla
kommuner, men vi kommer fokusera lite extra på en eller två av dem, där vi ska
försöka få en helhetsbild av webbplatsens tillgänglighet. De kommuner vi ska
arbeta med är Malmö, Mölndal, Göteborg och Mjölby.
Praktiken kommer börja med en introduktion, vi får träffa
kommunerna och berätta vilka vi är. Därefter kommer vi få en tydlig instruktion
av uppgiften. Själva granskningen kommer hålla på i en vecka, under tiden
kommer det finnas öppna Zoom-rum där vi i klassen kan prata med varandra. Under
tiden finns möjlighet att ta kontakt med våra lärare från Funka om/när vi
behöver hjälp. Vi kommer jobba i par, eftersom vi alla har olika
förutsättningar så kan vi granska olika saker. Vi ska använda de system vi
känner oss bekväma med och sedan får vi berätta för kommunerna vilka operativsystem,
webbläsare , eventuella hjälpmedel med mera som används i granskningen. Om man
däremot gör en betald granskning behöver man testa med flera olika webbläsare,
eftersom webbplatser fungerar olika i olika webbläsare.
Efter själva granskningen skickar vi en skriftlig rapport
till Funka. Vi kommer få en mall som visar vad vi ska testa och hur vi ska
rapportera det. Trots att vi samarbetar två och två ska vi skriva individuella
rapporter med de tester vi själva genomfört. Samarbetet är till för att bolla
tankar och idéer, samt att diskutera olika saker vi kommer fram till. Sedan
lägger vi ihop det till en hel rapport som vi skickar till kommunerna.
När de fått några dagar på sig att läsa det så ska vi ha ett
möte för att presentera muntligt. Det sista steget är att vi får återkoppling
från kommunerna, där de berättar vad som fungerat bra, vad som fungerat mindre
bra och vad de lärt sig. Detta är viktigt för oss användarexperter inför
kommande granskningar.
CAPTCHA
Jag ställd en fråga om CAPTCHA, vilket jag nämner i min
uppsats om autism som snart kommer publiceras här på bloggen. CAPTCHA är alltså
ett test som ibland dyker upp på webbsidor där användaren ska bevisa att man
inte är en robot. Det brukar handla om att det syns ett antal bilder och
användaren ska markera alla bilder som innehåller exempelvis ett
övergångsställe. Detta är svårt att genomföra för många användare, bland annat
för oss med nedsatt syn. Istället för att använda bilder så kan en fråga
användas, exempelvis ”Vad är 1 plus 1?”. En dator kan känna igen ett +-tecken,
men den kan inte svara på frågan om plus står med bokstäver.
Susanna berättade att robotar är ett stort problem, men
genom att använda CAPTCHA så använder man besökarna som en lösning på
problemet, trots att de inte orsakat det. Problemet borde lösas tekniskt, inte
genom användarna. Det är mycket bättre att ha ett ordentligt filter.
Detta inlägg kom upp lite sent, så vi hörs snart igen med
ett inlägg om denna veckas lektioner 😊
/Emelie
Kommentarer
Skicka en kommentar