wcag
1.0.0
Harap gunakan cabang ini sebagai target untuk permintaan tarik hingga 10 Juli 2016.
Repositori ini digunakan untuk mengembangkan konten untuk WCAG 2, serta dokumen dan teknik pemahaman terkait.
@@ untuk menyelesaikan
Lihat juga: Panduan Gaya WCAG 2
WCAG 2.0 dipertahankan dalam struktur file yang berbeda dari versi WCAG berikutnya. File sumber untuk WCAG 2.0 ada di folder WCAG20 dan ada terutama untuk tujuan arsip. Jangan mengedit konten di folder itu.
Konten untuk WCAG 2.1 dan yang lebih baru diatur sesuai dengan struktur file di bawah ini. Repositori WCAG berisi file sumber dan tambahan untuk WCAG 2, Memahami WCAG 2, dan akhirnya teknik. Ini juga berisi file tambahan yang mendukung pemformatan otomatis dokumen. Untuk memfasilitasi pengeditan multi-partai, setiap kriteria keberhasilan ada dalam file terpisah, yang terdiri dari fragmen HTML yang dapat dimasukkan ke dalam pedoman utama. File kunci meliputi:
guidelines/index.html - File Pedoman Utamaguidelines/sc/{version}/*.html - File untuk setiap kriteria keberhasilanguidelines/terms/{version}/*.html - File untuk setiap definisiunderstanding/{version}/*.html - Memahami file untuk setiap kriteria keberhasilan Di mana {version} adalah "20", konten berasal dari WCAG 2.0. "21" digunakan untuk konten yang diperkenalkan di WCAG 2.1, "22" untuk WCAG 2.2, dll.
Manajer kriteria keberhasilan akan menyiapkan kriteria keberhasilan kandidat, siap untuk dimasukkan dalam dokumen pedoman. Untuk menyiapkan kriteria keberhasilan, ikuti langkah -langkah ini:
#1 .Kriteria Keberhasilan Gunakan struktur sederhana elemen HTML, dengan beberapa nilai atribut kelas, untuk memastikan konsistensi. Skrip Peningkatan dan Kunci Gaya dari struktur ini. Konten yang Anda berikan ditunjukkan dalam kawat gigi. Item setelah komentar adalah opsional.
< 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 >Catatan Anda tidak memberikan nomor SC. Angka akan ditetapkan, dan kemungkinan besar dihasilkan secara otomatis, nanti.
Nilai yang Anda berikan dijelaskan di bawah ini. Lihat Kriteria Sukses 2.2.1 Untuk contoh masing -masing konten ini.
`Elemen dapat disediakan.
Jika Anda memberikan definisi istilah bersama dengan SC Anda, sertakannya dalam guidelines/terms/{version} masing-masing, satu per-file, menggunakan format berikut:
< dt > < dfn id =" dfn-{shortname} " > {Term} </ dfn > </ dt >
< dd > {Definition} </ dd > Elemen dfn memberi tahu skrip bahwa ini adalah istilah dan menyebabkan fitur gaya dan penghubung khusus. Untuk menautkan ke istilah, gunakan elemen <a> tanpa atribut href ; Jika teks tautannya sama dengan istilah, tautan akan dihasilkan dengan benar. Misalnya, jika ada istilah <dfn>web page</dfn> di halaman, tautan dalam bentuk <a>web page</a> akan menghasilkan tautan yang tepat.
Jika teks tautan memiliki bentuk yang berbeda dari istilah kanonik, misalnya, "halaman web" (perhatikan jamak), Anda dapat memberikan petunjuk tentang definisi istilah dengan atribut data-lt . Dalam contoh ini, modifikasi istilah menjadi <dfn data-lt="web pages">web page</dfn> . Beberapa nama alternatif untuk istilah ini dapat dipisahkan dengan karakter pipa, tanpa ruang terkemuka atau trailing, misalnya, <dfn data-lt="web pages|page|pages">web page</dfn> .
Ada satu file pemahaman per kriteria keberhasilan, ditambah indeks:
understanding/index.html - halaman indeks, perlu tidak mengkomentasikan atau menambahkan referensi ke halaman pemahaman individual saat tersedia tersediaunderstanding/{version}/*.html - File untuk setiap halaman pemahaman, dinamai sama dengan file kriteria keberhasilan dalam pedomanFile dihuni dengan templat yang menyediakan struktur yang diharapkan. Biarkan struktur template di tempat, dan tambahkan konten yang sesuai dalam bagian. Elemen dengan class = "instruksi" memberikan panduan tentang konten apa yang akan dimasukkan di bagian itu; Anda dapat menghapus elemen -elemen itu jika Anda mau tetapi tidak harus. Template untuk contoh mengusulkan baik daftar peluru atau serangkaian sub-bagian, pilih salah satu dari pendekatan tersebut dan menghapus yang lain dari templat. Templat untuk teknik mencakup sub-bagian untuk "situasi", hapus bagian pembungkus itu jika tidak diperlukan.
Memahami file dirujuk dari kriteria keberhasilan yang relevan pada spesifikasi WCAG; Tautan ini dimasukkan oleh skrip.
Lokasi publikasi formal untuk pemahaman halaman saat ini https://www.w3.org/wai/wcag21/understanding/. Konten ini diperbarui sesuai kebutuhan; dan mungkin otomatis.
Teknik ada di folder teknik, dan dikelompokkan berdasarkan teknologi menjadi sub-folder. Setiap teknik adalah file mandiri, yang dalam format HTML dengan struktur elemen, kelas, dan IDS reguler.
Templat teknik menunjukkan struktur teknik. Bagian utama berada di elemen tingkat atas <section> dengan ID spesifik: meta, penerapan, deskripsi, contoh, tes, terkait, sumber daya. Bagian deskripsi dan pengujian diperlukan; Bagian penerapan dan contoh direkomendasikan; Bagian terkait dan sumber daya adalah opsional. Bagian meta memberikan konteks untuk teknik selama penulisan tetapi dihapus untuk publikasi. Judul teknik ini ada di elemen <h1> . Elemen dengan class="instructions" memberikan informasi tentang mengisi templat. Mereka harus dihapus saat teknik ini dikembangkan tetapi jika tidak dihapus, akan diabaikan oleh generator. Jangan menyalin class="instructions" pada konten nyata.
Teknik dapat menggunakan lembar gaya sementara untuk memfasilitasi peninjauan draft. Lembar gaya ini digantikan oleh lembaran gaya dan struktur lain untuk publikasi formal. Untuk menggunakan lembar gaya ini, tambahkan <link rel="stylesheet" type="text/css" href="../../css/editors.css"/> ke kepala teknik.
Teknik dapat mencakup gambar. Tempatkan file gambar di folder img dari teknologi yang relevan - yang berarti semua teknik untuk suatu teknologi berbagi serangkaian gambar yang umum. Gunakan tautan relatif untuk memuat gambar. Sebagian besar gambar harus dimuat dengan elemen <figure> dan diberi label dengan <figcaption> yang diposisikan di bagian bawah gambar. <figure> Elemen harus memiliki atribut id . Gambar inline kecil dapat dimuat dengan elemen <img> dengan teks alt yang sesuai.
Teknik harus mencakup contoh kode singkat untuk menunjukkan cara penulis konten yang mengikuti teknik ini. Contoh kode harus mudah dibaca, dan biasanya tidak menyelesaikan konten dalam diri mereka sendiri. Contoh yang lebih lengkap dapat diberikan sebagai contoh yang berfungsi (lihat di bawah). Tautan ke contoh yang berfungsi di bagian bawah setiap contoh, di elemen <p class="working-example"> , berisi tautan relatif ke ../../working-examples/{example-name}/ .
Referensi silang untuk teknik lain dapat disediakan jika berguna. Secara umum mereka harus disediakan di bagian "Teknik Terkait" tetapi dapat disediakan di tempat lain. Gunakan tautan relatif untuk referensi teknik, {Technique ID} Jika teknologi yang sama, atau ../{Technology}/{Technique ID} sebaliknya. Jika teknik ini masih dalam pengembangan dan tidak memiliki ID formal, referensi jalur ke file pengembangan. Jika teknik ini sedang dikembangkan di cabang yang berbeda, gunakan URI absolut untuk versi Rawgit dari teknik ini.
Referensi silang untuk pedoman dan kriteria keberhasilan harus menggunakan URI relatif ke halaman pemahaman untuk item itu. Referensi silang ke bagian lain dari pedoman harus menggunakan URI absolut untuk pedoman seperti yang diterbitkan pada halaman W3C TR, URI yang dimulai dengan https://www.w3.org/TR/WCAG21/# . Perhatikan bahwa referensi ke pedoman atau kriteria keberhasilan yang terkait dengan teknik ditambahkan oleh generator setelah publikasi berdasarkan informasi dalam dokumen pemahaman, sehingga tautan yang berlebihan dengan yang biasanya tidak diperlukan atau disarankan.
Prioritas umum dan proses untuk mengerjakan teknik dipertahankan di wiki.
Teknik baru harus menggunakan nama file yang berasal dari versi singkat dari judul teknik. Editor akan menetapkan teknik ID dan mengubah nama file saat diterima oleh kelompok kerja. Misalnya, teknik "menggunakan atribut alt pada elemen IMG untuk memberikan alternatif teks pendek" mungkin menggunakan "img-alt-short-text-alternatives.html" sebagai nama file. Editor akan menetapkan ID formal, dan mengganti nama file, ketika diterima oleh kelompok kerja.
Setiap teknik baru harus dibuat di cabang baru. Pengaturan cabang dan file diotomatisasi melalui skrip create-techniques.sh, yang dapat dijalankan dengan bash. Baris perintahnya adalah:
bash create-techniques.sh < technology > < filename > < type > " <title> "<technology> adalah direktori teknologi untuk teknik ini<filename> adalah nama file sementara (tanpa ekstensi) untuk teknik ini<type> adalah "teknik" atau "kegagalan"<title> adalah judul teknik ini, terlampir dalam kutipan dan melarikan diri dari karakter khusus dengan Ini mengotomatiskan langkah -langkah berikut:
Setelah cabang dan file teknik diatur, mengisi konten dan meminta ulasan:
Teknik dalam repositori adalah file HTML biasa dengan pemformatan minimal. Untuk publikasi ke lokasi editor draft dan W3C, teknik diformat oleh proses pembangunan berdasarkan Eleventy untuk templating dan cheerio untuk transformasi. Rincian lebih lanjut, termasuk instruksi untuk melihat pratinjau secara lokal, dapat ditemukan dalam proses pembuatan readme.
Generator mengkompilasi teknik bersama sebagai suite dengan pemformatan dan navigasi. Ini menegakkan struktur tertentu, seperti memesan bagian tingkat atas yang dijelaskan di atas dan standarisasi judul. Ia mencoba memproses tautan referensi silang untuk memastikan URIS bekerja saat publikasi. Salah satu peran yang paling substansial adalah mengisi bagian penerapan dengan referensi ke pedoman atau kriteria keberhasilan yang berhubungan dengan teknik tersebut. Informasi untuk ini berasal dari dokumen pemahaman. Penggunaan template teknik yang tepat penting untuk memungkinkan fungsionalitas ini, dan teknik yang dibentuk mal dapat menyebabkan generator gagal.
Teknik usang tidak boleh dihapus dari repositori. Sebaliknya, mereka dapat ditandai menggunakan materi depan YAML. Misalnya:
---
obsoleteSince : 22
obsoleteMessage : |
This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2.
---obsoleteSince menunjukkan versi paling awal dari WCAG 2 ketika teknik ini menjadi usang (ini dapat ditetapkan ke 20 jika harus secara efektif usang untuk semua versi, misalnya untuk teknik yang melibatkan elemen HTML yang sudah usang)obsoleteMessage menunjukkan pesan yang akan ditampilkan di bagian Teknik Tentang ini Dalam kasus di mana seluruh teknologi sudah usang (mis. Flash dan Silverlight), sifat -sifat ini juga dapat ditentukan pada tingkat subdirektori teknik, misalnya melalui techniques/flash/flash.11tydata.json . Perhatikan bahwa kasus ini secara khusus memerlukan format JSON, karena ini dikonsumsi oleh baik sebelas puluh dan kode tambahan dalam proses pembuatan yang digunakan untuk merakit data teknik.
Dokumen informatif dihasilkan dari file sumber yang sama untuk WCAG 2.2 dan 2.1, karena sebagian besar kontennya konsisten di antara mereka. (Pedoman itu sendiri terus dipertahankan pada cabang yang terpisah misalnya WCAG-2.1 , untuk keperluan mempertahankan konsep editor terpisah.)
Saat membangun dokumen informatif untuk versi yang lebih lama, sistem build memangkas kriteria keberhasilan yang khusus untuk versi yang lebih baru, dan pada gilirannya teknik apa pun yang secara eksklusif terkait dengan kriteria tersebut.
Ada beberapa kasus di mana konten mungkin perlu memenuhi versi tertentu, dijelaskan di bagian ini.
Catatan: Ini hanya berlaku dalam techniques dan understanding folder ( bukan guidelines ).
Dalam kasus di mana nomor versi yang tepat harus ditampilkan dalam dokumen informatif, masukkan {{ versionDecimal }} . Ini akan diganti dengan nomor versi yang dibatasi titik desimal, misalnya 2.1 atau 2.2.
Dalam kasus di mana dokumen yang berkaitan dengan beberapa versi menjamin panggilan out spesifik tentang pembaruan dalam versi yang lebih baru, class="wcagXY" dapat diterapkan pada elemen yang mengelilingi prosa yang dimaksud (misalnya class="wcag22" untuk WCAG 2.2) . Ini akan mengakibatkan prosa dihilangkan dari versi sebelumnya, dan ditampilkan dengan awalan "baru di WCAG XY:" Dalam versi yang berlaku.
Kelas ini juga dapat diterapkan bersama kelas note , dalam hal ini "(baru di WCAG XY)" akan ditambahkan ke judul "Catatan" dalam versi yang berlaku, dan catatan akan disembunyikan dalam versi sebelumnya.
Pada saat penulisan (November 2024), log perubahan dalam indeks teknik identik antara WCAG 2.1 dan 2.2. Ini telah dibagi menjadi versi khusus yang terpisah termasuk di bawah _includes/techniques/changelog/*.html untuk pembuktian masa depan dalam mendukung membangun beberapa versi dokumen informatif dari cabang yang sama.
Contoh dalam teknik harus singkat sampel kode yang mudah dikonsumsi tentang bagaimana teknik ini digunakan dalam konten. Oleh karena itu contoh harus fokus pada fitur spesifik yang dijelaskan teknik ini, dan tidak termasuk konten terkait seperti gaya, skrip, konten web di sekitarnya, dll.
Seringkali diinginkan untuk memberikan contoh yang lebih komprehensif, yang menunjukkan teknik ini beraksi sambil tidak mengganggu dokumen teknik utama. Contoh -contoh ini juga menunjukkan kode lengkap yang diperlukan untuk membuat teknik ini beroperasi, termasuk gaya penuh dan file skrip, gambar, kode halaman, dll. Biasanya, "contoh kerja" ini dirujuk di bagian bawah contoh yang dielakkan yang termasuk dalam utama teknik.
Contoh kerja disimpan dalam direktori working-examples repositori. Setiap contoh dalam subdirektori sendiri, untuk berisi beberapa file yang mungkin diperlukan untuk membuat contoh berfungsi. Dalam beberapa kasus, beberapa contoh kerja akan berbagi sumber daya umum; Ini disimpan dalam sub-direktori yang sesuai dari direktori kertas kerja, misalnya, working-examples/css , working-examples/img , working-examples/script . Referensi sumber daya umum ini bila tersedia; Kalau tidak, tempatkan sumber daya di direktori contoh kerja, menggunakan subdirektori untuk mengatur jika perlu.
Untuk membuat contoh yang berfungsi:
example- awalan- dan yang sebaliknya secara semantik mengidentifikasi contoh, misalnya, example-alt-attribute .working-examples/alt-attribute/ .index.html . Jika tidak, buat nama file yang sesuai.../css/example.css . Tempatkan sumber daya lain di direktori yang sama dengan contoh utama, misalnya, working-examples/alt-attribute/css/alt.css .https://rawgit.com/w3c/wcag/main/working-examples/alt-attribute/ . Editor akan memperbarui tautan saat contoh disetujui.WCAG 2.2 siap untuk diterjemahkan. Untuk menerjemahkan WCAG 2.2, ikuti instruksi tentang cara menerjemahkan WCAG 2.
