wcag
1.0.0
Bitte verwenden Sie diese Filiale als Ziel für Pull -Anfragen bis zum 10. Juli 2016.
Dieses Repository wird verwendet, um Inhalte für WCAG 2 zu entwickeln, sowie das damit verbundene Verständnis von Dokumenten und Techniken.
@@ zu vervollständigen
Siehe auch: WCAG 2 Style Guide
WCAG 2.0 wurde in einer anderen Dateistruktur gehalten als nachfolgende Versionen von WCAG. Quelldateien für WCAG 2.0 befinden sich im Ordner WCAG20 und existieren hauptsächlich für Archivzwecke. Bearbeiten Sie den Inhalt in diesem Ordner nicht.
Der Inhalt für WCAG 2.1 und später wird gemäß der folgenden Dateistruktur organisiert. Das WCAG -Repository enthält Quell- und Hilfsdateien für WCAG 2, das Verständnis von WCAG 2 und schließlich Techniken. Es enthält auch Hilfsdateien, die die automatisierte Formatierung des Dokuments unterstützen. Um die Bearbeitung von mehreren Parteien zu erleichtern, befindet sich jedes Erfolgskriterium in einer separaten Datei, die aus einem HTML-Fragment besteht, das in die Hauptrichtlinien einbezogen werden kann. Die Schlüsseldateien umfassen:
guidelines/index.html - Die Hauptrichtliniendateiguidelines/sc/{version}/*.html - Dateien für jedes Erfolgskriteriumguidelines/terms/{version}/*.html - Dateien für jede Definitionunderstanding/{version}/*.html - Dateien für jedes Erfolgskriterium verstehen Wo {version} "20" ist, stammte der Inhalt von WCAG 2.0. "21" wird für Inhalte verwendet, die in WCAG 2.1, "22" für WCAG 2.2 usw. eingeführt wurden.
Erfolgskriterien -Manager erstellen Kandidatenerfolgskriterien, die für die Aufnahme in das Dokument der Richtlinien bereit sind. Um Erfolgskriterien vorzubereiten, befolgen Sie die folgenden Schritte:
#1 , entwickelt wurde.Erfolgskriterien verwenden eine einfache Struktur von HTML -Elementen mit wenigen Klassenattributwerten, um eine Konsistenz zu gewährleisten. Verbesserungskripte und Stilschlüssel von dieser Struktur. Inhalt, den Sie bereitstellen, ist in Zahnspangen angegeben. Elemente nach Kommentaren sind optional.
< 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 >Beachten Sie, dass Sie die SC -Nummer nicht angeben. Nummern werden später zugewiesen und höchstwahrscheinlich automatisch generiert.
Werte, die Sie bereitstellen, werden nachstehend beschrieben. Eine Beispiel für jedes dieser Inhalte finden Sie im Erfolgskriterium 2.2.1.
`Elemente können bereitgestellt werden.
Wenn Sie zusammen mit Ihrem SC Term Definitionen bereitstellen, fügen Sie sie in die jeweiligen guidelines/terms/{version} Verzeichnis ein pro-file mit dem folgenden Format auf:
< dt > < dfn id =" dfn-{shortname} " > {Term} </ dfn > </ dt >
< dd > {Definition} </ dd > Das dfn -Element teilt dem Skript mit, dass dies ein Begriff ist und spezielle Styling- und Verknüpfungsfunktionen verursacht. Verwenden Sie zum Verknüpfen eines Begriffs ein <a> Element ohne ein href -Attribut. Wenn der Link -Text dem Begriff übereinstimmt, wird der Link korrekt generiert. Wenn beispielsweise auf der Seite einen Begriff <dfn>web page</dfn> vorhanden ist, führt ein Link in Form von <a>web page</a> zu einem ordnungsgemäßen Link.
Wenn der Link-Text eine andere Form als der kanonische Begriff, z. B. "Webseiten" (beachten Sie den Plural), können Sie mit dem data-lt Attribut einen Hinweis auf die Term Definition geben. Ändern Sie in diesem Beispiel den Begriff in <dfn data-lt="web pages">web page</dfn> . Mehrere alternative Namen für den Begriff können mit Rohrzeichen getrennt werden, ohne dass der führende oder nachverfolgende Raum, z. B. <dfn data-lt="web pages|page|pages">web page</dfn> .
Es gibt eine Verständnisdatei pro Erfolgskriterium sowie einen Index:
understanding/index.html - Indexseite, muss sich anerfassen oder auf individuelle Verständnisseiten hinzufügen, sobald sie verfügbar sindunderstanding/{version}/*.html - Dateien für jede Verständnisseite, die wie die Erfolgskriteriumsdatei in den Richtlinien bezeichnet wirdDateien werden mit einer Vorlage besiedelt, die die erwartete Struktur liefert. Lassen Sie die Vorlagenstruktur vorhanden und fügen Sie in den Abschnitten den Inhalt hinzu. Elemente mit class = "Anweisungen" geben Anleitungen darüber, welche Inhalte in diesem Abschnitt enthalten sind. Sie können diese Elemente entfernen, wenn Sie möchten, aber nicht müssen. Die Vorlage für Beispiele schlägt entweder eine Kugelliste oder eine Reihe von Unterabschnitten vor, wählen Sie einen dieser Ansätze aus und entfernen Sie die andere aus der Vorlage. Die Vorlage für Techniken enthält Unterabschnitte für "Situationen". Entfernen Sie diesen Wrapper-Abschnitt, falls dies nicht erforderlich ist.
Das Verständnis von Dateien entsteht aus dem relevanten Erfolgskriterium in der WCAG -Spezifikation. Diese Links werden vom Skript eingefügt.
Der formelle Veröffentlichungsort zum Verständnis von Seiten ist derzeit https://www.w3.org/wai/wcag21/undstanding/. Dieser Inhalt wird nach Bedarf aktualisiert. und kann automatisiert werden.
Techniken befinden sich im Ordner für Techniken und werden von Technologie in Unterordner gruppiert. Jede Technik ist eine eigenständige Datei, die sich im HTML -Format mit einer regelmäßigen Struktur von Elementen, Klassen und IDs befindet.
Die Technikvorlage zeigt die Struktur von Techniken. Die Hauptabschnitte finden Sie in Elementen auf höchstem Niveau <abschnitts> mit spezifischen IDs: Meta, Anwendbarkeit, Beschreibung, Beispiele, Tests, verwandten Ressourcen. Die Beschreibung und die Testabschnitte sind erforderlich; Die Abschnitte der Anwendbarkeit und Beispiele werden empfohlen. Die zugehörigen Abschnitte und die Ressourcenabschnitte sind optional. Der Meta -Abschnitt enthält einen Kontext für die Technik während des Autorings, wird jedoch zur Veröffentlichung entfernt. Der Titel der Technik befindet sich im Element <h1> . Elemente mit class="instructions" geben Informationen zur Bevölkerung der Vorlage an. Sie sollten entfernt werden, wenn die Technik entwickelt wird, aber wenn sie nicht entfernt wird, werden vom Generator ignoriert. Kopieren Sie nicht class="instructions" auf echten Inhalten.
Techniken können ein temporäres Stilblatt verwenden, um die Überprüfung von Entwürfen zu erleichtern. Dieses Stilblatt wird durch andere Stilblätter und Struktur für die formelle Veröffentlichung ersetzt. Um dieses Stilblatt zu verwenden, fügen Sie <link rel="stylesheet" type="text/css" href="../../css/editors.css"/> zum Kopf der Technik hinzu.
Techniken können Bilder enthalten. Platzieren Sie die Bilddatei in den img -Ordner der relevanten Technologie - dh alle Techniken für eine Technologie teilen sich eine gemeinsame Reihe von Bildern. Verwenden Sie einen relativen Link, um das Bild zu laden. Die meisten Bilder sollten mit einem <figure> -Element geladen und mit einer <figcaption> am unteren Rand der Abbildung angegeben werden. <figure> Elemente müssen ein id -Attribut haben. Kleine Inline -Bilder können mit einem <img> -Element mit geeignetem alt -Text geladen werden.
Die Techniken sollten kurze Code -Beispiele enthalten, um zu demonstrieren, wie Inhalte der Technik auftreten. Code -Beispiele sollten leicht zu lesen sein und in der Regel nicht in den Inhalten an sich selbst abgeschlossen sein. Ausführlichere Beispiele können als Arbeitsbeispiele angegeben werden (siehe unten). Link zu Arbeitsbeispielen am Ende jedes Beispiels in einem <p class="working-example"> Element, das einen relativen Link zu ../../working-examples/{example-name}/ <Example-nameen enthält.
Überkreuzte Verweise auf andere Techniken können zur Verfügung gestellt werden, wenn sie nützlich sind. Im Allgemeinen sollten sie im Abschnitt "Verwandte Techniken" bereitgestellt werden, können jedoch an anderer Stelle bereitgestellt werden. Verwenden Sie einen relativen Link, um die Technik zu verweisen, {Technique ID} wenn dieselbe Technologie oder ../{Technology}/{Technique ID} sonst. Wenn sich die Technik noch in der Entwicklung befindet und keine formale ID hat, verweisen Sie auf den Pfad zur Entwicklungsdatei. Wenn sich die Technik in einem anderen Zweig entwickelt, verwenden Sie eine absolute URI für die Rawgit -Version der Technik.
Überschreiten Verweise auf Richtlinien und Erfolgskriterien sollten einen relativen URI zur Verständnisseite für diesen Artikel verwenden. Querverweise auf andere Teile der Richtlinien sollten einen absoluten URI zu den Richtlinien verwenden, die auf der W3C TR -Seite veröffentlicht wurden, eine URI, die mit https://www.w3.org/TR/WCAG21/# beginnt. Beachten Sie, dass Verweise auf Richtlinien oder Erfolgskriterien, auf die sich Techniken beziehen, vom Generator bei der Veröffentlichung auf der Grundlage von Informationen in den Verständnisdokumenten hinzugefügt werden, sodass redundante Links zu diesen normalerweise nicht benötigt oder empfohlen werden.
Allgemeine Prioritäten und der Prozess, um an Techniken zu arbeiten, werden im Wiki aufrechterhalten.
Neue Techniken sollten einen Dateinamen verwenden, der aus einer verkürzten Version des Techniktitels abgeleitet wird. Die Redakteure weisen der Technik eine ID zu und benennen die Datei um, wenn sie von der Arbeitsgruppe akzeptiert wird. Beispielsweise könnte eine Technik "Verwenden des ALT-Attributs im IMG-Element zur Bereitstellung von kurzen Textalternativen" als "Img-Alt-Short-Text-Alternativen.html" als Dateiname verwendet. Die Redakteure weisen ihm eine formale ID zu und benennen die Datei um, wenn sie von der Arbeitsgruppe akzeptiert wird.
Jede neue Technik sollte in einem neuen Zweig erstellt werden. Die Einrichtung der Niederlassung und Datei wird über das Skript create-techniques.sh-Skript automatisiert, das mit Bash ausgeführt werden kann. Die Befehlszeile lautet:
bash create-techniques.sh < technology > < filename > < type > " <title> "<technology> ist das Technologieverzeichnis für die Technik<filename> ist der temporäre Dateiname (ohne Erweiterung) für die Technik<type> ist "Technik" oder "Misserfolg"<title> ist der Titel der Technik, die in Zitaten und entkommenen Sonderzeichen mit beigefügt istDies automatisiert die folgenden Schritte:
Sobald eine Technik -Niederlassung und -Datei eingerichtet sind, füllen Sie den Inhalt und fordern Sie die Überprüfung an:
Techniken im Repository sind einfache HTML -Dateien mit minimaler Formatierung. Zur Veröffentlichung zum Entwurf der Redakteure und des W3C -Standorts werden Techniken durch einen Build -Prozess formatiert, der auf ELEITY für Templating und Cheerio für Transformationen basiert. Weitere Details, einschließlich Anweisungen zur Vorschau vor Ort, finden Sie im Build Process Readme.
Der Generator kompilt die Techniken als Suite mit Formatierung und Navigation zusammen. Es erzwingt bestimmte Strukturen, z. B. die oben beschriebenen Abschnitte auf höchster Ebene und die Standardisierung von Überschriften. Es wird versucht, Cross -Referenz -Links zu verarbeiten, um sicherzustellen, dass die URIS -Arbeit nach der Veröffentlichung funktioniert. Eine der umfangreichsten Rollen ist es, den Abschnitt der Anwendbarkeit mit Verweise auf die Richtlinien oder Erfolgskriterien zu bevölkern, auf die sich die Technik bezieht. Die Informationen hierfür stammen aus den Verständnisdokumenten. Die ordnungsgemäße Verwendung der Technikvorlage ist wichtig, um diese Funktionalität zu ermöglichen, und fehlgeformte Techniken können dazu führen, dass der Generator fehlschlägt.
Veraltete Techniken sollten nicht aus dem Repository entfernt werden. Stattdessen können sie mit Yaml Front-Materie markiert werden. Zum Beispiel:
---
obsoleteSince : 22
obsoleteMessage : |
This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2.
---obsoleteSince zeigt die früheste Version von WCAG 2 an, wenn die Technik veraltet wurde (dies kann auf 20 gesetzt werden, wenn sie für alle Versionen effektiv veraltet sein sollte, z. B. für Techniken mit veralteten HTML -Elementen).obsoleteMessage gibt eine Nachricht an In Fällen, in denen ganze Technologien veraltet sind (z. B. Flash und Silberlight), können diese Eigenschaften auch auf der technik -Unterverzeichnisebene, z. B. über techniques/flash/flash.11tydata.json , angegeben werden. Beachten Sie, dass dieser Fall speziell ein JSON -Format erfordert, da dies sowohl von elf und zusätzlichen Code im Build -Prozess verwendet wird, um Technikendaten zusammenzustellen.
Informative Dokumente werden aus denselben Quelldateien sowohl für WCAG 2.2 als auch für 2.1 generiert, da der größte Teil ihres Inhalts zwischen ihnen konsistent ist. (Die Richtlinien selbst werden weiterhin in getrennten Zweigen aufrechterhalten, z WCAG-2.1
Beim Erstellen informativer Dokumente für ältere Versionen wird das Build -System Erfolgkriterien, die spezifisch für neuere Versionen sind, und wiederum alle Techniken, die ausschließlich mit diesen Kriterien zusammenhängen.
Es gibt einige Fälle, in denen Inhalte möglicherweise auf eine bestimmte Version gerichtet werden müssen, die in diesem Abschnitt erläutert wird.
Hinweis: Dies gilt nur innerhalb von techniques und understanding ( nicht guidelines ).
In Fällen, in denen die genaue Versionsnummer in informativen Dokumenten angezeigt werden sollte, fügen Sie {{ versionDecimal }} ein. Dies wird durch die delimitierte Versionsnummer, z. B. 2.1 oder 2.2, ersetzt.
In Fällen, in denen ein Dokument, das sich auf mehrere Versionen bezieht, einen spezifischen Aufruf über ein Update in einer neueren Version garantiert, kann class="wcagXY" auf ein Element, das die betreffende Prosa umgibt, angewendet werden (z. B. class="wcag22" für WCAG 2.2) . Dies führt dazu, dass die Prosa aus früheren Versionen weggelassen und mit dem Präfix "neu in WCAG XY:" In den zutreffenden Versionen angezeigt wird.
Diese Klasse kann auch neben der note angewendet werden, in diesem Fall "(neu in WCAG XY)" wird in den geltenden Versionen an den Titel "Notiz" angehängt, und der Hinweis wird in früheren Versionen versteckt.
Zum Zeitpunkt des Schreibens (November 2024) ist das Änderungsprotokoll im Technikenindex zwischen WCAG 2.1 und 2.2 identisch. Diese wurden in separate Versionsspezifische unter _includes/techniques/changelog/*.html
Beispiele in Techniken sollten kurz zu konsumierende Code-Beispiele dafür sein, wie die Technik im Inhalt verwendet wird. Beispiele sollten sich auf die spezifischen Merkmale konzentrieren, die die Technik beschreibt, und nicht verwandte Inhalte wie Stil, Skript, umgebende Webinhalte usw. enthalten.
Oft ist es wünschenswert, umfassendere Beispiele zu liefern, die die Technik in Aktion zeigen, ohne das Dokument der Haupttechnik zu stören. Diese Beispiele zeigen auch den vollständigen Code, der erforderlich ist, um die Technik funktionieren zu Technik.
Arbeitsbeispiele werden im Verzeichnis working-examples des Repositorys gespeichert. Jedes Beispiel befindet sich in seinem eigenen Unterverzeichnis, um die mehrere Dateien zu enthalten, die möglicherweise erforderlich sind, um das Beispiel zum Laufen zu bringen. In einigen Fällen teilen mehrere Arbeitsbeispiele gemeinsame Ressourcen. working-examples/img werden im geeigneten Unterabschnitt des Arbeitsuntersuchungsverzeichnisses working-examples/script z working-examples/css Verweisen Sie auf diese gemeinsamen Ressourcen, sofern verfügbar; Legen Sie ansonsten Ressourcen in das Arbeitsbeispielverzeichnis ein und verwenden Sie unter Verwendung von Unterverzeichnissen, um gegebenenfalls zu organisieren.
So erstellen Sie ein funktionierendes Beispiel:
example- beginnt-und die ansonsten das Beispiel identifiziert, z. B. example-alt-attribute .working-examples/alt-attribute/ verwendet wird, verwendet wird.index.html . Ansonsten erstellen Sie einen geeigneten Dateinamen.../css/example.css , geteilt werden. Stellen Sie andere Ressourcen in das gleiche Verzeichnis wie das Hauptbeispiel, z. B. working-examples/alt-attribute/css/alt.css .https://rawgit.com/w3c/wcag/main/working-examples/alt-attribute/ die das RAWGIT-URI auf das Beispiel in seiner Entwicklungszweig, z. Die Redakteure aktualisieren Links, wenn Beispiele genehmigt werden.WCAG 2.2 ist zur Übersetzung bereit. Um WCAG 2.2 zu übersetzen, befolgen Sie Anweisungen zur Übersetzung von WCAG 2.
