Så här ser en Metodkoll-rapport ut

Tre sidor granskade: startsidan, en produktsida och sökfunktionen. Rapport som PDF plus utkast till tillgänglighetsinformation inom 48 timmar. 2 490 kr ex moms, betalas i förskott.

Hela exempelrapporten som PDF (41 sidor, 3,3 MB)

Kod- och flödesgranskning, ej hjälpmedelstest, ej certifiering, ej godkänd av PTS. Sitora är fristående och har ingen koppling till Post- och telestyrelsen. Metodkoll är Sitoras tjänst, och Sitora är en enmansfirma; företagsuppgifter finns i villkoren.

Det här är en Metodkoll-rapport i full längd, gjord på demobutiken Luma. Magento är en av de vanligaste e-handelsplattformarna, Luma är Magentos egen demobutik med påhittade produkter, och kopian vi granskade (magento2-demo.magebit.com) drivs öppet av en Magento-byrå. Demobutiken är inte en kund och inte ett prospekt. Vi valde den för att vem som helst kan öppna samma tre sidor och kontrollera det vi skriver, så länge demobutiken är oförändrad sedan den 19 september 2026.

Rapporten är gjord med samma verktyg och samma mall som en kundrapport: automatisk skanning av startsida, produktsida och sökfunktion, återskapning av varje träff i webbläsare med skärmdump, och sedan rapporten. Rapporttexten skrivs med hjälp av AI. Skanningen gav tolv möjliga brister. Elva kunde vi återskapa i webbläsaren; en visade sig inte vara någon brist och ströks. Den strukna står kvar i rapporten med motivering men räknas inte.

De elva bristerna går tillbaka på fyra orsaker i temat: huvudmenyns uppmärkning, sidhuvudets flikstruktur, produktsidans flikar och storleksvalens textfärg. Rapporten redovisar sida för sida, så samma fel i sidhuvudet räknas en gång per sida. Vid brister med samma orsak står det vilka andra brister som försvinner när orsaken rättas.

Tre saker skiljer exemplet från en kundrapport.

• Demobutiker skiljer sig från de butiker handlare faktiskt driver: tema, tillägg, kassa och innehåll är era egna, och det är där bristerna brukar sitta. En kundrapport görs på er webbplats, med ert namn, er plattform och era adresser.
• I en kundrapport är varje brist verifierad genom manuell återskapning i webbläsare. I exemplet är återskapningen gjord med ett eget program i webbläsaren, inte för hand, och rapporten säger det på varje brist och i garantiraden. Det är så garantin definierar en verifierad brist: återskapad för hand, med steg och skärmdump.
• Kontrollerna som skannern inte kan göra (tangentbordsnavigering, synligt fokus, zoom till 200 procent, smal skärm på 320 px, mobilvy) ingår i en kundrapport men är inte gjorda i exemplet. Exemplet är gjort utan kund att leverera till; de momenten görs av granskaren vid tangentbordet i varje kundleverans. Rapportens avsnitt 2.3 säger "Inte utförd" på den raden.

Siffrorna nedan gäller demobutiken den 19 september 2026, inte er butik.

Beställ Metodkoll, 2 490 kr ex moms

Samma tre sidor och samma rapport, på er egen webbplats. Svensk rapport inom 48 timmar från det att betalning och webbadress har kommit in, med skärmdumpar, kodnära åtgärder och utkastet till tillgänglighetsinformation. 2 490 kr ex moms, betalas i förskott.

Mikroföretag, det vill säga färre än tio anställda och högst 2 miljoner euro i omsättning eller balansomslutning, är undantagna från kraven på tjänster. Är ni osäkra på om ni omfattas, fråga oss innan ni beställer.

Kod- och flödesgranskning, ej hjälpmedelstest, ej certifiering, ej godkänd av PTS.

Minst fem verifierade brister, annars pengarna tillbaka. En verifierad brist är en avvikelse mot ett kriterium i WCAG 2.2 på nivå A eller AA, på någon av de tre granskade sidorna, som vi har återskapat manuellt i webbläsare och dokumenterat med steg och skärmdump. Hela definitionen finns i villkoren.

Ni kan avbeställa fram till dess att granskningen har startat och får då hela beloppet tillbaka.

Rapportens sammanfattning

Sidan efter försättsbladet är sammanfattningen. Det är den sidan en inköpare läser först, och den ska räcka för att förstå läget utan att bläddra vidare. Här är rapportens avsnitt 1, ordagrant.

