Table des matières

Résumé

🧭 L’essentiel à retenir

La nouvelle norme EN 301 549 v4.1.0 met à jour les exigences d’accessibilité pour les applications mobiles en s’alignant sur WCAG 2.2.

👉 Elle va remplacer la version actuelle (v3.2.1) et servira à prouver la conformité avec les exigences européennes (EAA).

📱 Ce qui change pour les apps mobiles

1. Clarification majeure

  • Les web views dans les apps mobiles sont considérées comme du logiciel non web
  • 👉 Donc : seule la clause 11 s’applique (plus d’ambiguïté)

2. Logique d’application simplifiée

  • Un critère s’applique uniquement si la fonctionnalité existe
  • 👉 Sinon, il est automatiquement validé

3. Responsabilité par couches

  • OS / plateforme
  • App mobile
  • Matériel
  • Technologies d’assistance

👉 Une app n’est responsable que de ce qu’elle contrôle

✅ Nouveaux points importants (WCAG 2.2)

  • Focus visible : ne doit pas être caché
  • Drag alternatif : pas d’action uniquement par glissement
  • Taille minimale : 24×24 (idéalement 44×44)
  • Pas de saisie répétée
  • Auth accessible : éviter mémoire/puzzle sans alternative

🔁 Nouveaux critères maintenant obligatoires

  • Titre d’écran clair
  • Composants cohérents (même action = même apparence)

🛠️ Clarifications importantes

  • Support du clavier externe / assistif
  • Texte redimensionnable (200%)
  • Reflow sans perte de contenu
  • Compatibilité avec les réglages d’accessibilité du système
  • Messages accessibles aux lecteurs d’écran

❌ Ce qui disparaît

  • Parsing
  • Aide cohérente

🎯 En résumé

👉 La norme devient :

  • plus claire
  • plus stricte côté mobile
  • plus alignée WCAG 2.2

👉 Et impose :

  • des tests plus complets
  • une meilleure UX accessible
  • une prise en compte réelle des usages mobiles

Article traduit

La norme EN 301 549 v3.2.1 est la principale norme européenne harmonisée dans l’Union européenne pour l’accessibilité des produits et services TIC. Elle est alignée sur WCAG 2.1 niveau AA et s’applique aux sites web, aux applications mobiles, aux logiciels non web, au matériel et aux documents électroniques.

La norme est référencée au Journal officiel de l’Union européenne depuis 2021 et peut être utilisée pour démontrer la conformité avec l’Acte européen sur l’accessibilité (EAA) via le mécanisme de présomption de conformité des normes harmonisées. Cela signifie que les organisations qui appliquent cette norme sont considérées comme respectant les exigences légales en matière d’accessibilité.

Une nouvelle version de la norme, EN 301 549 v4.1.0, est actuellement en cours d’approbation à l’Institut européen des normes de télécommunications (ETSI). Cette version met à jour les clauses 9, 10 et 11 afin de s’aligner sur WCAG 2.2 et intègre des concepts et interprétations issus de la note du groupe WCAG2ICT du W3C datée du 11 décembre 2025. Une fois cette version publiée au Journal officiel de l’Union européenne, elle remplacera la version actuelle v3.2.1, probablement avec une période de transition, comme ce fut le cas lorsque la version v3.2.1 a remplacé la v2.1.2.

Qu’est-ce que cela signifie pour les applications mobiles ?

EN 301 549 v4.1.0 introduit à la fois des clarifications conceptuelles et des changements dans les définitions et la clause 11 qui affectent directement la manière dont l’accessibilité des applications mobiles est évaluée. Certains critères de succès auparavant hors périmètre pour les logiciels non web s’appliquent désormais, et plusieurs critères WCAG 2.2 ont été ajoutés.

Cette version est beaucoup plus étroitement alignée sur la note WCAG2ICT, avec de nombreuses notes explicatives harmonisées entre les deux documents. Cet article se concentre sur ces évolutions et explique ce qui doit être revu dans une approche de test d’accessibilité mobile afin de s’aligner sur la norme mise à jour.

Changements conceptuels et clarifications

Le changement conceptuel le plus important concerne probablement les web views. EN 301 549 v4.1.0 précise explicitement :

