Details on Accessibility¶
Accessibility Requirements¶
In Germany, public authorities are subject to legal requirements regarding the implementation of digital accessibility. Before commissioning an assessment, it is important to determine which requirements should serve as the basis for the evaluation.
The general overview outlines the requirements under the current regulation BITV 2.0 (transl. Accessible Information Technology Ordinance) that must be observed depending on the context and application technology.
| Subject of the Audit | ETSI EN 301 549 | Additional Requirements in Accordance with BITV 2.0 or as Specified by State Legislation |
|---|---|---|
| Website or mobile version of a public agency's website | Annex A, Table A.1 | 1. Accessibility statement with a feedback mechanism (§ 7), 2. Explanations in German Sign Language and easy read (§ 4), 3. Highest possible level of accessibility, (§ 3 para. 4) |
| Mobile App from a Government Agency | Annex A, Table A.2 | 1. Accessibility Statement with Feedback Mechanism (§ 7) (required for each operating system; to be published at the location where the mobile application is available for download or on the public body’s website) 2. Highest possible level of accessibility (§ 3 para. 4) |
Further information on the testing criteria can be found in the guide “Quality Criteria for the Assessment of Accessibility” published by the German Federal Supervisory Authority (BFIT).
Since the national EUDI Wallet app falls under the scope of a mobile application, it is guided by the corresponding directive.
In this context, the following points, among others, should be taken into account.
For further reference, links to relevant information, for example on implementation for the Android operating system, are provided below:
- Contrast - Accessibility designing – Material Design 3 & Color contrast - Android Accessibility Help
- Text and interface elements meet contrast ratio
- Touch Target Size - Accessibility overview – Material Design 3
- Interactive areas are no smaller than 48x48 dp and have sufficient spacing to prevent mis-taps
- Content Description - Make apps more accessible | App quality | Android Developers
- Text Label for form elements
- Images MUST have a content Description unless they are decorative or redundant
- Image Button controls MUST have a content Description.
- Focus, e.g. Handle input method visibility | Views | Android Developers
- visible indication on each element
- Focusable
- Interactive elements need to be focusable
- Focus moves in a logical sequence (Modify traversal order | Jetpack Compose | Android Developers) and provides visible indication on each element
- Modal dialogs MUST trap keyboard and screen reader focus and MUST prevent focus of the grayed-out content.
- Notifying Users of Changes
- TalkBack (Voice Over System of Android) users MUST be notified of dynamic content changes either through spoken accessibility announcements OR focus management.
- Name, Role, Value (e.g. toggle state) of elements
- Audio & Video
- Captions and transcripts are available
- Dynamic content updates are announced to assistive technologies
- Hidden elements are removed from accessibility trees unless needed; overlays are properly managed
- Responsiveness: The interface remains functional and visually consistent in both portrait and landscape orientations
Presentation of the User Flow; Description for Visually Impaired Users¶
To illustrate the sequence of a “happy path” for PID issuance, a link to a document is provided here that allows people with visual impairments to follow along.
This screen sequence does not yet meet all accessibility requirements and is intended solely to illustrate the step-by-step process for PID issuance.
The document is available in both German and English at the following links:
Note: These screens in the document do not represent the final design version of the app. They only illustrate the process of creating a PID using the selected high-fidelity screens.
Strategy on Ensuring Accessibility¶
In product development, it is equally crucial to consider accessibility as an integral part of user-friendliness. Standards such as the WCAG (Web Content Accessibility Guidelines) and ETSI EN 301 549 , which specifically addresses the accessibility of interactive systems, are taken into account.
However, the strategy is not solely to achieve accessibility by adhering to the standards.
Overall, the following approach is therefore planned:
- Internal expert assessment of compliance with accessibility criteria according to the required standards, in close coordination with the developers
- Consultation with external experts in the field of accessibility and relevant associations
- Conducting user studies with people with various disabilities to achieve continuous improvement of the user experience
- When designing the screens, accessibility considerations are taken into account from the outset
The goal is not merely to comply with regulatory accessibility criteria, but to achieve a high level of user-friendliness in accessibility. This is why particular emphasis is placed on conducting user studies with people with disabilities.
Discussions with associations and a small-scale user study have already taken place.
The relationship between the EN Standard, BITV 2.0 and the WCAG¶
The current version of the Accessible Information Technology Ordinance (BITV) 2.0 came into force on 25 May 2019. Since then, BITV 2.0 has not described the standard for the accessible design of information technology in detail, but has referred to the harmonized standards published in the Official Journal of the European Union, including EN 301 549, version V3.2.1.
Due to BITV 2.0's reference to EN 301 549, as well as the WCAG success criteria referenced in earlier versions (cited in Chapter 9 of EN 301 549), many other accessibility requirements have also become relevant (see above).