Vi har granskat tre delar av https://magento2-demo.magebit.com/: startsidan, en produktsida och sökfunktionen. Det är samma tre delar som Post- och telestyrelsen (PTS) uppger att de granskar i sin planlagda tillsyn av e-handelstjänster (PTS, nyhet 2025-10-15). Vi har kontrollerat sidorna mot WCAG 2.2 nivå A och AA och kontrollerat om den information om tjänstens tillgänglighet som lagen kräver finns, var den finns och vad den innehåller.

1.1 Antal brister

Kandidater från den automatiska skanningen, per sida och allvarlighetsgrad. Allvarlighetsgraden är ett förslag, se avsnitt 2.4.

Antal unika WCAG-kriterier med kandidatbrist: 4 av 55 kriterier på nivå A och AA. Antal granskade sidor: 3 av 3.

Garantiavstämning: 11 brister återskapade med eget skript utan att använda axe:s bedömning. Garantin i våra villkor räknar brister som granskaren har återskapat för hand i webbläsare; i en kundrapport står här antalet sådana brister, och garantin är minst fem.

1.2 De viktigaste åtgärderna

1. B-07 – Klickbara element ligger inuti varandra (produktsida, P1). Ett klickbart element ligger inuti ett annat, till exempel en knapp inuti en länk eller en länk inuti en knapp.
2. B-01, B-04, B-08 – ARIA-roll saknar den förälder den kräver (startsida, produktsida, sökfunktion, P1). Ett element med roll menuitem, option eller listitem ligger inte i den behållare rollen kräver.
3. B-03, B-06, B-10 – Listpunkt utan lista (startsida, produktsida, sökfunktion, P1). Ett <li>-element ligger inte direkt i en <ul> eller <ol>.

1.3 Lagstadgad information om tjänstens tillgänglighet

Status: Kunde inte bedömas: ingen villkorssida hittades. Skannern hittade ingen villkorssida bland webbplatsens länkar, och ingen text om tillgänglighet på de sidor den läste. Punkten kunde därför inte bedömas; granskaren letar för hand. Se avsnitt 4. Ett utkast som ni kan utgå från finns i bilaga A.

1.4 Vad rapporten inte säger

Rapporten säger inte att webbplatsen uppfyller eller inte uppfyller kraven i lag (2023:254). Den visar vilka brister mot WCAG 2.2 nivå A och AA vi har kunnat peka ut på tre sidor, och vad som saknas i informationen om tjänstens tillgänglighet. Sidor och flöden som inte ingår i omfattningen har inte granskats. Se avsnitt 6.

Två saker att veta när ni läser tabellen. Den tolfte kandidaten, B-12 på sökfunktionen, ströks vid återskapningen: verktyget räknade ett fokuserbart omslag runt storleksvalen som klickmål, men de riktiga klickmålen är 40 × 30 px, och ett klick i den fria remsan väljer inget alternativ utan flyttar bara fokus till omslaget. B-12 står kvar under sökfunktionen i rapportens avsnitt 3.3 med den motiveringen, noteras i 3.4, och finns inte med i bilaga A:s tabell över kända brister. Och garantiraden i exemplet säger uttryckligen att de elva är återskapade med skript; i en kundrapport står där antalet brister som granskaren återskapat för hand.

Tre brister ur rapporten, för er utvecklare

Det här avsnittet är skrivet för er utvecklare eller byrå. Vill ni inte läsa kod: hoppa till beställningen.

Varje brist i rapporten har samma uppställning:

• kriterium, allvarlighetsgrad och prioritet,
• var elementet sitter, hur många element regeln träffar, och vilken verktygsregel som gav träffen,
• vilka skärmdumpar som hör till bristen: skannerns sidbild i bilaga B och återskapningens bild direkt under tabellen,
• granskarens rad för återskapningen i webbläsare,
• vad som händer för användaren och steg för att återskapa felet själv,
• nuvarande kod, kodnära åtgärd och granskarens anpassning för just den här webbplatsen,
• för de flesta regler ett standardexempel på rättad kod, vad som ska kontrolleras efteråt och var koden brukar ligga på plattformen.

Här är tre av de elva, ordagrant ur rapporten: en från varje granskad sida och tre olika kriterier. De övriga åtta finns i PDF:en.

