wcag
1.0.0
Por favor, use esta filial como alvo para solicitações de tração até 10 de julho de 2016.
Esse repositório é usado para desenvolver conteúdo para o WCAG 2, bem como os documentos e técnicas de compreensão associados.
@@ para concluir
Veja também: Guia de estilo WCAG 2
O WCAG 2.0 foi mantido em uma estrutura de arquivo diferente das versões subsequentes do WCAG. Os arquivos de origem para o WCAG 2.0 estão na pasta WCAG20 e existe principalmente para fins de arquivo. Não edite conteúdo nessa pasta.
O conteúdo do WCAG 2.1 e posterior é organizado de acordo com a estrutura do arquivo abaixo. O repositório WCAG contém arquivos de origem e auxiliar para o WCAG 2, entendendo o WCAG 2 e, eventualmente, técnicas. Ele também contém arquivos auxiliares que suportam a formatação automatizada do documento. Para facilitar a edição de várias partes, cada critério de sucesso está em um arquivo separado, consistindo em um fragmento HTML que pode ser incluído nas diretrizes principais. Os arquivos -chave incluem:
guidelines/index.html - O arquivo de diretrizes principaisguidelines/sc/{version}/*.html - Arquivos para cada critério de sucessoguidelines/terms/{version}/*.html - arquivos para cada definiçãounderstanding/{version}/*.html - Entendendo os arquivos para cada critério de sucesso Onde {version} é "20", o conteúdo veio do WCAG 2.0. "21" é usado para o conteúdo introduzido no WCAG 2.1, "22" para WCAG 2.2, etc.
Os gerentes de critérios de sucesso prepararão os critérios de sucesso do candidato, prontos para a inclusão no documento das diretrizes. Para preparar os critérios de sucesso, siga estas etapas:
#1 .Os critérios de sucesso usam uma estrutura simples dos elementos HTML, com alguns valores de atributo de classe, para garantir a consistência. Scripts de aprimoramento e estilo de estilo dessa estrutura. O conteúdo que você fornece é indicado em aparelhos. Os itens após os comentários são opcionais.
< 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 >Observe que você não fornece o número SC. Os números serão atribuídos e provavelmente gerados automaticamente, posteriormente.
Os valores que você fornece são descritos abaixo. Consulte o Critério de Sucesso 2.2.1 para um exemplo de cada uma dessas peças de conteúdo.
`elementos podem ser fornecidos.
Se você estiver fornecendo definições de termo junto com seu SC, inclua-as nas respectivas guidelines/terms/{version} , um por arquivo, usando o seguinte formato:
< dt > < dfn id =" dfn-{shortname} " > {Term} </ dfn > </ dt >
< dd > {Definition} </ dd > O elemento dfn informa ao script que este é um termo e causa recursos especiais de estilo e vinculação. Para vincular a um termo, use um elemento <a> sem um atributo href ; Se o texto do link for o mesmo que o termo, o link será gerado corretamente. Por exemplo, se houver um termo <dfn>web page</dfn> na página, um link na forma de <a>web page</a> resultará em um link adequado.
Se o texto do link tiver um formulário diferente do termo canônico, por exemplo, "Páginas da Web" (observe o plural), você poderá fornecer uma dica sobre o termo definição com o atributo data-lt . Neste exemplo, modifique o termo para ser <dfn data-lt="web pages">web page</dfn> . Vários nomes alternativos para o termo podem ser separados com caracteres de tubo, sem espaço de liderança ou à direita, por exemplo, <dfn data-lt="web pages|page|pages">web page</dfn> .
Há um arquivo de compreensão por critério de sucesso, além de um índice:
understanding/index.html - página de índice, precisa de descomentar ou adicionar uma referência às páginas de entendimento individuais à medida que são disponibilizadasunderstanding/{version}/*.html - arquivos para cada página de compreensão, denominada o mesmo que o arquivo de critério de sucesso nas diretrizesOs arquivos são preenchidos com um modelo que fornece a estrutura esperada. Deixe a estrutura do modelo no lugar e adicione conteúdo conforme apropriado nas seções. Elementos com class = "Instruções" fornecem orientações sobre qual conteúdo incluir nessa seção; Você pode remover esses elementos, se quiser, mas não precisar. O modelo para exemplos propõe uma lista de marcadores ou uma série de subseções, escolha uma dessas abordagens e remova a outra do modelo. O modelo para técnicas inclui subseções para "situações", remova a seção de invólucro, se não for necessário.
A compreensão dos arquivos são referenciados a partir do critério de sucesso relevante na especificação do WCAG; Esses links são colocados pelo script.
O local formal da publicação para entender as páginas é atualmente https://www.w3.org/wai/wcag21/understanding/. Este conteúdo é atualizado conforme necessário; e pode ser automatizado.
As técnicas estão na pasta Técnicas e agrupadas pela tecnologia em sub-dobras. Cada técnica é um arquivo independente, que está no formato HTML com uma estrutura regular de elementos, classes e IDs.
O modelo de técnica mostra a estrutura das técnicas. As seções principais estão em elementos <Section> de nível superior com IDs específicos: meta, aplicabilidade, descrição, exemplos, testes, relacionados, recursos. As seções de descrição e testes são necessárias; As seções de aplicabilidade e exemplos são recomendadas; As seções relacionadas e de recursos são opcionais. A meta seção fornece contexto para a técnica durante a criação, mas é removida para publicação. O título da técnica está no elemento <h1> . Elementos com class="instructions" Forneça informações sobre como preencher o modelo. Eles devem ser removidos à medida que a técnica é desenvolvida, mas se não for removida, será ignorada pelo gerador. Não copie class="instructions" no conteúdo real.
As técnicas podem usar uma folha de estilo temporário para facilitar a revisão dos rascunhos. Esta folha de estilo é substituída por outras folhas de estilo e estrutura para publicação formal. Para usar esta folha de estilo, adicione <link rel="stylesheet" type="text/css" href="../../css/editors.css"/> na cabeça da técnica.
Técnicas podem incluir imagens. Coloque o arquivo de imagem na pasta img da tecnologia relevante - o que significa que todas as técnicas para uma tecnologia compartilham um conjunto comum de imagens. Use um link relativo para carregar a imagem. A maioria das imagens deve ser carregada com um elemento <figure> e marcada com uma <figcaption> posicionada na parte inferior da figura. <figure> Os elementos devem ter um atributo id . Pequenas imagens embutidas podem ser carregadas com um elemento <img> com texto alt adequado.
As técnicas devem incluir breves exemplos de código para demonstrar como autorizar o conteúdo que segue a técnica. Exemplos de código devem ser fáceis de ler e geralmente não completam conteúdo em si mesmos. Exemplos mais completos podem ser fornecidos como exemplos de trabalho (veja abaixo). Link para exemplos de trabalho na parte inferior de cada exemplo, em um elemento <p class="working-example"> , contendo um link relativo para ../../working-examples/{example-name}/ }/.
Referências cruzadas a outras técnicas podem ser fornecidas quando útil. Geralmente, eles devem ser fornecidos na seção "Técnicas relacionadas", mas podem ser fornecidas em outros lugares. Use um link relativo para fazer referência à técnica, {Technique ID} se a mesma tecnologia ou ../{Technology}/{Technique ID} caso contrário. Se a técnica ainda estiver em desenvolvimento e não tiver um ID formal, faça referência ao caminho para o arquivo de desenvolvimento. Se a técnica estiver em desenvolvimento em um ramo diferente, use um URI absoluto para a versão RawGit da técnica.
Referências cruzadas a diretrizes e critérios de sucesso devem usar um URI relativo na página de compreensão desse item. As referências cruzadas a outras partes das diretrizes devem usar um URI absoluto para as diretrizes, conforme publicado na página W3C TR, um URI começando com https://www.w3.org/TR/WCAG21/# . Observe que as referências a diretrizes ou critérios de sucesso aos quais as técnicas se relacionam são adicionadas pelo gerador após a publicação com base nas informações nos documentos de compreensão; portanto, links redundantes para eles não são normalmente necessários ou recomendados.
As prioridades gerais e o processo para trabalhar em técnicas são mantidos no wiki.
Novas técnicas devem usar um nome de arquivo derivado de uma versão abreviada do título da técnica. Os editores atribuirão à técnica um ID e renomearão o arquivo quando for aceito pelo grupo de trabalho. Por exemplo, uma técnica "usando o atributo ALT no elemento IMG para fornecer alternativas de texto curto" pode usar "img-alt-short-text-alternatives.html" como o nome do arquivo. Os editores atribuirão um ID formal e renomearão o arquivo, quando for aceito pelo grupo de trabalho.
Cada nova técnica deve ser criada em uma nova filial. A configuração da ramificação e do arquivo é automatizada através do script create-techniques.sh, que pode ser executado com o Bash. A linha de comando é:
bash create-techniques.sh < technology > < filename > < type > " <title> "<technology> é o diretório de tecnologia para a técnica<filename> é o nome do arquivo temporário (sem extensão) para a técnica<type> é "técnica" ou "falha"<title> é o título da técnica, fechada em citações e escape de caracteres especiais com Isso automatiza as seguintes etapas:
Depois que uma ramificação e arquivo da técnica for configurada, preencha o conteúdo e solicite a revisão:
As técnicas no repositório são arquivos HTML simples com formatação mínima. Para publicação no rascunho dos editores e na localização do W3C, as técnicas são formatadas por um processo de construção baseado no elevente para modelar e Cheerio para transformações. Mais detalhes, incluindo instruções para visualizar localmente, podem ser encontrados no processo de compilação ReadMe.
O gerador compila as técnicas como uma suíte com formatação e navegação. Ele aplica certas estruturas, como solicitar seções de nível superior descritas acima e padronizar os títulos. Ele tenta processar links de referência cruzada para garantir que o URIS trabalhe após a publicação. Uma das funções mais substanciais é preencher a seção de aplicabilidade com referências às diretrizes ou critérios de sucesso aos quais a técnica se relaciona. As informações para isso vêm dos documentos de compreensão. O uso adequado do modelo de técnica é importante para permitir essa funcionalidade, e as técnicas de mal formadas podem fazer com que o gerador falhe.
Técnicas obsoletas não devem ser removidas do repositório. Em vez disso, eles podem ser marcados usando a frente da YAML. Por exemplo:
---
obsoleteSince : 22
obsoleteMessage : |
This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2.
---obsoleteSince como indica a versão mais antiga do WCAG 2 quando a técnica se tornou obsoleta (isso pode ser definido como 20 se deve ser efetivamente obsoleto para todas as versões, por exemplo, para técnicas envolvendo elementos html depreciados)obsoleteMessage indica uma mensagem a ser exibida na seção sobre esta técnica Nos casos em que tecnologias inteiras são obsoletas (por exemplo, flash e Silverlight), essas propriedades também podem ser especificadas no nível do subdiretório da técnica, por exemplo, através de techniques/flash/flash.11tydata.json . Observe que este caso requer especificamente o formato JSON, pois isso é consumido pelo código elevador e adicional no processo de construção usado para montar os dados das técnicas.
Os documentos informativos são gerados a partir dos mesmos arquivos de origem para o WCAG 2.2 e 2.1, pois a maior parte de seu conteúdo é consistente entre eles. (As próprias diretrizes continuam sendo mantidas em filiais separadas, por exemplo, WCAG-2.1 , para fins de manutenção de rascunhos dos editores separados.)
Ao criar documentos informativos para versões mais antigas, o sistema de construção remove os critérios de sucesso específicos para versões mais recentes e, por sua vez, quaisquer técnicas relacionadas exclusivamente a esses critérios.
Existem alguns casos em que o conteúdo pode precisar atender a uma versão específica, explicada nesta seção.
Nota: Isso é aplicável apenas nas techniques e nas pastas understanding ( não guidelines ).
Nos casos em que o número preciso da versão deve ser exibido em documentos informativos, insira {{ versionDecimal }} . Isso será substituído pelo número da versão delimitado por ponto decimal, por exemplo, 2.1 ou 2.2.
Nos casos em que um documento referente a várias versões garante uma chamada específica sobre uma atualização em uma versão mais recente, class="wcagXY" pode ser aplicado a um elemento em torno da prosa em questão (por exemplo, class="wcag22" para WCAG 2.2) . Isso resultará na prosa que está sendo omitida de versões anteriores e exibida com o prefixo "Novo no WCAG XY:" nas versões aplicáveis.
Esta classe também pode ser aplicada ao lado da classe note , nesse caso "(novo no WCAG XY)" será anexado ao título "Nota" nas versões aplicáveis, e a nota será oculta nas versões anteriores.
No momento da redação deste artigo (novembro de 2024), o log de alterações no índice de técnicas é idêntico entre o WCAG 2.1 e 2.2. Estes foram divididos em uma versão separada específica inclui em _includes/techniques/changelog/*.html para a prova de futuras no apoio à criação de várias versões de documentos informativos da mesma filial.
Exemplos em técnicas devem ser breves amostras de código fácil de consumir de como a técnica é usada no conteúdo. Portanto, os exemplos devem se concentrar nos recursos específicos que a técnica descreve e não incluir conteúdo relacionado, como estilo, script, conteúdo da web circundante etc.
Muitas vezes, é desejável fornecer exemplos mais abrangentes, que mostram a técnica de ação, sem interferir no documento principal da técnica. Esses exemplos também mostram o código completo necessário para fazer a técnica operar, incluindo arquivos de estilo e script completo, imagens, código de página etc. Geralmente, esses "exemplos de trabalho" são referenciados na parte inferior do exemplo elidado, incluído no principal técnica.
Exemplos de trabalho são armazenados no diretório working-examples do repositório. Cada exemplo está em seu próprio subdiretório, para conter os vários arquivos que podem ser necessários para fazer o exemplo funcionar. Em alguns casos, vários exemplos de trabalho compartilharão recursos comuns; Estes são armazenados no subdiretório apropriado do diretório de amostras de trabalho, por exemplo, working-examples/css , working-examples/img , working-examples/script . Referenciar esses recursos comuns, quando disponíveis; Caso contrário, coloque os recursos no diretório de exemplo de trabalho, usando subdiretos para organizar quando apropriado.
Para criar um exemplo de funcionamento:
example- prefixo-e que, de outra forma, identifica semanticamente o exemplo, por exemplo, example-alt-attribute .working-examples/alt-attribute/ .index.html . Caso contrário, crie um nome de arquivo adequado.../css/example.css . Coloque outros recursos no mesmo diretório que o exemplo principal, por exemplo, working-examples/alt-attribute/css/alt.css .https://rawgit.com/w3c/wcag/main/working-examples/alt-attribute/ . Os editores atualizarão os links quando os exemplos forem aprovados.O WCAG 2.2 está pronto para a tradução. Para traduzir o WCAG 2.2, siga as instruções sobre como traduzir o WCAG 2.
