Blank checklist, printable form
Voice & Video Calling Checklist
EN 301 549 Chapter 6 Compliance Checklist
Blank checklist for offline completion.
Tick one box per row. Add comments and evidence references in the Notes column as needed.
Audio Quality & Bandwidth
EN 301 549 §6.1, Voice communication services must support sufficient audio bandwidth for speech intelligibility.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 §6.1 | Critical | Voice communication supports a frequency range of at least 300–3400 Hz (narrowband minimum).This is the minimum for speech intelligibility. Standard telephony meets this. VoIP services must ensure codec selection supports at least this range. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.1 | Major | Wideband audio (150–7000 Hz) is supported where the network allows.Wideband audio significantly improves speech clarity for hearing aid users and users with hearing loss. HD Voice / VoLTE support is strongly recommended. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Real-Time Text (RTT)
EN 301 549 §6.2, If voice communication is provided, real-time text must be supported alongside it.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 §6.2.1.1 | Critical | If voice communication is provided, real-time text (RTT) is also supported.RTT transmits text character-by-character as it is typed, unlike SMS or chat where text is sent as a block. This is essential for deaf and hard-of-hearing users. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.2.1.2 | Critical | RTT can be used simultaneously with voice (concurrent voice and text).Users must be able to speak AND type in the same call, not be forced to choose between voice mode and text mode. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.2.2.1 | Major | Sent and received RTT are visually distinguishable in the display.Like a chat interface, the user's own text and the remote party's text must be visually distinct (different colours, sides, or labels). | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.2.2.2 | Major | Direction of RTT (sent vs received) is programmatically determinable.Screen readers must be able to distinguish sent from received text, not just visual styling but semantic markup. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.2.3 | Major | RTT interoperates with other RTT-capable services and networks.RTT from your service must be able to reach users on other RTT-capable platforms. Interoperability with standards like RFC 4103 is expected. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.2.4 | Critical | RTT characters appear within 500ms of being typed.The defining feature of RTT is real-time display. Characters must appear on the remote screen within half a second of being typed, not buffered until Enter is pressed. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Caller Identification
EN 301 549 §6.3, Caller identity must be available in text form.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 §6.3 | Critical | Caller identification is available in text form, not just audio announcement.Deaf users cannot hear the caller's name announced by the system. Caller ID must be displayed visually and exposed to assistive technology. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Alternatives to Voice
EN 301 549 §6.4, At least one non-voice communication alternative must be available.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 §6.4 | Critical | At least one non-voice alternative is available (text, email, chat, video relay).Users who cannot speak (mute users, speech disabilities) must have an alternative communication channel. Text chat, email, or video relay must be offered. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.4 | Major | The non-voice alternative provides equivalent functionality to the voice channel.If voice support can resolve all issues, the text/chat alternative must also have full resolution capability, not just a 'please call us' redirect. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Video Communication
EN 301 549 §6.5, If video calling is provided, quality must support sign language communication.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 §6.5.2 | Critical | Video calling supports at least QVGA resolution (320×240 pixels).This is the minimum resolution for sign language to be intelligible. Higher resolution is preferred for clear hand and facial expression visibility. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.5.3 | Critical | Video frame rate is at least 20fps, adaptable to network conditions.Below 20fps, sign language becomes difficult to understand. The system should prioritise frame rate over resolution when bandwidth is limited. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.5.4 | Major | Audio and video are synchronised, lip sync within 100ms.Lip-reading users depend on precise audio-visual sync. Test under typical network conditions, not just ideal. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.5.5 | Major | A visual indicator is shown when audio is active (speaking indicator).Deaf users on video calls need a visual cue that someone is speaking, a pulsing icon, border highlight, or waveform. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.5.6 | Major | The active speaker is visually identified when multiple participants are present.In group calls, the current speaker must be visually highlighted so sign language interpreters and lip readers know who to watch. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §6.6 | Major | A non-video alternative exists for all video-based communication.Users who cannot use video (bandwidth constraints, privacy, blindness) must have an alternative, voice + RTT, or text-only communication. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |