---
title: Accessibility in Medical Device Design: Inclusive Usability Under MDR
description: How accessibility and inclusive usability fit into the EN 62366-1 process and meet MDR Annex I safety obligations.
authors: Tibor Zechmeister, Felix Lenhard
category: Usability Under MDR
primary_keyword: accessibility inclusive usability MDR
canonical_url: https://zechmeister-solutions.com/en/blog/accessibility-inclusive-usability-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Accessibility in Medical Device Design: Inclusive Usability Under MDR

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Accessibility is not a separate workstream under MDR. It is part of usability engineering under EN 62366-1:2015+A1:2020, and it flows directly from the safety obligations in MDR Annex I §5 and §22. If a user cannot read the screen, distinguish the alarm colors, or press the button, the device is not safe for that user, and the manufacturer carries that risk.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- MDR Annex I §5 requires manufacturers to reduce risks related to ergonomic features and the intended environment of use, which includes the physical and cognitive capabilities of the users.
- MDR Annex I §22 adds explicit obligations for devices intended for use by lay persons, including people who may have reduced dexterity, sight, or literacy.
- EN 62366-1:2015+A1:2020 is the harmonised standard for the usability engineering process and covers accessibility as part of the use specification and user characterisation.
- Accessibility issues that Tibor sees fail audits most often are low color contrast, font sizes below 12 point, touch targets under 9 mm, and alarm tones above 4 kHz that older users cannot hear.
- WCAG is a web accessibility framework, not a medical device standard. It can be used as state of the art input to the usability file, but manufacturers must map its criteria back to EN 62366-1 and MDR Annex I.

## Why accessibility belongs inside the usability file

Startups often treat accessibility as a branding topic. A marketing lead asks whether the app is "accessible," someone adds alt text to a few icons, and the question gets closed. Tibor has seen this framing collapse inside stage 2 audits repeatedly. The auditor does not open a marketing deck. The auditor opens the usability engineering file and asks one question: did the manufacturer characterise the intended users, including their sensory, motor, and cognitive capabilities, and did the design mitigate the foreseeable hazards that follow from those characteristics?

If the answer is "we followed WCAG," that is not an answer. WCAG is the Web Content Accessibility Guidelines, maintained by the W3C. It is a web accessibility framework. It is useful, and Tibor often sees teams use it as a source of good practice, but WCAG is not a harmonised standard under MDR. The harmonised standard is EN 62366-1:2015+A1:2020.

The correct framing is this. Accessibility is inclusive usability. Inclusive usability is a subset of usability. Usability under MDR is governed by EN 62366-1 and by MDR Annex I §5 and §22. Every accessibility decision must therefore trace into the usability engineering file, not live in a separate document that the notified body never sees.

## What MDR actually says

MDR Annex I §5 states, in the General Safety and Performance Requirements, that "in eliminating or reducing risks related to use error, the manufacturer shall: (a) reduce as far as possible the risks related to the ergonomic features of the device and the environment in which the device is intended to be used (design for patient safety), and (b) give consideration to the technical knowledge, experience, education, training and use environment, where applicable, and the medical and physical conditions of intended users (design for lay, professional, disabled or other users)."

Read that last clause carefully. The MDR explicitly names "disabled" users as a category the manufacturer must consider. This is not optional. It is not limited to Class III devices. It is not waived for software. It applies whenever the design choices interact with the user, which is always.

MDR Annex I §22 goes further for devices intended for use by lay persons. It requires that such devices be designed and manufactured to perform appropriately for the lay user, taking into account the skills and means available to that user and the influence resulting from variation that can be reasonably anticipated in the user's technique and environment. It also requires information and instructions to be easily understood and applied.

EN 62366-1:2015+A1:2020 operationalises both of these. Clause 5.1 requires a use specification. The use specification must include "intended user profile," which covers mental, physical and demographic characteristics, education, literacy and sensory capabilities. If the manufacturer writes "users are adults with a smartphone" and stops, the use specification is incomplete and the file fails.

## A worked example

Consider a Class IIa software app that helps diabetes patients titrate insulin doses. The intended users are adults with type 2 diabetes. Tibor would push the team hard on the use specification, because the real population includes people in their seventies, people with early diabetic retinopathy, people with peripheral neuropathy affecting fingertips, and people with limited digital literacy.

The team runs formative evaluations with a representative sample. They discover three accessibility findings. First, the dose display uses gray text on a white background at a contrast ratio the team estimates around 3:1. Older users with cataracts cannot read it reliably in bright rooms. Second, the "confirm dose" button is 7 mm wide. Users with peripheral neuropathy miss it and press the adjacent "cancel" button. Third, the alarm tone for a missed dose is a 4.5 kHz beep. Users over 65 with presbycusis do not hear it at all.

Each finding is a hazardous use scenario under EN 62366-1 clause 5.5 and feeds directly into risk management under EN ISO 14971:2019+A11:2021. The team raises the contrast ratio to 7:1, enlarges the button to 12 mm, and replaces the alarm with a multi-frequency tone plus a haptic vibration and a visual flash. They document the design decisions, re-run summative validation, and show the notified body the complete trace from use specification to risk control to summative evidence.

This is what a clean accessibility story looks like under MDR. It is not a WCAG audit. It is a usability engineering process that happens to produce accessible outcomes because the use specification was written honestly.

## The Subtract to Ship playbook

