wcag
1.0.0
Veuillez utiliser cette branche comme cible pour les demandes de traction jusqu'au 10 juillet 2016.
Ce référentiel est utilisé pour développer du contenu pour WCAG 2, ainsi que des documents et des techniques de compréhension associés.
@@ pour terminer
Voir aussi: Guide de style WCAG 2
WCAG 2.0 a été maintenu dans une structure de fichiers différente de celle des versions ultérieures de WCAG. Les fichiers source pour WCAG 2.0 sont dans le dossier WCAG20 et existe principalement à des fins d'archives. Ne modifiez pas le contenu dans ce dossier.
Le contenu de WCAG 2.1 et ultérieure est organisé en fonction de la structure du fichier ci-dessous. Le référentiel WCAG contient des fichiers source et auxiliaires pour WCAG 2, comprenant WCAG 2 et éventuellement des techniques. Il contient également des fichiers auxiliaires qui prennent en charge le formatage automatisé du document. Pour faciliter l'édition multipartite, chaque critère de réussite est dans un fichier séparé, composé d'un fragment HTML qui peut être inclus dans les principales directives. Les fichiers clés incluent:
guidelines/index.html - Le fichier de directives principalesguidelines/sc/{version}/*.html - Fichiers pour chaque critère de réussiteguidelines/terms/{version}/*.html - Fichiers pour chaque définitionunderstanding/{version}/*.html - Comprendre les fichiers pour chaque critère de réussite Où {version} est "20", le contenu provient de WCAG 2.0. "21" est utilisé pour le contenu introduit dans WCAG 2.1, "22" pour WCAG 2.2, etc.
Critères de réussite Les gestionnaires préparèrent les critères de réussite des candidats, prêts à l'inclusion dans le document des lignes directrices. Pour préparer les critères de réussite, suivez ces étapes:
#1 .Les critères de réussite utilisent une structure simple d'éléments HTML, avec quelques valeurs d'attribut de classe, pour assurer la cohérence. Les scripts d'amélioration et la clé de style de cette structure. Le contenu que vous fournissez est indiqué en accolades. Les articles après les commentaires sont facultatifs.
< section class =" sc " >
< h4 > {SC Handle} </ h4 >
< p class =" conformance-level " > {Level} </ p >
< p class =" change " > {Change} </ p >
< p > {Main SC Text} </ p >
<!-- if SC has sub-points -->
< dl >
< dt > {Point Handle} </ dt >
< dd > {Point Text} </ dd >
</ dl >
<!-- if SC has notes -->
< p class =" note " > {Note} </ p >
</ section >Remarque Vous ne fournissez pas le numéro SC. Les numéros seront attribués et probablement générés automatiquement, plus tard.
Les valeurs que vous fournissez sont décrites ci-dessous. Reportez-vous au critère de réussite 2.2.1 pour un exemple de chacun de ces éléments de contenu.
«Des éléments peuvent être fournis.
Si vous fournissez des définitions de terme avec votre SC, incluez-les dans le répertoire guidelines/terms/{version}
< dt > < dfn id =" dfn-{shortname} " > {Term} </ dfn > </ dt >
< dd > {Definition} </ dd > L'élément dfn indique au script qu'il s'agit d'un terme et provoque des fonctionnalités de style et de liaison spéciales. Pour lier à un terme, utilisez un élément <a> sans attribut href ; Si le texte du lien est le même que le terme, le lien sera correctement généré. Par exemple, s'il y a une <dfn>web page</dfn> sur la page, un lien sous forme de <a>web page</a> entraînera un lien approprié.
Si le texte de liaison a une forme différente du terme canonique, par exemple, "pages Web" (noter le pluriel), vous pouvez fournir un indice sur le terme définition avec l'attribut data-lt . Dans cet exemple, modifiez le terme à être <dfn data-lt="web pages">web page</dfn> . Plusieurs noms alternatifs pour le terme peuvent être séparés avec des caractères de tuyau, sans espace de pointe ou de fuite, par exemple, <dfn data-lt="web pages|page|pages">web page</dfn> .
Il existe un fichier de compréhension par critère de réussite, plus un index:
understanding/index.html - page d'index, nécessite un décOMMANT ou ajouter une référence aux pages de compréhension individuelles car ils sont mis à dispositionunderstanding/{version}/*.html - Fichiers pour chaque page de compréhension, nommé le même que le fichier de critère de réussite dans les directivesLes fichiers sont remplis d'un modèle qui fournit la structure attendue. Laissez la structure du modèle en place et ajoutez du contenu le cas échéant dans les sections. Les éléments avec class = "instructions" fournissent des conseils sur le contenu à inclure dans cette section; Vous pouvez supprimer ces éléments si vous le souhaitez, mais vous n'êtes pas obligé. Le modèle pour les exemples propose soit une liste de balles ou une série de sous-sections, de choisir l'une de ces approches et de supprimer l'autre du modèle. Le modèle pour les techniques comprend des sous-sections pour les "situations", supprimez cette section wrapper si ce n'est pas nécessaire.
Les fichiers de compréhension sont référencés à partir du critère de réussite pertinent sur la spécification WCAG; Ces liens sont placés par le script.
Le lieu de publication officielle pour comprendre les pages est actuellement https://www.w3.org/wai/wcag21/udgerstanding/. Ce contenu est mis à jour selon les besoins; et peut être automatisé.
Les techniques sont dans le dossier Techniques et regroupées par technologie en sous-reprendurs. Chaque technique est un fichier autonome, qui est au format HTML avec une structure régulière d'éléments, de classes et d'ID.
Le modèle de technique montre la structure des techniques. Les sections principales sont dans des éléments de haut niveau <Section> avec des ID spécifiques: méta, applicabilité, description, exemples, tests, connexes, ressources. Les sections de description et de test sont nécessaires; Les sections d'applicabilité et d'exemples sont recommandées; Les sections connexes et de ressources sont facultatives. La méta-section fournit un contexte pour la technique pendant la création mais est supprimé pour publication. Le titre de la technique est dans l'élément <h1> . Les éléments avec class="instructions" fournissent des informations sur le remplissage du modèle. Ils doivent être supprimés au fur et à mesure que la technique est développé mais s'il n'est pas supprimé, sera ignoré par le générateur. Ne copiez pas class="instructions" sur le contenu réel.
Les techniques peuvent utiliser une feuille de style temporaire pour faciliter l'examen des brouillons. Cette feuille de style est remplacée par d'autres feuilles de style et la structure pour une publication formelle. Pour utiliser cette feuille de style, ajoutez <link rel="stylesheet" type="text/css" href="../../css/editors.css"/> à la tête de la technique.
Les techniques peuvent inclure des images. Placez le fichier image dans le dossier img de la technologie pertinente - ce qui signifie que toutes les techniques pour une technologie partagent un ensemble d'images communes. Utilisez un lien relatif pour charger l'image. La plupart des images doivent être chargées avec un élément <figure> et étiquetées avec une <figcaption> positionnée au bas de la figure. <figure> Les éléments doivent avoir un attribut id . De petites images en ligne peuvent être chargées d'un élément <img> avec du texte alt approprié.
Les techniques devraient inclure de brefs exemples de code pour démontrer comment auteur du contenu qui suit la technique. Les exemples de code doivent être faciles à lire et généralement ne pas compléter le contenu en eux-mêmes. Des exemples plus complets peuvent être fournis comme exemples de travail (voir ci-dessous). Lien vers des exemples de travail au bas de chaque exemple, dans un élément <p class="working-example"> , contenant un lien relatif vers ../../working-examples/{example-name}/ }/.
Des références croisées à d'autres techniques peuvent être fournies lorsqu'ils sont utiles. Généralement, ils doivent être fournis dans la section "Techniques connexes" mais peuvent être fournis ailleurs. Utilisez un lien relatif pour référencer la technique, {Technique ID} si la même technologie, ou ../{Technology}/{Technique ID} sinon. Si la technique est toujours en cours de développement et n'a pas d'identification formelle, référez le chemin du fichier de développement. Si la technique est en cours de développement dans une branche différente, utilisez un URI absolu dans la version Rawgit de la technique.
Les références croisées aux directives et aux critères de réussite doivent utiliser un URI relatif à la page de compréhension de cet élément. Les références croisées à d'autres parties des directives doivent utiliser un URI absolu aux directives publiées sur la page W3C TR, un URI commençant par https://www.w3.org/TR/WCAG21/# . Notez que les références à des lignes directrices ou à des critères de réussite auxquelles les techniques se rapportent sont ajoutées par le générateur lors de la publication en fonction des informations dans les documents de compréhension, de sorte que les liens redondants à ceux-ci ne sont pas normalement nécessaires ou conseillées.
Les priorités générales et les processus pour travailler sur les techniques sont maintenus dans le wiki.
Les nouvelles techniques devraient utiliser un nom de fichier dérivé d'une version raccourcie du titre de technique. Les éditeurs attribueront à la technique un ID et renommeront le fichier lorsqu'il sera accepté par le groupe de travail. Par exemple, une technique "utilisant l'attribut alt sur l'élément IMG pour fournir des alternatives de texte courtes" peut utiliser "IMG-alt-short-text-alternatives.html" comme nom de fichier. Les éditeurs lui attribueront un ID officiel et renommeront le fichier, lorsqu'il sera accepté par le groupe de travail.
Chaque nouvelle technique doit être créée dans une nouvelle branche. La configuration de la branche et du fichier est automatisée via le script Create-Techniques.sh, qui peut être exécuté avec Bash. La ligne de commande est:
bash create-techniques.sh < technology > < filename > < type > " <title> "<technology> est le répertoire technologique de la technique<filename> est le nom de fichier temporaire (sans extension) pour la technique<type> est "technique" ou "échec"<title> est le titre de la technique, enfermé en citations et échappant aux caractères spéciaux avec Cela automatise les étapes suivantes:
Une fois qu'une branche et un fichier techniques sont configurés, remplissez le contenu et la demande d'examen:
Les techniques du référentiel sont des fichiers HTML simples avec un formatage minimal. Pour publication au projet des éditeurs et à l'emplacement du W3C, les techniques sont formatées par un processus de construction basé sur Eleventy pour les modèles et les Cheerio pour les transformations. Plus de détails, y compris les instructions de prévisualisation localement, peuvent être trouvés dans le processus de construction Readme.
Le générateur compile les techniques en tant que suite avec formatage et navigation. Il applique certaines structures, telles que la commande de sections de niveau supérieur décrites ci-dessus et la normalisation des titres. Il tente de traiter les liens de référence croisés pour s'assurer que l'uris fonctionne lors de la publication. L'un des rôles les plus substantiels consiste à remplir la section d'applicabilité avec des références aux directives ou aux critères de réussite auxquels la technique se rapporte. Les informations à ce sujet proviennent des documents de compréhension. Une utilisation appropriée du modèle de technique est importante pour permettre cette fonctionnalité, et les techniques mal formées peuvent faire échouer le générateur.
Les techniques obsolètes ne doivent pas être supprimées du référentiel. Au lieu de cela, ils peuvent être marqués à l'aide du front-matière YAML. Par exemple:
---
obsoleteSince : 22
obsoleteMessage : |
This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2.
---obsoleteSince indique la première version de WCAG 2 lorsque la technique est devenue obsolète (cela peut être fixé à 20 s'il doit être effectivement obsolète pour toutes les versions, par exemple pour les techniques impliquant des éléments HTML obsapurants)obsoleteMessage indique un message à afficher dans la section de technique à propos de cette technique Dans les cas où des technologies entières sont obsolètes (par exemple, Flash et Silverlight), ces propriétés peuvent également être spécifiées au niveau du sous-répertoire technique, par exemple via techniques/flash/flash.11tydata.json . Notez que ce cas nécessite spécifiquement le format JSON, car cela est consommé à la fois par Eleventy et Code supplémentaire dans le processus de construction utilisé pour assembler les données techniques.
Les documents informatifs sont générés à partir des mêmes fichiers source pour les WCAG 2.2 et 2.1, car la plupart de leur contenu est cohérent entre eux. (Les lignes directrices elles-mêmes continuent d'être maintenues sur des succursales distinctes, par exemple WCAG-2.1 , dans le but de maintenir des ébauches de rédacteurs distinctes.)
Lors de la création de documents informatifs pour les versions plus anciennes, le système de construction élagait les critères de réussite spécifiques aux versions plus récentes, et à son tour toutes les techniques qui sont exclusivement liées à ces critères.
Il y a quelques cas où le contenu peut avoir besoin de répondre à une version spécifique, expliquée dans cette section.
Remarque: Ceci n'est applicable que dans techniques et les dossiers understanding ( pas guidelines ).
Dans les cas où le numéro de version précis doit être affiché dans des documents informatifs, insérer {{ versionDecimal }} . Ceci sera remplacé par le numéro de version dédié à point décimal, par exemple 2.1 ou 2.2.
Dans les cas où un document relatif à plusieurs versions justifie un appel spécifique sur une mise à jour dans une version plus récente, class="wcagXY" peut être appliquée à un élément entourant la prose en question (par exemple class="wcag22" pour WCAG 2.2) . Cela entraînera l'omission de la prose des versions antérieures et affichée avec le préfixe "Nouveau dans WCAG XY:" Dans les versions applicables.
Cette classe peut également être appliquée à côté de la classe note , auquel cas "(nouveau dans WCAG XY)" sera annexé au titre "Note" dans les versions applicables, et la note sera cachée dans les versions antérieures.
Au moment de la rédaction (novembre 2024), le journal des modifications dans l'indice des techniques est identique entre WCAG 2.1 et 2.2. Ceux-ci ont été divisés en incluses spécifiques à des versions distinctes sous _includes/techniques/changelog/*.html pour la future intervenue à l'appui de la construction de plusieurs versions de documents informatifs de la même branche.
Les exemples de techniques devraient être de brefs échantillons de code faciles à consommer de la façon dont la technique est utilisée dans le contenu. Par conséquent, les exemples devraient se concentrer sur les caractéristiques spécifiques que la technique décrit, et ne pas inclure du contenu connexe tel que le style, le script, le contenu Web environnant, etc.
Souvent, il est souhaitable de fournir des exemples plus complets, qui montrent la technique en action sans interférer avec le document de technique principal. Ces exemples montrent également le code complet requis pour faire fonctionner la technique, y compris le style complet et les fichiers de script, les images, le code de page, etc. Habituellement, ces "exemples de travail" sont référencés en bas de l'exemple élivé qui est inclus dans le principal technique.
Les exemples de travail sont stockés dans le répertoire working-examples du référentiel. Chaque exemple est dans son propre sous-répertoire, pour contenir les multiples fichiers qui peuvent être nécessaires pour faire fonctionner l'exemple. Dans certains cas, plusieurs exemples de travail partageront des ressources communes; Ceux-ci sont stockés dans le sous-répertoire approprié du répertoire des exemples de travail, par exemple, working-examples/css , working-examples/img , working-examples/script . Référence à ces ressources communes lorsqu'elles sont disponibles; Sinon, placez les ressources dans l'exemple de répertoire de travail, en utilisant des sous-répertoires pour organiser le cas échéant.
Pour créer un exemple de travail:
example- de préfixe - et qui identifie autrement sémantiquement l'exemple, par exemple, example-alt-attribute .working-examples/alt-attribute/ .index.html . Sinon, créez un nom de fichier approprié.../css/example.css . Placez d'autres ressources dans le même répertoire que l'exemple principal, par exemple, working-examples/alt-attribute/css/alt.css .https://rawgit.com/w3c/wcag/main/working-examples/alt-attribute/ . Les éditeurs mettront à jour les liens lorsque des exemples seront approuvés.WCAG 2.2 est prêt pour la traduction. Pour traduire WCAG 2.2, suivez les instructions sur la façon de traduire WCAG 2.
