ForHosting KIT · Veille et lecture de sites web

Attributs requis du rôle ARIA

Consultez un rôle ARIA et obtenez son contrat exact : checkbox exige aria-checked, compte 8 attributs recommandés comme aria-label ou aria-invalid et demande un nom accessible. Fondé sur WAI-ARIA 1.2, avec les rôles inconnus refusés. Gratuit dans votre navigateur.

  • Gratuit
  • Fonctionne dans votre navigateur
  • Sans inscription
  • Vos données restent sur votre appareil
Utilisez-le depuis WebAPIE-mailTelegramApp bientôt
Si vous saisissez
Poste
checkbox
Vous obtenez
Catégorie
widget
Superclasse
input
Attributs obligatoires
aria-checked
Nombre requis
1

Accessible Rich Internet Applications (ARIA) définit des dizaines de rôles afin que les widgets personnalisés exposent le même sens que les contrôles HTML natifs. Chaque rôle porte un contrat fixe : certains états et propriétés sont obligatoires, d'autres sont recommandés pour un bon support des technologies d'assistance, et de nombreux rôles exigent aussi un nom accessible. Deviner ces attributs de mémoire est une cause fréquente d'échecs d'audit — absence de aria-checked sur un rôle checkbox, oubli de aria-controls sur un combobox, ou landmark region livré sans libellé. Cette capacité accepte un seul nom de rôle ARIA, normalise la casse et les préfixes courants, et renvoie un paquet déterministe : attributs requis, attributs recommandés, catégorie, superclasse, exigences de nom et une courte description fondée sur WAI-ARIA 1.2.

Signification des attributs ARIA requis et recommandés

Dans la spécification WAI-ARIA, chaque rôle concret énumère les Required States and Properties — attributs que l'auteur doit fournir pour que le rôle soit valide — et les Supported States and Properties que les technologies d'assistance attendent lorsque le motif nécessite un état plus riche. Les attributs requis sont non négociables : un rôle checkbox sans aria-checked, un slider sans aria-valuenow ou un combobox sans aria-controls et aria-expanded échoue aux contrôles automatiques et perturbe les lecteurs d'écran.

La réponse indique aussi si le rôle exige un nom accessible et comment ce nom peut être calculé (attributs fournis par l'auteur, contenu de l'élément ou interdit). Les rôles concrets obsolètes comme directory restent interrogeables mais sont signalés pour que les outils de migration avertissent sans bloquer la recherche.

Contrat d'entrée, forme de la réponse et erreurs

Des notes optionnelles apparaissent lorsqu'une exigence est conditionnelle — par exemple un separator focalisable exige aria-valuenow, aria-valuemin et aria-valuemax alors qu'un separator décoratif statique ne les exige pas. Exemple : le rôle checkbox renvoie aria-checked comme requis et un ensemble recommandé couvrant readonly, required, disabled, libellés et messages d'erreur. Exemple : le rôle scrollbar renvoie les quatre propriétés obligatoires aria-controls, aria-valuenow, aria-valuemin et aria-valuemax.

Associez la recherche à votre propre documentation de lint ou de design system ; ce point d'accès ne parcourt pas une page ni ne valide le balisage en direct — il répond uniquement à la question de spécification pour un nom de rôle à la fois.

Oracles de lint d'accessibilité en CI

À partir des valeurs role extraites du balisage ou de Storybook, vérifiez que chaque attribut requis est présent avant le merge ; échouez sur les rôles abstraits ou inconnus.

Quels attributs ARIA sont requis pour un rôle donné ?

Envoyez le nom du rôle (par exemple checkbox, combobox, slider).

Cela valide-t-il ma page HTML ?

Non. Cela ne consulte que les caractéristiques de spécification pour un nom de rôle. Utilisez un auditeur d'accessibilité (par exemple web.accessibility) pour analyser le balisage en direct.

Quelle différence entre attributs requis et recommandés ?

Les attributs requis doivent être présents pour que le rôle soit valide : une case checkbox sans aria-checked échoue aux contrôles automatiques et désoriente les lecteurs d'écran. Les recommandés sont ceux qu'attendent les technologies d'assistance quand le modèle a besoin de plus d'état, comme désactivé, lecture seule ou message d'erreur.

Le rôle checkbox a-t-il besoin d'un nom accessible ?

Oui. La recherche indique que le nom est obligatoire et qu'il peut provenir du contenu de l'élément ou de l'auteur, par exemple avec aria-label ou aria-labelledby lorsque le texte visible ne suffit pas.

Que deviennent les rôles dépréciés ou abstraits ?

