wcag
1.0.0
Utilice esta sucursal como el objetivo para las solicitudes de extracción hasta el 10 de julio de 2016.
Este repositorio se utiliza para desarrollar contenido para WCAG 2, así como documentos de comprensión asociados.
@@ para completar
Ver también: Guía de estilo WCAG 2
WCAG 2.0 se mantuvo en una estructura de archivo diferente a las versiones posteriores de WCAG. Los archivos de origen para WCAG 2.0 están en la carpeta WCAG20 y existe principalmente para fines de archivo. No edite contenido en esa carpeta.
El contenido para WCAG 2.1 y más tarde se organiza de acuerdo con la estructura del archivo a continuación. El repositorio de WCAG contiene archivos de origen y auxiliar para WCAG 2, comprensión de WCAG 2 y, finalmente, técnicas. También contiene archivos auxiliares que admiten el formato automatizado del documento. Para facilitar la edición multipartidista, cada criterio de éxito está en un archivo separado, que consiste en un fragmento HTML que puede incluirse en las pautas principales. Los archivos clave incluyen:
guidelines/index.html : el archivo de directrices principalesguidelines/sc/{version}/*.html - Archivos para cada criterio de éxitoguidelines/terms/{version}/*.html - archivos para cada definiciónunderstanding/{version}/*.html - Entendiendo archivos para cada criterio de éxito Donde {version} es "20", el contenido vino de WCAG 2.0. "21" se usa para el contenido introducido en WCAG 2.1, "22" para WCAG 2.2, etc.
Los gerentes de criterios de éxito prepararán los criterios de éxito de los candidatos, listos para su inclusión en el documento de pautas. Para preparar los criterios de éxito, siga estos pasos:
#1 .Criterios de éxito Utilice una estructura simple de elementos HTML, con algunos valores de atributos de clase, para garantizar la consistencia. Scripts de mejora y llave de estilo de esta estructura. El contenido que proporciona está indicado en aparatos ortopédicos. Elementos después de los comentarios son opcionales.
< 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 >Tenga en cuenta que no proporciona el número SC. Los números se asignarán, y probablemente se generarán automáticamente, más adelante.
Los valores que proporcione se describen a continuación. Consulte el Criterio de éxito 2.2.1 para obtener un ejemplo de cada una de estas piezas de contenido.
Se pueden proporcionar elementos.
Si proporciona definiciones de términos junto con su SC, incluya el directorio de las guidelines/terms/{version} , un por archivo, utilizando el siguiente formato:
< dt > < dfn id =" dfn-{shortname} " > {Term} </ dfn > </ dt >
< dd > {Definition} </ dd > El elemento dfn le dice al script que este es un término y causa características especiales de estilo y vinculación. Para vincular a un término, use un elemento <a> sin un atributo href ; Si el texto del enlace es el mismo que el término, el enlace se generará correctamente. Por ejemplo, si hay un término <dfn>web page</dfn> en la página, un enlace en forma de <a>web page</a> dará como resultado un enlace adecuado.
Si el texto del enlace tiene una forma diferente del término canónico, por ejemplo, "páginas web" (tenga en cuenta el plural), puede proporcionar una pista sobre la definición del término con el atributo data-lt . En este ejemplo, modifique el término para ser <dfn data-lt="web pages">web page</dfn> . Múltiples nombres alternativos para el término se pueden separar con caracteres de tubería, sin espacio inicial o de salida, por ejemplo, <dfn data-lt="web pages|page|pages">web page</dfn> .
Hay un archivo comprensivo por criterio de éxito, más un índice:
understanding/index.html - página de índice, necesitar descomodar o agregar una referencia a las páginas de comprensión individuales a medida que están disponiblesunderstanding/{version}/*.html - Archivos para cada página de comprensión, nombrada igual que el archivo de criterio de éxito en las pautasLos archivos están poblados con una plantilla que proporciona la estructura esperada. Deje la estructura de la plantilla en su lugar y agregue contenido según corresponda dentro de las secciones. Elementos con class = "instrucciones" Proporcione orientación sobre qué contenido incluir en esa sección; Puede eliminar esos elementos si lo desea pero no tiene que hacerlo. La plantilla para ejemplos propone una lista de balas o una serie de subsecciones, elija uno de esos enfoques y elimine el otro de la plantilla. La plantilla para técnicas incluye subsecciones para "situaciones", elimine esa sección de envoltura si no es necesario.
La comprensión de los archivos se hace referencia al criterio de éxito relevante en la especificación WCAG; El script pone estos enlaces.
La ubicación de publicación formal para las páginas de comprensión es actualmente https://www.w3.org/wai/wcag21/understanding/. Este contenido se actualiza según sea necesario; y puede ser automatizado.
Las técnicas están en la carpeta de técnicas y se agrupan por la tecnología en subcarpetas. Cada técnica es un archivo independiente, que está en formato HTML con una estructura regular de elementos, clases e ID.
La plantilla de técnica muestra la estructura de las técnicas. Las secciones principales se encuentran en elementos de nivel superior <sección> con identificaciones específicas: meta, aplicabilidad, descripción, ejemplos, pruebas, recursos relacionados. Se requieren las secciones de descripción y pruebas; Se recomiendan las secciones de aplicabilidad y ejemplos; Las secciones relacionadas y de recursos son opcionales. La meta sección proporciona contexto para la técnica durante la autorización, pero se elimina para su publicación. El título de la técnica está en el elemento <h1> . Elementos con class="instructions" Proporcione información sobre la población de la plantilla. Deben eliminarse a medida que se desarrolle la técnica, pero si no se elimina, será ignorado por el generador. No copie class="instructions" en contenido real.
Las técnicas pueden usar una hoja de estilo temporal para facilitar la revisión de los borradores. Esta hoja de estilo se reemplaza por otras hojas de estilo y estructura para la publicación formal. Para usar esta hoja de estilo, agregue <link rel="stylesheet" type="text/css" href="../../css/editors.css"/> al cabezal de la técnica.
Las técnicas pueden incluir imágenes. Coloque el archivo de imagen en la carpeta img de la tecnología relevante, lo que significa que todas las técnicas para una tecnología comparten un conjunto común de imágenes. Use un enlace relativo para cargar la imagen. La mayoría de las imágenes deben cargarse con un elemento <figure> y etiquetarse con un <figcaption> posicionado en la parte inferior de la figura. <figure> Los elementos deben tener un atributo id . Se pueden cargar pequeñas imágenes en línea con un elemento <img> con texto alt adecuado.
Las técnicas deben incluir breves ejemplos de código para demostrar cómo el contenido del autor que siga la técnica. Los ejemplos de código deben ser fáciles de leer y, por lo general, no completar contenido en sí mismos. Se pueden proporcionar ejemplos más completos como ejemplos de trabajo (ver más abajo). Enlace a ejemplos de trabajo en la parte inferior de cada ejemplo, en un elemento <p class="working-example"> , que contiene un enlace relativo a ../../working-examples/{example-name}/ .
Se pueden proporcionar referencias cruzadas a otras técnicas cuando sea útil. En general, deben proporcionarse en la sección "Técnicas relacionadas", pero se pueden proporcionar en otro lugar. Use un enlace relativo para hacer referencia a la técnica, {Technique ID} si la misma tecnología, o ../{Technology}/{Technique ID} de lo contrario. Si la técnica aún está en desarrollo y no tiene una identificación formal, haga referencia a la ruta al archivo de desarrollo. Si la técnica está en desarrollo en una rama diferente, use un URI absoluto para la versión RAWGIT de la técnica.
Las referencias cruzadas a las pautas y los criterios de éxito deben usar un URI relativo para la página de comprensión de ese elemento. Las referencias cruzadas a otras partes de las pautas deben usar un URI absoluto para las pautas publicadas en la página W3C TR, un URI que comienza con https://www.w3.org/TR/WCAG21/# . Tenga en cuenta que las referencias a las directrices o criterios de éxito a los que se relacionan las técnicas se relacionan con el generador tras la publicación basada en información en los documentos de comprensión, por lo que los enlaces redundantes a ellas normalmente no se necesitan ni se recomienda.
Las prioridades generales y el proceso para trabajar en técnicas se mantienen en el wiki.
Las nuevas técnicas deben usar un nombre de archivo derivado de una versión abreviada del título de la técnica. Los editores asignarán a la técnica una identificación y cambiarán el nombre del archivo cuando sea aceptado por el grupo de trabajo. Por ejemplo, una técnica "que usa el atributo ALT en el elemento IMG para proporcionar alternativas de texto cortas" podría usar "IMG-Alt-Short-Text-alternativo.html" como el nombre de archivo. Los editores le asignarán una identificación formal y cambiarán el nombre del archivo, cuando sea aceptado por el grupo de trabajo.
Cada nueva técnica debe crearse en una nueva rama. La configuración de la sucursal y el archivo se automatiza a través del script Create-Techniques.sh, que se puede ejecutar con BASH. La línea de comando es:
bash create-techniques.sh < technology > < filename > < type > " <title> "<technology> es el directorio de tecnología para la técnica<filename> es el nombre de archivo temporal (sin extensión) para la técnica<type> es "técnica" o "falla"<title> es el título de la técnica, encerrado en citas y escapando de caracteres especiales con Esto automatiza los siguientes pasos:
Una vez que se configura una rama y un archivo de la técnica, complete el contenido y la revisión de la solicitud:
Las técnicas en el repositorio son archivos HTML simples con un formato mínimo. Para su publicación en el borrador del editor y la ubicación de W3C, las técnicas se formatean por un proceso de compilación basado en Eleventa para plantillas y Cheerio para las transformaciones. Se pueden encontrar más detalles, incluidas instrucciones para obtener una vista previa localmente, en el ReadMe del proceso de compilación.
El generador compila las técnicas juntas como una suite con formato y navegación. Hace cumplir ciertas estructuras, como ordenar secciones de nivel superior descritas anteriormente y estandarizar encabezados. Intenta procesar enlaces de referencia cruzados para asegurarse de que los URI funcionen después de la publicación. Uno de los roles más sustanciales es poblar la sección de aplicabilidad con referencias a las directrices o criterios de éxito con los que se relaciona la técnica. La información para esto proviene de los documentos de comprensión. El uso adecuado de la plantilla de técnica es importante para habilitar esta funcionalidad, y las técnicas formadas por mal pueden hacer que el generador falle.
Las técnicas obsoletas no deben eliminarse del repositorio. En cambio, se pueden marcar con la materia frontal Yaml. Por ejemplo:
---
obsoleteSince : 22
obsoleteMessage : |
This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2.
---obsoleteSince indica la versión más temprana de WCAG 2 cuando la técnica se volvió obsoleta (esto se puede establecer en 20 si efectivamente se obsoleta para todas las versiones, por ejemplo, para técnicas que involucran elementos HTML en desuso)obsoleteMessage indica un mensaje que se mostrará dentro de la sección de técnica sobre esta técnica En los casos en que las tecnologías completas son obsoletas (por ejemplo, Flash y Silverlight), estas propiedades también pueden especificarse a nivel de subdirectorio técnico, por ejemplo, a través de techniques/flash/flash.11tydata.json . Tenga en cuenta que este caso requiere específicamente el formato JSON, ya que esto se consume tanto por el elevado y el código adicional en el proceso de compilación utilizado para ensamblar datos de técnicas.
Los documentos informativos se generan a partir de los mismos archivos de origen tanto para WCAG 2.2 como 2.1, ya que la mayor parte de su contenido es consistente entre ellos. (Las pautas en sí se continúan manteniéndose en ramas separadas, por ejemplo, WCAG-2.1 , a los efectos de mantener los borradores de editores separados).
Al construir documentos informativos para versiones anteriores, el sistema de compilación poda los criterios de éxito que son específicos de las versiones más nuevas y, a su vez, cualquier técnica que esté exclusivamente relacionada con esos criterios.
Hay algunos casos en los que el contenido puede necesitar atender una versión específica, explicada en esta sección.
Nota: Esto solo es aplicable dentro de techniques y las carpetas understanding ( no guidelines ).
En los casos en que el número de versión preciso debe mostrarse dentro de documentos informativos, inserte {{ versionDecimal }} . Esto se reemplazará con el número de versión delimitada de punto decimal, por ejemplo, 2.1 o 2.2.
En los casos en que un documento relacionado con múltiples versiones garantiza una llamada específica sobre una actualización en una versión más nueva, class="wcagXY" puede aplicarse a un elemento que rodea la prosa en cuestión (por ejemplo, class="wcag22" para WCAG 2.2) . Esto dará como resultado que la prosa se omite a partir de versiones anteriores, y se muestre con el prefijo "Nuevo en WCAG XY:" en versiones aplicables.
Esta clase también se puede aplicar junto con la clase note , en cuyo caso "(nuevo en WCAG XY)" se agregará al título "Nota" en las versiones aplicables, y la nota se ocultará en versiones anteriores.
Al momento de escribir este artículo (noviembre de 2024), el inicio de sesión de cambio en el índice de técnicas es idéntico entre WCAG 2.1 y 2.2. Estos se han dividido en una versión separada, incluyen en _includes/techniques/changelog/*.html para la prueba futura en apoyo de la construcción de múltiples versiones de documentos informativos de la misma rama.
Los ejemplos en técnicas deben ser muestras de código breves de consumo de cómo se utiliza la técnica en el contenido. Por lo tanto, los ejemplos deben centrarse en las características específicas que describe la técnica y no incluir contenido relacionado como estilo, script, contenido web circundante, etc.
A menudo es deseable proporcionar ejemplos más completos, que muestran la técnica en acción sin interferir con el documento de técnica principal. Estos ejemplos también muestran el código completo requerido para hacer que la técnica funcione, incluidos los archivos completos de estilo y script, imágenes, código de página, etc. Por lo general, estos "ejemplos de trabajo" se hacen referencia en la parte inferior del ejemplo de elided que se incluye en el principal técnica.
Los ejemplos de trabajo se almacenan en el directorio working-examples del repositorio. Cada ejemplo está en su propio subdirectorio, para contener los múltiples archivos que pueden ser necesarios para que el ejemplo funcione. En algunos casos, múltiples ejemplos de trabajo compartirán recursos comunes; Estos se almacenan en el subdirectorio apropiado del directorio de exámenes de trabajo, por ejemplo, working-examples/css , working-examples/img , working-examples/script . Referencia a estos recursos comunes cuando estén disponibles; De lo contrario, coloque los recursos en el directorio de ejemplo de trabajo, utilizando subdirectorios para organizarse cuando sea apropiado.
Para crear un ejemplo de trabajo:
example- de prefijo, y que de otro modo identifica semánticamente el ejemplo, por ejemplo, example-alt-attribute .working-examples/alt-attribute/ .index.html . De lo contrario, cree un nombre de archivo adecuado.../css/example.css . Coloque otros recursos en el mismo directorio que el ejemplo principal, por ejemplo, working-examples/alt-attribute/css/alt.css .https://rawgit.com/w3c/wcag/main/working-examples/alt-attribute/ . Los editores actualizarán los enlaces cuando se aprueben los ejemplos.WCAG 2.2 está listo para la traducción. Para traducir WCAG 2.2, siga las instrucciones en cómo traducir WCAG 2.
