Tillgänglighet på webbplatser Göteborgs Universitet – föreskrifter för

Tillgänglighet på webbplatser Göteborgs Universitet –
föreskrifter för webbdesigners och webbutvecklare
Version: 2.0
Datum: 2012-10-25
Inledning
Detta dokument beskriver vilka krav som ställs på den gränssnittskod (HTML/XHTML, CSS,
JavaScript/ECMAScript, RSS/XML) som används för externa webblösningar inom Göteborgs
Universitet. Dokumentet innehåller även beskrivningar av hur respektive kodtyp kan valideras
och kvalitetskontrolleras. Dessutom finns en bilaga med krav på grundkonstruktion som utgår
från WCAG och e-delegationens riktlinjer (se bilaga 1).
Målgruppen är i första hand webbdesigners och webbutvecklare som ska kvalitetskontrollera
sin leverans. Goda kunskaper om webbutveckling, särskilt gränssnittsprogrammering,
förutsätts.
Tillgänglighetsmål
All information och alla tjänster som publiceras på Göteborgs universitets externa
webbplatser ska vara tillgänglig och användbar för alla besökare, oavsett om de har något
funktionshinder och oavsett vilken webbläsare eller vilket operativsystem de använder
(under förutsättning att deras webbläsare uppfyller vissa grundläggande krav, se avsnittet
"Krav på webbläsare").
I detta dokument används hädanefter ”webblösning” som ett samlingsbegrepp för
information och tjänster som är avsedda för webben.
Krav på och kontroll av gränssnittskod
Ett mycket viktigt led i kvalitetssäkringen av all gränssnittsrelaterad kod som används för
Göteborgs Universitets webblösningar är att säkerställa att den är korrekt skriven, det vill
säga följer de specifikationer som finns och är skriven enligt god programmeringssed. För
att tillgänglighetsmålet ska kunna uppnås är det nödvändigt att riktlinjerna i detta dokument
följs av dig som är delaktig i att utveckla webblösningar, och att du använder riktlinjerna
från varje projekts början. Att i efterhand göra en webblösning tillgänglig blir med få
undantag mycket dyrare än att göra rätt från början.
Alla Göteborgs Universitets webblösningar ska följa gällande riktlinjer för tillgänglighet
och användbarhet. Det viktigaste dokumentet att följa är World Wide Web Consortiums
(W3C) Web Content Accessibility Guidelines (WCAG) 2.0, finns på www.w3c.org. I edelegationens Riktlinjer för webbutveckling så är också den första riktlinjen R1, Utgå från
WCAG 2.0 nivå AA. Även den resterade110 riktlinjerna är viktiga att ta hänsyn till. Dessa
finns på www.webbriktlinjer.se.
Syftet med föreskrifterna är att säkerställa att alla webblösningar är tillgängligt
konstruerade, robusta och framtidssäkra, och därmed fungerar med alla typer av webbläsare
och hjälpmedel för funktionshindrade.
Uppmärkningskod (HTML/XHTML)
Den uppmärkningskod som används för att strukturera dokument och ge innehåll betydelse
ska validera enligt XHTML 1.0 Strict. På www.gu.se används för närvarande XHTML 1.0
Transitional för att minska antalet valideringsfel orsakade av gammalt innehåll.
Nyutvecklad kod ska valideras mot XHTML 1.0 Strict.
Det finns flera verktyg som hjälper dig som utvecklare att kvalitetssäkra uppmärkningskod.
Ett allmänt råd är att använda verktygen kontinuerligt under utvecklingen. Annars finns risk
att delar av webblösningen blir baserad på och beroende av felaktig uppmärkningskod.
W3C:s tjänst för validering av uppmärkningskod
HTML validerar du med hjälp av W3C:s tjänst för validering av uppmärkningskod
(hädanefter kallad HTML-valideraren), http://validator.w3.org/.
I HTML-validerarens webbaserade gränssnitt kan du ange vilken kod som ska valideras på
tre olika sätt:
• Genom att ange ett dokuments URL
• Genom att ladda upp en fil
• Genom att klistra in kod i ett textfält
Web Developer Extension
För webbläsaren Firefox finns tillägget Web Developer Extension som har funktioner för att
automatiskt anropa HTML-valideraren. För att validera ett dokument öppnar du det i
webbläsaren och väljer ”Tools/Validate HTML” från Web Developer Extensions
verktygsrad. För att detta ska fungera måste dokumentet finnas publikt åtkomligt och inte
vara skyddat av till exempel inloggning.
För att validera dokument som inte är publikt åtkomliga kan du i stället välja
”Tools/Validate Local HTML”. Då skickas koden, inte sidans URL, till HTML- valideraren.
HTML Validator Extension
Ett annat tillägg för Firefox är HTML Validator Extension. När tillägget är installerat gör
det en kvalitetskontroll av varje dokument du laddar i webbläsaren. Det finns två olika typer
av validering i HTML Validator Extension – HTML Tidy- respektive OpenSP- baserad. För
att få samma resultat som W3C:s HTML-validerar ska HTML Validator Extension vara
inställd på att använda enbart ”SGML parser”.
Stilmallskod (CSS)
För att styra presentationen av webblösningar ska du använda Cascading Style Sheets
(CSS) – stilmallar på svenska. CSS-koden ska validera enligt vald nivå, till exempel CSS 2,
2.1 eller 3.
Undantag från valideringskravet kan göras för CSS-regler som är avsedda att korrigera
felaktigt beteende i Internet Explorer för Windows, under förutsättning att så kallade
Conditional Comments används för att säkerställa att endast Internet Explorer applicerar
dessa regler.
Undantag kan också göras för leverantörsspecifika tillägg (vendor specific extensions) som
följer W3C:s regler för hur sådana egenskaper ska namnges.
I båda fallen är det lämpligt att skriva förklarande kommentarer i CSS-koden, så att det blir
tydligt för andra utvecklare varför man har använt CSS som ger valideringsfel.
All CSS-kod ska laddas från externa filer.
Precis som för HTML finns flera verktyg som hjälper dig som utvecklare att kvalitetssäkra
CSS.
W3C:s tjänst för validering av stilmallskod
CSS validerar du med hjälp av W3C:s tjänst för validering av stilmallskod (hädanefter
kallad CSS-valideraren), http://jigsaw.w3.org/css-validator/.
På samma sätt som i HTML-valideraren låter CSS-validerarens webbaserade gränssnitt dig
ange vilken kod som ska valideras på tre olika sätt:
• Genom att ange ett dokuments URL
• Genom att ladda upp en fil
• Genom att klistra in kod i ett textfält
Observera att CSS-valideraren i dagsläget är förinställd på att validera mot CSS 3specifikationen. Om din CSS-kod använder selektorer eller egenskaper som definieras i en
tidigare version av CSS måste du manuellt ange vilken version CSS-valideraren ska
använda. Val för detta finns i CSS-validerarens utökade gränssnitt.
Web Developer Extension
Web Developer Extension kan hjälpa till med CSS-validering på samma sätt som med
HTML-validering. För att validera den CSS ett dokument innehåller eller laddar från
externa filer öppnar du dokumentet i webbläsaren och väljer ”Tools/Validate CSS” eller
”Tools/Validate Local CSS” från Web Developer Extensions verktygsrad.
Firebug
Ett annat verktyg som är mycket bra för att undersöka hur olika delar av ett dokument
påverkas av den CSS man använder är Firefoxtillägget Firebug. Utförlig information om
hur man använder Firebug för detta finns i CSS Development på Firebugs webbplats.
JavaScript
Att validera JavaScript är inte lika rakt på sak som att validera HTML eller CSS. Det finns
verktyg som kontrollerar att man har använt korrekt syntax, men inget som verifierar att alla
metoder och objekt finns i W3C:s DOM (Document Object Model, definierar hur objekt i
HTML-dokument exponeras för skript) eller hur väl de stöds av olika webbläsare.
Därför är funktionstester i de webbläsare som finns specificerade i avsnittet ”Krav på
webbläsare” mycket viktiga.
Notera att grundläggande funktionalitet som navigering och enkel sökning inte får vara
beroende av JavaScript. Därför är det mycket viktigt att avaktivera JavaScript och därefter
kontrollera att det fortfarande går att använda webblösningen, om än inte på exakt samma
sätt.
All användning av JavaScript ska ske enligt principen för Progressive enhancement och där
det är relevant använda sig av WAI-ARIA för att säkerställa att all funktionalitet är
användbar med hjälpmedel som till exempel skärmläsare.
JSLint, The JavaScript Verifier
JSLint består av ett textinmatningsfält som du klistrar in koden som ska verifieras i. Det går
att göra vissa inställningar för att reglera nivån på de varningar som genereras. Varningarna
kan upplevas som mycket strikta eftersom de rapporterar viss syntax som är tillåten som
potentiella källor till problem. Det finns dock anledningar till det (se dokumentation på
JSLints webbplats), så målet bör vara att åtgärda alla rapporterade problem.
JavaScript Lint
JavaScript Lint är samma typ av verktyg som JSLint, och har även det ett
textinmatningsfält. JavaScript Lint finns även som ett fristående program.
Firebug
Firebug innehåller en utmärkt JavaScript-debugger och visar eventuella JavaScriptfel i en
konsoll. Mer information om hur man använder Firebug för detta finns i JavaScript
Debugging.
Funktionstest i webbläsare
Även om inget av verktygen rapporterar några problem är det inte självklart att skriptet
kommer att fungera i alla webbläsare. Därför måste du komplettera syntaxverifieringen med
funktionstest i de webbläsare som är aktuella enligt avsnittet ”Krav på webbläsare”.
Annan teknik, till exempel Adobe Flash
Om det är väl motiverat kan även annan teknik än HTML och CSS, till exempel Adobe
Flash, användas. Det finns dock en del viktiga saker att tänka på.
• Använd inte Flash eller andra format som kräver insticksprogram för kritisk
funktionalitet som navigering eller formulärhantering.
•
Går problemet att lösa med HTML, CSS och JavaScript? I så fall är det att föredra.
•
Det ska alltid finnas alternativ för besökare vars webbläsare inte har stöd för
tekniken.
•
Flash ska precis som JavaScript implementeras enligt principen för Progressive
enhancement, till exempel med hjälp av swfobject.
•
Om Flash används ska själva innehållet göras så tillgängligt som möjligt med hjälp
av det tillgänglighetsstöd som finns i utvecklingsverktyget för Flash. Var dock
medveten om att Flash i dagsläget inte stöds av alla hjälpmedel.
Nyhetsflöden (RSS/XML)
Den kod (RSS i XML-format) som används för att tillhandahålla nyhetsflöden ska validera
enligt vald standard (RSS 1.0 eller RSS 2.0).
För nyhetsflöden rekommenderas formatet RSS 2.0, men det går även att använda RSS1.0.
För att göra det lättare för besökare att hitta och prenumerera på nyhetsflöden bör länkar till
sådana finnas i varje HTML-dokuments head-element och följa syntaxen för RSS
Autodiscovery. Det gör det möjligt för webbläsare att visa för användaren att webbplatsen
har ett RSS-flöde.
W3C:s tjänst för validering av nyhetsflöden
Nyhetsflöden validerar du med hjälp av W3C:s tjänst för validering av RSS och Atom,
http://validator.w3.org/feed/.
I flödesvaliderarens webbaserade gränssnitt kan du ange vilken kod som ska valideras på
två olika sätt:
•
Genom att ange en URL
•
Genom att klistra in kod i ett textfält
Teknisk tillgänglighet
Här beskrivs hur du gör en grundläggande kontroll av teknisk tillgänglighet. Kontrollen
berör endast i begränsad omfattning hur tillgängligt skrivet, organiserat eller presenterat
själva innehållet är. Den delen av tillgänglighetsarbetet är i huvudsak en fråga för
interaktionsdesigners, grafiska formgivare och redaktörer.
I bilaga 1, finns krav för grundkonstruktion av webbplats, där finns krav som utgår från
riktlinjerna som beskrivs under rubriken ”Krav på och kontroll av gränssnittskod”.
Det är mycket viktigt att vara medveten om att det inte går att göra någon fullständig
kontroll av tillgänglighet med hjälp av automatiserade verktyg. Anledningen är att
tillgänglighet handlar om hur användbart ett dokument eller en webbplats är för människor.
Därför är det inte möjligt att på ett tillfredsställande sätt utföra sådana kontroller utan
medverkan av mänsklig expertis.
Onlinetjänster
Det finns ett antal onlinetjänster som kan fungera som stöd vid utvärderingen.
•
•
•
NetRelations Inspector
Truwex Online
HiSoftware Cynthia Says
Att använda dessa verktyg kräver inga avancerade förkunskaper, men för att utvärdera
resultaten på ett korrekt sätt krävs expertkunskaper inom tillgänglighet.
Web Developer Extension
Web Developer Extension, som redan nämnts flera gånger, har många funktioner som
underlättar utvärdering av tillgänglighet. I granskningsförfarandet nedan hänvisas i många
fall till dem.
Granskningsförfarande
Var medveten om att detta inte är en uttömmande granskning. Tillgänglighetsproblem kan
finnas även om inga problem noteras, men de problem som orsakar störst olägenhet bör
fångas upp av detta.
1. Validera uppmärkningskod med hjälp av W3C:s HTML-validerare,
http://validator.w3.org/.
2. Validera stilmallskod med hjälp av W3C:s CSS-validerare, http://jigsaw.w3.org/cssvalidator/.
3. Använd inga ramar (frame- eller iframe-element).
4. Kontrollera att alternativtext för bilder används på rätt sätt med hjälp av Web
Developer Extensions funktion ”Images/Replace Images With Alt Attributes” samt
genom att kontrollera källkoden.
•
För dekorativa bilder ska alt-attributet innehålla en tom sträng (alt="").
•
Om bilden innehåller text ska alt-attributet innehålla motsvarande text.
•
Om bilden är länkad ska alt-attributet beskriva vart länken leder eller vilken
funktion den har. Om länken även innehåller beskrivande text kan bilden ha
tom alt-text.
5. Stäng av JavaScript och kontrollera att webblösningen fortfarande går att använda.
Detta gör du enklast genom att välja ”Disable/Disable JavaScript/All JavaScript”
från Web Developer Extensions verktygsrad.
6. . Öka textstorleken i webbläsaren. Dels ska textstorleken faktiskt gå att ändra i alla
webbläsare, dels ska inget innehåll försvinna eller bli oläsligt när textstorleken har
ökats inom rimliga gränser. Designen bör klara att textstorleken ökas till 200 %
enligt WCAG 2.0.
7. Kontrollera att riktiga rubriker (h1-h6-element) används och används på rätt sätt
genom att välja ”Information/View Document Outline” från Web Developer
Extensions verktygsrad. Resultatet ska vara en tydlig dokumentstruktur liknande den
man får i Microsoft Word genom att välja "Visa/Disposition". Varje sida ska ha en
huvudrubrik (h1), och inga rubriknivåer får hoppas över. Rubriker av nivå 2 kan få
finnas före huvudrubriken om de används för att förtydliga vad olika delar av sidan
innehåller, till exempel ”Huvudnavigering” eller ”Undernavigering”.
8. Stäng av CSS och kontrollera att webblösningen fortfarande går att använda. Detta gör
du enklast genom att välja ”CSS/Disable Styles/All Styles” från Web. Developer
Extensions verktygsrad.
9. Kontrollera färgkontraster för text. Med hjälp av WCAG Contrast checker kan man
snabbt få en översikt av eventuella problem. Andra verktyg som rekommenderas är
Colour Contrast Check, ett onlineverktyg som gör det enkelt att prova ut fungerande
färgkombinationer med hjälp av skjutreglage, och Contrast Analyser, som är ett
fristående program för Windows och Mac OS X.
10. Lägg undan musen och kontrollera att det går att navigera på webblösningen samt
använda den eller de funktioner som tillhandahålls enbart med hjälp av
tangentbordet. Kontrollera också att det tydligt framgår vilket element på sidan som
har fokus.
11. Datatabeller ska vara korrekt kodade. HTML-tabeller ska endast användas för att
presentera information i tabellformat. För att de ska bli tillgängliga krävs att de är
kodade på rätt sätt och använder de tillgänglighetsrelaterade element och attribut som
finns i HTML. Detta kontrollerar du genom att välja "Information/Display Table
Information" i Web Developer Extension. Rad- och kolumnrubriker ska då få en text
som säger att de är "Heading for this row" eller "Heading for this column".
12. Formulär ska vara uppbyggda på rätt sätt. Till exempel ska alla inmatningsfält ha en
förklarande fältetikett, och den ska vara ihopkopplad med fältet. ”Forms/View Form
Information” i Web Developer Extension underlättar vid denna kontroll. I tabellen
”Elements” listas de inmatningsfält som finns i respektive formulär, och i kolumnen
”Label” visas respektive fälts etikett.
Krav på webbläsare
För full funktionalitet är det rimligt att kräva att webbläsare har stöd för följande:
• HTML 4.01/XHTML 1.0
• CSS 2.1
• JavaScript + DOM Level 2
Dock ska stöd för HTML 4.01 vara tillräckligt för att kunna ta del av all information och
använda de viktigaste tjänsterna. För webbläsare som saknar stöd för CSS och/eller
JavaScript/DOM Level 2 finns inga krav på bibehållen presentation eller kompletterande
gränssnittsfunktionalitet. Däremot ska grundfunktionalitet finnas. Ingen webbläsare får
medvetet utestängas samma sak i olika webbläsare. Vissa skillnader i utseende är
ofrånkomliga och helt i linje med webbens heterogenitet.
Exempel på webbläsare
Att namnge specifika webbläsare och versioner av dem är vanskligt i ett dokument som ska
leva vidare under en relativt lång tidsperiod. Dock går det att säga vilka webbläsare som i
skrivande stund (kvartal 2, 2010) anses ha tillräckligt bra stöd för webbstandarder för att
uppnå full funktionalitet.
Man kan dela in webbläsare i olika familjer beroende på vilken renderingsmotor de
använder. Följande familjer, med exempel på webbläsare, är i dagsläget tillräckligt spridda
och moderna för att de ska vara relevanta att testa i:
• Gecko (Firefox, Camino, Flock)
• WebCore (Safari, Chrome, OmniWeb, Shiira)
• Presto (Opera)
• Trident (Internet Explorer för Windows)
När dessa renderingsmotorer utvecklas eller nya tillkommer behöver en professionell
bedömning göras för att avgöra om de ska ingå i testproceduren. I dagsläget ska testning
utföras minst i följande webbläsare från angiven version och senare:
• Firefox 3.6 och senare
• Safari 3.0 och senare
• Chrome
• Internet Explorer version 7 och senare
Godkända tester i dessa webbläsare innebär med stor sannolikhet att webblösningen
fungerar tillfredsställande även i andra webbläsare inom samma familj. Ett viktigt undantag
gäller dock för Internet Explorer. Det som fungerar i Internet Explorer 7 kan inte utan
vidare antas fungera eller se likadant ut i nyare versioner.
För äldre versioner av dessa webbläsare gäller generellt att de antingen visar gränssnittet
med vissa skönhetsfel eller att de visar gränssnittet helt utan extern form, det vill säga enbart
baserat på sina egna fördefinierade stilmallar.
Nyare versioner av de nämnda webbläsarna, eller helt nya webbläsare som inte nämns här,
bör inte framkalla problem såvida inte deras stöd för webbstandarder försämras.
Nedlagda webbläsare som Netscape 4 och Internet Explorer för Mac OS når inte upp till
den nivå som krävs för full funktionalitet och fullgod presentation. Därför blir deras
funktionalitet begränsad till den som uppnås med enbart HTML-lagret.
Bedömning av problem
Eventuella problem som uppstår vid testning i webbläsare kan delas in i två grupper –
skönhetsfel och funktionsfel – där funktionsfel anses vara betydligt allvarligare.
Funktionsfel
Med funktionsfel avses problem som leder till att den som använder den aktuella
webbläsaren inte på ett tillfredsställande sätt kan ta del av all information eller utnyttja all
funktionalitet som webbplatsen tillhandahåller. Denna typ av fel ska åtgärdas.
Skönhetsfel
Med skönhetsfel avses problem som leder till att webbplatsens presentation i den aktuella
webbläsaren inte är optimal. Skönhetsfel som innebär försämrad läsbarhet eller
tillgänglighet ska åtgärdas. Övriga skönhetsfel bör åtgärdas när så är möjligt.
Bilaga 1- Krav på grundkonstruktion och grundläggande
design – före leverans
Nedan följer krav på grundkonstruktion och grundläggande design. Riktlinjer utöver detta från
WCAG och Riktlinjer för webbutveckling ska följas där de är applicerbara. Hänvisning till
riktlinjer avser riktlinjer för webbutveckling (webbriktlinjer.se). Dessa markeras med R följt av
riktlinjens nummer. I vissa fall hänvisas till WCAGs riktlinjer de finns på www.w3c.org.
Struktur och navigation
Startsida
•
Startsidan ska tydligt visa att det är Göteborgs Universitet
som är avsändare.
•
Startsidan ska vägleda besökaren in till webbplatsens olika
delar.
•
Använd inte animeringar och onödiga introduktionssidor
som visas innan webbplatsens startsida.
•
Använd startsidan för att tydliggöra syftet med
webbplatsen.
•
Sidan ska kallas startsida.
•
Startsidan ska vara åtkomlig från alla sidor på
webbplatsen.
R30
Sökningen ska vara åtkomlig från alla sidor. WCAG 2.4.5
Första länk på sidan ska vara ”Till innehållet”, som ska vara en
länk till huvudrubriken på sidan. R75
Accesskey – ska användas för att lägga in kortkommandon, i
riktlinje R68 anges förslag på kortkommandon. Lägg accesskey
på de befintliga länkarna, inte som en rad länkar i början av
sidan.
Länkar och tydlig navigering
Var konsekvent i navigation, struktur och utformning
• Låt menyns placering vara densamma och fungera
likadant på hela webbplatsen.
•
Undvik att placera viktigt innehåll långt till höger på
sidan.
Undvik helt att lägga innehåll till höger om
huvudspalten när sidan ligger långt ner i strukturen.
R 29
•
Kommentar
Struktur och navigation
Titeln på sidan ska hjälpa användaren att veta vart hon/han
befinner sig.
Formen: Unika sidan – (avdelning/meny)- Göteborgs
universitet WCAG 2.4.2
Hjälp användarna förstå var de är på webbplatsen
Detta kan göras på flera sätt, dels visuellt för presentationen
på bildskärmen, dels tekniskt för användare med hjälpmedel.
•
Det ska finnas en Länkstig (smullist).
•
Det ska framgå visuellt vart användaren befinner sig,
genom att det syns tydligt vilken länk i huvudmenyn som
är vald, och vilken länk i undermenyn som är aktiv. Detta
kan bland annat göras genom annan bakgrundsfärg för
aktiva länkar.
•
Visuell tydlighet av nivå i navigeringen kan åstadkommas
med indrag och/eller markeringar i färg, form eller
kontrast. Använd inte enbart färg.
•
Använd punktlistor för att bygga upp
navigeringsnivåerna.
•
Var konsekvent i formuleringen av rubriker och
länktexter. Samma ordval som i menyn eller textlänken
bör återkomma i den länkade sidans rubrik.
R27
Länklistor
När flera länkar ligger grupperade ska dessa ligga i en lista (UL).
Om navigering har nivåer som fälls ut ska dessa ligga i nästlade
listor. WCAG 2.4.1
När länkar läggs under varandra är det viktigt att det framgår
visuellt tydligt när en länk börjar och slutar, så att inte raderna
med länkar flyter ihop. Särskilt viktigt när länkar radbryts.
När länkar placeras på en rad ska det finnas en visuell
avgränsning. Denna placeras som bakgrundsbild.
När undermenyer i vänstermeny visas är det viktigt att det
framgår tydligt, vad som är undernivå.
se även R34
Kommentar
Struktur och navigation
Det ska tydligt framgå vad som är klickbart. Använd olika
färger för besökta och icke-besökta länkar, men det måste
framgå på något mer sätt vad som är länkat. Exempelvis
genom en symbol som placeras som en bakgrundsbild före
länkar eller genom understrukna länktexter. Det är viktigt att
inte enbart färg visar vad som är länk. Användning av
länkutseende ska vara konsekvent. R34
Öka storleken på klickbara ytor, genom att lägga till
innermarginaler (padding) runt länkelement i den klickbara
ytan. R34
Tangentbordstyrning ska stödjas fullt ut. Användare som inte
använder sig av muspekare för att navigera ska kunna använda
tab tangent eller pil tangent (skärmläsare för gravt synskadade)
för att navigera på webbsidor. WCAG 2.1.1, 2.1.2, 2.4
Länkar ska ändra utseende när användaren pekar på länken
och när länken har tabbfokus. Gör en tydlig förändring av
länken som är lätt att se även för synsvaga. WCAG 2.4.7 R34.
Det ska framgå om länkar öppnas i nytt fönster, i textform
eller med en symbol med alternativtext (alt=”Nytt fönster”).
Symbolen får inte vara en bakgrundsbild utan bilden ska ingå i
länktaggen.
Detta gäller även för dokument, där ska även framgå format
och storlek. Formattext kan ersättas av en symbol med
alternativtext exempel alt=”Word, nytt fönster”. WCAG 3.2.4,
2.4.4
Se till att bakåt-knappen alltid fungerar. Diskutera och bestäm
om och varför eventuella undantag från detta görs. R97
Rubriker
Se till att Rubrik och titel på sidan överensstämmer. De ska
också överensstämma med Länken som går till aktuell sida.
R27
Alla sidor ska ha en huvudrubrik (h1). Den första rubriken på
sidan ska vara en Huvudrubrik (h1). R105
Kommentar
Struktur och navigation
Kommentar
Alla visuella rubriker ska kodas som rubriker. De ska ha en
struktur som är riktig. Ingen nivå får hoppas över. Skapa
rubriker med HTML-element (h1 – h6).
Det ska finnas klasser för olika rubriknivåer i CSS:en. Om det
behövs ska det skapas flera varianter av varje rubriknivå,
exempel om layouten kräver att en h2 ser olika ut om den är
placerad i mittenkolumn eller högerkolumn. R105
Bilder
Ange alltid alternativattribut för bilder, som inte är
bakgrundsbilder.
•
Bilder som är klickbara ska ha en alternativtext som
beskriver vart länken leder, Exempel logotyper
•
Bilder med text ska ha en alternativtext som motsvarar
texten på bilden.
•
För bilder som behöver en längre förklaring, gör en länk
till en egen sida
•
Bilder som inte är meningsbärande ska ha en tom
alternativtext (alt=””) eller placeras som bakgrundsbilder.
WCAG 1.1.1, 2.4.4
Använd inte bokstavsbilder, och inte onödiga tecken som >>
eller | . Om dessa används lägg dem som bakgrundsbilder.
Val av standarder, kodning och krav på insticksprogram
Vi vill att webbplatsen ska följa standarden XHTML 1.0 Strict
(http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0Strict) och CSS 2.1.
Vid leveranser av mallar ska dessa följa standarder och klara av
validering av kod enligt W3C:s uppmärkningsspråksvalidering
samt stilmallsvalidering. Dokumenttypsbeskrivning måste
finnas för att validering ska kunna göras.
Se till att koden ligger i den ordning som sidan ska läsas, så
läsordning och tabbordning är logisk och korrekt.
Märk upp sidor eller text som har ett språk som avviker från
valt språk. Exempel om text är på engelska på en svensk
webbplats, ska texten märkas upp med hjälp av lang-attribut.
R 80, 81, 82, 84
Kommentar
Val av standarder, kodning och krav på insticksprogram
Kommentar
Webbplatsens grundläggande funktioner ska inte vara
beroende av javaskript. Alla sidor ska kunna visas utan
javaskript.
Alla tjänster ska kunna användas i ett grundutförande utan
javaskript. Om skript används ska de användas för
extrafunktionalitet. Skript ska inte användas för funktioner som
redan finns i webbläsare eller fungerar lika bra utan skript.
Diskutera om och hur skript ska användas. R93
Undvik Flash eller andra insticksprogram om det används ange
hur det ska vara tillgängligt för alla. R86
Flimmer, blinkningar i gränssnittet ska inte användas. Rörelser
eller animationer i gränssnittet ska undvikas och om de
används ska användaren kunna pausa eller stänga av
rörelserna.
Layout
Externa stilmallar (CSS) ska användas för att styra presentation
och layout, till exempel hur olika menyer och kolumner av
innehåll är placerade samt visuell presentation. Style-attribut
ska inte finnas i html-kodningen. R82
Tabeller och ramar (frames) ska inte användas för layout.
Tabeller ska enbart användas för att presentera data. R83
Webbsidan/funktionen ska utvecklas med flexibla
måttenheter. Webbsidorna ska fungera att ta till sig om
användaren har en stor eller en liten skärm. Låg eller hög
upplösning. Det ska inte bli en horisontell rullningslist när
upplösningen är låg. Texten bör flöda neråt vid förstoring av
text. R91
Texten ska fungera att förstora till 200 % utan att layouten
förstörs så att det inte går att ta till sig innehållet. Texten ska
vara angiven med måttenheten em. WCAG 1.4.4
Webbplatsen ska kunna användas även om stilmallarna är
avstängda eller inte kan tolkas. R92.
Kommentar
Layout
Kommentar
Webbplatsen ska ha en separat stilmall för utskrifter. R96
Färg, kontrast och typografi
Kommentar
I universitetets CMS ingår färdiga mallar med layout och en gemensam uppsättning typsnitt för till
exempel brödtext, ingress och rubrik. Mallarna erbjuder olika möjligheter att profilera varje
verksamhet inom ramen för Göteborgs universitet. Detta gör att våra besökare känner igen
universitetets webbplats men kan ta del av den profil som varje verksamhet vill förmedla.
Det är inte tillåtet att ändra presentationen i GU:s stilmallar
på webbsidor vad gäller teckensnitt, teckenstorlek, färger och
bakgrunder. Det är inte heller tillåtet att ändra utseende och
formatering på sidhuvud, sidfot och vänstermarginal.
Kontrasten mellan för- och bakgrundsfärg på webbplatsen ska
vara minst 4,5:1. Undantag kan göras för logotyper och stor
text. Färgerna ska följa Göteborgs Universitets grafiska profil.
WCAG 1.4.3
Ge webbplatsen en god läsbarhet
Teckensnitt, teckengrad, radavstånd, stycken och spaltbredder
ska följa standarder för god läsbarhet. R39
Menyposter och rubriker ska vara skrivna versalgement med
stor begynnelsebokstav. Vänstermenyer ska vara
vänsterställda. R39
Formulär, sökfält och andra inmatningsfält.
Följ råd kring formulär R50,R52-R60
Fältetiketterna till samtliga fält på webbplatsen ska vara
ihopkopplade med respektive fält (label). WCAG 1.3.1
Alternativt kan fältet innehålla ett ”Value” som visas i fältet,
och en titel.
Gruppera formulärfält med fieldset och legend. R53
Fel inmatning i formulär
Systemet ska i första hand automatiskt omvandla information
Kommentar
Formulär, sökfält och andra inmatningsfält.
Kommentar
som ifylld på fel format till det format som systemet behöver
för att behandla informationen. Till exempel ordningen och
bindestrecken i telefonnummer, personnummer och datum.
Ge begripliga felmeddelanden R2
Alla formulär på webbplatsen ska vara oberoende av
inmatningsenhet. Till exempel att det går att navigera i och
skicka formulär genom att enbart använda tangentbord.
Använd inte onchange-attribut.
Tabeller som presenterar data
Kommentar
Använd rad- och kolumnrubriker (th och td) och framhäv dem
grafiskt.
Randa tabeller för att öka läsbarheten, men se till att ha bra
kontraster ändå. R98
Koppla ihop dataceller med rubrikceller. R98
Beskriv kortfattat tabellens innehåll med en tabellrubrik
(caption)
Sökning
Ge tydliga sökresultatsidor:
•
Sökmöjligheten ska kvarstå på sidan
•
Sammanhanget för träffen ska visas
•
Antalet träffar på sidan bör begränsas, ex visa tio träffar
per sida
•
Det ska framgå vilken avdelning träffarna tillhör
•
Det ska gå att sortera träffarna på olika sätt
•
Ingen onödig information ska visas
•
Dessutom bör sökordet visas och hur många träffar som
har hittats.
•
Träffarna bör vara numrerade, det är lättare att hålla
isär träffar då. Lägg sökträffarna i en numrerad lista (ol).
•
Träffarna bör vara tydligt avgränsade från varandra
Kommentar