Acessibilidade: Seção 508 x WCAG

Visão geral:

Seção de Acessibilidade Web 508:

 
"Seção 508" refere-se especificamente a Seção 508 da Lei de Reabilitação de 1973, alterada pela Workforce Investment Act de 1998. A lei exige que as agências federais a comprar tecnologia eletrônica e de informação acessível aos empregados com deficiência, e na medida em que as agências que fornecem tecnologia da informação para o público, ela também será acessível a pessoas com deficiência.

Na verdade, a Seção 508 foi incluído em uma emenda à Lei de Reabilitação em 1986, com a exigência de que o Governo Federal fornecer tecnologia acessível aos trabalhadores e ao público. Mas a versão 1986 não forneceu orientação para determinar a acessibilidade da tecnologia de informação e não houve procedimentos de execução.

A emenda de 1998, dirigida ambas as questões. O Conselho de acesso (o Conselho de Arquitetura e Compliance Transporte Barreiras) foi atribuído a tarefa de determinar padrões para a tecnologia eletrônica e de informação acessível. Embora a lei aplica-se ao desenvolvimento, aquisição, manutenção ou uso de toda a tecnologia eletrônica e da informação, é a aquisição em que a execução se encontra.

O resultado do esforço do Conselho de Acesso é um conjunto de padrões para a tecnologia eletrônica e de informação acessível.

O endereço de normas específicas:
    Aplicações de software e sistemas operacionais (§ 1.194,21)
    Informações baseadas na Web de intranet e internet e aplicativos (§ 1.194,22)
    Produtos de telecomunicações (§ 1.194,23)
    Vídeo ou produtos multimédia (§ 1.194,24)
    Auto-suficientes produtos fechados, tais como copiadoras (§ 1.194,25)
    Computadores de mesa e portáteis (§ 1.194,26)

As normas de acessibilidade da Seção 508 se aplicam a agências federais de compra de tecnologia eletrônica e de informação. Espera-se que a pressão do mercado de contratos Federal terá um efeito muito mais amplo do que apenas fazer a tecnologia da informação acessível Federal, embora mesmo esta é uma meta significativa.

Em particular, as exigências da Seção 508 não se estendem aos beneficiários de fundos federais ou empresas privadas. Há uma exceção notável a essa isenção. Segundo o site da ATAP, "estados que recebem recursos federais sob a Lei de Tecnologia Assistiva de 1998 são obrigados por lei a que proporcionar uma garantia de conformidade com a Seção 508. Atualmente, todos os 50 estados e todos os territórios receben recursos de apoio de tecnologia e todos têm algum forma de garantia da Seção 508.

Esta comparação da prioridade WCAG um postos de controle e as normas de acessibilidade Seção 508 da web é de interesse para os estados, porque alguns optaram por usar as WCAG como critério de acessibilidade na web.

As Diretrizes de Acessibilidade Web Initiative (WCAG)

A Web Accessibility Initiative (WAI) foi formada pelo World Wide Web Consortium (W3C), a fim de trazer considerações de acessibilidade para o desenvolvimento de tecnologia de Web Consortium e determinar diretrizes para a tecnologia acessível, incluindo a criação de web e agentes do usuário (navegadores). Como Tim Berners-Lee, o inventor da Web, e do diretor do W3C colocou, "O poder da Web está na sua universalidade. Acesso por todos, independentemente da deficiência é um aspecto essencial."

A primeira versão das diretrizes de criação, o Web Content Accessibility Guidelines 1.0, se tornou uma recomendação da W3C em 5 de maio de 1999.

As orientações são organizados em uma lista de verificação. Os pontos de verificação são classificados como prioridade 1, 2 ou 3. Aqui é a caracterização dessas prioridades das Diretrizes:

[Prioridade 1]
Criadores de conteúdo Web devem satisfazer. Caso contrário, um ou mais grupos de usuários ficarão impossibilitados de acessar as informações contidas no documento. A satisfação desse tipo de pontos é um requisito básico para que determinados grupos possam aceder a documentos da web.
 
