From 074785cea106179cb3305637055ab0a009ca74f2 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:52 -0500 Subject: initial commit --- .../index.html | 100 +++++++++ .../index.html | 234 +++++++++++++++++++++ .../acessibilidade/desenvolvimento_web/index.html | 54 +++++ .../web/acessibilidade/entendendo_wcag/index.html | 57 +++++ .../entendendo_wcag/keyboard/index.html | 87 ++++++++ files/pt-br/web/acessibilidade/index.html | 52 +++++ .../problemas_com_jaws_no_firefox/index.html | 11 + 7 files changed, 595 insertions(+) create mode 100644 files/pt-br/web/acessibilidade/accessibilidade_para_plataforma_movel/index.html create mode 100644 files/pt-br/web/acessibilidade/an_overview_of_accessible_web_applications_and_widgets/index.html create mode 100644 files/pt-br/web/acessibilidade/desenvolvimento_web/index.html create mode 100644 files/pt-br/web/acessibilidade/entendendo_wcag/index.html create mode 100644 files/pt-br/web/acessibilidade/entendendo_wcag/keyboard/index.html create mode 100644 files/pt-br/web/acessibilidade/index.html create mode 100644 files/pt-br/web/acessibilidade/problemas_com_jaws_no_firefox/index.html (limited to 'files/pt-br/web/acessibilidade') diff --git a/files/pt-br/web/acessibilidade/accessibilidade_para_plataforma_movel/index.html b/files/pt-br/web/acessibilidade/accessibilidade_para_plataforma_movel/index.html new file mode 100644 index 0000000000..29d407c175 --- /dev/null +++ b/files/pt-br/web/acessibilidade/accessibilidade_para_plataforma_movel/index.html @@ -0,0 +1,100 @@ +--- +title: Acessibilidade para plataforma móvel +slug: Web/Acessibilidade/Accessibilidade_para_plataforma_movel +tags: + - Acessibilidade + - Firefox OS + - Guías + - Móveis +translation_of: Web/Accessibility/Mobile_accessibility_checklist +--- +
+

Este documento contém uma lista concisa de requisitos para desenvolvedores de aplicativos móveis. Tem como intenção evoluir continuamente conforme forem aparecendo outros padrões.

+
+ +

Cor

+ + + +
+

   Jon Snook escreveu um útil Colour Contrast Checker  que é usado para checar o contraste de cores entre o background e o foreground. De maneira alternativa o Tanaguru Contrast-Finder faz um trabalho similar, mas também sugeste melhores contrastes de cores considerando as usadas.

+
+ +

Visibilidade

+ + + +

Foco

+ + + +

Textos Equivalentes

+ + + +

Manipulação de Estado

+ + + +

Orientações gerais

+ + + +
+

Tanaguru's automated accessibility testing service fornece uma maneira útil para descobrir alguns erros de acessibilidade que ocorrem em páginas web, ou instalando aplicativos web (ex: Firefox OS.) Você pode encontrar mais sobre a técnica de implementação do Tanaguru, como também contribuir para o projeto tanaguru.org.

+
+ +
+

A versão original desse documento foi escrita por Yura Zenevich.

+
+ +

 

diff --git a/files/pt-br/web/acessibilidade/an_overview_of_accessible_web_applications_and_widgets/index.html b/files/pt-br/web/acessibilidade/an_overview_of_accessible_web_applications_and_widgets/index.html new file mode 100644 index 0000000000..df43b575a6 --- /dev/null +++ b/files/pt-br/web/acessibilidade/an_overview_of_accessible_web_applications_and_widgets/index.html @@ -0,0 +1,234 @@ +--- +title: Visão geral da acessibilidade nas aplicações web e widgets +slug: Web/Acessibilidade/An_overview_of_accessible_web_applications_and_widgets +tags: + - ARIA + - Accessibility + - Acessibilidade + - Aplicativos Web + - CSS + - DHTML + - Guía + - HTML+ARIA + - Navegação+Teclado + - WAI-ARA + - Widgets +translation_of: Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets +--- +

A Rede Mundial está mudando. Estatísticamente, os sítios baseados em páginas estão, cada vez mais, sendo repostos por aplicações dinâmicas, em estilo Ambiente, que fazem uso intenso de JavaScript e AJAX. Estilistas estão criando novos widgets e controles inteiramente com a combinação de JavaScript, HTML e CSS. Este salto tem o potencial de aperfeiçoar, dramaticamente, a capacidade de resposta e a usabilidade da Rede, mas milhares de utilizadores estão sob o risco de exclusão, devido a algumas lacunas na acessibilidade. A JavaScript tem, tradicionalmente, tido a reputação de ser inviável para quem usa tecnologias assistivas, como leitores de tela mas, agora, existem maneiras de criar interfaces de utilização dinâmicas acessíveis a uma ampla variedade de pessoas.

+ +

O problema

+ +

A maior parte do conjunto de ferramentas JavaScript oferece uma biblioteca de utilização de widgets que imita o comportamento de interfaces de Ambiente familiares. Deslizantes, barras de menus, visão de arquivos em lista e muito mais pode ser construído com uma combinação de JavaScript, CSS e HTML. Uma vez que a especificação da HTML 4 não fornece etiquetas integradas (built-in tags) que descrevam estes tipos de widgets semanticamente, os desenvolvedores recorrem ao uso de elementos genéricos, tais como <div> e <span>. Embora isto resulte em um widget que se pareça com seu duplo de ambiente, geralmente não existe informação semântica suficiente, na marcação, para torná-lo utilizável por uma tecnologia assistiva. Teor dinâmico em uma página da Rede Mundial pode ser particularmente problemático para quem, por alguma razão, não pode ver a tela. Cotações de ações, alimentação instantânea de atualizações do twitter, indicadores de progresso e conteúdos similares alteram o DOM, enquanto uma tecnologia assistiva (TA/AT) pode não ser alertada disso. Aqui é onde o conjunto ARIA entra.

+ +

Exemplo 1: Marcação para um widget de abas construído sem as indicações ARIA. Não existem informações semânticas, na marcação, que descrevam a sua forma, nem a sua função.

+ +
<!-- This is a tabs widget. How would you know, looking only at the markup? -->
+<ol>
+  <li id="ch1Tab">
+    <a href="#ch1Panel">Chapter 1</a>
+  </li>
+  <li id="ch2Tab">
+    <a href="#ch2Panel">Chapter 2</a>
+  </li>
+  <li id="quizTab">
+    <a href="#quizPanel">Quiz</a>
+  </li>
+</ol>
+
+<div>
+  <div id="ch1Panel">Chapter 1 content goes here</div>
+  <div id="ch2Panel">Chapter 2 content goes here</div>
+  <div id="quizPanel">Quiz content goes here</div>
+</div>
+ +

Exemplo 2: Como o widget de abas pode ser visto. Seus utilizadores podem reconhecer sua aparência, mas não há semântica legível por mecanismos de tecnologias assistivas.
+ Screenshot of the tabs widget

+ +

ARIA

+ +

As definições para WAI-ARIA Accessible Rich Internet Applications (Aplicações Ricas para uma Internete Acessível), da W3C -  Web Accessibility Initiative (Iniciativa pela Acessibilidade na Rede Mundial/World Wide Web Consortium-W3C) - oferecem uma via para a adição das necessidades semânticas perdidas pelas tecnologias assistivas, como os leitores de tela. O conjunto ARIA possibilita que desenvolvedores possam descrever seus widgets de forma mais detalhada com a inclusão de atributos especiais à marcação. Projetado para preencher a lacuna entre o padrão de rotulagem HTML e os controles com estilo ambiente encontrados em aplicações dinâmicas pela web, o conjunto ARIA fornece funções (roles) e estados (states) que descrevem o comportamento da maioria das interfaces de utilização dos widgets conhecidas.

+ +

A especificação ARIA está dividida em três tipos diferentes de atributos: funções (roles), estados (states) e propriedades (properties). As funções (roles) descrevem os widgets que não estão disponíveis de outra forma em HTML 4, como deslizantes, barras de menu, abas e diálogos. As propriedades (properties) descrevem as características desses widgets - se podem ser arrastados (draggable), se existe algum elemento obrigatório, ou se trazem uma janela de explosão (popup) associada. Os estados (states) descrevem a interação atual de um elemento, informando à tecnlogia assistiva se este se encontra ativo, desativado, selecionado, ou oculto.

+ +

Os atributos ARIA são projetados para serem interpretados automaticamente pelo navegador e traduzidos para as APIs (Application Programming Interface/Interface de Programação de Aplicativo) de acessibilidade nativas do sistema operacional. Quando o conjunto ARIA está presente as tecnologias assistivas são capazes de reconhecer e interagir com os controles personalizados pela  JavaScript da mesma forma que fazem com os seus equivalentes de ambiente. Isto tem o potencial de oferecer uma experiência de utilização muito mais consistente do que aquela que foi possível nas gerações anteriores das aplicações da Rede, uma vez que os utilizadores de tecnologias assistivas podem empregar todo o seu conhecimento sobre o funcionamento das aplicações de ambiente, ao usar aquelas que são baseadas na web.

+ +

Exemplo 3: Marcação para um widget de abas com os atributos ARIA adicionados:

+ +
<!-- Now *these* are Tabs! -->
+<!-- We've added role attributes to describe the tab list and each tab. -->
+<ol role="tablist">
+  <li id="ch1Tab" role="tab">
+    <a href="#ch1Panel">Chapter 1</a>
+  </li>
+  <li id="ch2Tab" role="tab">
+    <a href="#ch2Panel">Chapter 2</a>
+  </li>
+  <li id="quizTab" role="tab">
+    <a href="#quizPanel">Quiz</a>
+  </li>
+</ol>
+
+<div>
+  <!-- Notice the role and aria-labelledby attributes we've added to describe these panels. -->
+  <div id="ch1Panel" role="tabpanel" aria-labelledby="ch1Tab">Chapter 1 content goes here</div>
+  <div id="ch2Panel" role="tabpanel" aria-labelledby="ch2Tab">Chapter 2 content goes here</div>
+  <div id="quizPanel" role="tabpanel" aria-labelledby="quizTab">Quiz content goes here</div>
+</div>
+
+ +

O conjunto ARIA tem suporte nas últimas versões de todos os maiores navegadores, incluindo Firefox, Safari, Opera, Chrome e Internet Explorer. Muitas das tecnologias assistivas, como as de código aberto NVDA e os leitores de tela Orca, da mesma foma, trazem suporte ao ARIA. Progressivamente, as bibliotecas  JavaScript para widget, tais como  jQuery UI, YUI, Google Closure e Dojo Dijit também incluem as marcações ARIA.

+ +

Mudanças na apresentação

+ +

Mudanças de apresentação dinâmicas agregam o uso de CSS para alterar a aparência do conteúdo (uma borda vermelha em volta de algum dado inválido, ou a troca da cor de fundo de uma caixa de seleção já marcada), bem como quando um item é exibido, ou escondido.

+ +

Mudanças de estado

+ +

