Tillgänglighet på webbplatser Göteborgs Universitet föreskrifter för webbdesigners och webbutvecklare

Transkript

1 Tillgänglighet på webbplatser Göteborgs Universitet föreskrifter för webbdesigners och webbutvecklare Version: 2.0 Datum: 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å I e- delegationens 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å 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

2 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å 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), 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.

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), 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.

4 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.

5 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, 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.

6 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, 2. Validera stilmallskod med hjälp av W3C:s CSS-validerare, 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 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.

7 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

8 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.

9 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å 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 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

10 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 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 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

11 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 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, 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

12 Struktur och navigation 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, 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 ( Strict) 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

13 Val av standarder, kodning och krav på insticksprogram 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 Webbplatsen ska kunna användas även om stilmallarna är avstängda eller inte kan tolkas. R92.

14 Layout Webbplatsen ska ha en separat stilmall för utskrifter. R96 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. 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 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 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

15 Formulär, sökfält och andra inmatningsfält. 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 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