Les rôles dépréciés, comme directory, restent consultables mais sont signalés, afin qu'un outil de migration puisse avertir sans bloquer. Les rôles abstraits et les noms inconnus sont refusés, pour que personne n'ajoute d'attributs à un rôle qui n'existe pas.

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

POSThttps://api.kit.forhosting.com/web/aria-role-lookup

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

curl -X POST https://api.kit.forhosting.com/web/aria-role-lookup \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"role":"checkbox"}'
{
  "role": "checkbox"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "web.aria_role_lookup",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

timeout_sec30
max_crawl_pages25
HTTPCodeSignification
401unauthorizedClé API absente ou invalide : vérifiez l’en-tête Authorization.
402insufficient_balanceSolde insuffisant : rechargez votre compte pour lancer cette tâche.
404unknown_typeType de tâche inconnu : vérifiez le champ type de votre requête.
429rate_limitedTrop de requêtes : ralentissez la cadence, puis réessayez.

Les noms non reconnus et les rôles abstraits échouent avec invalid_input pour que les clients n'inventent jamais d'attributs pour des rôles inexistants. La même table pure alimente l'outil gratuit du navigateur et l'API prépayée à $0.002 par élément réussi.

Signification des attributs ARIA requis et recommandés

Les attributs recommandés de cette API sont les propriétés prises en charge dont les auteurs ont le plus souvent besoin pour un comportement clavier et AT correct : indicateurs de sélection et d'expansion, min et max de valeur pour les widgets de plage, orientation pour toolbars et tablists, et aides au nommage telles que aria-label et aria-labelledby lorsque le texte visible est insuffisant.

Contrat d'entrée, forme de la réponse et erreurs

Envoyez un corps JSON avec un champ chaîne obligatoire, role, qui peut aussi arriver sous les alias value, name, query ou aria_role. Le moteur coupe les espaces, met le jeton en minuscules, retire les préfixes optionnels comme role= ou aria-role, et supprime les espaces ou underscores internes afin que column header et columnheader se résolvent tous deux. En cas de succès le corps renvoie le rôle normalisé, category, superclass, description, abstract false, required_attributes et recommended_attributes sous forme de tableaux de chaînes triés, required_count et recommended_count, name_required, name_from, deprecated, et spec fixé à WAI-ARIA 1.2. Rôle manquant, chaîne vide, noms inconnus et rôles abstraits lèvent invalid_input avec un message qui nomme le problème ; ces échecs ne sont pas facturés.

Où la recherche d'attributs de rôle ARIA est utile

Les plateformes de formation et cours WCAG utilisent le chemin gratuit du navigateur pour que les apprenants explorent checkbox face à switch, ou dialog face à alertdialog, sans mémoriser les tables de caractéristiques complètes. Ancrez dans vos tests les tableaux triés renvoyés, documentez le rejet des rôles abstraits pour les auteurs qui copient par erreur des noms de taxonomie, et vous obtenez un contrat stable pour guides de style, outils MCP et validateurs en bordure sans déployer un moteur d'accessibilité complet. Les linters d'accessibilité et plugins CI appellent l'API comme oracle : à partir de la chaîne role trouvée sur un nœud, ils récupèrent les attributs requis et font échouer le build si l'un manque. Comme l'implémentation est parse de niveau A avec un modèle de coût analytique, chaque appel réussi coûte le prix de base publié $0.002, s'exécute hors ligne dans l'isolate du worker et ne dépend jamais d'un téléchargement du site W3C.

Documentation de design system

Générez des tableaux ARIA par composant à partir de la chaîne role pour que les ingénieurs voient attributs requis et recommandés à côté de l'API React ou Web Component.

Formation et ateliers WCAG

Permettez aux apprenants de consulter checkbox, combobox et region de façon interactive et de comparer les règles name_required sans mémoriser les tables WAI-ARIA complètes.

Que se passe-t-il si le nom du rôle est inconnu ?

La tâche échoue avec invalid_input et un message indiquant que le rôle n'est pas reconnu. Les rôles abstraits comme widget ou landmark sont aussi rejetés car les auteurs ne doivent pas les utiliser.

La recherche est-elle sensible à la casse ?

Non. Les noms de rôle sont normalisés en minuscules ; les préfixes optionnels comme role= sont retirés, et les espaces ou underscores dans le jeton sont supprimés.

Combien coûte la recherche d'attributs de rôle ARIA ?

L'outil navigateur est gratuit. Les requêtes API utilisent le solde prépayé KIT à $0.002 par appel réussi ; une entrée invalide n'est pas facturée.

Consulter la documentation complète du KIT →