O conjunto ARIA provê atributos para declarar o estado atual da interface de utilização de um widget. Os exemplos abrangem (mas não são apenas estes, com certeza( :

+ + + +

(Para uma lista completa de estados ARIA, consulte a ARIA list of states and properties (lista de estados e propriedades ARIA).

+ +

Os desenvolvedores devem dar preferência ao uso dos estados ARIA para indicar a situação atual dos elementos widgets na interface de utilização (UI) e os seletores de atributos CSS para alterar a sua aparência, com base nas mudanças desses estados (em vez de usar um roteiro (script) para mudar um nome de classe de um elemento).

+ +

A Open Ajax Alliance (OAA - Aliança OpenAJAX ) disponibiliza um exemplo de um seletor de atributos CSS baseado nos estados ARIA (em inglês) - an example of CSS attribute selectors based on ARIA states. O exemplo mostra a interface de um editor WYS/WYG com um sistema de menu dinâmico. Os itens selecionados no menu, como o tipo de fonte estão, visualmente, distintos dos outros. As partes importantes do exemplo são explicadas a seguir.

+ +

Neste exemplo, a HTML para um menu tem a forma exibida abaixo. Note como, nas linhas 7 e 13, a propriedade (property) aria-checked é usada para declarar o estado da seleção dos itens do menu.

+ +

Exemplo 1a: HTML para um menu selecionável (adaptado da  http://www.oaa-accessibility.org/example/25/).

+ +
<ul id="fontMenu" class="menu" role="menu" aria-hidden="true">
+  <li id="sans-serif"
+      class="menu-item"
+      role="menuitemradio"
+      tabindex="-1"
+      aria-controls="st1"
+      aria-checked="true">Sans-serif</li>
+  <li id="serif"
+      class="menu-item"
+      role="menuitemradio"
+      tabindex="-1"
+      aria-controls="st1"
+      aria-checked="false">Serif</li>
+  ...
+
+ +

A CSS usada para alterar a aparência do item selecionado é mostrada no Exemplo 1b. Perceba que não existe um nome de classe (classname) de personalização, apenas o estado do atributo aria-checked, na linha 1.

+ +

Exemplo 1b: Seletor baseado em atributo para indicar um estado (da  http://www.oaa-accessibility.org/example/25/).

+ +
li[aria-checked="true"] {
+  font-weight: bold;
+  background-image: url('images/dot.png');
+  background-repeat: no-repeat;
+  background-position: 5px 10px;
+}
+
+ +

O  JavaScript para atualizar a propriedade aria-checked tem a forma exibida no Exemplo 1c. Repare que o roteiro (script) apenas atualiza o atributo aria-checked (linhas 3 e 8); também não é necessário adicionar, ou remover, um nome de classe personalizada.

+ +

Exemplo 1c: A  JavaScript atualiza o atributo aria-checked  (baseado em  http://www.oaa-accessibility.org/example/25/).

+ +
var processMenuChoice = function(item) {
+  // 'check' the selected item
+  item.setAttribute('aria-checked', 'true');
+  // 'un-check' the other menu items
+  var sib = item.parentNode.firstChild;
+  for (; sib; sib = sib.nextSibling ) {
+    if ( sib.nodeType === 1 && sib !== item ) {
+      sib.setAttribute('aria-checked', 'false');
+    }
+  }
+};
+
+ +

Alterações visuais

+ +

Quando o conteúdo visual é alterado (isto é, um elemento é escondido, ou mostrado), os desenvolvedores devem mudar o valor da propriedade aria-hidden. As técnicas descritas acima devem ser usadas, a fim de declarar a CSS para ocultar um elemento utilizando display:none (exibir:nenhum).

+ +

O sítio da Open Ajax Alliance fornece um exemplo de uma dica de tela (tooltip) que utiliza o estado aria-hidden para controlar a sua visibilidade (em inglês) an example of a tooltip that uses aria-hidden to control the visibility of the tooltip. O exemplo mostra um formulário web simples, com caixas de dicas de tela contendo instruções associadas aos campos de entrada. As partes relevantes deste exemplo estão explicadas abaixo.

+ +

Aqui, a HTML para a dica de tela tem a forma exibida no Exemplo 2a. A linha 9 configura o estado da aria-hidden para true.

+ +

Exemplo 2a: HTML para dicas de tela (adaptado de  http://www.oaa-accessibility.org/example/39/).

+ +
<div class="text">
+    <label id="tp1-label" for="first">First Name:</label>
+    <input type="text" id="first" name="first" size="20"
+           aria-labelledby="tp1-label"
+           aria-describedby="tp1"
+           aria-required="false" />
+    <div id="tp1" class="tooltip"
+         role="tooltip"
+         aria-hidden="true">Your first name is optional</div>
+</div>
+
+ +

A CSS para esta marcação está explicada no Exemplo 2b. Veja que não há uso de classname personalizada, apenas o estado do atributo aria-hidden, na linha 1.

+ +

Exemplo 2b:  Seletor basedo em atributo para indicar um estado  (de http://www.oaa-accessibility.org/example/39/).

+ +
div.tooltip[aria-hidden="true"] {
+  display: none;
+  }
+
+ +

O JavaScript que atualiza a propriedade aria-hidden tem a forma exposta no Exemplo 2c. Observe que o roteiro apenas atualiza o atributo aria-hidden (linha 2); não é necessário adicionar, nem remover, uma classname customizada.

+ +

Exemplo 2c: JavaScript para atualização do atributo aria-checked (com base em http://www.oaa-accessibility.org/example/39/).

+ +
var showTip = function(el) {
+  el.setAttribute('aria-hidden', 'false');
+}
+ +

Mudança de Atributo (Role)

+ +
Em construção
+ +

O conjunto ARIA possibilita que os desenvolvedores possam declarar uma função semântica para um elemento que, de outro modo, não a apresentaria, ou a ofereceria de forma incorreta. Por exemplo, quando alguma lista desordenada é utilizada para criar um menu, à {{ HTMLElement("ul") }} deve ser dada uma role de menubar e cada {{ HTMLElement("li") }} deve ter uma role de menuitem.

+ +

O papel (role) de um elemento não deve mudar. Em vez disso, remova o elemento original e ocupe seu lugar com um elemento que tenha a função (role) nova.

+ +

Por exemplo, considere um widget de edição "inline": um componente que possibilita que seus utilizadores sejam capazes de editar uma parte de um texto, sem mudar toda a composição. Este componente carrega o modo "visualizar", no qual o texto não pode ser modificado, mas pode ser ativado e um modo "editar", no qual o texto pode ser alterado. Se você o desenvolve, pode ter a tentação de implementar o modo "visualizar" com o uso do elemento texto "somente leitura"  {{ HTMLElement("input") }}, definindo a sua ARIA role para button e, em seguida, alternando para o modo "editar", para tornar o elemento apto à gravação e removendo o atributo role no modo "editar" (desde que os elementos {{ HTMLElement("input") }} tenham as suas próprias funções semânticas).

+ +

Não faça isso. Em substituição, implemente o modo "visualizar" usando um elemento completamente diferente, tal como uma {{ HTMLElement("div") }}, ou {{ HTMLElement("span") }} com uma role de button e o modo « edit » utilizando um elemento texto {{ HTMLElement("input") }}.

+ +

Mudanças assíncronas de conteúdo

+ +
Em construção. Veja, também, Regiões Dinâmicas
+ + + +

Muitas vezes, os desenvolvedores negligenciam o suporte ao teclado quando criam widgets personalizados. Para ser acessível a uma gama maior de pessoas, todas as configurações de uma aplicação web, ou de um widget, devem oferecer controles pelo teclado, sem a necessidade de um rato. Na prática isto, frequentemente, envolve as convenções suportadas por widgets similares, de ambiente, tirando plena vantagem das teclas Tab, Entra, Barra de Espaço e Setas.

+ +

Tradicionalmente, a navegação pelo teclado na web tem sido limitada à tecla Tab, que é pressionada para dar foco a cada botão, vínculo, ou formulário na página, em uma ordenação linear e Shift-Tab para navegar em sentido contrário (navegação regresssiva). É uma forma unidimensional de navegação - para frente e para trás, um elemento por vez. Em páginas mais pesadas, alguém que navegue apenas pelo teclado deve pressioná-lo dezenas de vezes antes de alcançar a seção desejada. Implementar as convenções para teclado no modelo ambiente, para a web, tem o potencial de tornar a navegação significativamente mais rápida para essas pessoas.

+ +

Aqui está um resumo sobre como a navegação pelo teclado deve funcionar, com a habilitação do conjunto ARIA, na aplicação web:

+ + + +

Assim, para o exemplo de widget de abas acima, a pessoa que estiver navegando deve ser capaz de entrar e sair da caixa que o contém usando as teclas "Tab" e "Shift+Tab" ( a <ol> na nossa marcação). Uma vez que o foco, pelo teclado, estiver dentro do contêiner, as teclas de setas devem permitir a navegação entre as suas diferentes guias (os elementos <li> ). A partir daqui as convenções variam de plataforma para plataforma. No Windows, a próxima aba deve ser ativada, automaticamente, quando as teclas de setas forem pressionadas. Em Mac OS X, seus utilizadores ativam a próxima aba pressionando a tecla "Entra", ou a "barra de espaço". Um  tutorial abrangente, para a criação de widgets, com navegação pelo teclado, descreve como implementar esse comportamento utilizando JavaScript Keyboard-navigable JavaScript widgets (JavaScript para widgets navegáveis pelo teclado).

+ +

Para mais detalhes sobre as convenções da navegação pelo teclado em modelo ambiente, um guia completo (em inglês) DHTML style guide (guia de estilos da HTML Dinâmica) está disponível. Este guia oferece uma visão global de como a navegação pelo teclado deve funcionar em cada tipo de widget suportado pelo conjunto ARIA. A  W3C também oferece um documento que ajuda muito, ARIA Best Practices, incluindo a navegação pelo teclado e as convenções de atalhos para uma variedade de widgets.

+ +

Veja, também

+ + diff --git a/files/pt-br/web/acessibilidade/desenvolvimento_web/index.html b/files/pt-br/web/acessibilidade/desenvolvimento_web/index.html new file mode 100644 index 0000000000..a8b43d18fa --- /dev/null +++ b/files/pt-br/web/acessibilidade/desenvolvimento_web/index.html @@ -0,0 +1,54 @@ +--- +title: Desenvolvimento Web +slug: Web/Acessibilidade/Desenvolvimento_Web +tags: + - ARIA + - Accessibility + - Acessibilidade + - DHTML + - Desenvolvimento Web + - WebMechanics + - Widgets acessíveis + - XUL +translation_of: Web/Accessibility +--- +

Este documento oferece mais informações para os desenvolvedores sobre as acessibilidades web e XUL

+ + + + + + + + +
+

Acessibilidade na Rede Mundial

+ +
+
ARIA para desenvolvedores
+
O conjunto ARIA possibilita a acessibilidade em conteúdo dinâmico HTML. São exemplos de uso de ARIA os conteúdos de regiões dinâmicas e widgets com JavaScript.
+
JavaScript para widgets navegáveis pelo teclado
+
Até agora, programadores web construiam seus modelos de widgets baseados em <div> e <span>, por faltarem as técnicas adequadas. A acessibilidade através do teclado é parte das exigências mínimas para a acessibilidade, das quais todos os desenvolvedores devem ter consciência.
+
+ +

Acessibilidade XUL

+ +
+
 
+
Construindo componentes personalizados e acessíveis com XUL
+
A utilização das técnicas de acessibilidade DHTML, a fim de tornar acessíveis os componentes customizados com a XUL.
+
Acessibilidade XUL - diretrizes de autoria
+
Quando a autoria está de acordo com estas diretrizes, a XUL é capaz de gerar interfaces acessíveis. Codificadores, revisores, construtores e engenheiros de produção (QA) devem se familiarizar com elas.
+
+ 		+

Recursos Externos

+ +
+
Mergulhe na Acessibilidade
+
Este livro responde a duas questões e a primeira, é: "Por que eu devo tornar meu sítio mais acessível?". A segunda, é: "Como eu posso fazer meu sítio mais acessível?"
+
Construindo páginas acessíveis
+
Uma boa lista sobre acessiblidade na rede mundial, feita pela IBM.
+
+
+ +

 

diff --git a/files/pt-br/web/acessibilidade/entendendo_wcag/index.html b/files/pt-br/web/acessibilidade/entendendo_wcag/index.html new file mode 100644 index 0000000000..392c1008b7 --- /dev/null +++ b/files/pt-br/web/acessibilidade/entendendo_wcag/index.html @@ -0,0 +1,57 @@ +--- +title: Entendendo as Diretrizes de Acessibilidade do Conteúdo Web +slug: Web/Acessibilidade/Entendendo_WCAG +tags: + - WCAG + - Web Content Accessibility Guidelines +translation_of: Web/Accessibility/Understanding_WCAG +--- +

Este conjunto de artigos fornece explicações rápidas para ajudá-lo a entender as etapas que devem ser seguidas para estar em conformidade com as recomendações descritas nas Diretrizes de Acessibilidade para Conteúdo Web 2.0 ou 2.1 do W3C (ou apenas WCAG, para as finalidades deste artigo).

+ +

O WCAG 2.0 e 2.1 fornece um conjunto detalhado de diretrizes para tornar o conteúdo web mais acessível para pessoas com uma ampla variedade de deficiências. Isso é compreensivo, porém incrivelmente detalhado e muito difícil de obter uma compreensão rápida disso. Por essa razão, nós fizemos uma sumário com os passos práticosque você precisa saber para satisfazer as diferentes recomendações, com mais alguns link para mais detalhes do que está sendo solicitado.

+ +

Os quatro princípios

+ +

WCAG is broadly broken down into four principles — major things that web content must be to be considered accessible (see Understanding the Four Principles of Accessibility for the WCAG definitions).

+ +

Each of the links below will take you to pages that further expand on these areas, giving you practical advice on how to write your web content so it conforms to the success criteria outlined in each of the WCAG 2.0 and 2.1 guidelines that further sub-divides each principle.

+ + + +

Should I use WCAG 2.0 or 2.1?

+ +

WCAG 2.1 is the most recent and relevant accessibility standard. Use WCAG 2.1 to help more people with disabilities and reduce the future legal risk for web site owners. Target WCAG 2.0 first when allocating resources. Then step up to WCAG 2.1. 

+ +

O que é o WCAG 2.1?

+ +

WCAG 2.1 was published as an official recommendation on 05 June 2018. The European Union (EU) adopted WCAG 2.1 as the digital accessibility standard in September 2018. W3C published a press release WCAG 2.1 Adoption in Europe. 

+ +

WCAG 2.1 includes:

+ + + + + +

This guide is intended to provide practical information to help you build better, more accessible websites. However, we are not lawyers, and none of this constitutes legal advice. If you are worried about the legal implications of web accessibility, we'd recommend that you check the specific legislation governing accessibility for the web/public resources in your country or locale, and seek the advice of a qualified lawyer.

+ +

O que é acessibilidade? e particulamente o Guia de Acessibilidade e a seção de regras fornecem mais informações relacionadas.

diff --git a/files/pt-br/web/acessibilidade/entendendo_wcag/keyboard/index.html b/files/pt-br/web/acessibilidade/entendendo_wcag/keyboard/index.html new file mode 100644 index 0000000000..905c6d062f --- /dev/null +++ b/files/pt-br/web/acessibilidade/entendendo_wcag/keyboard/index.html @@ -0,0 +1,87 @@ +--- +title: Keyboard +slug: Web/Acessibilidade/Entendendo_WCAG/Keyboard +translation_of: Web/Accessibility/Understanding_WCAG/Keyboard +--- +
To be fully accessible, a web page must be operable by someone using only a keyboard to access and control it. This includes users of screen readers, but can also include users who have trouble operating a pointing device such as a mouse or trackball, or whose mouse is not working at the moment, or who simply prefer to use a keyboard for input whenever possible.
+ +

Focusable elements should have interactive semantics

+ +

If an element can be focused using the keyboard, then it should be interactive; that is, the user should be able to do something to it and produce a change of some kind (for example, activating a link or changing an option).

+ +
+

Note: One important exception to this rule is if the element has role="document" applied to it, inside an interactive context (such as role="application"). In such a case, focusing the nested document is the only way of returning assistive technology to a non-interactive state (often called "browse mode").

+
+ +

Most interactive elements are focusable by default; you can make an element focusable by adding a tabindex=0 attribute value to it. However, you should only add tabindex if you have also made the element interactive, for example, by defining appropriate event handlers keyboard events.

+ +

See also

+ + + +

Avoid using tabindex attribute greater than zero

+ +

The tabindex attribute indicates that an element is focusable using the keyboard. A value of zero indicates that the element is part of the default focus order, which is based on the ordering of elements in the HTML document. A positive value puts the element ahead of those in the default ordering; elements with positive values are focused in the order of their tabindex values (1, then 2, then 3, etc.).

+ +

This creates confusion for keyboard-only users when the focus order differs from the logical order of the page. A better strategy is to structure the HTML document so that focusable elements are in a logical order, without the need to re-order them with positive tabindex values.

+ +

See also

+ + + +

Clickable elements must be focusable and should have interactive semantics

+ +

If an element can be clicked with a pointing device, such as a mouse, then it should also be focusable using the keyboard, and the user should be able to do something by interacting with it.

+ +

An element is clickable if it has an onclick event handler defined. You can make it focusable by adding a tabindex=0 attribute value to it. You can make it operable with the keyboard by defining an onkeydown event handler; in most cases, the action taken by event handler should be the same for both types of events.

+ +

See also

+ + + +

Interactive elements must be able to be activated using a keyboard

+ +

If the user can interact with an element using touch or a pointing device, then the element should also support interacting using the keyboard. That is, if you have defined event handlers for touch or click events, you should also define them for keyboard events. The keyboard event handlers should enable the effectively the same interaction as the touch or click handlers.

+ +

See also

+ + + +

Interactive elements must be focusable

+ +

If the user can interact with an element (for example, using touch or a pointing device), then it should be focusable using the keyboard. You can make it focusable by adding a tabindex=0 attribute value to it. That will add the element to the list of elements that can be focused by pressing the Tab key, in the sequence of such elements as defined in the HTML document.

+ +

See also

+ + + +

Focusable element must have focus styling

+ +

Any element that can receive keyboard focus should have visible styling that indicates when the element is focused. You can do this with the :focus CSS pseudo-class.

+ +

Standard focusable elements such as links and input fields are given special styling by the browser by default, so you might not need to specify focus styling for such elements, unless you want the focus styling to be more distinctive.

+ +

If you create your own focusable components, be sure that you also define focus styling for them.

+ +

See also

+ + diff --git a/files/pt-br/web/acessibilidade/index.html b/files/pt-br/web/acessibilidade/index.html new file mode 100644 index 0000000000..b494b06163 --- /dev/null +++ b/files/pt-br/web/acessibilidade/index.html @@ -0,0 +1,52 @@ +--- +title: Acessibilidade +slug: Web/Acessibilidade +tags: + - ARIA + - Acessibilidade + - Avançado + - Desenvolvimento Web + - TA - Tecnologias Assistivas +translation_of: Web/Accessibility +--- +

Acessiblidade no desenvolvimento Web significa permitir que o máximo possível de pessoas possa acessar os sites da web mesmo quando suas habilidades são limitadas de alguma forma. Aqui nós fornecemos informações sobre o desenvolvimento de conteúdo acessível.

+ +

"A palavra Acessibilidade é, frequentemente, usada para descrever facilidades ou assistências às pessoas com necessidades especiais, como em acessível para cadeirantes. Isto pode se estender para o Sistema Braille, rampas para cadeirantes, sinais sonoros em passagens de pedestres, modelos de páginas e assim por diante". Acessibilidade na Wikipedia

+ +

"A Web é, fundamentalmente, projetada para funcionar para todas as pessoas, independentemente de máquina, programas, língua, cultura, localização ou capacidade física ou mental de seus utilizadores. Quando a web atende a esses requisitos, ela se torna acessível a pessoas com dificuldades auditivas, motoras, visuais e cognitivas". W3C - Acessibilidade

+ +
+
+

Documentação

+ +
+
Desenvolvimento Web
+
Uma coleção de artigos destinados a mostrar as principais questões de desenvolvimento web no mundo da acessibilidade.
+
ARIA
+
Uma coleção de artigos para aprender como usar ARIA e tornar seus documentos HTML mais acessíveis.
+
Desenvolvimento de tecnologias assistivas (TA)
+
Uma coleção de artigos direcionados a desenvolvedores de tecnologias assistivas.
+
Acessibilidade em dispositivos móveis
+
Esse documento fornece uma breve lista das necessidades da acessibilidade para desenvolvedores de aplicativos móveis.
+
+ +

Ver todos os artigos sobre Acessibilidade...

+
+ +
+

Ferramentas para desenvolvedores web

+ + + + + +

Outras páginas úteis

+ + +
+
diff --git a/files/pt-br/web/acessibilidade/problemas_com_jaws_no_firefox/index.html b/files/pt-br/web/acessibilidade/problemas_com_jaws_no_firefox/index.html new file mode 100644 index 0000000000..65fe989377 --- /dev/null +++ b/files/pt-br/web/acessibilidade/problemas_com_jaws_no_firefox/index.html @@ -0,0 +1,11 @@ +--- +title: Problemas com JAWS no Firefox +slug: Web/Acessibilidade/Problemas_com_JAWS_no_Firefox +tags: + - Acessibilidade + - Obsolento +translation_of: Web/Accessibility/JAWS_Issues_with_Firefox +--- +

Problemas JAWS Firefox conhecidos

+ +

Esse artigo não é mais relevante. Por favor, veja o FAQ no site de suporte Mozilla.

-- cgit v1.2.3-54-g00ecf