Diskrimineringsombudsmannen skriver:
Från och med den 1 januari 2015 ingår bristande tillgänglighet som en ny form av diskriminering i diskrimineringslagen. Det nya förbudet mot diskriminering ska bidra till att öka tillgängligheten i samhället så att människor med funktionsnedsättning kan delta på likvärdiga villkor.
Tillgängliga webbsidor är inget val längre, det är ett lagkrav.
För att skapa tillgängliga webbsidor bör man i första hand följa PTS:s Vägledning för webbutveckling som bland annat säger att vi ska följa W3C:s WAI-standard WCAG 2.0 Nivå AA.
Den här dokumentationen beskriver hur man uppfyller kravet på tillgänglig webbutveckling samt innehåller även tillägg från WAI-ARIA 1.1 (standard för tillgängliga webbapplikationer).
Information och komponenter i ett användargränssnitt måste presenteras för användare på sätt som de kan uppfatta.
Bild, video, ljud och multimedia behöver ha textalternativ som visar samma innehåll.
Riktlinjerna uppfylls genom att alltid ha ett textalternativ till mediafiler som är betydelsebärande. I fallet med bilder kan det vara en alternativ-text, video eller ljud kan det vara textning som kan nås för en skärmläsare.
Man kan även uppfylla riktlinjerna genom att använda video som ett tillägg till ett hjälpavsnitt som redan förklarar hjälpinnehållet. I det fallet är videon ett sätt att förenkla avsnittet, men all information finns tillgänglig på ett teknikoberoende sätt, till skillnad från att använda video som det enda hjälpavsnittet.
Direktsändningar av video eller ljud kräver inte textning, men om materialet sparas på webbplatsen ska text läggas till inom två veckor.
<img alt="" />Tänk på att alt-texten endast ska användas betydelsebärande. Exempel "leende kvinna" hjälper inte förståelsen av sidan om bilden bara är en illustration. I de fall bilden inte är betydelsebärande ska alt=""-attributet vara tomt (alt="").
Använd inte tilläggstexter som till exempel "Bild av …", då skärmläsaren redan lägger till information om att det är en bild.
Om bilden har text kan alt-texten oftast använda samma text.
Ignorera att texten visas om musen hovrar över bilden. alt-texten är till för funktionshindrade användare och om man kan se bilden har den redan den beskrivning som behövs (visuellt).
Bakgrundsbilder ska endast användas till dekorativa bilder eller som ersättning för text. Till exempel om en ikon används används utan text kan text läggas till och flyttas från visningsytan:
<button class="help">Hjälp</button>
<style type="text/css">
.help
{
text-indent: -9999px; /* Flyttar texten utanför synliga ytan, men kan ändå läsas av en skärmläsare */
background-image: url(help.png); /* Ersättningsbilden */
}
</style>Ett textalternativ kan användas med <audio>-taggen genom att lägga till <track> med texten från ljudfilen.
<audio>
<source src="audio.mp3"></source>
<track kind="subtitles" label="English subtitles" src="subtitles_en.vtt" srclang="en"></track>
<track kind="subtitles" label="Svensk undertext" src="subtitles_sv.vtt" srclang="sv" default></track>
</audio>En video kan använda undertexter genom att använda <track> med undertexten för videon.
<video>
<source src="video.mp4" type="video/mp4></source>
<track kind="subtitles" label="English subtitles" src="subtitles_en.vtt" srclang="en"></track>
<track kind="subtitles" label="Svensk undertext" src="subtitles_sv.vtt" srclang="sv" default></track>
</video>Riktlinjen berör anpassning för olika sätt att ta till sig innehåll, i viss mån med hjälp av samma tekniker som används för att anpassa till olika skärmar – det vill säga responsive design, men också till olika hjälpmedel.
Det handlar om att hantera gränssnittskod som ett välstrukturerat dokument snarare än som design. Det vill säga innehåll i den ordning som sidan ska förstås snarare än hur det ska presenteras i en webbläsare: innehållet först, en hierarkisk struktur för rubriker och formulär utifrån logik snarare än hur det ska vara uppställt på sidan.
Det handlar också om att lägga till kod för att stödja WAI-ARIA (Accessible Rich Internet Applications).
Alla råd för §1.3 Anpassningsbart är nivå A.
role="" och aria-*=""-attribut används för att ge semantik där sådan saknas och för att förklara funktioner som inte är självförklarande.
W3C har angivit 5 regler för hur ARIA-roller, tillstånd eller egenskaper bäst används för tillgänglig webbutveckling:
Om naturliga HTML-element kan användas bör de användas
Ändra inte semantiska betydelsen av ett element om det inte är nödvändigt.
Om till exempel en rubrik också är en knapp ska en <button> snarare läggas till än att <h1> ska få role="button", alltså <h1><button>Rubrik som är en knapp</button></h1>, inte <h1 role="button">Rubrik som är en knapp</h1>
Alla ARIA-kontroller måste vara tillgängliga via tangentbord
Använd aldrig role="presentation" eller aria-hidden="true" på ett element som är synligt och möjligt att välja; som en knapp, en länk eller ett formulärelement
Alla interaktiva kontroller måste använda namn/id
role="":Lägg till role=""-attribut för element som är viktiga för sidan och för funktioner för att låta skärmläsare och till exempel sökmotorer förstå vad sidan innehåller.
<header role="banner">…</header>
<nav…</nav>
<main>
<article>
<header><h1>…</h1></header>
…
<footer>…</footer>
</article>
<aside>…</aside>
</main>
<footer role="contentinfo">…</footer>Flera rolldefinitioner används för att återskapa funktionalitet när inte semantiska element används i koden. Exempelvis används role="link" när ett element som inte är en länk används för att länka vidare till en annan sida än den nuvarande. Rekommendationen är istället att alltid använda det semantiska elementet när det är möjligt.
Det är heller inte rekommenderat att lägga till en roll till ett element som redan har samma semantiska betydelse. Exempelvis <a href="" role="link"> är redundant. W3C har en lista över alla element och deras implicita roller och när de ändå ska sättas ut. När en länk-tagg har en annan roll än att vara bara en länk, som en knapp, ska role sättas ut (role="button", role="menuitem", role="tab" som exempel).
I dokumentationen har vissa role-definitioner flyttats till utfällbara ytor för fullständig dokumentation.
Landmärkesroller används för att peka ut särskilda delar av sidstrukturen:
role="application" används för del av sida som är en webbapplikation. Ska endast användas för webbapplikationer som använder huvuddelen av sidans funktion.role="banner" används för sajt-övergripande (till exempel sidhuvud). Kan bara användas en gång per sida.role="contentinfo" används för sajtens övergripande sidfot (kan bara användas en gång per sida).role="search" grupperar sökformulär på sidan, kan även inkludera element som filtrerar sökresultatet.role="complementary" används för innehåll som kompletterar sidans innehåll, men som också är meningsfull för sig själv (som till exempel en faktaruta). Använd hellre elementet <aside>.role="form" används för formulär och tillåter användaren att hoppa direkt till formuläret. Använd hellre elementet <form>, men när det är relevant kan rollen användas för att omsluta mer än bara det faktiska formuläret.role="main" används en gång per sida och visar på sidans huvuddel, inte delar som upprepas från andra sidor. vänd hellre elementet <main>.role="navigation" används för att gruppera länkar för att navigera på sajten eller på sidan. Använd hellre elementet <nav>.Roller för dokumentstrukturen används för att organisera sidans innehåll:
role="article" används för del av webbsida som är en självständig artikel (exempelvis sidans innehåll eller en enskild nyhet i en nyhetslistning).role="document" om innehållet i ett Word-dokument skulle presenteras som en webbsida skulle role="document" användas. Om den används ska även tabindex="0" sättas för att användaren ska kunna tangentbordsnavigera sig till elementet.role="img" används för att gruppera till exempel bild och bildtext. Används framför allt när andra bildformat som inline svg eller ASCII-bilder. Exempel:
<figure role="img">
<img />
<figcaption>…</figcaption>
</figure>role="presentation" används för att ta bort elements semantiska betydelse för skärmläsare. Exempelvis för att endast visa en meny som menu och menuitem även om en koden i själva verket är en ul/li-lista:
<nav role="menu">
<ul role="presentation">
<li>
<a href="" role="menuitem">…</a>
</li>
</ul>
</nav>role="toolbar" används för vanliga funktioner. Till exempel för delning eller verktyg i en applikation.role="columnheader" används för rubriker för delar av sidan.role="definition" används för till exempel ordförklaringar.role="directory" kan användas för till exempel en meny på sidan som fungerar som innehållsförteckning (av sidan).role="group" används istället för andra gruppera andra element (delar av en meny eller istället för fieldset om fieldset inte är tillgängligt).role="heading" används för att rubrik-semantik (tillsammans med aria-level=""). Använd hellre <h1>-<h6>role="region" en del av en sida viktig nog för att var med i en innehållsförteckning. Används för till exempel statistik. Använd hellre elementet <section>role="separator" används för att separera grupper av innehåll, till exempel med en <hr /> (som har role="separator" i innehållet eller <li role="separator"></li> i en meny.
role="list" kan användas för pseudolistor för innehåll som inte är interagerbart. Använd hellre elementen <ul>/<ol>-listor istället.role="listitem" ett element i en role="directory" eller role="list".role="math" används för att visa ett matematiskt utryck.role="note" används för information till stöd för huvudinnehållet.Widget-roller används för särskilda delar av en sida:
role="alert" för meddelanden i gränssnittet.role="alertdialog" för meddelanden i gränssnittet där webbläsarens fokus läggs i meddelandet (till exempel vid modalt fönster)role="dialog" används för dialogrutor som ska avbryta användaren vid till exempel inmatningen av ett formulär.role="log" används för ett område där ny information kan läggas till och där gammal information kan försvinna. Till exempel för en lista med infinite scroll.role="progressbar" ett element som visar status för uppgifter i flera steg. Använder även aria-valuexxx="" för att berätta status för skärmläsaren. Exempel: <div role="progressbar" aria-valuenow="20" aria-valuemin="0" aria-valuemax="100">Steg 2: Välj utskott</div>role="status" för information som inte är viktig nog för att avbryta användaren med role="alert" men som ändå informerar om status.role="tooltip" används för hjälpruta vid till exempel ett inmatningsfält som informerar om inmatningen.role="button" används framför allt för knappar som inte är uppmärkta med input eller button (som länk-knappar).role="checkbox" används för element som kan ha ha två eller tre tillstånd (aria-checked="true", aria-checked="false" och aria-checked="mixed"). Om elementet använder role="checkbox" måste även aria-checked="" sättas dynamiskt beroende på tillstånd. För element i menyer/funktioner används role="menuitemcheckbox" (till exempel för meny med möjlighet att dölja/visa kolumner). role="link" används om ett annat element än en a-tagg används för att användaren ska navigera från sin nuvarande plats.role="marquee" är lik role="log" men behöver inte vara i tidsordning. Används för innehåll som uppdateras, som aktie-/ränteinformation.role="radio" ett element med två tillstånd där bara ett kan vara valt på samma gång (som <input type="radio" />). För element i menyer/funktioner används role="radio" (till exempel för sortering). Om rollerna används ska även attributet aria-checked="true/false" sättas.role="scrollbar" för en skapad rullista.role="slider" för ett element som genererat ett värde från en given skala. Jämför <input type="range" />role="spinbutton" för ett element som stegar fram ett värde. Jämför spinnern för standardvisningen av <input type="number">.role="textbox" för ett fält där användaren kan mata in flödande text. Jämför <textarea>.role="timer" för till exempel information om tid till utloggning.Eller för att gruppera widgets:
role="combobox" används för att gruppera en <input /> med en role="listbox" för autocomplete när användaren skriver. Exempel: <input type="text" aria-label="Välj bostadsort" role="combobox" aria-expanded="true" aria-autocomplete="list" aria-owns="choose-city" aria-activedescendant="selected-city">
<ul role="listbox" id="choose-city">
<li role="option">Stockholm</li>
<li role="option" id="selected-city">Örebro <abbr title="For the win!">FTW!</abbr></li>
</ul>role="menu"/role="menubar" (innehåller role="menuitem", role="menuitemcheckbox" och/eller role="menuitemradio") används för menyer. Det kan finnas fler menyer på en sida. role="menubar" används för en meny som för gränssnittet i en applikation. Den ska finnas i gränssnittet hela tiden.
För specifikt om widget-rollerna role="menuitemcheckbox" och role="menuitemradio" se role="checkbox" och role="radio".
Exempel:
<nav role="menu">
<ul role="presentation">
<li><a href="" role="menuitem">…</a></li>
</ul>
</nav>role="grid" (kan innehålla element med row, rowgroup, rowheader och gridcell) för att skapa tabulär data utan att använda tabeller.role="listbox" används för funktioner som har samma funktionalitet som en <select>-box men med möjlighet att använda andra valbara element än bara text (för att till exempel välja bland bilder). Ett element med role="listbox" innehåller element med role="option".role="radiogroup" används för motsvarande <fieldset> för att gruppera role="radio".role="tablist" (innehåller element med role="tab" och role="tabpanel")role="tree"/role="treegrid" (innehåller role="treeitem" och eventuellt role="group") används för till exempel för en sajtkarta. role="treegrid" har samma semantik, men i tabellform. De kan ibland öppnas och stängas i flera nivåer.aria-*=""Lägg till ARIA-attribut för att förklara funktioner eller tala om hur funktioner/innehåll hör ihop.
ARIA-attribut används för att visa på egenskaper och tillstånd som inte är möjliga att uppfatta på annat sätt utan att se innehållet.
Element som introduceras i gränssnittet ska till exempel få aria-expanded="true" när innehåll eller ett meddelande de visas. Om meddelandet är ett felmeddelande ska det även role="alert" samt aria-live="assertive":
<div role="alert" aria-live="assertive" aria-expanded="true" class="error"><span class="icon" aria-hidden="true"></span>Felmeddelande</div>role="alert" och aria-live="assertive" används samtidigt, trots att de har samma betydelse. Det beror på att vissa skärmläsare endast har stöd för den ena eller den andre.
En rubrik som hör till en högerspalt kan använda aria-label="" och aria-labelledby="" när inte rubriken visas direkt i ytan, när till exempel en bild visas innan rubriken:
<aside aria-labelledby="id-x">
<img />
…
<h2 id="id-x">Spaltrubrik</h2>
<div class="content">…</div>
</aside>Dropdownmeny använder aria-haspopup="" för att berätta att den har en dropdown (tillsammans med aria-expanded="" för att berätta att det finns innehåll samt sitt tillstånd):
<ul role="menu">
<li role="menuitem" aria-haspopup="true" aria-expanded="false" aria-labelledby="id-y"><span id="id-y">File</span>
<ul role="menu">
<li role="menuitem">…</li>
<li role="menuitem">…</li>
</ul>
</li>
…
</ul>Ett formulärfält ska alltid använda label, men om designen inte stödjer en visuell label kan i undantag en dold label användas:
<label for="field-a" id="label-a" class="sr-only">Text för skärmläsare</label>
<input … id="field-a" aria-labelledby="label-a" />ARIA-attribut kan även användas för att märka ut fel i inmatningen i formulär eller i applikationsdelar (aria-invalid="").
När knappar använder grafik eller annat material istället för text ersätter aria-label=""-attribut för att förklara användningen:
<button aria-label="Stäng" class="close-button">×</button>Det finns olika grupper ARIA-attribut: för widgets, aktiva delar, dra och släpp-regioner samt för att beskriva relationer.
Formulär ska alltid använda ledtexter (label) och grupperas efter innehåll (fieldset) och inte efter hur de ser ut.
<fieldset role="group">
<legend>Rubrik för gruppen av formulärfält</legend>
…
</fieldset>
<fieldset role="group">
<legend>Rubrik för gruppen av formulärfält</legend>
…
</fieldset>Använd rätt formulärfälttyp efter vilken input som ska användas (hjälper både funktionshindrade och enheter som stödjer andra tangentbord, som smartphones och tablets).
<input … type="search" />
<input … type="email" />
<input … type="url" />
<input … type="tel" />
<input … type="number" />
<input … type="range" />
<input … type="date" />
<input … type="month" />
<input … type="week" />
<input … type="time" />
<input … type="datetime" />
<input … type="datetime-local" />
<input … type="color" />Förenklingar för autocomplete hjälper alla användare, inklusive funktionshindrade användare genom att automatisera inmatningsprocessen.
<input … autocomplete="name">
<input … autocomplete="email">
<input … autocomplete="street-address">
<input … autocomplete="postal-code">
<input … autocomplete="address-level2"> <!-- Stad, address-level1 är stat/län alltså inte relevant för svenska adresser -->
<input … autocomplete="country">
<input … autocomplete="tel">Platshållare kan förklara inmatningen genom att visa hur det ska vara formaterat innan det fyllts i.
<label for="personal-id">Personnummer</label>
<input type="text" id="personal-id" name="personal-id" placeholder="ÅÅÅÅMMDD-XXXX" />Felmeddelanden som använder label kan knytas till det felande formulärfältet för enklare rättning. En skärmläsare kommer endast läsa den första label som finns för ett formulärfält, det andra knyts genom aria-describedby=""
<label for="personal-id">Personnummer</label>
<input type="text" id="personal-id" name="personal-id" aria-describedby="error-personal-id" />
<label for="personal-id" id="error-personal-id" class="error" aria-expanded="true">Personnumret är felaktigt ifyllt.</label>Riktlinjen handlar om att använda text, färger, bilder och multimedia på ett tillgängligt sätt.
All text ska vara möjlig att förstora med hjälp av webbläsaren upp till 200 % av ursprungsstorleken utan förlorad funktionalitet.
Det här sköter webbläsaren ofta själv, men positionering av element behöver granskas för att se att objekt inte försvinner ur synliga ytor eller göms under element. Problemet med gömda element händer vid användning av absolut positionering.
Text som bild ska inte användas, om inte bilden är av avgörande betydelse (som till exempel en logotyp). När det används ska alltid en textbeskrivning finnas med.
Ljud som startas automatiskt och spelas längre än tre sekunder måste ha en möjlighet att stängas av oberoende av devicens möjlighet att hantera ljud.
Färger ska inte användas som enskild urskiljningsmetod. Att be användaren använda "den gröna knappen" är till exempel något som bryter mot den här riktlinjen. Att knappen är grön och hjälper andra användare genom sin färg är bra, men det främsta sättet att berätta hur man ska ta sig vidare på andra sätt ("Nästa-knappen", till exempel). Eftersom den nya sajten som byggs kommer vara responsiv är det inte heller att rekommendera att prata om "den högra knappen" då vi inte nödvändigtvis vet vilken placering innehåll kommer vara i olika renderingsstorlekar eller för all del i språk som inte läses vänster till höger.
Länkar ska vara urskilda i färg eller på annat sätt från övrig text. Textlänkar ska ha samma färg på hela webbplatsen (undantag är menyer). §34 i vägledningen för webbutveckling rekommenderar även annan färg för besökta länkar.
Normal text (förutom logotyper) ska ha ett kontrastvärde på 4,5:1. Stor text ska ha ett kontrastvärde på 3:1. För nivå AAA (ett steg över krav) ska normal text ha ett kontrastvärde på 7:1 och större text 4,5:1.
För att kontrollera kontrast kan till exempel Colour Contrast Check användas.
Komponenter i ett användargränssnitt och navigering måste vara hanterbara.
Genom kortkommandon och genom att ta tabba sig igenom länkar och till exempel formulärfält på sidan.
Ett formulär ska alltid kunna skickas via tangentbordet.
En genomtänkt tabbordning är alltid att föredra, men förenklas samtidigt av att se innehåll som ett flöde och inte hur det är designat enligt principerna för responsive design.
Om ett objekt som i vanliga fall inte tabbas till ska kunna nås behöver tabindex="0" specificeras till exempel ett objekt som används som knapp med till exempel javascript.
tabindex="0" normal tabbordning, behöver endast för element som normalt inte är tabbara.
tabindex="n" bryter tabbordningen och får tabben att gå direkt i tabindex-ordningen
tabindex="-1" undantar objekt från tabbordningen.
Ett objekt på sidan får aldrig tvinga användaren att stanna på objektet som är tabbat till (tangentbordsfälla).
Justerbar tidsgräns för tidsbegränsade uppgifter och en möjlighet att pausa eller ta bort rörligt innehåll är vad som krävs för att uppfylla kriteriet (Nivå A).
Innehåll som uppdateras automatiskt behöver kunna pausas eller stoppas helt.
I vårt fall är den viktigaste delen inloggat läge där timeout behöver kunna förlängas innan utloggning (upp till 10×). En session som kräver utloggning efter en viss tid ska kunna återupptas utan att data förloras.
Inget innehåll ska flimra mer än tre gånger under en ensekundsperiod (Nivå A).
Genom att använda accesskey="" för viktiga funktioner kan användare ges möjlighet att komma direkt till viktiga funktioner på sidan som kontakt, sök och hjälp, men även till inloggning till exempel. Vägledningen för webbutveckling har rekommendationer för vilka funktioner som ska använda standardiserade snabbkommandon på en webbplats (Riktlinje 68). Vägledningen säger samtidigt att man ska vara sparsam med användningen av kortkommandon.
Om standardsnabbkommandon används på webbplatsen bör de placeras sent i kodordningen eller använda tabindex="-1" för att inte tabbordningen ska störas.
I webbapplikationer är det även möjligt att använda snabbkommandon för ofta utförda uppgifter för att förenkla inmatning. Snabbkommandon och möjlighet att nå
Användare ska kunna hoppa över grupperat innehåll som upprepas på flera sidor. Det kan till exempel handla om navigering. Det uppnås enklast genom en ankarlänk som kan ligga utanför det synliga gränssnittet men som ändå kan aktiveras med tangentbordsnavigering. Riktlinje 68 i Vägledningen för Webbutveckling rekommenderar s som tangentbordskommando för att komma till innehållet (accesskey="s"). Landmärkesroller ersätter ofta användningen av accesskey="s".
Länken med accesskey="s" bör placeras innan sajtens huvud. Den kan vara utanför sidans synliga yta, men ska visas när den fokuseras (genom att den tabbas till).
Sidans titel ska alltid förklara sidans innehåll.
En länk ska helst vara självförklarande (om alla länktexter är självförklarande uppnås nivå AAA). En länktext som "Läs mer" (som helst ska undvikas) behöver kompletteras med title=""-attribut.
När länken har självförklarande text ska inte title=""-attribut på länken användas. Texten kommer läsas upp dubbelt i skärmläsaren.
Länkade bilder kommer läsa upp alt-texten som länktext. Därmed behöver alt-texten förklara länksyftet, inte beskriva bilden. Om betydelsen är viktig i sig, men inte är samma som länktexten ska title-attribut användas på länken.
CSS behöver definieras för när ett objekt på sidan är valt :focus. Det här gäller länkar, formulärfält och andra objekt som användaren kan interagera med eller aktivera på sidorna.
Avdelningar på sidan ska innehålla rubriker som beskriver avsnittet och formulärfält ska ha etiketter (label) som beskriver fältet.
Vad det gäller rubrikerna kan skärmläsare till exempel navigera på sidan genom att hoppa mellan rubriker (hn).
Formulär använder alltid label-fält för att beskriva formulär-fältet.
<label for="field-name">Label</label>
<input type="text" id="field-name" name="field-name" />En användare ska kunna hitta innehåll på fler sätt än att navigera sig fram genom menyer, genom till exempel en sökfunktion eller en sitemap.
Under den här riktlinjen finns även en riktlinje på nivå AAA där användaren ska få hjälp att förstå var hen befinner sig genom till exempel en brödsmulenavigering.
Information och hantering av användargränssnitt måste vara begriplig.
För att uppfylla riktlinjen ska sidans språk anges på sidnivå (<body lang="sv-SE">(Nivå A) men även på del av sida där annat språk finns (<a lang="en">Read this page in English</a>) (Nivå AA). På det här sättet kan till exempel en skärmläsare välja rätt uttal för innehållet. Men det förklarar även innehållet för robottekniker som sökmotorspindlar.
Nivå AAA för riktlinjen handlar om att ovanliga ord och fraser förklaras, att förkortningar skrivs ut i html-kod (<abbr title="Web Accessibility Initiative">WAI</abbr> men allra helst i klartext, att en lättläst version är tillgänglig för komplicerade texter samt att uttal av ord förklaras om betydelsen kan vara tvetydig.
Vägledningen för webbutveckling har flera riktlinjer som handlar om språk och som berör språkriktlinjen i WCAG.
Riktlinje §10, §12, §13, §14 och §15 berör språkhantering på webbplatser. §12, §13, §14 och §15 är mindre relevant för webbapplikationer.
§10 säger att all text ska vara på begriplig svenska för att användare med funktionsnedsättningar och svenska som andraspråk ska kunna ta till sig innehållet. Text som måste använda komplicerade ord ska förklara dem. §12 Vid behov, efter målgruppsanalys, ska information ges på lättläst svenska. §13 Viktiga sidor och tjänster ska översättas till svenska minoritetsspråk (finska, meänkieli och samiska) samt §14 till svenskt teckenspråk. Vägledningen pekar särskilt ut service för välfärdstjänster för äldre. §15 gäller andra språk som ska väljas genom statistik från besökare på webbplatsen.
När ett objekt på sidan får fokus ska inte sidans innehåll förändras eller användarens kontext förflyttas. Användaren måste själv aktivera länken eller funktionen för att kontexten ska ändras.
Användaren ska inte automatiskt flyttas vidare vid inmatning i ett formulärfält. Som exempel kan vara om en användare fyllt i sitt personnummer så ska inte användaren automatiskt flyttas över till en egen ruta för fyra sista siffrorna när år-dag-månad är ifyllt.
Navigeringsmetoder som upprepas på flera sidor inom en särskild uppsättning av webbsidor ska presenteras i samma inbördes ordning varje gång de upprepas om inte användaren själv initierat en ändring.
Vän av ordning skulle kunna hävda att subnavigeringen på pensionsmyndigheten.se i viss mån bryter mot den här riktlinjen idag då syskonsidor försvinner ur navigeringen när ett barn besöks, även om det är användaren själv som initierar förändringen genom att klicka på en länk i navigationen.
En funktion som används på samma sätt på webbplatsen ska identifieras på samma sätt. En Hjälp-funktion benämnd som Hjälp ska genomgående heta Hjälp och sök ska inte byta Sök till Hitta eller liknande.
Fel vid inmatning i till exempel formulär ska det som är fel markeras och felet beskrivas för användaren med text (Nivå A). Om det finns kända rättningsförslag ska det föreslås för användaren (Nivå AA).
Formulär ska validera formulär i klienten (med hjälp av skript) för att användaren ska slippa posta formuläret och sedan göra om. Om det inte är möjligt ska formuläret behålla inmatat innehåll efter omladdning.
Ett felmeddelande ska använda role="alert" eller och aria-live="assertive" på grund av att vissa skärmläsare endast har stöd för ena eller andra. aria-expanded="true" används för berätta för skärmläsaren att ytan skapats/vistas efter den först att sidan renderats. Notera att en ikon som hjälper seende kan användas, men den göms för skärmläsare då den inte hjälper där (aria-hidden="true"):
<div role="alert" aria-live="assertive" aria-expanded="true" class="error">
<span class="icon icon-error" aria-hidden="true"></span>
Felmeddelande
</div>Vägledningen för webbutveckling rekommenderar att samla felmeddelanden i en yta ovanför ett formulär som valideras, men att även ange felmeddelanden vid respektive formulärfält.
Ett felaktigt formulärfält använder även aria-invalid="true" för att berätta för skärmläsaren att fältet är felaktigt ifyllt. För att ytterligare hjälpa skärmläsaren kan då aria-describedby="" användas för att peka mot texten som förklarar felet:
<div role="alert" aria-live="assertive" aria-expanded="true" class="error">
<h1>
<span class="icon icon-error" aria-hidden="true"></span>
Felmeddelanderubrik
</h1>
<ol>
<li>Namnfältet får inte vara tomt. <label for="name">Fyll i namn</label></li>
<li>Personnumret måste fyllas i på rätt sätt. <label for="personal-id">Rätta personnumret</label></li>
</ol>
</div>
<form …>
<fieldset>
<label for="name">Namn</label>
<input type="text" id="name" name="name" required class="error" aria-invalid="true" aria-describedBy="error-1" />
<label for="personal-id" class="error" id="error-1">Namnfältet får inte vara tomt.</label>
<label for="personal-id">Personnummer</label>
<input type="text" id="personal-id" name="personal-id" aria-invalid="true" aria-describedBy="error-2" />
<label for="personal-id" class="error" id="error-2">Personnumret är felaktigt ifyllt.</label>
</fieldset>
</form>Ett modalt fönster med felmeddelande använder role="alertdialog":
<div role="alertdialog" aria-labelledby="alert-heading" aria-describedby="alert-text">
<h1 id="alert-heading">Fel</h1>
<div id="alert-text">Beskrivning av felet.</div>
<button>Rätta felet</button>
</div>Se Riktlinje 1.3 Anpassningsbart.
Ge en möjlighet att förhandsgranska information som lämnas innan den slutgiltigt skickas in.
På Nivå AAA finns även en riktlinje om att ha sammanhangsberoende hjälp på webbsidor och -applikationer.
Hjälp ska då finnas på atomär nivå i en applikation eller i ett formulärfällt (vid varje interaktionsdel).
Innehåll måste vara robust nog för att kunna tolkas på ett pålitligt sätt av ett brett spektrum av olika användarprogram, inklusive hjälpmedel.
HTML-kod ska validera och följa vald standard. Det ger största möjliga stöd från webbläsare, inklusive skärmläsare – både dagens och morgondagens versioner.
Se Riktlinje 1.3 Anpassningsbart.
Eftersom många av tjänsterna som utvecklas på Pensionsmyndigheten skapas bakom brandvägg kan de flesta av verktygen som testar tillgänglighet inte användas.
En del av dem har stöd för att testa webbsidors kod genom uppladdning i verktyget och en del tillägg finns att använda i webbläsaren.
Automatiska test i sig räcker sällan för att få en komplett bild av tillgänglighet på webbsidor. Men de är bra för att få en snabb bild över enkla missar.