Lorsque des parties de logiciels non web, comme les applications mobiles, sont implémentées avec des web views, celles-ci sont intégrées à l’application et ne répondent donc pas à la définition d’une page web. Les exigences de la clause 11 « Logiciels non web » sont celles qui doivent être appliquées. Il n’existe aucun cas où les exigences de la clause 9 et celles de la clause 11 s’appliquent simultanément. En cas de doute, la clause 11 prévaut.

Cette clarification supprime une ambiguïté de longue date pour les applications mobiles intégrant des web views. Celles-ci doivent être évaluées comme faisant partie du logiciel non web.

La norme précise également que les critères de succès ne s’appliquent que lorsque la situation décrite se produit réellement dans l’application. Si une fonctionnalité n’existe pas, le critère est considéré comme satisfait.

Un autre changement important est l’introduction d’un modèle clair de responsabilité par couches :

  • couche sous-jacente (matériel, bas niveau),
  • logiciel de plateforme (OS, composants natifs),
  • logiciel applicatif (applications mobiles),
  • technologies d’assistance.

Chaque couche est responsable uniquement de ce qu’elle contrôle.

La terminologie évolue également : « user agent » devient « user agent ou autre logiciel de plateforme ».

Critères de succès désormais applicables aux applications mobiles

11.2.4.2 Logiciel non web avec titre

(aligné WCAG 2.2 – 2.4.2, niveau A)

Les écrans doivent avoir un titre décrivant leur contenu ou leur objectif. Dans une app mobile, cela peut être un titre visible, une icône ou un indicateur de navigation.

11.3.2.4 Identification cohérente

(aligné WCAG 2.2 – 3.2.4, niveau AA)

Les composants ayant la même fonction doivent être identifiés de manière cohérente dans toute l’application.

Nouveaux critères issus de WCAG 2.2

11.2.4.11 Focus non masqué (minimum)

Un élément ayant le focus ne doit pas être totalement caché par d’autres contenus.

11.2.5.7 Mouvements de glissement (drag)

Toute action nécessitant un glissement doit pouvoir être réalisée sans glissement, sauf si indispensable.

11.2.5.8 Taille de cible (minimum)

Les zones interactives doivent faire au moins 24 × 24 pixels (ou équivalent). Recommandation pratique : viser 44 × 44 pour une meilleure utilisabilité.

11.3.3.7 Saisie redondante

Les informations déjà fournies ne doivent pas être redemandées inutilement.

11.3.3.8 Authentification accessible (minimum)

L’authentification ne doit pas reposer uniquement sur des capacités cognitives (mémoire, puzzle), sauf si :

  • une alternative existe,
  • une aide est fournie,
  • ou des mécanismes comme biométrie sont disponibles.

Critères modifiés ou clarifiés

Quelques points clés :

  • Descriptions audio : niveau AA couvre automatiquement le niveau A.
  • Orientation : non applicable si l’app est limitée à une orientation physique.
  • Objectif des champs : dépend des capacités de la plateforme.
  • Redimensionnement du texte : jusqu’à 200 %, sans perte de contenu.
  • Reflow : contenu adaptable sans défilement bidimensionnel.
  • Contraste non textuel : concerne aussi les composants personnalisés.
  • Espacement du texte : doit être respecté si configurable.
  • Contenu au survol/focus : doit être contrôlable et persistant.
  • Clavier : compatibilité avec les entrées clavier système (physique ou assistive).
  • Piège clavier : ne s’applique que s’il y a gestion du focus.
  • Clignotement : concerne uniquement ce que l’app génère elle-même.
  • Liens : incluent les contrôles de navigation mobile.
  • Gestes pointeur : responsabilité par couche.
  • Messages d’état : doivent être accessibles aux technologies d’assistance.

Critères devenus non applicables (Void)

  • 11.4.1.1 Parsing
  • 11.3.2.6 Aide cohérente

Conclusion

La version EN 301 549 v4.1.0 renforce fortement l’alignement avec WCAG 2.2 et clarifie de nombreux points spécifiques au mobile. Elle implique :

  • une extension du périmètre des tests,
  • une meilleure prise en compte des couches techniques,
  • et une évolution des pratiques de test d’accessibilité mobile.