[Prioridade 2]
Criadores de conteúdo Web devem satisfazer. Caso contrário, um ou mais grupos terão dificuldades para acessar as informações no documento. A satisfação deste tipo de pontos irá remoção de barreiras significativas ao acesso a documentos da web.
 
[Prioridade 3]
Criadores de conteúdo Web podem satisfazer. Caso contrário, um ou mais grupos vai encontrá-lo um pouco difícil de acessar as informações no documento. A satisfação deste tipo de pontos irá melhorar o acesso a documentos web.

Esta comparação lado-a-lado olha primeiro na prioridade 1 checkpoints WCAG (do ponto de vista da  WCAG) e compara cada um com com relevantes Seção padrões web 508. Por outro lado, do ponto de vista da seção 508 relaciona todos os padrões web 508 e compara esses postos de controle WCAG, alguns postos de controle de prioridade 2 e 3 estão relacionados com os padrões de 508.

Recursos de implementação:

Os WCAG são introduzidos a um documento técnicas, Técnicas para Web Content Accessibility Diretrizes, que ensina técnicas para apoiar cada ponto de verificação. Além disso, há recursos de treinamento no site WAI.

O Conselho de Acesso lançou um guia informativo para os padrões da web que está ligado a pelo site Access Board Seção 508. Os individuais padrões web 508 nas tabelas abaixo estão ligados a esse documento. A Assistência Técnica de Tecnologia da Informação e Centro de Treinamento (ITTATC) foi fundada para apoiar a Seção 508. Há muitos recursos disponíveis no site ITTATC. Um tutorial sobre Acessibilidade Web para a seção 508 foi escrito para ITTATC e em breve estará disponível em seu site. 

A IBM também oferece diretrizes para acessibilidade na web. Os IBM Accessibility Guidelines Web incluem documentação sobre lógica, técnicas de implementação e testes. O site da IBM inclui links para outros recursos, como o faz o site Accessibility Initiative. 

Tabela de comparação: Seção 508 x WCAG

A Vista de WCAG:

Palavras-chave	WCAG Prioridade 1	Comparação	Seção 508
Equivalente texto	Fornecer um texto equivalente para cada elemento não-texto (por exemplo, através de "alt", "longdesc" ou no conteúdo do elemento) Isto inclui:. imagens, representações gráficas do texto (incluindo símbolos), regiões de mapa de imagem, animações (por exemplo, , GIF animados), applets e objectos programados, arte ASCII, frames, scripts, imagens utilizadas como pontos de enumeração, espaçadores, botões gráficos, sons (reproduzidos com ou sem interacção do utilizador), stand-alone arquivos de áudio, faixas de áudio de vídeo e vídeo.	Semelhante	Um texto equivalente para cada elemento de texto não deve ser fornecida (por exemplo, através de "alt", "longdesc" ou no conteúdo do elemento).
	A Seção 508 padrão usa a linguagem exata das WCAG 1.1 sem Checkpoint "Isso inclui" do WCAG 1.1. Dada a decisão do Conselho de acesso para utilizar o texto WCAG, segue-se que os exemplos de "não-texto" em elementos WCAG 1,1 aplicar a Seção 508 1194,22 (a) também. Isso é confirmado no debate que antecede os padrões de áudio mencionando como exemplo sobre a não-texto elementos.  O Conselho também interpreta esta disposição de exigir que, quando as apresentações de áudio estão disponíveis em uma página web, porque o áudio é uma organização não-textual elemento de texto, na forma de legendas deve acompanhar o áudio, para permitir que pessoas surdas ou com deficiência auditiva para compreender o conteúdo.  Foi um erro para se referir a legendagem de áudio nos padrões definitivos. As guias para os padrões de esclarecer este (ver § 1.194,22 (b) ). Se um site oferece arquivos de áudio sem vídeo, eles têm que ser legendados? Não, porque não é de multimédia. No entanto, uma vez que o áudio é um elemento não-texto, um equivalente de texto, tal como um transcrito, deve estar disponível. Da mesma forma, um (silêncio) web apresentação de slides não precisa ter uma descrição de áudio que o acompanha, mas requer alternativas de texto a ser associado com os gráficos. Para imagens espaçadoras, as utilizadas para formatação de saída, o equivalente texto é a cadeia vazia, alt = "", e que é o texto alternativo que deve ser associado a essas imagens. A questão dos equivalentes textuais para scripts, applets e objetos programados é uma questão completamente diferente. É raro que não existe tal coisa como um "texto equivalente" para um desses objetos programáticos. Tal é frequentemente interpretado como uma descrição funcional do objeto, como em "este applet fornece uma interface para o login, de modo a ver a sua conta 401K." A imagem é complicada pelo papel de tais extensões para HTML em WCAG 1.0 comparada com a secção 508. Para o primeiro as páginas devem ser utilizável com scripts e applets desligados ou não suportados. Isto faz com que a importância do "equivalente de texto" muito maior para o cumprimento WCAG comparação com a secção 508. Para a seção 508 essas extensões deve ser acessível (ver parágrafos 1.194,22 (l) e 1.194,22 (m)).
