Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 63080: Accessibility Requirements for ICT Products and Services
International Standard for Inclusive Design of Information and Communication Technology
1. Scope and Conformance Framework of IEC 63080
IEC 63080 is the first horizontally applicable international standard that establishes accessibility requirements specifically for information and communication technology (ICT) products and services. Unlike vertically oriented sector-specific standards, IEC 63080 applies across all ICT domains — from operating systems and mobile applications to self-service kiosks, telecommunications equipment, and cloud-based productivity services. The standard was developed in coordination with the ITU-T Focus Group on Accessibility and incorporates the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as a normative reference for web-based interfaces.
IEC 63080 adopts a functional performance approach rather than prescribing specific design solutions. This means the standard defines what accessibility outcomes must be achieved (e.g., “the product shall support operation without color perception”) while leaving how to achieve those outcomes to the creativity of the design team. This approach ensures the standard remains relevant as technology evolves.
The conformance framework is built around eight functional performance statements: (1) usage without vision, (2) usage with limited vision, (3) usage without perception of color, (4) usage without hearing, (5) usage with limited hearing, (6) usage with limited manual dexterity, (7) usage with limited reach and strength, and (8) usage with limited cognitive function. Each statement maps to a set of technical requirements that are verified through a combination of design review, user testing, and declared conformance.
| Functional Performance Category | Key Technical Requirement Examples | Verification Method |
|---|---|---|
| Without Vision | Screen reader compatibility, non-text content alternatives, keyboard-only navigation | Automated test + assisted user test |
| Limited Vision | Text resize up to 200%, contrast ratio ≥4.5:1, focus indicators | Measurement + inspection |
| Without Color | Information not conveyed by color alone, pattern fills in charts | Design review |
| Without Hearing | Captions for audio content, visual indicators for audio alerts | Inspection + user test |
| Limited Hearing | Volume control range ≥40 dB, telecoil compatibility for telephones | Measurement |
| Limited Manual Dexterity | Button size ≥20 mm touch target, no time-limited input, adjustable timing | Measurement + inspection |
| Limited Reach/Strength | Operating force ≤22 N, controls within 400-1200 mm range | Measurement |
| Limited Cognitive | Predictable navigation, error recovery guidance, plain language option | User test + design review |
2. Technical Requirements for Hardware and Software Accessibility
For hardware ICT products, IEC 63080 specifies requirements that go beyond the traditional focus on physical ergonomics. Touchscreen interfaces must support operation with a gloved hand and have a minimum touch target size of 20 mm × 20 mm with a minimum force activation threshold of 0.3 N to prevent accidental activation. Physical controls — keys, buttons, and switches — must have tactile distinguishability without requiring visual identification, achieved through shape coding (distinct geometric profiles for different functions), surface texture variation, or Braille markings.
One of the most frequently cited non-compliance issues under IEC 63080 is the time-out problem: ICT products that impose a fixed time limit for user input without providing the option to extend or disable the time limit. The standard requires that for any time-limited operation longer than 20 seconds, the user must be given at least one of three options: (a) turn off the time limit, (b) adjust the time limit to at least 10 times the default, or (c) receive a warning and be granted at least 20 additional seconds before timeout.
For software and web-based services, IEC 63080 incorporates WCAG 2.1 Level AA success criteria as normative requirements and adds ICT-specific provisions. Real-time text communication services (chat, instant messaging) must support assistive technology APIs such as Microsoft UI Automation, Apple Accessibility API, or Linux AT-SPI. The standard also requires that error messages include specific error identification and suggested recovery actions, rather than generic error codes — for example, “The password must contain at least 8 characters including one number” instead of “Error 0x80070057.”
Documentation and support: IEC 63080 requires that product documentation — including user manuals, quick-start guides, and online help — be provided in an accessible electronic format (WCAG 2.1 Level AA conformant HTML or PDF with proper tagging). Technical support services must be available through at least two communication channels (e.g., phone and email, or chat and relay service), and support staff must receive training on accessibility features of the product.
3. Engineering Implementation and Design Insights
Experience from early adopters of IEC 63080 demonstrates that integrating accessibility requirements from the start of the design process reduces overall development cost by 30-60% compared to retrofitting accessibility after product launch. The standard recommends including at least one person with a disability in the design review team and conducting accessibility user testing with a minimum of five participants representing diverse impairment categories.
Platform-level versus application-level accessibility: IEC 63080 emphasizes that accessibility must be implemented at both levels. Platform-level accessibility services (screen readers, magnification, high-contrast themes, speech recognition input) must be provided by the operating system, while application-level accessibility requires that applications correctly implement platform accessibility APIs. The standard identifies a common failure mode: applications that create custom UI controls without implementing proper accessibility patterns (e.g., a custom slider control that does not expose its value range to the accessibility API).
Assistive technology compatibility testing: The standard requires documented compatibility testing with at least two assistive technologies in each relevant category — for example, both JAWS and NVDA screen readers for Windows platforms, and both VoiceOver and TalkBack for mobile platforms. Testing must verify that all functionality is accessible through the assistive technology alone, without requiring simultaneous use of direct interaction. The report provides a test protocol template that includes a task-based evaluation with defined success criteria for each critical user journey.
A critical requirement often overlooked in web-based ICT products: the standard mandates that authentication mechanisms (login pages, password fields, CAPTCHA) must not require cognitive function tests (such as identifying objects in images) as the only authentication method. This directly impacts the growing use of image-based CAPTCHAs. The standard recommends alternative authentication methods such as OTP via email/SMS, hardware security keys, or biometric authentication as accessibility-equivalent alternatives.
4. Frequently Asked Questions
Q1: Is IEC 63080 mandatory for ICT products sold in the EU or other markets?
A: The European Accessibility Act (Directive 2019/882), effective June 2025, references IEC 63080 as a harmonized standard for demonstrating compliance with accessibility requirements for ICT products and services placed on the EU market.
A: The European Accessibility Act (Directive 2019/882), effective June 2025, references IEC 63080 as a harmonized standard for demonstrating compliance with accessibility requirements for ICT products and services placed on the EU market.
Q2: How does IEC 63080 relate to EN 301 549 (EU accessibility standard)?
A: IEC 63080 and EN 301 549 have converged significantly. IEC 63080 was developed in coordination with the European standardization organizations, and the technical requirements are substantially aligned. EN 301 549 includes additional procurement-specific clauses for public sector bodies.
A: IEC 63080 and EN 301 549 have converged significantly. IEC 63080 was developed in coordination with the European standardization organizations, and the technical requirements are substantially aligned. EN 301 549 includes additional procurement-specific clauses for public sector bodies.
Q3: What is the minimum font size requirement under IEC 63080?
A: The standard does not prescribe a minimum font size as a fixed value. Instead, it requires that text be resizable up to 200% without loss of content or functionality, and that the font size used in product documentation and on-device displays be readable by the intended audience under typical viewing conditions.
A: The standard does not prescribe a minimum font size as a fixed value. Instead, it requires that text be resizable up to 200% without loss of content or functionality, and that the font size used in product documentation and on-device displays be readable by the intended audience under typical viewing conditions.
Q4: Are there exemptions for products that incorporate accessibility as a manufacturer-claimed feature?
A: No. IEC 63080 applies to all ICT products and services within its scope regardless of marketing positioning. However, the standard provides a “proportionate burden” clause — if a manufacturer can demonstrate that meeting a specific requirement would impose a disproportionate financial or organizational burden, an alternative accessibility solution providing substantially equivalent functionality may be accepted.
A: No. IEC 63080 applies to all ICT products and services within its scope regardless of marketing positioning. However, the standard provides a “proportionate burden” clause — if a manufacturer can demonstrate that meeting a specific requirement would impose a disproportionate financial or organizational burden, an alternative accessibility solution providing substantially equivalent functionality may be accepted.
