fremforge Accessibility Statement

title: fremforge Accessibility Statement author: fremverk date: 2026-08-11 status: Published v1.4 version: “1.4” lang: en #

Last updated: 2026-08-11

Current Version: 1.3 (2026-08-11) — Published at www.frem.sh/legal/accessibility-statement/.

This statement applies to the fremforge service operated by fremverk ApS at frem.sh, www.frem.sh and docs.frem.sh. Controller identification is in legal-meta.md.

1. Commitment #

fremverk ApS is committed to making the fremforge service accessible, in accordance with EN 301 549 (the European standard for ICT accessibility, which incorporates WCAG 2.1 level AA by reference at clause 9), Directive (EU) 2019/882 (the European Accessibility Act) and its national transpositions, and — for the Norwegian market — the forskrift om universell utforming av IKT-løsninger made under the likestillings- og diskrimineringsloven.

This statement is written to the structure of the model statement in Commission Implementing Decision (EU) 2018/1523, because that is the form public-sector customers ask suppliers to provide during procurement.

2. Compliance status #

Partially compliant with EN 301 549 / WCAG 2.1 AA, because of the non-conformances listed in §3.

This is a self-assessment. No third-party audit has been carried out. A conformance claim supported only by self-assessment is weaker evidence than an independent audit report, and public-sector procurement may require the latter — see §6.

3. Non-accessible content #

3.1 Non-conformances with EN 301 549 #

Resolved 2026-08-11 (recorded rather than deleted, because a reader assessing this statement should be able to see what moved, and in what order it was found):

Contrast — five defects in the design tokens, all measured:

• Primary buttons failed WCAG 1.4.3 in dark mode on the administration console (4.26:1) and in both modes on the code-hosting surface (4.26:1). The brand green could not carry an accessible label in either direction; the interactive colour ramp now inverts by mode.
• Inline links on the code-hosting surface failed 1.4.3 in light mode (4.04:1 on the page background). The dark mode of the same token had been fixed earlier and measured; the light mode had not.
• Input placeholder text failed 1.4.3 (4.00:1 / 3.79:1).
• Text-input, select and textarea borders failed WCAG 1.4.11 (Non-text Contrast) at 1.43:1 (light) and 2.47:1 (dark), so form fields had no perceivable boundary.
• A danger-variant keyboard focus indicator failed 1.4.11 in dark mode (2.96:1).

Structure and behaviour — found by the automated gates once they existed:

• Interactive controls in the shared interface announced behaviour they did not have. The account and organisation popovers and the appearance selector were described to assistive technology as menus — a description that promises arrow-key navigation and dismissal with Escape. Neither existed: the interface contained no arrow-key handling at all, so a user who was told “menu” and navigated accordingly found the keys inert, and Escape did not close the popover. WCAG 2.1.1 and 4.1.2. The behaviour is now implemented and asserted on every change, including returning focus to the control that opened a popover when it closes.

  Worth stating because it shapes what this statement can be relied on for: automated rule-checking had passed all of these. Rule-checkers verify that a description is present and structurally legal, not that the behaviour it promises exists — so this class of defect is invisible to them by construction, and finding it required driving a real browser with real key presses.

• Landmarks on every administration and operator page. The shell’s own role="banner" top bar, sidebar navigation and footer were nested inside the page’s <main> landmark, so “jump to main content” skipped nothing and landmark navigation was materially degraded. WCAG 1.3.1. The content column is now the single <main>, and the skip-link target moved with it.

• Two <main> landmarks on the welcome and onboarding pages — the pages a brand-new customer sees first — because the page supplied its own <main> inside the one the shared layout already emits. WCAG 1.3.1.

• An uncontrollable timed redirect on the two-factor-enrolment gate, implemented as <meta http-equiv="refresh"> with a few seconds’ delay. This is a Level A failure of WCAG 2.2.1 (Timing Adjustable) with no applicable exception: the user could not turn it off, adjust it or extend it, and for a screen-reader or cognitive-load user it navigated the page away mid-sentence. Removed, along with the mechanism that produced it, so it cannot be reintroduced by a future caller. The page’s prominent action button was, and remains, the working affordance.

