Accessibility statement

Last updated: 2026-09-21

Skolkoll applies the Swedish Web Accessibility Act (DOS-lagen) in full — and is currently partially compliant with it. We report the remaining issues in section 2. Level A and AA issues are given a remediation deadline no later than 90 days after the latest publication of this statement, unless another date is given. Issues concerning AAA criteria fall outside the level this statement commits to; they are disclosed openly but carry no commitment date, and that is stated at each such entry.

Skolkoll is responsible for this website. We want as many people as possible to be able to use skolkoll.se. This statement describes how Skolkoll measures up against WCAG 2.1 level AA — what meets the requirements and what does not — and how you can report problems to us so we can fix them.

Skolkoll is a private operator that targets, among others, the Swedish public sector (municipal licences for school data). We therefore apply the requirements in EU Directive 2016/2102 (the Web Accessibility Directive) and Sweden's Act (2018:1937) on the accessibility of digital public services as if they applied in full.

1. How accessible is the website?

We are aware that parts of the website are not fully accessible. Skolkoll is partially compliant with the Swedish Web Accessibility Act. The issues that exist are described in section 2 below.

The original assessment was made on 2026-04-29 against WCAG 2.1 level AA. At that time 16 issues were identified — 7 serious (P1), 5 substantial (P2) and 4 minor (P3). All 7 P1 issues and all 5 P2 issues have been remediated (see history in section 2.5). Of the four P3 issues, two were verified away against production (1.4.12 and 2.5.5). The other P3 findings from the original assessment concerned 3.1.5 and 3.3.3; their current status is described below. That priority scale applies to that assessment only; findings made since have not been triaged on the same scale and are therefore reported per WCAG criterion and measured value rather than with a severity label.

Current status and outstanding verification:

• 1.4.3 Contrast (Minimum), level AA — corrections included. A re-audit against the then-production build d79fb0a87 (2026-09-02) found text below 4.5:1. The historical measurements are reported by surface in section 2.1; none of the surfaces appeared after 2026-09-03. Corrections for these surfaces are included in this version. This does not mean that contrast across the entire website has been verified again.
• 3.3.3 Error Suggestion, level AA — verification outstanding. The school-choice wizard now stops a search with no factors selected and shows a helpful error message. The older description of an empty result does not match the current code. Full manual verification remains outstanding (section 2.3).
• 3.1.5 Reading Level, level AAA — open, outside the level this statement covers. AAA criteria fall outside the level this statement commits to and therefore carry no commitment date (section 2.3).
• Evidence gap: the manual screen-reader review, tracked in #2229, has started but is not finished. NVDA + Firefox was run 2026-09-12 to 2026-09-14 by an external tester, but not every protocol step; VoiceOver + Safari is still entirely outstanding, and all assistive-technology testing on mobile is deferred. The issues that the run found have implemented fixes but have not yet been re-tested with a screen reader in production. The review may therefore produce further findings (section 5).

The commitment for level AA — 1.4.3 and 3.3.3 — remains: corrections and outstanding verification are due no later than 2026-10-16. The previously reported level A findings have implemented fixes (section 2.5). Republishing this statement does not restart the remediation date of an individual issue — the 90-day rule in the introduction sets a ceiling for newly disclosed issues; it does not extend a date already given.

If issue #2229 still shows the previous deadline of 2026-09-16, the date in this statement applies. The previous deadline has passed; the issue's schedule is being updated as part of publication.

2. Content that is not accessible

Remaining limitations, implemented corrections and historical findings are reported below per WCAG criterion. Historical measurements describe the specified build, not a new measurement of this version.

About the phrase "no known remaining issues". It rests on the self-assessment, the automated checks in CI and the part of the manual screen-reader testing that has been carried out. That part is not finished (sections 1 and 5) and may produce further findings. The phrase is therefore not a conformance certificate for the criterion — it states what we know today.

2.1 Perceivable

1.1.1 Non-text Content (level A)

• No known remaining issues. The home-page logo suffix previously duplicated the page title for screen readers; from #2118 onward the logo image has an empty alt and the full accessible name sits in the sr-only span without a leading dash.

1.3.1 Info and Relationships (level A)