Felix has coached 44 startups, and the pattern is always the same. Accessibility gets added late, treated as a UX polish sprint, and then fails under regulatory scrutiny because the work never touched the risk file. The Subtract to Ship approach is to fold accessibility into the usability engineering process from day one and cut everything else that does not serve it.

Step one is to write an honest use specification. Name the real users. If the device is for elderly home users, write down that a meaningful fraction will have reduced visual acuity, reduced hearing above 3 kHz, reduced fine motor control, and limited experience with touchscreens. Do not write "users are adults." Tibor rejects that language in every audit.

Step two is to pull state of the art inputs. WCAG 2.1 Level AA  is a common starting point for visual and interaction accessibility. ISO 9241-171 on software accessibility and ISO 21056  can also be referenced. Document in the usability file why the chosen inputs represent state of the art for your device, per MDR Annex I §1, which requires state of the art to be considered.

Step three is to translate those inputs into concrete design constraints. Minimum contrast ratio 4.5:1 for normal text and 3:1 for large text. Minimum touch target size 9 mm, preferably 12 mm for home use devices. Alarms below 4 kHz with multi-sensory redundancy. Text resizable to at least 200 percent without loss of function. Captions or transcripts for any instructional video content.

Step four is to make these constraints show up in risk controls. Each one maps to a hazardous use scenario in the use specification. Each one gets verified during design verification and validated during summative evaluation. This is the trace the notified body wants.

Step five is to subtract. If the app has three color themes, two font choices, and a "simplified mode," cut two themes, lock one font at readable size, and make the simplified mode the default. Every toggle is a chance for a user to end up in an unsafe configuration. Felix has seen startups ship with 40 preference toggles and then discover in summative that most users never change them and the defaults were the problem all along.

## Reality Check

1. Does the use specification name the specific sensory, motor, and cognitive characteristics of the intended users, including worst-case representative users?
2. Is accessibility addressed inside the usability engineering file, or does it live in a separate document the notified body will not see?
3. Can you trace every accessibility design decision (contrast, target size, alarm tones, language level) to a hazardous use scenario in the use specification?
4. Did formative evaluation include representative users with the full range of capabilities described in the use specification, not only healthy testers?
5. Does summative validation evidence the accessibility design decisions, not only the clinical workflow?
6. Are the state of the art inputs used (WCAG version, ISO accessibility standards) documented and justified as state of the art for the device type?
7. Have you subtracted unnecessary configuration options that could leave users in an inaccessible default state?

## Frequently Asked Questions

**Does MDR require WCAG compliance for medical device software?**
MDR does not cite WCAG. MDR requires usability under Annex I §5 and §22 and, through the harmonised standards list, presumes conformity via EN 62366-1:2015+A1:2020. WCAG can be used as state of the art input but is not itself a regulatory requirement. The manufacturer must justify in the usability file why the chosen accessibility inputs represent state of the art.

**Is accessibility only required for devices used by lay persons under Annex I §22?**
No. Annex I §5 applies to all devices and explicitly names "disabled or other users" as a category to consider. A clinical device used by nurses must still accommodate nurses with color vision deficiency or reduced hearing. §22 adds extra obligations for lay users but does not exempt professional devices from basic accessibility.

**What minimum contrast ratio should a medical device screen use?**
There is no MDR-mandated number. WCAG 2.1 AA recommends 4.5:1 for normal text and 3:1 for large text as a state of the art baseline. For devices used in variable lighting or by users with age-related vision loss, Tibor often pushes teams to 7:1. The justification must be documented in the usability file against the intended use environment.

**Does a Class I device need the same accessibility rigor as a Class IIa?**
The rigor scales with the risk and use scenarios, not the class directly. A Class I thermometer used by elderly home users needs serious accessibility consideration under Annex I §22. A Class IIa professional tool used in a clinical setting may need different considerations. Both are governed by the same EN 62366-1 process; the depth of evidence scales with the hazardous use scenarios identified.

**How do I prove accessibility in a summative evaluation with only 15 participants?**
EN 62366-1 does not mandate a fixed participant count, but FDA guidance and notified body expectations commonly land around 15 users per distinct user group. If your user groups include "adults with reduced visual acuity" and "adults with reduced dexterity," those are distinct groups that may need their own participants. Tibor has seen startups try to cover three groups with 15 total participants and fail validation.

**Can I use a third-party accessibility audit instead of running summative usability?**
No. A third-party accessibility audit is not a substitute for summative usability evaluation under EN 62366-1. It can be input to the process, but summative validation is a regulatory requirement that must be performed by the manufacturer against the device's specific use scenarios.

## Related reading
- [IEC 60601-1-6 and the usability cross-reference](/blog/iec-60601-1-6-usability-cross-reference) explains how electrical device standards point back to EN 62366-1.
- [Risk management and usability engineering link](/blog/risk-management-usability-engineering-link) shows how hazardous use scenarios flow from the use specification into the risk file.
- [Patient information for lay users under MDR](/blog/patient-information-lay-users-mdr) covers the Annex I §23 obligations that run alongside accessibility.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §5, §22, §23.
2. EN 62366-1:2015+A1:2020, Medical devices – Part 1: Application of usability engineering to medical devices.
3. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices.

---

*This post is part of the [Usability Under MDR](https://zechmeister-solutions.com/en/blog/category/usability) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*