• Nine transient error messages that were never announced. Error banners are shown in response to an action; 13 of 39 rendered without a live region, so a screen-reader user received no notification that anything had gone wrong. WCAG 3.3.1 / 4.1.3. Nine now announce assertively. Three were deliberately left silent and are documented as such: two describe standing account state rather than an event, and one is a styled container around a table — making those assertive would interrupt the user on every page load, which is a regression rather than a fix.

3.2 Content not yet assessed #

What follows is the limit of what has been assessed. Entries are listed because an unassessed area is not the same as a conformant one, and a statement that omitted them would overstate what is known. Two entries describe partial coverage rather than none, and say exactly where that coverage stops:

• Keyboard operability — assessed for the shared interface, with a narrower remaining gap. An automated gate drives real key sequences in a browser engine on every change. Covered: the command palette (opens on its advertised shortcut, places focus in its input, Escape closes it without trapping focus, arrow keys stay inside the dialog); the account and organisation popovers (open from the keyboard, arrow keys move between their items, Home and End jump to the ends, Escape closes and returns focus to the control that opened it); the appearance selector (arrow keys move between options and wrap); and the page framework (the skip link is the first stop and reveals itself when focused, and Tab reaches page content past the whole navigation chrome).

  Still not covered: keyboard behaviour on individual administration pages, rather than the shared interface they sit in. The setup-progress control that previously appeared here is resolved — it no longer describes itself as a set of tabs, and it is now exercised by the automated checks (see the change log).

• Assistive-technology testing — NOT performed. No testing with NVDA, JAWS or VoiceOver has been carried out, and nothing described in this statement has been heard by a person using a screen reader. This remains the most significant gap here, and it is why an external audit is being commissioned.

  Two automated checks exist nearby and neither is a substitute. Both are described because a reader is entitled to know exactly how far the automation goes:

  1. Since 2026-08-11 a check confirms that error and status messages reach the accessibility tree as live regions carrying their text — not hidden, not stripped by a container, not left unnamed. That is a structural property computed by the browser.
  2. Also since 2026-08-11, a screen-reader simulator reads each page and produces the sequence of phrases a screen reader would say. It checks that an error is announced as an error rather than as ordinary prose, that it is announced before the form controls it refers to, that decorative marks stay silent, and that nothing is said twice in a row.

  What the second one is worth, stated plainly: it implements the specification for how a page should be announced. Real screen readers each depart from that specification in their own ways, and those departures are where announcement usually fails in practice — including how assertive and polite messages actually interrupt, and anything to do with braille or verbosity settings. During development the simulator reported a repeated phrase that a real screen reader would not produce, which is a concrete example of the divergence rather than a hypothetical one.

  So read these as “the page is built to announce correctly”, never as “users hear it correctly”. Only testing with real assistive technology, and with people who use it, settles the second — and that has not been done.

• Populated page states. Automated checks cover 39 view components, but render them from default props — that is each page’s empty, initial or error state. A page showing real data (long tables, deep nesting, many controls) is not yet swept.

• The bulk of the code-hosting interface. Automated checks reach it only through the pages a signed-out visitor can load. Everything behind sign-in — repositories, issues, pull requests, code review, settings — is unassessed and is the subject of §3.3.

• Non-web documents (PDF exports, generated reports).

No longer in this list — <html lang> was hard-coded to en, which would have become a WCAG 3.1.1 failure the moment a second interface language shipped. The document language now follows the user’s own language choice, with an allowlist so an unrecognised value cannot land in the attribute.

3.3 Disproportionate burden — third-party code-hosting interface #

The code-hosting interface at frem.sh (repositories, issues, pull requests, code review, settings) is built on Forgejo, third-party free and open-source software. fremverk applies a small series of patches to it, none of which touch the user-interface layer, and a white-label theme.

fremverk does not control the accessibility of this interface and cannot practically bring the whole of it into conformance: it is the large majority of the customer-facing surface, it changes with every upstream release, and remediating it would mean maintaining a permanent private fork of another project’s entire front end. fremverk relies on Article 14(1)(b) of Directive (EU) 2019/882 (fundamental alteration / disproportionate burden) for this component only.

This is a bounded and time-limited position, not a permanent exemption:

• It applies only to interface behaviour originating upstream. Everything fremverk authors — the administration console, the marketing and documentation sites, the theme, the e-mail templates — is in scope for full conformance and is assessed in §3.1.
• Where a defect in the third-party interface can be repaired from the theme, template or script layer that fremverk does control, it is repaired there and not claimed as burden. The contrast defects resolved in §3.1 are examples — they were on the third-party surface but were fixable in fremverk’s own theme, so they were fixed — and item 2 in §3.1 is another.
• fremverk does not undertake to obtain changes in the third-party component itself. This is a deliberate position rather than an oversight. fremverk has no control over whether or when a change is accepted by a third-party project, so a commitment to achieve one would be a commitment it cannot keep, and an accessibility statement should not contain commitments of that kind. Where a defect cannot be repaired at fremverk’s own layer it is disclosed as unresolved in §3.1 or §3.2, so a reader can see it rather than being told it is being handled.
• The assessment underlying this claim is re-run when the upstream version is upgraded.

4. Preparation of this statement #

• Prepared: 2026-08-11.

• Method: self-assessment, comprising (a) an automated scan of the live public surfaces using axe-core; (b) an automated audit of the design system’s colour tokens against the WCAG 2.x contrast formula; (c) a source-level review of the interface markup.

• Scope of the live scan: frem.sh/user/login, frem.sh/user/forgot_password, frem.sh/user/sign_up, frem.sh/explore/repos, frem.sh/explore/users, frem.sh/explore/organizations, www.frem.sh, docs.frem.sh. Unauthenticated pages only.

• Limitations of the method: automated testing detects a minority of accessibility barriers. Colour contrast was assessed exhaustively against the design tokens rather than per-page, which is stronger for that criterion, but automated tooling cannot assess keyboard operability, focus management or assistive-technology compatibility at all. §3.2 lists what this leaves unknown.

• Regression protection: six automated assessments run in continuous integration on every change, so the resolved items in §3.1 cannot silently regress and a new violation of a covered rule fails the build:

  1. a colour-contrast audit of the design tokens, covering light and dark themes for both text and non-text contrast;
  2. an axe-core structural sweep of the shared page framework plus 39 view components;
  3. a check that every transient error message sits in a live region;
  4. a keyboard-operability gate that presses real keys in a browser engine;
  5. an accessibility-tree gate confirming messages surface to assistive technology as named live regions — see the caveat in §3.2;
  6. a screen-reader simulator asserting what is announced and in what order — see the same caveat, which applies to this one most of all.

  Each carries a guard that fails the build if the check itself ever stops measuring anything, because a check that silently covers nothing reports success, which is worse than having no check.

5. Feedback #

If you encounter an accessibility barrier in fremforge, or need content provided in an alternative format, please contact:

• E-mail: accessibility@fremverk.com
• Postal: fremverk ApS, Ringager 4C, 2. tv, 2605 Brøndby, Denmark

We aim to acknowledge within 5 working days and to give a substantive response, including a remediation timeline where a barrier is confirmed, within 20 working days.

6. Public-sector procurement #

Public-sector bodies in the EU and EEA are themselves bound by Directive (EU) 2016/2102 and generally require suppliers to evidence conformance with EN 301 549. fremverk will on request provide the current version of this statement and the underlying automated assessment output. fremverk cannot currently provide a third-party audit report or a completed accessibility conformance report (ACR). Where a tender requires one, that gap should be raised before bidding rather than discovered at evaluation.

7. Enforcement procedure #

If you are not satisfied with our response under §5, you can escalate. Accessibility of digital services is supervised nationally, so the competent body depends on the country you are in and, in several states, on whether the complaint concerns a product or a service.

How to escalate:

1. Tell us you are dissatisfied, at accessibility@fremverk.com. We will confirm in writing what we did and did not do, so you have something to hand on.
2. Contact the accessibility supervisory authority in your own country. In EU Member States this is the body designated under Directive (EU) 2019/882; in Norway it is the authority designated under the forskrift om universell utforming av IKT-løsninger. Your national government’s accessibility or consumer-protection portal will name the current body.
3. If you tell us which country you are in, we will identify the correct authority for you and put it in writing. You should not have to navigate this to make a complaint about us.

This section deliberately does not print a table of named authorities. The allocation of competence between market-surveillance authorities, sector regulators and equality bodies differs by Member State and changes over time, and a statement that names the wrong authority obstructs the complaint it is supposed to enable. Naming the route accurately is more useful than naming a body inaccurately. Where fremverk contracts with a customer in a specific market, the competent authority for that market is confirmed and stated in the engagement documentation.

8. Change log #