• No known remaining issues. Sortable table columns previously lacked aria-sort; from #2221 onward (fixed 2026-04-29) the SSR template sets aria-sort="none" on all sortable <th>, and the active column is promoted to ascending/descending after each sort update. The duplicate header structure on the home page is also remediated because the home hero now renders as a named section.
• Implemented corrections; manual re-testing remains outstanding. The comparison dialog did not expose its data as a table, missing values were read as silence, and municipality key figures were read value before label (#6166). The corrections are described in section 2.5.

1.4.1 Use of Color (level A)

• No known remaining issues. The map's metric colouring previously used a red-to-green scale via yellow (discriminating against deuteranopia/protanopia); from #2223 onward (fixed 2026-05-05) it uses a perceptually uniform viridis scale (dark purple → teal → light yellow), which is colour-blind-safe under deuteranopia, protanopia and tritanopia.
• No known remaining issues. Map status indication (ACTIVE/DORMANT/CLOSED) previously relied on green/orange/red alone; from #2223 onward it uses the Okabe-Ito colour-blind-safe palette (bluish green / orange / vermillion / sky blue), which is distinguishable under all common colour-vision deficiencies. The map legend also has text labels per status.

1.4.3 Contrast (Minimum) (level AA)

• Historical contrast findings and implemented corrections. A contrast re-audit against production build d79fb0a87 (2026-09-02) found text below the 4.5:1 the criterion requires for normal text. The surfaces are listed individually below rather than as a number of issues, because where one finding ends and the next begins has not been settled. The values below describe the earlier build, before the corrections; none of the surfaces appeared after 2026-09-03. Earlier versions of this statement claimed the opposite — that text and user-interface components met the AA requirement — which was wrong; see the version history in section 8.

  To read the figures: 4.5:1 is the threshold for normal text. 4.48:1 is just below it — legible, but not conformant. Around 2:1 is weak and hard to read for many people. Around 1.1:1 means the text is effectively invisible against its background.

  • 3.63:1, dark theme. The "Enterprise" eyebrow in the product CTA module. The module is used in the school-overview, municipality and county templates and the dynamic statistics templates, in Swedish and English. Standalone statistics articles do not use the module. It affects a single label line inside the module, not the page's body text. Historical finding: #5806.
  • 1.12:1, dark theme. The "this supervision record may be out of date" banner on school pages. It used an undeclared --surface-2 token whose light fallback stayed in place as the background in dark mode, while the text on top of it was light. Whether this counts as a separate issue or as part of #5806 has not been settled — one of the reasons we enumerate surfaces rather than issues. Its correction belongs with the eyebrow above, under #5806 rather than #6257, despite the shared mechanism with the next entry.
  • 1.13:1, mostly dark theme. Eight --surface-* tokens that then lacked declarations: their light fallback colour stayed in place as the background while the text on top of it turned light in dark mode — light on light. It affects individual blocks — key-figure cards, table headers, warning and info callouts, contact cards — not whole pages; the rest of the text on the same page is unaffected. Affected pages: /statistik/dubbelt-utsatta/, /statistik/friskolekoncerner/, /statistik/koncerner-vs-salsa/, /statistik/nojdhet-vs-resultat/, /statistik/skolenkaten/, /statistik/trendranking/, /upphandling/, /kunder/, /kommunlicens/, /antagning/, /antagning/<kommun>/, /antagningssimulator/, /arsrapport/, /syv-underlag/, /om/skolkoll-i-siffror/, /huvudman/<slug>/ and /koncern/<slug>/, plus the /en/ counterparts of those that exist in English. Historical finding: #6257.
  • 4.48:1, light theme. Small info labels on /skola/<slug>/data/ and /en/school/<slug>/data/. Those pages are not search-indexed, but users reach them through the tabs on the school page. Historical finding: #6258.
  • 2.09:1, both light and dark. Unchecked history-layer chips on the same two pages, where the defect had existed since 2026-06-02. The chips are operable checkboxes, so the exception for inactive user interface components does not apply. Historical finding: #6259.
  • 1.11:1, both light and dark. The text in the quality badge's key figures. It renders on /skola/<slug>/, /en/school/<slug>/, /kommun/<slug>/ and /en/municipality/<slug>/ — all search-indexed — and on the two school data pages above, which are not. The comparison pages show their own, separately coded quality badge, which this finding does not cover. Historical finding: #6260.

  The widgets. None of the surfaces above renders on the four embeddable widget routes. This was checked in the source for this publication: none of the affected components is imported by the widget pages, and none of the eight undeclared --surface-* tokens is used there. That check is a source review, not a browser measurement; the full manual audit of the widgets is still outstanding (section 5).

  This version includes the corrections: the product-card eyebrow and supervision banner (#6225), page surface tokens (#6245), info labels (#6241), history-layer chips (#6251), and quality badge (#6252). Implementation and scoped checks are not a new whole-site review. The commitment for these surfaces remains 2026-10-16; they were not disclosed under the previous date, 2026-09-16. Only one surface (#6259) has a verified date for when it appeared; for the others we know they were present in build d79fb0a87 but not exactly how long they had been.

1.4.10 Reflow (level AA)

• No known remaining issues. The dated evidence is the text-spacing sweep of 2026-08-25, which at 375 px measured 0 controls with clipped content and no horizontal page scroll (protocol: docs/audits/a11y-1412-textavstand-2026-08-25.md). That sweep covered the home-page hero; reflow has not been measured separately per page template. That smooth scrolling respects prefers-reduced-motion belongs to 2.3.3, not here.

1.4.11 Non-text Contrast (level AA)

• No known remaining issues. The search clear icon previously had insufficient contrast (white icon on a translucent-white pill); from #2226 onward the pill uses a dark-translucent fill with a white border so both the icon and its pill have ≥3:1 against the surrounding hero.

1.4.12 Text Spacing (level AA)

• No known remaining issues. It was previously reported that hero chip buttons could be truncated at increased text spacing. Verified against production on 2026-08-25 — the issue does not exist. Method: WCAG 1.4.12's four values were applied as an !important override (line-height: 1.5, letter-spacing: 0.12em, word-spacing: 0.16em, paragraph spacing 2em) and every interactive hero element was re-measured, comparing scrollWidth/scrollHeight against clientWidth/clientHeight. The sample was taken structurally — every visible interactive element in the hero, including the search field, the clear button (which only renders once the field has content), nearby-btn, search-submit and the guide link. The sweep was run in three states — default, with "Fler filter" expanded, and with the "Nära mig" picker open — because several controls only exist once the user opens something. Result with all states open: 24 controls at 375 px and 26 at 1280 px, 0 with clipped content, and no horizontal page scroll. The counts differ between widths because two controls exist only at desktop width. The chips use min-height, not a fixed height, and white-space: normal — they wrap rather than clip. The protocol is in docs/audits/a11y-1412-textavstand-2026-08-25.md.

2.2 Operable

2.4.3 Focus Order (level A)

• No known remaining issues. The cookie banner previously stole initial focus without restoring it; from #2224 onward (fixed 2026-05-05) the previously active element is captured in previouslyFocused before the banner appears, and focus is returned to that element when the user accepts or rejects.
• Implemented corrections; manual re-testing remains outstanding. The comparison bar's buttons sat in tab order after the entire footer, and the bar stayed on top of the open comparison dialog (#6165). The corrections are described in section 2.5.

2.5.5 Target Size (level AAA)

• No known remaining issues. The statement previously recorded the search clear button as ~31×31 px and therefore below the AAA threshold. Verified against production on 2026-08-26 — the button is 44×44 px, meeting the AAA threshold of 44×44 in 2.5.5. (It also clears, with room to spare, the 24×24 threshold in WCAG 2.2 SC 2.5.8 Target Size (Minimum), level AA. This statement declares WCAG 2.1, which has no level AA target-size threshold; an earlier version wrongly called 24×24 an AA threshold under 2.1.) .search-clear is set to width: 2.75rem; height: 2.75rem at a 16 px root size, measured at 44×44 px at both 375 px and 1280 px. The earlier figure was incorrect and has been removed rather than deferred.

2.3 Understandable

3.1.2 Language of Parts (level AA)

• No known remaining issues. English programme names (e.g. "International Baccalaureate") on Swedish school pages previously lacked a language tag; from #2226 onward they are wrapped in <span lang="en">.

3.1.5 Reading Level (level AAA)

• Text on the home page is at Swedish B1–B2 level. AAA requires text to be understandable at lower secondary level (plain-language). The site targets AA. The criterion is AAA and falls outside the audit's declared level, so it is not an AA blocker and is not scheduled under the statement's commitment date. There is currently no open work item for plain-language Swedish. The statement previously pointed at #1380, but that issue was closed as "will not be done" on 2026-04-28 — the day before this statement was first published. The reference was therefore wrong from the start, and it is removed rather than replaced with a tracker that does not exist. (Severity in the original assessment: P3, AAA)

3.3.1 Error Identification (level A)

• Implemented corrections; manual re-testing remains outstanding. The school-choice wizard's validation aborted silently: the error message was shown visually only, and the field got neither aria-invalid nor a link to the error text (#6163). The corrections are described in section 2.5.

3.3.3 Error Suggestion (level AA)

• Validation has changed; manual verification remains outstanding. The school-choice wizard shows a helpful message and stops the search when no factor is selected. When distance is weighted but a location is missing, an error is shown, the address field receives aria-invalid and focus moves to it. The fixes in #6167 mean that the older description of an empty result without validation no longer describes the current code. We do not mark the criterion as fully verified: the remaining manual review is tracked in #2229. The previous commitment date was 2026-09-16, after moving from 2026-08-28 to 2026-09-16 on 2026-08-25; verification was not complete at that deadline. The commitment remains 2026-10-16. (Priority in the original assessment: P3. The assessment incorrectly listed AAA; the criterion level was corrected to AA in the 2026-08-25 update.)

2.4 Robust

4.1.2 Name, Role, Value (level A)

• No known remaining issues. The sticky header was previously rendered with data-visible="false" only, leaving its links in tab order so screen readers heard both navigations; from #1951 onward the SSR template renders the sticky header with both hidden and inert (plus aria-hidden="true"), and sticky-header.js toggles inert/hidden in sync with visibility.
• Implemented corrections; manual re-testing remains outstanding. The manual NVDA run in September 2026 found three issues against this criterion in the build tested at that time: the school-choice wizard's school-type and weighting buttons exposed no selected state (#6162), and neither the wizard nor the map popup had an accessible name when focus moved into it (#6164). The corrections are described in section 2.5.

4.1.3 Status Messages (level AA)

• No known remaining issues. The KPI summary on the home page previously used aria-live="polite" directly on the visible cards, which spammed screen readers during fast typing; from #2225 onward the announcement has moved to a separate debounced role="status" region, now updated after 700 ms without new input; pending loads and late search indexes can defer the write, up to 5 seconds.
• Implemented corrections; manual re-testing remains outstanding. The wizard's status line was a plain paragraph with no live region, so search, validation and location-error messages were silent for screen readers (#6163). The comparison bar did not announce how many schools were selected (#6165), and the home-page search status was announced on every keystroke from two visible regions while the region intended to carry it was never announced at all (#6166). The corrections are described in section 2.5.

2.5 History — remediated issues

Seven P1 (serious) issues and five P2 issues were identified in the 2026-04-29 assessment. All P1 and P2 issues have now been remediated.

• Fixed 2026-04-29: 1.3.1 Sortable table columns lacked aria-sort — fixed in #2221.
• Fixed 2026-05-05 (P2): 1.1.1 Coat-of-arms images on the home page now have fallback names through aria-label on the link — fixed in #2226.
• Fixed 2026-05-05 (P2): 1.3.1 SSR selects for status and school type now expose loading state with aria-busy until options are populated — fixed in #2226.
• Fixed 2026-04-29: 3.1.2 English programme names (e.g. "International Baccalaureate") on Swedish school pages lacked a language tag — fixed in #2226.
• Fixed 2026-04-28: 4.1.2 <div role="button"> on #table-tools-toggle migrated to native <button> — fixed in #2163.
• Fixed 2026-05-05: 4.1.3 KPI summary announced too aggressively — moved to a debounced role="status" region in #2225.
• Fixed 2026-05-05: 1.4.1 Map metric scale switched from red–green to viridis (colour-blind-safe) — fixed in #2223.
• Fixed 2026-05-05: 1.4.1 Map status colours switched to the Okabe-Ito colour-blind-safe palette — fixed in #2223.
• Fixed 2026-05-05 (P2): 1.4.11 The search clear icon now has a contrasting dark pill background, white border and white icon — fixed in #2226.
• Fixed 2026-05-05: 2.4.3 Cookie banner now restores focus to the previously focused element on accept/reject — fixed in #2224.
• Fixed 2026-05-23 (P2): 4.1.2 Sticky header is now SSR-rendered with hidden, inert and aria-hidden="true" so hidden links no longer reach tab order or screen readers — fixed in #1951.
• Fixed 2026-05-30 (P2): 1.3.1 Home hero no longer renders as a second <header> landmark inside <main>; it is now a named section — fixed in #3560.

The manual NVDA + Firefox run of 2026-09-12 to 2026-09-14 (part of #2229) produced new findings that were not in the 2026-04-29 assessment. Their fixes are already included in production version v1.21.29 — but have not yet been re-tested with a screen reader in production. They have not been triaged on the P1/P2/P3 scale above and are therefore reported per criterion. The run produced 16 reported findings plus two owner observations: one from the speech logs and one from a screenshot. Three of the reported ones were re-triaged as not being issues — correct ARIA, expected Tab behaviour, or a screen-reader artefact — and one was not a separate finding but the same defect as another. That left twelve issues plus the two observations; they are grouped per criterion below:

• Correction in v1.21.29: 3.3.1 Error Identification (level A) — the wizard's validation aborted silently. Clicking "Show results" with no criterion set, or entering a location that could not be resolved, showed the message visually only: the field got neither aria-invalid nor a link to the error text. Fixed in #6163 through #6167.
• Correction in v1.21.29: 4.1.2 Name, Role, Value (level A) — the wizard's school-type and weighting buttons lacked aria-pressed, so the selected state could not be read. Fixed in #6162 through #6167.
• Correction in v1.21.29: 4.1.2 Name, Role, Value (level A) — neither the wizard nor the map popup had an accessible name when focus moved into it. Fixed in #6164 through #6167.
• Correction in v1.21.29: 4.1.3 Status Messages (level AA) — the wizard's status line had no live region (#6163); the comparison bar did not announce the number of selected schools (#6165); the home-page search status was announced on every keystroke from two visible regions while the region intended to carry it was never announced at all (#6166).
• Correction in v1.21.29: 2.4.3 Focus Order (level A) — the comparison bar's buttons sat last in tab order, after the entire footer, and the bar stayed on top of the open comparison dialog (#6165). After "Search schools", users also had to locate the results table themselves; focus now moves to the results heading (#6166).
• Correction in v1.21.29: 1.3.1 Info and Relationships (level A) — the comparison dialog did not expose its data as a table, missing values were read as silence, and municipality key figures were read value before label. Fixed in #6166.
• Correction in v1.21.29, no criterion of its own: the comparison dialog had no control for removing an individual school. This was not a criterion failure — the checkbox in the results table already removed a school — but it was a practical obstacle for screen-reader users, and it was fixed alongside the rest (#6166).

What works

Being clear about what does work matters as much as reporting what does not. The following rests on the self-assessment, the automated checks in CI and the part of the manual testing that has been carried out, and holds after this publication. It is not a conformance certificate: where a criterion has a known open issue, the entry says so.

• Keyboard and focus. The flows we have been through can be operated with the keyboard alone. There is a skip-to-content link first in tab order, and the focus indicator is visible. The cookie banner returns focus to the element you were on (2.4.3, 2.4.7). The pass is not exhaustive — the manual keyboard and screen-reader sweep is not finished, and the comparison bar’s earlier focus-order defect is included in the re-testing.
• Screen readers. Pages have a single <h1> and a correct heading hierarchy, landmarks (main, nav, header) and programmatic names on interactive elements. Sortable tables expose aria-sort, and status updates are announced through a debounced role="status" region without being intrusive (1.3.1, 4.1.2, 4.1.3). The issues the manual NVDA run found against these criteria have implemented fixes (section 2.5), but the review is not finished.
• Colour. The map's scales use colour-blind-safe palettes (viridis for metrics, Okabe-Ito for status) and information is never conveyed by colour alone (1.4.1). User-interface components and graphics have no known issues against the non-text contrast requirement (1.4.11).
• Contrast. The historical findings below 4.5:1 and their corrections are reported in section 2.1 (1.4.3). Corrections cover labels, chips, key figures and the backgrounds of certain blocks. We do not claim that all pages have thereby been verified against the contrast requirement.
• Motion and magnification. Animations and smooth scrolling respect prefers-reduced-motion (2.3.3). Pages can be magnified, and the dated sweep of the home page at 375 px produced no horizontal page scroll and no clipped content (1.4.10) — but reflow has not been measured separately per page template, see section 2.1.
• Dark mode and language. The website follows the system's light/dark setting. Several historical contrast findings in section 2.1 concerned dark mode; the corrections cover this mode too. The page language is declared and English inserts are marked with lang="en" so screen readers pronounce them correctly (3.1.1, 3.1.2).

All seven serious (P1) and five substantial (P2) issues from the original assessment are remediated — see the history in section 2.5. What remains is verification and follow-up for 1.4.3 and 3.3.3, the manual screen-reader review that has started but is not finished, and 3.1.5 (AAA, outside the level this statement covers). All of it is listed openly in sections 1 and 2.

3. Disproportionate burden

Skolkoll does not invoke disproportionate burden under section 12 of the Act (2018:1937) for any part of this website. The previously reported level A findings have implemented fixes. For 1.4.3 Contrast (Minimum) and 3.3.3 Error Suggestion, both level AA, section 2 reports implemented corrections and outstanding verification. The commitment date in section 1 remains unchanged. The remaining AAA issue (3.1.5) is a criterion the Act does not require; it is disclosed openly in section 2 rather than omitted. The outstanding evidence task — the manual screen-reader review — is tracked in #2229 and has started but is not finished; it may produce further findings.

4. Content not covered by the law

The following content on skolkoll.se is not covered by the requirements of the Act on the accessibility of digital public services:

• Third-party content outside our control. The open APIs from Skolverket, SCB, Bolagsverket and Skolinspektionen deliver text and documents whose layout we cannot control. When such content is embedded (e.g. document lists from Skolverket), accessibility issues in the source material may occur. This is exempted under Article 1.4(b) of the Web Accessibility Directive (third-party content not funded or developed by us).
• Embedded maps (Leaflet/OpenStreetMap) for non-navigational purposes. The map on the home page is a complement to the searchable table. The table is the primary entry point for keyboard users. School markers in the map are now keyboard-reachable, but online maps are explicitly exempted in Article 1.4(c) of the Directive and we apply the exemption restrictively.
• Third-party libraries. D3.js and Leaflet are served locally from skolkoll.se. Any accessibility issues in the libraries' own components (e.g. Leaflet's default controls) are outside our codebase but are documented and reported to the respective maintainers.

5. How we tested the website

This accessibility statement is based on:

• Self-assessment via manual code review against the WCAG 2.1 AA success-criteria checklist. The review was carried out in April 2026 by the platform team and is documented in docs/audits/a11y-2026-04.md, which is available on request.
• Scope of the review covers: home page, school page, municipality page, comparison view, hero navigation, Leaflet map, cookie banner, and embeddable widgets.
• Embeddable widgets: the four widget routes (municipality key figures, municipality top-5 schools, school profile and nearby schools) are in the automated a11y scope in CI (Pa11y WCAG2AA and Lighthouse after staging deployment and in its nightly run). The automated checks pass — but as the note on reach below shows, that does not mean the page meets the requirements, only that the checks that do run report nothing. A draft assessment also exists, docs/audits/widget-a11y-conformance-2026-06.md, available on request. A full manual audit (keyboard + screen reader + reflow) for the widgets is still pending and is tracked in #2229, which carries the whole manual sweep; the groundwork was done under #4088. This assessment is therefore a draft — automated checks pass, manual audit pending — not a conformance certificate.
• Review process: Five review rounds with adversarial methodology (parallel reviewers + sceptical verification + final arbitration) — see docs/audits/a11y-audit-methodology.md.
• Manual screen-reader testing — started, not finished. An external tester ran NVDA + Firefox from 2026-09-12 to 2026-09-14. Every protocol step was run for journeys 1 and 4; journey 3 except its aria-sort step; journey 5 except its empty/zero-result state; journey 2 only partially. VoiceOver + Safari is still entirely outstanding, and iOS is explicitly deferred. The run produced 16 reported findings plus two owner observations: one from the speech logs and one from a screenshot. Three were re-triaged as not being issues (correct ARIA, expected Tab behaviour or a screen-reader artefact) and one was not a separate finding; the rest have implemented fixes (section 2.5) but have not yet been re-tested with a screen reader in production. The remaining steps may produce further findings. The run also has quality gaps of its own, which we disclose openly: journeys 2 and 4 were run without evidence of a fresh consent state, journey 5 was run with a second private tab open against the instructions, the Firefox version is not documented, and journeys 2, 4 and 5 were failed by the tester without being re-tested. The protocol and execution summary are in docs/audits/a11y-screenreader-2026-04.md. The raw NVDA speech logs are under docs/audits/evidence/a11y-2229-nvda-2026-09-12/; the work is tracked in #2229.
• Automated checks — and how far they reach. Pa11y (HTML_CodeSniffer, WCAG2AA) runs in CI in both the light and the dark theme. Lighthouse's accessibility check also runs in CI, but in the light theme only. A WAVE audit runs against production after every release. All of them run against fixed URL lists that differ from each other and that do not cover every page — they are samples per page template, not a sweep. Automated findings can cause checks to fail, but a passing sample is not a certificate for the whole website. Which URLs each list contains is set out in the audit evidence, available on request.

  The automatic dark run after staging deployment exceeded the zero baseline on five pages, which became #5806. The issue did not name the rule behind the finding — it explicitly left that open — and only a later re-run of the same audit, with full findings, attributed it to the "Enterprise" eyebrow and additionally found the stale supervision banner. The banner therefore comes from that re-run, not from the initial run's report — one of the reasons section 2.1 says the boundary between the banner and #5806 has not been settled. Most of the other surfaces sit on pages no list reaches. But at least one surface — the quality badge (#6260) — sits on page types the lists do cover and was still not reported. The follow-up is tracked in #6260. Why is under investigation; it may be that the badge does not render on the particular URLs in the list, or that the check cannot measure it. The platform team owns this; the investigation is due by 2026-10-16 and will be reported at the next publication of this statement. Until then the phrase "no known remaining issues" rests on a checking chain with a known hole.

• The contrast re-audit in section 2.1 was made against production build d79fb0a87 (2026-09-02) with the same engine plus computation from the token values in public/styles.css.

The most recent full assessment was made on 2026-06-18. That assessment's conclusion — "four P3 issues remain, none of them an AA blocker" — has proven incomplete, which is what this statement corrects. No new whole-site review has been made since; the next one is planned as described in section 8. This statement is updated after every major accessibility remediation and at least annually. (Earlier versions stated here that the website was published before 23 September 2018 — the transitional rule in DOS-lagen that determines which compliance deadline applies. We lack evidence for the claim that publication preceded that date. The claim was removed on 2026-09-21; we make no claim under that transitional rule.)

6. Contact and feedback

We want to know if you find accessibility issues on skolkoll.se so we can fix them. You can also request information in another format if you need it — for example a printable version or text without tables.

Contact us:

• Email: info@skolspegeln.se
• Write "Accessibility" in the subject line and the message will be routed directly to the right person.

We aim to respond within 14 days. If we need more time to resolve an issue we will inform you of a preliminary timeline.

7. Enforcement procedure

The Swedish Agency for Digital Government (DiGG) is responsible for supervision of the Act on the accessibility of digital public services. If you are not satisfied with how we handle your feedback, or if you have complaints about how the website complies with the law, you can report it to DiGG.

Report an accessibility issue to DiGG: digg.se/tdosanmalan (Swedish form).

For procurers

If you are buying Skolkoll for a municipality or another public body, you need to document the service's accessibility in your own procurement and DOS follow-up. Audit evidence can be released on request:

Read this first: this statement is not a conformance certificate, neither as a whole nor for an individual criterion. It reports what we know today. The site is partially compliant (section 1), AA corrections and outstanding verification are reported with a commitment date, and the manual screen-reader review is not finished. Do not embed a claim of full conformance in your procurement documentation on the strength of this document.

• This statement reports status, known issues per WCAG criterion and the remediation plan.
• The audit evidence covers the self-assessment against WCAG 2.1 AA, the review methodology and the screen-reader protocol. Available on request.
• The embeddable widgets (municipal licence) have a separate draft conformance assessment; the full manual audit is tracked in #2229. None of the contrast surfaces in section 2.1 renders on the widget routes — see the note there for how that was checked.
• Security and data protection for procurement is collected on our security page.

If you need documentation in a particular format — for example an EN 301 549 mapping or a VPAT equivalent — contact us at info@skolspegeln.se and we will produce it.

8. Last updated

This statement was first prepared and published on 2026-04-29 and was last updated on 2026-09-21. The most recent full self-assessment of the whole website was carried out on 2026-06-18; updates in between concern individual, dated checks and do not mean a new whole-site review has taken place. The next planned full review will take place when the manual screen-reader review in #2229 is complete, and at the latest by 2027-06-18. The full dated version history is published in the Swedish version of this statement; the entry for this update is summarised below.

What changed on 2026-09-21

• The previous commitment date, 2026-09-16, passed without completed verification. The manual screen-reader review (#2229) is still unfinished: NVDA + Firefox was run 2026-09-12 to 2026-09-14 without completing every protocol step, and VoiceOver + Safari is still entirely outstanding. The commitment date is now 2026-10-16. The missed deadline is disclosed rather than hidden as a routine extension. The earlier date had already moved from 2026-08-28 to 2026-09-16 on 2026-08-25. For 3.3.3, validation is implemented but manual verification remains outstanding.
• Contrast findings are disclosed together with the corrections. The historical 1.4.3 surfaces in section 2.1 were not covered by the earlier commitment because they were absent from the statement. They are now reported with their original measurements, implemented corrections and continuing commitment.
• This statement contained incorrect claims, corrected here. Section 1 said the remaining open issues were "2 P3". That was wrong: the contrast issues above were live and undisclosed. Section 3 also failed to distinguish implemented corrections from completed verification. The Swedish "What works" section said text and user-interface components met the AA contrast requirement and that dark mode kept its contrast. Both were wrong; the historical findings and their corrections are now reported separately. Until this publication the English statement had no "What works" section at all, so it never carried those two sentences — but it carried the same false claims in sections 1 and 3. That section now exists in English too, so both locales say the same thing.
• Level A. Section 2.4 said there were no remaining issues against 4.1.2 and 4.1.3. That was not true at the previous publication: the manual NVDA run found live issues against 3.3.1, 4.1.2, 4.1.3, 2.4.3 and 1.3.1. They have implemented fixes and are listed in section 2.5.
• Tracking. The reference to #1380 for plain-language Swedish (3.1.5) has been removed: that issue was closed as "will not be done" on 2026-04-28, the day before this statement was first published, so the reference was wrong throughout. There is no replacement tracker. The historical contrast findings were documented in #5806, #6257, #6258, #6259 and #6260.
• How the error survived, and what changed. The earlier claims rested on treating closed issues as evidence that a defect was gone, and on automated checks whose URL lists do not reach the affected pages — and, in at least one case, on a check that did reach the page type and still did not report the surface (section 5). This correction distinguishes dated measurements of the older build from the implemented corrections. It is not a new measurement of the entire website. Two of the statement's tracking references have turned out to point at closed issues (#1975 and #1380). Every reference to an issue is now listed in a registry in the codebase, and the registry distinguishes two kinds. For the issues the statement currently names as the place the work is being done, a test requires the registry to say the issue is open and that this was checked by hand no earlier than the day the statement was last published. Purely historical references — such as the two just named — are listed as well, but nothing requires them to be open: they are closed, which is the normal case for a historical note. The test does not query GitHub — it requires the entry to be re-dated at every new publication and blocks a reference whose entry has not been confirmed afresh. A test cannot force anyone to actually open the issue; it can only require that the check be attested.