Glossaire

Le nom, le rôle, la valeur, le paramétrage et les changements d'états

Ajouter ma proposition
  • Proposition DINSIC | 06/05/2019 - 17:03

    Modification de l’entrée de glossaire “Le nom, le rôle, la valeur, le paramétrage et les changements d'états”

    Raison de la modification

    Référence au document WAI-ARIA 1.1 Authoring Practices et remplacement de API ARIA par WAI-ARIA

    Ancienne entrée de glossaire

    Le nom, le rôle, la valeur, le paramétrage et les changements d’états

    Un composant doit avoir un rôle et un nom appropriés, ses valeurs, états et paramètres éventuels doivent également être accessibles et correctement transmis aux APIs d'accessibilité notamment.

    Un composant peut s'appuyer sur un élément interactif HTML ou sur un élément non interactif surchargé par l'API ARIA via un rôle ad hoc. Important : les boutons (balises button ou input type="button") lorsqu'ils sont contrôlés via JavaScript sont à évaluer avec le critère 7.1.

    Le nom peut être l'intitulé du composant comme l'intitulé d'un bouton par exemple.

    La valeur est, par exemple, l'élément sélectionné d'une liste déroulante ou la valeur actuelle d'un curseur (slider).

    Le rôle correspond au type d'élément défini par la spécification HTML ou l'API WAI-ARIA (comme la balise button ou le rôle ARIA role="button").

    Le paramétrage correspond aux informations particulières d'un composant, généralement mis à disposition par l'API WAI-ARIA. Par exemple aria-controls est un paramètre qui transmet aux APIs l'information que le composant contrôle tel ou tel contenu (référencé par son identifiant - attribut id).

    Les changements d'états sont également mis à disposition par l'API WAI-ARIA. Par exemple aria-expanded est un état permettant de signaler aux APIs que le composant est « ouvert » ou « fermé ». Note : un état peut également être transmis via le nom, lorsque l'intitulé est changé dynamiquement pour correspondre à l'état de la zone contrôlée notamment.

    Ces paramètres ne sont pas obligatoires mais peuvent être requis s'ils sont indispensables pour rendre le composant accessible. C'est à l'auditeur de considérer les cas où ces paramètres sont indispensables en fonction du contexte lié à l'utilisation du composant.

    L'auditeur doit également vérifier que, lorsqu'il sont présents, ces paramètres sont correctement utilisés.

    Note : les rôles, propriétés et états ARIA s'implémentent via des attributs, par exemple role="banner", aria-hidden="true".

    Nouvelle entrée de glossaire

    Le nom, le rôle, la valeur, le paramétrage et les changements d’états

    Un composant doit avoir un rôle et un nom appropriés. Ses valeurs, états et paramètres éventuels doivent également être accessibles et correctement transmis aux APIs d'accessibilité notamment.

    Un composant peut s'appuyer sur un élément interactif HTML ou sur un élément non interactif surchargé par WAI-ARIA via un rôle ad hoc. Important : les boutons (balises <button> ou <input type="button">) lorsqu'ils sont contrôlés via JavaScript sont à évaluer avec le critère 7.1.

    Le nom peut être l'intitulé du composant (l'intitulé d'un bouton, par exemple).

    La valeur est, par exemple, l'élément sélectionné d'une liste déroulante ou la valeur actuelle d'un curseur (slider).

    Le rôle correspond au type d'élément défini par la spécification HTML ou WAI-ARIA (comme la balise button ou l’attribut WAI-ARIA role="button").

    Le paramétrage correspond aux informations particulières d'un composant, généralement mis à disposition par WAI-ARIA. Par exemple aria-controls est un paramètre qui transmet aux APIs l'information que le composant contrôle tel ou tel contenu (référencé par son identifiant - attribut id).

    Les changements d'états sont également mis à disposition par WAI-ARIA. Par exemple aria-expanded est un état permettant de signaler aux APIs que le composant est « ouvert » ou « fermé ». Note : un état peut également être transmis via le nom, lorsque l'intitulé est changé dynamiquement pour correspondre à l'état de la zone contrôlée notamment.

    Ces paramètres ne sont pas obligatoires mais peuvent être requis s'ils sont indispensables pour rendre le composant accessible. C'est à l'auditeur de considérer les cas où ces paramètres sont indispensables en fonction du contexte lié à l'utilisation du composant.

    L'auditeur doit également vérifier que, lorsqu'ils sont présents, ces paramètres sont correctement utilisés.

    Pour ce faire (s’il juge cela pertinent compte tenu du contexte d’implémentation des composants et des choix ergonomiques mis en œuvre) il peut s’appuyer sur les recommandations d’utilisation de WAI-ARIA pour les composants ayant des attributs WAI-ARIA correspondant à un motif de conception tel que décrit dans le document WAI-ARIA 1.1 Authoring Practices

    Note : les rôles, propriétés et états WAI-ARIA s'implémentent via des attributs, par exemple role="banner", aria-hidden="true".

    Mise(s) à jour

    • le 20/05/2019 suite à commentaire sdeschamps 20/05/2019 - 17:26

     

    abatifol

    Bonjour,

    Dans ce cas n'est-il pas impératif aussi de rajouter un type button pour la balise button ?

    "les boutons (balises ou ) lorsqu'ils sont contrôlés via JavaScript sont à évaluer avec le critère 7.1."

    • Pas d'accord 0 Pas d'accord

    abatifol

    Bonjour,

    Dans ce cas n'est-il pas impératif aussi de rajouter un type button pour la balise button ?

    "les boutons (balises button type="button" ou input type="button") lorsqu'ils sont contrôlés via JavaScript sont à évaluer avec le critère 7.1."

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour, un bouton sans type button sera également à évaluer avec le critère 7.1 dès lors qu'il est contrôlé par Javascript. Le type button permet simplement d'éviter de devoir annuler l'action par défaut du bouton via javascript.

    • Pas d'accord 0 Pas d'accord

    sdeschamps

    Bonjour,

    Petite note de FALC et d'ortho (comme dirait Annecav ;)) :

    « Un composant doit avoir un rôle et un nom appropriés, ses valeurs, états et paramètres éventuels doivent également être accessibles et correctement transmis aux APIs d'accessibilité notamment. »

    Deux phrases, donc à séparer par un point :

    « Un composant doit avoir un rôle et un nom appropriés. Ses valeurs, états et paramètres éventuels doivent également être accessibles et correctement transmis aux APIs d'accessibilité notamment. »

    • Pas d'accord 0 Pas d'accord

    sdeschamps

    Bonjour,

    Formulation difficile à suivre :

    « Le nom peut être l'intitulé du composant comme l'intitulé d'un bouton par exemple. »

    Propositions :
    * « Le nom peut être l'intitulé du composant, comme l'intitulé d'un bouton par exemple. »
    * « Le nom peut être l'intitulé du composant (l'intitulé d'un bouton, par exemple). »

    • Pas d'accord 0 Pas d'accord

    sdeschamps

    Bonjour, petites coquilles :

    « lorsqu'il sont présents » → « lorsqu'ils sont présents »

    « et des choix ergonomiques mise en oeuvre » → « et des choix ergonomiques mis en œuvre »

    Par ailleurs, pour des questions de lisibilité, je remplacerais :

    « Pour ce faire s’il juge cela pertinent compte tenu du contexte d’implémentation des composants et des choix ergonomiques mise en oeuvre il peut s’appuyer sur les recommandations d’utilisation de WAI-ARIA pour les composants ayant des attributs WAI-ARIA correspondant à un motif de conception tel que décrit dans le document WAI-ARIA 1.1 Authoring Practices »

    … par :

    « Pour ce faire (s’il juge cela pertinent compte tenu du contexte d’implémentation des composants et des choix ergonomiques mis en œuvre) il peut s’appuyer sur les recommandations d’utilisation de WAI-ARIA pour les composants ayant des attributs WAI-ARIA correspondant à un motif de conception tel que décrit dans le document WAI-ARIA 1.1 Authoring Practices »

    (ou virgules d'apposition, au choix)

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonsoir, vos commentaires ont été pris en compte.

    • Pas d'accord 0 Pas d'accord

Retour en haut