Do lado do servidor Mapas Imagem	Fornecer links de texto redundantes para cada região ativa de um mapa de imagem do lado do servidor.	O mesmo	Links de texto redundantes devem ser fornecidas para cada região ativa de um mapa de imagem do lado do servidor.
Descrição sonora	Até que os agentes do utilizador possam ler automaticamente em voz alta o equivalente textual de uma pista visual, fornecer uma descrição sonora das informações importantes da pista visual de uma apresentação multimédia.	Não em 508
	Por WCAG 1.1 e 1.4 (Secção 508 1194,22 (a) e (b)) de vídeo deve ter um equivalente de texto sincronizadas. Dado o ambiente web, é natural supor que o texto equivalente sincronizado poderia ser exibido em uma janela ao lado (ou acima ou abaixo) o vídeo como legendas. O problema abordado pelo WCAG 1.3 é que os usuários cegos, para quem isso é importante, não têm hoje acesso a esse texto; seus leitores de tela não vai ler as descrições do vídeo. Até que, WCAG 1.3 requer que o texto de descrição do vídeo ser apresentado em áudio. Vídeo na web que tem texto descritivo de vídeo importante estará de acordo com os padrões da web Seção 508. No entanto, na discussão das normas, o Conselho de acesso referiu especificamente a seção multimídia dos padrões: O Conselho não aprovou WCAG 1.0 1.3 Checkpoint, que prevê que "[u] agentes té pode ler automaticamente em voz alta o equivalente textual de uma pista visual, fornecer uma descrição sonora das informações importantes da pista visual de uma apresentação multimédia ... . " Embora o NPRM não propôs abordar esta questão na seção de web, havia uma disposição semelhante na seção de multimídia do NPRM. Na verdade, existe uma disposição semelhante na regra final também. Parágrafo 1.194,24 (d) da seção de multi-mídia (citados acima) exige que a formação e informação multi-mídia produções que apoiam a missão da agência deve ter descrições de áudio.
Sincronizadas multi-media	Para qualquer tempo com base em apresentação multi-mídia (por exemplo, um filme ou animação), sincronizar as alternativas equivalentes (eg, legendas ou descrições sonoras dos trechos visuais) com a apresentação.	O mesmo	Alternativas equivalentes para qualquer apresentação multimédia deve ser sincronizada com a apresentação.
Cor	Assegurar que todas as informações veiculadas com cor estejam também disponíveis sem cor, por exemplo a partir do contexto ou de marcações.	O mesmo	páginas da Web devem ser concebidos de modo que todas as informações veiculadas com cor estejam também disponíveis sem cor, por exemplo a partir do contexto ou de marcações.
Linguagem Natural	Identificar claramente quaisquer mudanças de idioma no texto de um documento e quaisquer equivalentes textuais (por exemplo, legendas).	Não em 508
	O Conselho de acesso determinado que: 1.        A intenção é de 4,1 para os autores de web para indicar mudança de linguagem natural, com marcação (lang = "en"), a não utilização de linhas de texto, como "a seguir é em alemão." 2.        Não muitas tecnologias assistivas apoiar marcação mudança de linguagem. Com base nessa determinação, o Conselho de Acesso decidiu não incluir este ponto de verificação como um padrão para a Seção 508.
