low complexity extracted Help & Support Confidence: 100%
1
Components
39
Shared
0
User Stories
Yes
Analyzed

Description

The Accessibility Statement feature provides users with a formal in-app declaration of the platform's commitment to WCAG 2.2 AA compliance, the scope of accessibility support, known limitations, and contact information for reporting accessibility barriers. The statement is required by Norwegian public sector regulations (forskrift om universell utforming av IKT) for publicly available digital solutions and is expected by the disability organizations using the platform. The screen presents the statement as structured readable text including the compliance status, evaluation methodology, and a direct link or form to report accessibility issues. Like the privacy policy, the content is fetched from a versioned backend endpoint and cached for offline access. It is permanently accessible from the Help & Support section and is part of the always-on module.

Analysis

Business Value

Norwegian regulations require that digital solutions used by public-sector- adjacent organizations publish an accessibility statement that meets the requirements of the EU Web Accessibility Directive as implemented in Norwegian law. All four member organizations receive public funding (including Bufdir grants) and serve users with disabilities, placing them squarely within the scope of this obligation. Absence of an accessibility statement creates compliance risk and signals that accessibility is treated as an afterthought. For the platform's credibility with Blindeforbundet, NHF, and HLF - all disability advocacy organizations - the accessibility statement is also a trust signal. These organizations scrutinize whether technology partners genuinely understand accessibility obligations. Shipping a complete, accurate statement at MVP demonstrates commitment and reduces the risk of organizational pushback during rollout.

Implementation Notes

Implementation mirrors the Privacy Policy screen: a Flutter screen that fetches versioned content from a backend endpoint, caches it with Drift, and renders it using the shared Markdown/HTML widget with platform typography tokens. The statement content is authored outside the app and updated independently of app releases. The screen must include a mechanism for reporting accessibility issues - either a mailto link or a reuse of the `SupportRequestService` from the Contact Us feature with a pre-filled category. Heading structure and semantic markup in the rendered content must support screen reader navigation. The Accessibility Audit CI step in the pipeline validates WCAG compliance of the screen itself, which is separately required as an example of the platform eating its own cooking.

Components (40)

User Interface (1)

Shared Components

These components are reused across multiple features

User Stories

No user stories have been generated for this feature yet.