La construction d'un composant de dialogue robuste (modal) pour ma bibliothèque Agnosticui m'a récemment conduit sur un chemin fascinant. Mon plan initial était de créer un composant complètement indépendant, en tirant parti du nouveau<dialog></dialog> élément pour les avantages accessibilité. Cependant, après des recherches approfondies, j'ai opté pour la bibliothèque A11y-dialogue de Kitty Giraudel, créant des adaptateurs pour Vue 3, Svelte et Angular (un adaptateur de réact existe déjà). Cette décision découle d'un examen attentif de la native<dialog></dialog> Limitations de l'élément.

Le natif<dialog></dialog> élément: une évaluation critique

Tandis que le natif<dialog></dialog> L'élément est prometteur et est activement amélioré, plusieurs lacunes actuelles ont influencé ma décision:

1. Cliquez sur la toile de fond: le comportement par défaut ne ferme pas la bo?te de dialogue lors du clic à l'extérieur.
2. Incompatibilité du r?le alertdialog : le r?le crucial alertdialog Aria, essentiel pour les alertes nécessitant l'interaction des utilisateurs et la prévention de la fermeture / la fermeture de l'ESC, ne fonctionne pas correctement.
3. ::backdrop : Cet élément de style n'est disponible que lorsque dialog.showModal() est utilisé par programme.
4. Incohérences de style: les styles par défaut sont dépendants du navigateur, nécessitant une intervention JavaScript, sapant l'avantage "pur html".

L'excellent post d'Adam Argyle sur la construction avec natif<dialog></dialog> Fournit des solutions de contournement précieuses, mais pour mes besoins, les complexités l'emportaient sur les avantages.

Définition des exigences d'accessibilité pour un composant de dialogue

Mon composant de dialogue Agnosticui nécessaire pour répondre à ces critères d'accessibilité cruciaux:

1. Fermeture de toile de fond / ESC: fermeture via des clics de fond ou des appuyés sur la touche ESC.
2. Piénage de mise au point: empêcher l'onglet à l'extérieur du composant.
3. Tabbing bidirectionnel: prise en charge en avant (onglet) et en arrière (onglet de décalage).
4. Restauration de mise au point: retournement de la mise au point à l'élément précédemment actif après la fermeture.
5. Attributs ARIA corrects: Application appropriée des attributs et bascules Aria.
6. Portails (framework-spécifiques): Prise en charge des portails dans les frameworks JavaScript.
7. alertdialog Role Support: Gestion correctement les scénarios d'alerte.
8. Prévention du parchemin du corps: Empêcher éventuellement le défilement du corps sous-jacent.
9. éviter natif<dialog></dialog> Pièges: aborder les limites de l'élément natif.
10. Style et prefers-reduced-motion : autoriser le style personnalisé et le respect des préférences des utilisateurs.

Les articles de Scott O'Hara et Kitty fournissent des plongées plus profondes dans la création de dialogue accessible. Ces exigences ont clairement mis en évidence les limites de compter uniquement sur le natif<dialog></dialog> élément.

Audit A11y-dialogue pour l'accessibilité

Avant d'intégrer A11y-dialog, j'ai effectué un audit d'accessibilité complet:

• Vérification manuelle: Testing des fonctionnalités entre les navigateurs.
• Outillage automatisé: Utilisation du phare, IBM Equal Access Accessibility Checker, Deque's Axe et Wave.
• Test du lecteur d'écran: Utilisation des machoires, des NVDA et de la voix off.
• Test des utilisateurs: (idéalement, les tests avec de vrais utilisateurs).

Les recherches de Deque Systems indiquent que les outils automatisés ne prennent qu'environ 57% des problèmes d'accessibilité, soulignant l'importance des tests manuels et des commentaires des utilisateurs. J'ai testé à l'aide d'une page HTML locale simple pour isoler le composant à partir des complexités du cadre de test.

L'audit a confirmé la robustesse et l'adhésion d'A11y-dialogue et l'adhésion à mes conditions d'accessibilité.

Considérations de composants de dialogue spécifiques au framework

De nombreux cadres offrent leurs propres composants de dialogue. Bien que je ne les audit pas personnellement, voici quelques ressources et observations:

• Angular: l'audit de Deque 2020 a mis en évidence le matériau et NGX-Bootstrap en tant que prétendants forts.
• React: REAKIT, le chakra-ui, le matériel, la portée / la bo?te de dialogue et la bo?te de dialogue REACT-ARIA / méritent d'être explorés.
• Vue: Vuetensils, VueTtify et Primevue (avec un problème de restauration de focus noté) sont des options.
• Svelte: Svelte-Headlessui, Svelterial's Material Port et Svelte-A11y-Dialog (particulièrement utile pour la création de composants personnalisés).
• Bootstrap: nécessite des étapes manuelles pour la conformité à l'accessibilité.

Ma bibliothèque Agnosticui utilise des adaptateurs A11y-dialogue pour la compatibilité des travaux croisés.

Construire des systèmes de conception personnalisés: peser l'effort

La création d'un composant de bo?te de dialogue personnalisé pour un système de conception nécessite un effort important et une considération attentive des nuances d'accessibilité. Bien que faisable, le risque d'erreurs est élevé, et tirer parti des solutions existantes et bien testées comme A11y-dialogue s'avère souvent plus efficace et fiable. Les conseils de Scott O'Hara d'utiliser des plugins robustes comme A11y-dialog pour assurer des expériences de croisement cohérentes sont convaincants.

Conclusion

Mon choix d'utiliser A11y-dialog, couplé à la création d'adaptateurs Vue 3, Svelte et angulaires, accordé à l'accessibilité et à l'efficacité. Bien que la construction d'un composant personnalisé ait été une option, le potentiel d'erreurs et la qualité existante de A11y-dialogue en ont fait le choix supérieur. Ce voyage a souligné l'importance des audits d'accessibilité approfondis et la valeur de tirer parti des bibliothèques bien entretenues. L'adaptabilité de A11y-dialog, étendant ses fonctionnalités pour créer des composants de tiroir, a encore solidifié sa valeur au sein de ma bibliothèque.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!