KOMMUNIKATIONSENHETEN Tillgänglighet på webbplatser Göteborgs Universitet föreskrifter för webbdesigners och webbutvecklare Version: 3.0 Datum: 2012-10-25, uppdaterad 2016-09-27 Inledning Detta dokument beskriver vilka krav som ställs på den gränssnittskod (HTM, CSS, JavaScript/ECMAScript) 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 standarden WCAG2.0 och PTS Vägledningen för webbutveckling (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. Det finns en Kommunikationsenheten 1 (20) Erik Dahlbergsgatan 11 B, plan 5, 405 30, 405 30 Göteborg 031 786 00 00 www.gu.se
svensk vägledning som PTS (Post och telestyrelsen) är ansvarig för. Vägledning för webbutvecklings första riktlinje R1 är Följ WCAG 2.0 nivå AA. Även de resterade111 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) 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å. 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. 2 (20)
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 3- specifikationen. 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. 3 (20)
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. 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: 4 (20)
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). 5 (20)
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. 5. För dekorativa bilder ska alt-attributet innehålla en tom sträng (alt=""). 6. Om bilden innehåller text ska alt-attributet innehålla motsvarande text. 7. 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. 8. 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. 9. Ö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. 10. 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. 11. 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. 12. 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. 13. 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. 14. 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". 15. 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 6 (20)
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/HTML5 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 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. All ny kod ska stödja de tre senaste versionerna av webbläsarna: Firefox Safari Chrome Internet Explorer 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. 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. 7 (20)
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. 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. 8 (20)
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 navigering 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, R31, R33 Sökningen ska vara åtkomlig från alla sidor. Sökning ska finnas för större webbplatser. WCAG 2.4.5, R32 9 (20)
Struktur och navigation Gör det möjligt att hoppa förbi delar på sidorna R75 Skapa genvägar för att hoppa i strukturen över till exempel menyn, för att komma direkt till sidans innehåll. Gör genvägen synlig eller att den visas vid tangentbordsanvändning. Skapa tydliga h-rubriker, eftersom skärmläsare låter användarna snabbnavigera med hjälp av sidans rubriker. Använd WAI-ARIA landmark roles, till exempel main, search, navigation, banner contentinfo och så vidare. Det gör att användare med exempelvis skärmläsare på ett standardiserat sätt kan navigera mellan sidans olika delar. Om du använder HTML5, använd strukturelement som main, aside, header, footer och nav för att definiera vilken roll varje del av sidan har. Var konsekvent i navigation, struktur och utformning R 29 Använd samma utseende, funktionalitet för hela webbplatsen. Gör avsteg enbart om det är motiverat. 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. Sidtiteln ska vara tydlig och beskrivande Titeln på sidan ska hjälpa användaren att veta vart hon/han befinner sig. Titeln bör vara konsekvent med länk och huvudrubrik. Formen: Unika sidan (avdelning/meny)- Göteborgs universitet WCAG 2.4.2 10 (20)
Struktur och navigation 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. R27 Det ska finnas en länkstig (smullist) om det hjälper användaren. 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. Tekniskt ska navigeringsnivåerna förklaras genom exempel listor (nästlade listor för olika nivåer) eller och elementet nav (HTML5), 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. Tangentbordstyrning ska fungera på hela webbplatsen 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 Tabbordningen ska vara logisk Fokuserbara komponenter som länkar och formulärfält ska vara placerade i en logisk ordning (betydelse och användning). WCAG 2.4.3 Länkar och navigering Länkar och navigering 11 (20)
Länkar och navigering Gruppera länkar i länklistor När flera länkar ligger grupperade ska länkarna grupperas i en lista (UL). 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. R34, WCAG 2.4.1 Det ska tydligt framgå vad som är länkar, klickbart R34 Använd samma länkfärg. Användning av länkutseende ska vara konsekvent. Det är viktigt att inte enbart färg visar vad som är länk. Gör exempelvis symboler eller understrykning för att visa vad som är klickbart. Använd olika färger för besökta och icke-besökta länkar. Knappar eller andra klickbara ytor ska tydligt visa att det är klickbart. Klickbara ytor är tillräckligt stora Öka storleken på klickbara ytor exempel genom att lägga till innermarginaler (padding) runt länkelement i den klickbara ytan. Placera inte länkar för nära varandra R34 Gör tydligt tabb- och muspekarfokus 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 exempel en tydlig ruta eller annan bakgrundsfärg. WCAG 2.4.7, R34 12 (20)
Länkar och navigering Undvik att öppna nya fönster Öppna nya fönster enbart om det hjälper användaren. Det kan vara bra i vissa hänseenden. Nackdel är att bakåtknappen slutar fungera. R97 Länkar som öppnar nya fönster är tydligt märkt 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. R5, WCAG 3.2.4, 2.4.4 Det ska tydligt framgå om länken leder till annat format Det ska framgå om länkar leder till annat format än html som exempelvis dokument i formatet pdf, Word. Det kan framgå i textform eller symbol med alternativtext (alt= pdf ). Symbolen får inte vara en bakgrundsbild utan bilden ska ingå i länktaggen. Filens storlek bör framgå i länktexten. R5 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 Rubriker Se till att Rubrik och titel på sidan överensstämmer. Det ska också överensstämma med länken som går till aktuell sida. R27 13 (20)
Rubriker Skapa rubriker med h-element Skapa rubriker med HTML-element (h1 h6). De ska ha en struktur som är korrekt (h1, h2 osv), ingen nivå får hoppas över. Alla sidor ska ha en rubrik som är uppmärkt med H1. HTML5 erbjuder ett alternativt sätt att strukturera dokument och rubriker, via section-element. Varje sektion får då sin egen rubrikhierarki med början på h1. Det här är dock inte implementerat i alla webbläsare och hjälpmedel ännu, så använd h1 h6 tillsvidare. R105, R61 Bilder 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 standard, kodning och krav på instickprogram Val av standarder, kodning och insticksprogram 14 (20)
Val av standarder, kodning och insticksprogram Vi vill att webbplatsen ska följa standarden HTML4.01 eller HTML5. För presentation och layout ska CSS användas. Vid leveranser av mallar ska dessa följa standarder och klara av validering av kod enligt W3C:s uppmärkningsspråksvalidering samt stilmallsvalidering. Skicka med valideringsprotokoll av validering. Dokumenttypsbeskrivning måste finnas för att validering ska kunna göras. Teckenuppsättning ska vara korrekt angivet. Se till att koden ligger i den ordning som sidan ska läsas, så läsordning och tabbordning är logisk och korrekt. R80, 81, 82, 84 Webbplatsens grundläggande funktioner ska inte vara beroende av JavaScript. Alla sidor ska kunna visas utan JavaScript. Alla tjänster ska kunna användas i ett grundutförande utan JavaScript. 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 Komplexa tekniker ska inte utestänga användare 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. WCAG 2.2.2, 2.3.1 15 (20)
Val av standarder, kodning och insticksprogram Det huvudsakliga språket är angivet Alla sidor ska ha en uppmärkning av språk, görs med hjälp av lang attribut. WCAG 3.1.1 Om det är förändring i det huvudsakliga språket är det uppmärkt När delar av sidan har ett annat språk är det uppmärkt med korrekt språk lang= språkkod. Detgäller enstaka ord eller länkar. WCAG 3.1.2 Layout Layout CSS används för presentation och 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, WCAG 1.3.1 Tabeller och ramar (frames) ska inte användas för layout. Tabeller ska enbart användas för att presentera data. Ramar kan användas om det finns särskilda skäl till det. R83, R94, R95 Layouten fungerar bra med olika skärmstorlekar 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 16 (20)
Layout Text kan förstoras upp till 200 procent utan förlust av innehåll eller funktion Det ska gå att ta till sig innehållet även vid förstoring av innehåll exempel zoom-funktion. Texten ska vara angiven med måttenheten em. WCAG 1.4.4 Innehållet ska kunna användas utan CSS Webbplatsen ska kunna användas även om stilmallarna är avstängda eller inte kan tolkas. R92, WCAG 1.3.2 Webbplatsen ska ha en separat stilmall för utskrifter. R96 Färg, kontrast och typografi Färg, kontrast och typografi 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. Förgrunds- och bakgrundsfärg ger tillräcklig kontraster 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, R34 Ge webbplatsen en god läsbarhet Teckensnitt, teckengrad, radavstånd, stycken och spaltbredder ska följa standarder för god läsbarhet. R39 17 (20)
Färg, kontrast och typografi Menyposter och rubriker ska vara skrivna versalgement Det ska inledas med stor begynnelsebokstav. Vänstermenyer ska vara vänsterställda. R39 Begriplighet är inte beroende av användarens förmåga att uppfatta färg Det gäller exempelvis att visa vad som är länkar, hänvisningar i text. WCAG 1.4.1 Formulär, sökfält och andra inmatningsfält Formulär, sökfält och andra inmatningsfält Följ råd kring formulär Minimera antalet fält i formulär R50 Fyll formulär med kända uppgifter R52 Gör tydliga och användbara knappar -R60 Använd standardutseende på formulärfält R58 Markera obligatoriska fält R101 Koppla ihop fält och etikett-text med label Fältetiketterna till samtliga fält på webbplatsen ska vara ihopkopplade med respektive fält (label). Alternativt kan fältet innehålla ett Value som visas i fältet, och en titel. WCAG 1.3.1 och R55 Gruppera formulärfält med fieldset och legend Det gäller grupper av radioknappar, kryssrutor eller andra logiska grupper där det hjälper att gruppera. WCAG 1.3.1 och R53 Fel inmatning i formulär Systemet ska i första hand automatiskt omvandla information 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. R2 18 (20)
Formulär, sökfält och andra inmatningsfält Meddela användaren om det blir fel i inmatning Hjälp användaren när det blir fel. Exempel skriv felmeddelanden som är enkla att förstå, visa i layouten att något blev fel. R2, WCAG 3.3.3 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 19 (20)
Tabeller Tabeller som presenterar data Använd TH för rad- och eller kolumnrubriker Framhäv vad som är rubriker även grafiskt. Randa tabeller för att öka läsbarheten, men se till att ha bra kontraster ändå. WCAG 1.3.1, R98 Komplexa tabeller märks upp med rätt kod Koppla ihop dataceller med rubrikceller genom scope eller id. När det finns tabeller som har flera logiska nivåer med rad eller kolumnrubriker så bör det användas en särskilt uppmärkning. WCAG 1.3.1, R98 Förtydliga tabellens innehåll (vid behov) Vid behov beskriv kortfattat tabellens innehåll med en tabellrubrik (caption) eller en kort förklaring (summery) WCAG 1.3.1 20 (20)