Två saker att veta om texterna. Standardexemplen på rättad kod är regelns generella exempel och inte skrivna för demobutiken; rapporten säger det i etiketten ovanför varje sådant block, och där granskaren bedömt att exemplet inte gäller är det utelämnat. Det som är skrivet för just den här webbplatsen står under "Granskarens anpassning för den här webbplatsen".

Skärmdumparna är från återskapningen i Chromium 141, skrivbordsvy 1280 × 900, och samma bilder finns i rapporten (R02, R07 och R11–R13). Ramarna och rutan nedtill har vi lagt på; de hör inte till webbplatsen. Röd ram är skannerns första exempelelement, orange det andra, och rutan är en mätanteckning som upprepar granskarens rad; öppna bilden i full storlek för att läsa den. I B-02 omsluter båda elementen samma menyrad i sidhuvudet, så bara den orange ramen syns. I B-07 är den orange kanten på miniatyrbilden till vänster webbplatsens egen markering, inte vår.

B-02 · ARIA-roll saknar de barn den kräver

• Sida: Startsida, https://magento2-demo.magebit.com/
• Kriterium: 1.3.1 Information och relationer (nivå A). Princip: Uppfattningsbar
• Allvarlighet: Medel (förslag, satt utifrån regeltyp)
• Prioritet: P1 – förekommer på alla granskade sidor, ligger sannolikt i sidhuvud, sidfot eller tema
• Var: .section-items
• Omfattning: 2 element på startsida, varav 2 visas nedan (skannern sparar högst två exempel per regel)
• Verktygsregel: aria-required-children – Certain ARIA roles must contain particular children
• Skärmdump: S01 (bilaga B); från återskapningen: R02 (nedan)

Återskapning i webbläsare