Cabeçalhos de tabela	Para tabelas de dados, identificar cabeçalhos de linha e coluna.	O mesmo	Cabeçalhos de linha e coluna devem ser identificados para tabelas de dados.
Tabelas complexas	Para tabelas de dados com dois ou mais níveis lógicos de cabeçalhos de linha ou de coluna, utilizar marcações para associar as células de dados e células de cabeçalhos.	O mesmo	De marcação deve ser usado para associar células de dados e células de cabeçalhos de tabelas de dados que têm dois ou mais níveis lógicos de cabeçalhos de linha ou coluna.
Folhas de Estilo	Organizar documentos para que eles possam ser lidos sem folhas de estilo. Por exemplo, quando um documento HTML é apresentado sem a folha de estilo, ele ainda deve ser possível ler o documento.	O mesmo	Os documentos devem ser organizados de modo que eles possam ser lidos sem a necessidade de uma folha de estilo associada.
Conteúdo Dinâmico	Assegurar que os equivalentes de conteúdo dinâmico é actualizado quando as mudanças de conteúdo dinâmico.	Não em 508
	O conselho de acesso não incluir este ponto de verificação dos padrões de acessibilidade da Seção 508 da web porque foi considerado incerto. O objetivo da Checkpoint 6,2 é para fazer backup de outros pontos de controlo, como o 6.3, que necessitam de alternativas de texto para conteúdo dinâmico. Checkpoint 6,2 diz que as alternativas de texto deve ser mantido up-to-date. O documento técnicas para este ponto de verificação ( http://www.w3.org/TR/WCAG10-HTML-TECHS/ # scripts-alt ) dá um exemplo de como usar o elemento NOSCRIPT exibindo resultados esportivos em uma lista de definição, enquanto o script daria de presente os escores em uma "placa de conta". Este ponto de verificação exige que estas duas apresentações estão exibindo a mesma pontuação. Outro exemplo deste, meu favorito, é uma função de JavaScript que exibe a data em que a página foi atualizada na parte inferior de uma página web por meio de consulta a data do arquivo. Isso pode garantir que as informações de atualização é atual sem ter que alterar as informações de atualização a cada vez que a página é modificada. Mas se você usar a opção NOSCRIPT como uma alternativa de texto para que o conteúdo dinâmico, o conteúdo NOSCRIPT teria que ser atualizado a cada vez que a página foi modificada por este ponto de verificação, assim anulando a utilidade do script.
Scripting	Assegurar que as páginas são usáveis ​​quando scripts, applets, ou outros objectos programáveis ​​se encontram desactivados ou não são suportados. Se isso não for possível, fornecer informações equivalentes em uma página alternativa acessível.	WCAG mais restritiva	Quando as páginas utilizam linguagens de script para exibir o conteúdo, ou para criar elementos de interface, as informações fornecidas pelo script deve ser identificada com texto funcional, que pode ser lido por tecnologia assistiva. Quando uma página da web requer que um applet aplicativo, plug-in ou outro estar presente no sistema do cliente para interpretar o conteúdo da página, a página deve fornecer um link para um plug-in ou applet que está em conformidade com § 1.194,21 (um ) até (l).
	O ponto de verificação WCAG é muito mais fácil de interpretar, suas páginas têm de ser usáveis ​​quando scripts, applets e outros objetos programáticos estão desligados. Se a sua página satisfaz este ponto de verificação, então é provável que você também satisfazer a seção correspondente padrões 508 já referido. No entanto, a presunção de os padrões da Seção 508 é que scripts, applets e outros objetos programáticos será ligado (e apoiado) e todos aqueles deve ser acessível. Assim, se seu site utiliza scripts apenas para melhorias visuais, como a mudança de atributos de texto quando o mouse passar sobre o texto, o site satisfaz tanto as WCAG 6.3 e Parágrafo 1.194,22 (l). Se você usa o "fly-over" menus implementadas em JavaScript, e todos os itens de submenu estão disponíveis como links de texto normais, o site satisfaz tanto 6.3 e 1.194,22 (l). No entanto, se você usar para colocar Document.write (importante) de texto em sua página enquanto ele está carregando, então ele vai ser um texto funcional disponível para tecnologia assistiva. Supondo-se que o texto é importante, o local não WCAG 6,3 mas passa 1194,22 (l).
Tremer	Até que os agentes do usuário permitem que os usuários controlem cintilação, evitar causar a tela cintilar.	508 mais específico	Páginas devem ser projetadas para evitar causar o ecrã a piscar com uma freqüência maior que 2 Hz e menor que 55 Hz.
	A Seção 508 padrão 1.194,22 (j) destina-se a ser coerente com as WCAG checkpoint 7,1 adicionando apenas uma faixa específica de freqüências para ser evitado. Em particular, a placa de acesso indicado na norma final: Parágrafos (j) e (k) são feitos para serem compatíveis com as disposições semelhantes no WCAG 1.0, no entanto, a regra final usa uma linguagem que é mais consistente com a linguagem regulamentar aplicável. Pode-se argumentar que a 1.194,22 (j) é realmente mais restritivo, porque a maioria cintilação pode ser controlada nos principais navegadores, pressionando a tecla Escape.
Mapas imagem do lado do cliente	Fornecer mapas de imagem client-side em vez de mapas de imagens do servidor, exceto quando as regiões não podem ser definidas por forma geométrica disponível.	O mesmo	Mapas de imagem do lado do cliente deve ser fornecida em vez de mapas de imagens do servidor, exceto quando as regiões não podem ser definidas por forma geométrica disponível.
Texto só em último recurso	Se, depois de todos os esforços, não pode criar uma página acessível, fornecer um link para uma página alternativa que utilize tecnologias do W3C, seja acessível, com informação equivalente (ou funcionalidade), e é atualizado sempre que a página (original) inacessível.	O mesmo	Uma página apenas de texto, com informações equivalentes ou funcionalidade, deve ser fornecido para fazer um site em conformidade com as disposições da presente parte, quando o cumprimento não pode ser realizado de qualquer outra forma. O conteúdo da página de texto somente deverá ser atualizado sempre que as mudanças página principal.
Quadros	Título cada quadro para facilitar a identificação de quadros e de navegação.	O mesmo	Quadros deve ser intitulada com o texto que facilita a identificação de quadros e de navegação.
	Para ambos os requisitos, não se esqueça de incluir o nome significativo e atributos de título em elementos do quadro.
Linguagem clara	Use a linguagem simples e clara, adequada ao conteúdo de um site.	Não em 508
	O Conselho de Acesso decidiu contra a inclusão deste tipo de pontos como um padrão para acessibilidade na web, pois foi considerado muito difícil de aplicar. A exigência de utilização de linguagem simples e clara pode ser muito subjetiva.

A Vista de seção 508:

Palavras-chave	Seção 508	Comparação	WCAG
Equivalente texto	Um texto equivalente para cada elemento de texto não deve ser fornecida (por exemplo, através de "alt", "longdesc" ou no conteúdo do elemento).	Semelhante	Fornecer um texto equivalente para cada elemento não-texto (por exemplo, através de "alt", "longdesc" ou no conteúdo do elemento) Isto inclui:. imagens, representações gráficas do texto (incluindo símbolos), regiões de mapa de imagem, animações (por exemplo, , GIF animados), applets e objectos programados, arte ASCII, frames, scripts, imagens utilizadas como pontos de enumeração, espaçadores, botões gráficos, sons (reproduzidos com ou sem interacção do utilizador), stand-alone arquivos de áudio, faixas de áudio de vídeo e vídeo.
	A Seção 508 padrão usa a linguagem exata das WCAG 1.1 sem Checkpoint "Isso inclui" do WCAG 1.1. Dada a decisão do Conselho de acesso para utilizar o texto WCAG, segue-se que os exemplos de "não-texto" em elementos WCAG 1,1 aplicar a Seção 508 1194,22 (a) também. Isso é confirmado no debate que antecede os padrões de áudio mencionando como exemplo sobre a não-texto elementos. O Conselho também interpreta esta disposição de exigir que, quando as apresentações de áudio estão disponíveis em uma página web, porque o áudio é uma organização não-textual elemento de texto, na forma de legendas deve acompanhar o áudio, para permitir que pessoas surdas ou com deficiência auditiva para compreender o conteúdo. Foi um erro para se referir a legendagem de áudio nos padrões definitivos. As guias para os padrões de esclarecer este (ver 1.194,22 (b) ).Se um site oferece arquivos de áudio sem vídeo, eles têm que ser legendados? Não, porque não é de multimédia. No entanto, uma vez que o áudio é um elemento não-texto, um equivalente de texto, tal como um transcrito, deve estar disponível. Da mesma forma, um (silêncio) web apresentação de slides não precisa ter uma descrição de áudio que o acompanha, mas requer alternativas de texto a ser associado com os gráficos. Para imagens espaçadoras, as utilizadas para formatação de saída, o equivalente texto é a cadeia vazia, alt = "", e que é o texto alternativo que deve ser associado a essas imagens. A questão dos equivalentes textuais para scripts, applets e objetos programados é uma questão completamente diferente. É raro que não existe tal coisa como um "texto equivalente" para um desses objetos programáticos. Tal é frequentemente interpretado como uma descrição funcional do objeto, como em "este applet fornece uma interface para o login, de modo a ver a sua conta 401K." A imagem é complicada pelo papel de tais extensões para HTML em WCAG 1.0 comparada com a secção 508. Para o primeiro as páginas devem ser utilizável com scripts e applets desligados ou não suportados. Isto faz com que a importância do "equivalente de texto" muito maior para o cumprimento WCAG comparação com a secção 508. Para a seção 508 essas extensões deve ser acessível (ver parágrafos 1.194,22 (l) e 1.194,22 (m)).
Sincronizadas multi-media	Aternativas equivalentes para qualquer apresentação multimédia deve ser sincronizada com a apresentação.	O mesmo	Para qualquer tempo com base em apresentação multi-mídia (por exemplo, um filme ou animação), sincronizar as alternativas equivalentes (eg, legendas ou descrições sonoras dos trechos visuais) com a apresentação.
Cor	Páginas da Web devem ser concebidos de modo que todas as informações veiculadas com cor estejam também disponíveis sem cor, por exemplo a partir do contexto ou de marcações.	O mesmo	Assegurar que todas as informações veiculadas com cor estejam também disponíveis sem cor, por exemplo a partir do contexto ou de marcações.
Folhas de Estilo	Os documentos devem ser organizados de modo que eles possam ser lidos sem a necessidade de uma folha de estilo associada.	O mesmo	Organizar documentos para que eles possam ser lidos sem folhas de estilo. Por exemplo, quando um documento HTML é apresentado sem a folha de estilo, ele ainda deve ser possível ler o documento.
Do lado do servidor Mapas Imagem	Links de texto redundantes devem ser fornecidas para cada região ativa de um mapa de imagem do lado do servidor.	O mesmo	Fornecer links de texto redundantes para cada região ativa de um mapa de imagem do lado do servidor.
Mapas imagem do lado do cliente	Mapas de imagem do lado do cliente deve ser fornecida em vez de mapas de imagens do servidor, exceto quando as regiões não podem ser definidas por forma geométrica disponível.	O mesmo	Fornecer mapas de imagem client-side em vez de mapas de imagens do servidor, exceto quando as regiões não podem ser definidas por forma geométrica disponível.
Cabeçalhos de tabela	cabeçalhos de linha e coluna devem ser identificados para tabelas de dados.	O mesmo	Para tabelas de dados, identificar cabeçalhos de linha e coluna.
Tabelas complexas	De marcação deve ser usado para associar células de dados e células de cabeçalhos de tabelas de dados que têm dois ou mais níveis lógicos de cabeçalhos de linha ou coluna.	O mesmo	Para tabelas de dados com dois ou mais níveis lógicos de cabeçalhos de linha ou de coluna, utilizar marcações para associar as células de dados e células de cabeçalhos.
Quadros	Quadros deve ser intitulada com o texto que facilita a identificação de quadros e de navegação.	O mesmo	título cada quadro para facilitar a identificação de quadros e de navegação.
Tremer	páginas devem ser projetadas para evitar causar o ecrã a piscar com uma freqüência maior que 2 Hz e menor que 55 Hz.	508 mais específico	até que os agentes do usuário permitem que os usuários controlem cintilação, evitar causar a tela cintilar.
	A Seção 508 padrão 1.194,22 (j) destina-se a ser coerente com as WCAG checkpoint 7,1 adicionando apenas uma faixa específica de freqüências para ser evitado. Em particular, a placa de acesso indicado na norma final: Parágrafos (j) e (k) são feitos para serem compatíveis com as disposições semelhantes no WCAG 1.0, no entanto, a regra final usa uma linguagem que é mais consistente com a linguagem regulamentar aplicável. Pode-se argumentar que a 1.194,22 (j) é realmente mais restritivo, porque a maioria cintilação pode ser controlada nos principais navegadores, pressionando a tecla Escape.
Texto só em último recurso	Uma página apenas de texto, com informações equivalentes ou funcionalidade, deve ser fornecido para fazer um site em conformidade com as disposições da presente parte, quando o cumprimento não pode ser realizado de qualquer outra forma. O conteúdo da página de texto somente deverá ser atualizado sempre que as mudanças página principal.	O mesmo	Se, depois de todos os esforços, não pode criar uma página acessível, fornecer um link para uma página alternativa que utilize tecnologias do W3C, seja acessível, com informação equivalente (ou funcionalidade), e é atualizado sempre que a página (original) inacessível.
Scripting	Quando as páginas utilizam linguagens de script para exibir o conteúdo, ou para criar elementos de interface, as informações fornecidas pelo script deve ser identificada com texto funcional, que pode ser lido por tecnologia assistiva.	WCAG mais restritiva	Assegurar que as páginas são usáveis ​​quando scripts, applets, ou outros objectos programáveis ​​se encontram desactivados ou não são suportados. Se isso não for possível, fornecer informações equivalentes em uma página alternativa acessível. Para os scripts e applets, assegurar que os manipuladores de eventos são de entrada independente do dispositivo. (Prioridade 2) Criar elementos de programação, tais como scripts e applets, diretamente acessíveis ou compatíveis com tecnologias assistivas [Prioridade 1 se a funcionalidade for importante e não apresentadas em outro local, caso contrário, Prioridade 2.] dos scripts, especifique manipuladores de eventos lógicos em vez de manipuladores de eventos dependentes de dispositivos. (Prioridade 2)
	Conforme discutido no "The View WCAG", se páginas satisfazer Checkpoint 6,3, isso significa que os scripts não estão envolvidos com o conteúdo essencial ou importante (não a transmissão de informações) e, portanto, não seria necessário o texto que pode ser acessado pela tecnologia de apoio. Eles passariam 1.194,22 (l). Dois dos Prioridade WCAG dois postos de controle (6,4 e 9,3) enfatizar a necessidade de acessibilidade de manipuladores de eventos, principalmente para acesso ao teclado. Este foco não é refletido na seção padrões Web 508. Observe que o acesso do teclado é necessário nos padrões de software, 1194,21 (a), mas isso não se aplica ao conteúdo web. A comparação mais importante entre o padrão Seção 508 para os scripts e os postos de controle de WCAG é a Prioridade 2/1 Checkpoint 8,1 que exige que os scripts ser directamente acessíveis ou compatíveis com tecnologias de apoio. Minha interpretação de "compatível com a tecnologia assistiva," é que ele é essencialmente o que o § 1.194,22 (l) exige. Se Checkpoint 6.3 não estavam presentes, eu diria que as exigências sobre os scripts da Web Accessibility Initiative (incluindo Prioridade 2) é semelhante ao da Seção 508. No entanto, há uma inconsistência enigmática nos checkpoints WCAG. Checkpoint 8.1 é listado com a prioridade de dois itens, mas para a funcionalidade importante é suposto ser uma prioridade. Por outro lado, do ponto de verificação 6.3 (Prioridade 1) exige que as páginas ser utilizável com scripts e applets desligado. Parece-me que Checkpoint 6,3 trunfos Checkpoint 8,1 e scripts importantes não são permitidos, enquanto os scripts acessíveis (os 8,1 satisfatório) são permitidos por 1.194,22 (l).
Applets e plug-ins	Quando uma página da web requer que um applet aplicativo, plug-in ou outro estar presente no sistema do cliente para interpretar o conteúdo da página, a página deve fornecer um link para um plug-in ou applet que está em conformidade com § 1.194,21 (um ) até (l).	Semelhante	Assegurar que as páginas são usáveis ​​quando scripts, applets, ou outros objectos programáveis ​​se encontram desactivados ou não são suportados. Se isso não for possível, fornecer informações equivalentes em uma página alternativa acessível. (Prioridade 1) Para os scripts e applets, assegurar que os manipuladores de eventos são de entrada independente do dispositivo. (Prioridade 2) Criar elementos de programação, tais como scripts e applets, diretamente acessíveis ou compatíveis com tecnologias assistivas [Prioridade 1 se a funcionalidade for importante e não apresentadas em outro local, caso contrário, Prioridade 2.]
	A intenção da seção de padrões de software 508 (§ 1.194,21 (a) a (l)) é ter requisitos específicos que irá assegurar que o software é acessível directamente e / ou compatível com a tecnologia assistiva. Assim, se sites satisfazer 1.194,22 (m), então eles vão cumprir com pontos de verificação das WCAG 6.4 e 8.1. No entanto, eles não serão necessariamente cumprir a prioridade checkpoint WCAG 1 6.3.
Formas	Quando os formulários eletrônicos são projetados para ser preenchido on-line, o formulário deve permitir que as pessoas que usam a tecnologia assistiva para acessar as informações, elementos de campo e funcionalidade necessária para preenchimento e envio do formulário, incluindo todas as direções e sugestões.	Semelhante	até que os agentes do utilizador suportem associações explícitas entre rótulos e controlos de formulário, para todos os controles de formulário com rótulos implicitamente associados, garantir que a etiqueta está bem posicionado. (Prioridade 2) Associar explicitamente os rótulos aos respectivos controles. (Prioridade 2) dos scripts, especifique manipuladores de eventos lógicos em vez de manipuladores de eventos dependentes de dispositivos. (Prioridade 2)
	A chave para formas acessíveis é para uma pessoa que usa a tecnologia de apoio para ser capaz de identificar o propósito de qualquer elemento de controlo e de forma a ser capaz de manipular. Sabendo da intenção do elemento de entrada é o propósito de prioridade WCAG 2 checkpoints 10,2 e 12,4. WCAG checkpoint 9,3 seria garantir que o formulário pode ser manipulado com o teclado.
Pulo de navegação	Um método deve ser desde que usuários autorizações para pular links de navegação repetitivos.	Relacionada à WCAG mas 508 Seção mais específico	Fornecer barras de navegação para destacar e dar acesso ao mecanismo de navegação. (Prioridade 3) Agrupe links relacionados, identifique o grupo (por agentes do utilizador) e, até que os agentes do utilizador o façam, forneça uma forma de saltar um grupo. (Prioridade 3)
Respostas cronometrados	Quando uma resposta é temporizada, o usuário será alertado e dado tempo suficiente para indicar é necessário mais tempo.	Não em  WCAG
	Não há postos de controle comparáveis ​​nos Web Content Accessibility Guidelines.

  

Referência: 
Tabela traduzida do site: http://www.jimthatcher.com/sidebyside.htm