Återskapad 2026-09-19 i Chromium 141.0.7390.37 (Playwright 1.56.1, headless), skrivbord 1280×900, prefers-reduced-motion: reduce, med eget skript utan att använda axe:s bedömning. Två element. (1) div.section-items har role=tablist men dess synliga barn är två div med role=tabpanel (#store.menu med hela huvudmenyn och #store.links); de två div[role=tab] som finns är dolda (display: none) i skrivbordsläge. En tablist får bara innehålla tab. Tillgänglighetsträd: tablist > tabpanel > navigation > menu. (2) ul#ui-id-1 har role=menu men alla sex barn är <li> utan roll (implicit listitem); en menu ska innehålla menuitem, menuitemcheckbox, menuitemradio, group eller separator. Tillgänglighetsträd: menu > listitem > menuitem. 2 noder, samma som skannern. Del (2) har samma orsak som B-01 och B-03.

Vad som händer

En roll som menubar, list eller tablist innehåller element som rollen inte tillåter. Hjälpmedlet får en meny som inte innehåller menyval, och innehållet kan hoppas över helt.

Så återskapar du

1. Leta upp .section-items i DevTools och jämför rollens krav med barnen i trädet.

Nuvarande kod, exempel 1 (förkortad av verktyget)

<div class="section-items nav-sections-items mage-tabs-disabled" role="tablist">

Nuvarande kod, exempel 2 (förkortad av verktyget)

<ul id="ui-id-1" role="menu" tabindex="0" class="ui-menu ui-widget ui-widget-content">

Kodnära åtgärd

Vanligaste och bästa åtgärden: ta bort role="menubar"/role="menu" från huvudmenyn. En navigering med länkar ska vara <nav><ul><li><a> utan ARIA-roller. Menyroller är till för programliknande menyer med piltangentstyrning.

Ska mönstret behållas måste hela det byggas: role="menubar" → role="menuitem" på varje val, tangentbordsstyrning med piltangenter, Home/End och Esc.

Granskarens anpassning för den här webbplatsen: Två delar. (1) Sidhuvudets div.section-items: i skrivbordsläge är flikarna dolda och elementet är bara en behållare. Ta bort role=tablist där, och role=tabpanel på #store.menu och #store.links, eller sätt rollerna bara i det läge där flikarna visas (mobilläget, inte mätt här). Samma element ger B-05 del 1 och B-09 del 1. (2) ul#ui-id-1: ta bort role=menu och role=menuitem, se B-01; då försvinner B-01, B-02 del 2 och B-03 tillsammans. Standardexemplet nedan gäller del 2.

Exempel på rättad kod (regelns standardexempel, inte skrivet för den här webbplatsen)

<nav aria-label="Primär navigering">
  <ul>
    <li><a href="/dam">Dam</a></li>
  </ul>
</nav>

Kontrollera efteråt: Kontrollera i DevTools fliken Accessibility att sidhuvudets behållare inte längre har rollen tablist i skrivbordsläge, och att huvudmenyn visas som list med sex listitem som vart och ett innehåller en link.

Rollerna sätts vid körning av temats JavaScript-widgetar (jQuery UI-menyn ger id:n ui-id-n; flikarna sätts av flikwidgeten), inte i .phtml-mallarna. Åtgärda i widgetens initiering (data-mage-init i temats mall) eller med en mixin i temat, under app/design/frontend/<Leverantör>/<tema>/.

B-07 · Klickbara element ligger inuti varandra

• Sida: Produktsida, https://magento2-demo.magebit.com/radiant-tee.html
• Kriterium: 4.1.2 Namn, roll, värde (nivå A). Princip: Robust
• Allvarlighet: Hög (förslag, satt utifrån regeltyp)
• Prioritet: P1
• Var: #tab-label-description
• Omfattning: 3 element på produktsida, varav 2 visas nedan (skannern sparar högst två exempel per regel)
• Verktygsregel: nested-interactive – Interactive controls must not be nested
• Skärmdump: S02 (bilaga B); från återskapningen: R07 (nedan)

Återskapning i webbläsare

Återskapad 2026-09-19 i Chromium 141.0.7390.37 (Playwright 1.56.1, headless), skrivbord 1280×900, prefers-reduced-motion: reduce, med eget skript utan att använda axe:s bedömning. Produktsidans flikar div#tab-label-description[role=tab][tabindex=0] 'Details' och div#tab-label-additional[role=tab][tabindex=0] 'More Information' innehåller vardera en länk: a#tab-label-description-title[href="#description"][tabindex=-1] respektive a#tab-label-additional-title[href="#additional"][tabindex=-1]. Länken tar programmatiskt fokus trots tabindex=-1 (element.focus() ger document.activeElement = länken), vilket är precis det axe varnar för: ett fokuserbart element inuti en annan kontroll. Tillgänglighetsträd: tab 'Details' > link 'Details'. Tredje noden div#tab-label-reviews 'Reviews (3)' har samma mönster med a[href="#reviews"]. 3 noder, samma som skannern.

Vad som händer

Ett klickbart element ligger inuti ett annat, till exempel en knapp inuti en länk eller en länk inuti en knapp. Hjälpmedel kan då inte avgöra vad som ska aktiveras, och tangentbordsanvändaren får ett oförutsägbart resultat. Vanligt i menyer där en länk har en egen "öppna undermeny"-knapp.

Så återskapar du

1. Öppna DevTools och leta upp #tab-label-description.
2. Kontrollera om ett <button> eller <a> ligger inuti ett annat klickbart element.
3. Tabba till elementet och kontrollera hur många tabbstopp det ger och vad Enter respektive mellanslag gör.

Nuvarande kod, exempel 1 (förkortad av verktyget)

<div class="data item title active" data-role="collapsible" id="tab-label-description" role="tab" data-collapsible="true" aria-controls="description" aria-selected="false" aria-expanded="true" tabind…

Nuvarande kod, exempel 2 (förkortad av verktyget)

<div class="data item title " data-role="collapsible" id="tab-label-additional" role="tab" data-collapsible="true" aria-controls="additional" aria-selected="false" aria-expanded="false" tabindex="0">

Kodnära åtgärd

Lägg elementen bredvid varandra i stället för inuti varandra: länken till kategorin, och en separat knapp för att fälla ut undermenyn.

Knappen får aria-expanded och aria-controls mot undermenyns id.

Behöver hela ytan vara klickbar, använd ett så kallat "stretched link": en länk med ::after som täcker kortet, och låt knappen ligga ovanpå med position: relative; z-index: 1.

Granskarens anpassning för den här webbplatsen: Här är det inte en meny utan produktsidans flikar: varje div[role=tab] innehåller en länk (a[href="#description"] med tabindex=-1). Ta bort länken och låt fliken själv bära texten med tabindex=0, eller byt till button[role=tab] utan inre länk. Det är samma flikstruktur som B-05 del 3. Standardtexten ovan (länk plus separat knapp) gäller menyer och passar inte här; regelns kodexempel är utelämnat.

Kontrollera efteråt: Tabba till flikraden och kontrollera att varje flik är ett enda tabbstopp, att Enter eller mellanslag öppnar fliken, och att DevTools fliken Accessibility visar tab utan någon link inuti.

Rollerna sätts vid körning av temats JavaScript-widgetar (jQuery UI-menyn ger id:n ui-id-n; flikarna sätts av flikwidgeten), inte i .phtml-mallarna. Åtgärda i widgetens initiering (data-mage-init i temats mall) eller med en mixin i temat, under app/design/frontend/<Leverantör>/<tema>/.

B-11 · För låg kontrast mellan text och bakgrund

• Sida: Sökfunktion, https://magento2-demo.magebit.com/catalogsearch/result/?q=radiant
• Kriterium: 1.4.3 Kontrast (minimum) (nivå AA). Princip: Uppfattningsbar
• Allvarlighet: Medel (förslag, satt utifrån regeltyp)
• Prioritet: P2
• Var: #option-label-size-144-item-166
• Omfattning: 2 element på sökfunktion, varav 2 visas nedan (skannern sparar högst två exempel per regel)
• Verktygsregel: color-contrast – Elements must meet minimum color contrast ratio thresholds
• Skärmdump: S03 (bilaga B); från återskapningen: R11, R12, R13 (nedan)

Återskapning i webbläsare

Återskapad 2026-09-19 i Chromium 141.0.7390.37 (Playwright 1.56.1, headless), skrivbord 1280×900, prefers-reduced-motion: reduce, med eget skript utan att använda axe:s bedömning. Storleksvalen 'XS' (#option-label-size-144-item-166) och 'XL' (#option-label-size-144-item-170) i produktkortet för Radiant Tee: 12 px fet text, CSS-färg rgb(148,148,148) på rgb(240,240,240), rutan 40×30 px. Mätt i bild (urklipp av rutan, 1 200 bildpunkter): bakgrund #f0f0f0 (79 % av bildpunkterna), mörkaste textbildpunkt #949494, kontrast 2,66:1; alla övriga textbildpunkter är ljusare (kantutjämning) och ligger ännu lägre. Kravet för text under 18,66 px fet är 4,5:1. Grannarna 'S', 'M' och 'L' har samma CSS-färger (skannern hade fem osäkra kontrastträffar på sidan). Förstoringar av rutorna XS och XL visas nedan.

Vad som händer

Texten har för låg kontrast mot sin bakgrund. Kravet är 4,5:1 för vanlig text och 3:1 för stor text (minst 18 pt, eller 14 pt fet). Låg kontrast drabbar den som har nedsatt syn, den som läser i solljus och den som använder en billig skärm. Grå hjälptext, priser i ljusgrått och text ovanpå bilder är de vanligaste fallen.

Så återskapar du

1. Öppna sidan i Chrome.
2. Högerklicka på texten och välj Granska (DevTools).
3. Klicka på färgrutan vid color i stilpanelen – DevTools visar kontrastvärdet och en linje för 4,5:1.
4. Kontrollera att elementet #option-label-size-144-item-166 ligger under gränsvärdet.

Nuvarande kod, exempel 1 (förkortad av verktyget)

<div class="swatch-option text" id="option-label-size-14..." index="0" aria-checked="false" aria-describedby="option-label-size-14..." tabindex="0" data-option-type="0" data-option-id="166" data-opti…

Nuvarande kod, exempel 2 (förkortad av verktyget)

<div class="swatch-option text" id="option-label-size-14..." index="4" aria-checked="false" aria-describedby="option-label-size-14..." tabindex="0" data-option-type="0" data-option-id="170" data-opti…

Uppmätt kontrast 2,66:1 mellan #949494 och #f0f0f0, textstorlek 9 pt fet. Kravet för den storleken är 4,5:1. Textfärgen #6d6d6d på samma bakgrund ger 4,54:1 och är närmaste nyans av den nuvarande färgen som klarar kravet.

Föreslagen åtgärd (CSS, på klassen eller variabeln som styr elementet)

.swatch-option.text {
  color: #6d6d6d; /* var #949494, 2,66:1 mot #f0f0f0 */
}

Kodnära åtgärd

Ändra textfärgen (eller bakgrunden) tills kontrasten når gränsvärdet. Ändra i variabeln eller klassen, inte på det enskilda elementet, annars återkommer felet på nästa sida.

Ligger texten ovanpå en bild räcker det sällan att byta färg: lägg ett halvtransparent lager under texten, eller flytta texten till en ruta med egen bakgrund.

Kontrollera samtidigt hovrings- och fokusläget – de har ofta en annan färg som också måste klara gränsvärdet.

Granskarens anpassning för den här webbplatsen: Sätt färgen på klassen .swatch-option.text i temats CSS för storleksval, inte på id:t, som genereras per attributvärde. Kontrollera även markerat och hovrat läge, som kan ha egna färger (inte mätt här), och samma rutor på produktsidan.

Kontrollera efteråt: Mät om med DevTools eller ett kontrastverktyg efter ändringen, både i normalläge och vid hovring.

I Magento ligger mallarna i app/design/frontend/<Leverantör>/<tema>/ som .phtml-filer och i web/css/source/.

Kodförslagen i rapporten är exempel som anpassas till er kodbas och testas innan de sätts i produktion. Det står i rapportens avsnitt 6, och det gäller även ovan. Färgförslaget i B-11 är uträknat, inte gissat: den ljusaste grå nyans av den nuvarande färgen som når 4,5:1 mot samma bakgrund, kontrollerad med samma formel som verktyget använder.

Bilaga A: utkast till tillgänglighetsinformation

Lagen (2023:254) kräver att e-handlare tar fram information om tjänstens tillgänglighet, och enligt PTS föreskrifter ska den ingå i de allmänna villkoren eller motsvarande dokument. Skannern hittade ingen villkorssida i demobutiken och ingen text om tillgänglighet på de sidor den läste, vilket är väntat för en demobutik, och rapporten säger det i avsnitt 1.3 och 4. Bilaga A är därför ett utkast ni kan utgå från. I en kundleverans följer samma text också med som en egen PDF. Tabellen över kända brister tar bara med de återskapade bristerna, inte den strukna kandidaten.

Utkastet har åtta avsnitt: om tjänsten och hur den fungerar, vilka tillgänglighetskrav som gäller för tjänsten, hur tjänsten uppfyller kraven med en tabell över kända brister, undantag, så kontrollerar ni tillgängligheten, hur man får informationen muntligt eller i annat format, hur man rapporterar brister och kontaktar er, samt tillsyn. Sist finns en checklista före publicering. Det vi kan se utifrån är ifyllt: adress, sökfältets ledtext, datum, rapport-id och de brister rapporten pekade ut. Det vi inte kan veta står i gula fält som ni fyller i själva, till exempel betalsätt, kundtjänstens telefonnummer och hur ni kontrollerar nya funktioner innan de publiceras.

Ett kort utdrag, ordagrant (första stycket, inledningen till tabellen, två av tabellens elva rader samt raden om senaste externa granskning):

Texten nedan är ett underlag som bygger på vad vi kunde se utifrån vid granskningen 2026-09-19. Gula fält är sådant vi inte kan veta och som ni fyller i själva. Gå igenom varje avsnitt, stryk det som inte stämmer och lägg in texten i era allmänna villkor eller i ett dokument som villkoren länkar till. Utkastet är inte juridisk rådgivning, och ni ansvarar för innehållet.

…

Nedan listas de punkter som en extern kod- och flödesgranskning av startsidan, en produktsida och sökfunktionen pekade ut 2026-09-19. Magentos demobutik Luma fyller i planerad åtgärd och stryker det som redan är rättat.

…

Senaste externa granskning: Metodkoll av Sitora, 2026-09-19. Omfattning: startsidan, en produktsida och sökfunktionen. Kod- och flödesgranskning, ej hjälpmedelstest, ej certifiering, ej godkänd av PTS.

Vad rapporten är och inte är

Kod- och flödesgranskning, ej hjälpmedelstest, ej certifiering, ej godkänd av PTS. Sitora är fristående och har ingen koppling till Post- och telestyrelsen.

Rapporten säger inte att er webbplats uppfyller eller inte uppfyller kraven i lagen. Den visar vilka brister mot WCAG 2.2 nivå A och AA vi har kunnat peka ut på tre sidor, hur man återskapar dem, hur man rättar dem, och vad som saknas i informationen om tjänstens tillgänglighet.

Beställ

Samma tre sidor och samma rapport, på er egen webbplats. 2 490 kr ex moms, betalas i förskott. Mikroföretag, det vill säga färre än tio anställda och högst 2 miljoner euro i omsättning eller balansomslutning, är undantagna från kraven på tjänster. Är ni osäkra på om ni omfattas, fråga oss innan ni beställer.

Kod- och flödesgranskning, ej hjälpmedelstest, ej certifiering, ej godkänd av PTS.