303 See Other - HTTP

303 See Other
=============

O código de resposta de status de redirecionamento do HyperText Transfer Protocol (HTTP) **`303 See Other`** indica que o direcionamento não une a um recurso carregado novo, mas a outra página, com uma página de confirmação ou de progresso de carregamento. Este código de resposta normalmente é retornado como resultado de um `PUT` ou `POST`. O método usado para mostrar esta página redirecionada é sempre `GET`.

Status
------
```

303 See Other
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.4.4: 303 See Other | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

A informação mostrada abaixo foi retirada do Github da MDN (https://github.com/mdn/browser-compat-data).

Veja também
-----------

* `302` `Found`, the temporary redirect


506 Variant Also Negotiates - HTTP

506 Variant Also Negotiates
===========================

O código de status de resposta HTTP **`506 Variant Also Negotiates`** pode ser dado no contexto de Negociação de Conteúdo Transparente (Transparent Content Negotiation) (veja RFC 2295). Esse protocolo permite ao cliente requerer a melhor variante de um dado recurso, onde um servidor fornece múltiplos variantes.

O código de status **`Variant Also Negotiates`** indica um erro na configuração interna do servidor na qual a variante escolhida é em si configurada para entrar em uma negociação de conteúdo, então não é um *endpoint* de negociação apropriado.

Status
------
```

506 Variant Also Negotiates
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 2295, sessão 8.1: 506 Variant Also Negotiates | Transparent Content Negotiation in HTTP |


429 Too Many Requests - HTTP

429 Too Many Requests
=====================

O código de resposta HTTP **`429 Too Many Requests`** indica que o usuário enviou muitos pedidos em um determinado período de tempo.

Um header `Retry-After` pode ser incluído na resposta indicando quanto tempo o usuário deve esperar antes de fazer um novo pedido.

Status
------
```

429 Too Many Requests
```

Exemplo
-------
```

HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
```

Especificações
--------------

| Especificações | Título |
| --- | --- |
| RFC 6585, sessão 4: 429 Too Many Requests | Status HTTP adicionais |

Veja também
-----------

* `Retry-After`


201 Created - HTTP

201 Created
===========

O status HTTP "**201 Created**" é utilizado como resposta de sucesso, indica que a requisição foi bem sucedida e que um novo recurso foi criado. Este novo recurso é efetivamente criado antes do retorno da resposta e o novo recurso é enviado no corpo da mensagem (pode vir na URL ou na header `Location`).

Comumente, este status é utilizado em requisições do tipo `POST`.

Status
------
```

201 Created
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.3.2: 201 Created | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja mais
---------

* HTTP request methods


418 I'm a teapot - HTTP

418 I'm a teapot
================

O código de erro HTTP para o cliente **`418 I'm a teapot`** indica que o servidor se recusa a preparar café por ser um bule de chá. Este erro é uma referência ao *Hyper Text Coffee Pot Control Protocol*, que foi uma piada de 1º de abril de 1998.

Status
------
```

418 I'm a teapot
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 2324, sessão 2.3.2: 418 I'm a teapot | Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* Wikipedia: Hyper Text Coffee Pot Control Protocol


307 Redirecionamento temporário - HTTP

307 Redirecionamento temporário
===============================

HTTP O código de estado **`307 Redirecionamento temporário`** indica que o recurso da requisição foi temporariamente alterado para a URL informada no cabeçalho `Location`.

O método e o corpo da requisição original são reutilizados para realizar a requisição de redirecionamento. Em casos onde você deseja que o método utilizado seja alterado para `GET`, utilize o código de estado `303 See Other`. Isto é util quando você deseja dar uma resposta a um método `PUT` que não seja o recurso enviado, mas uma mensagem de confirmação (como por exemplo "Envio de XYZ concluído com sucesso").

A única diferença entre `307` e `302` é que o `307` garante que o método e o corpo não são alterados quando o redirecionamento é feito. Com o `302`, alguns clientes antigos alteram o método para `GET`: o comportamento com métodos não-`GET` e `302` fica assim imprevisível na Web, enquanto o comportamento com `307` é previsível. Para requisições `GET`, seu comportamento é identico.

Status
------
```

307 Redirecionamento temporário
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.4.7: 307 Temporary Redirect | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veja também
-----------

* `302 Found`, o equivalente a este código de estado, que pode mudar o método utilizado quiando não é um `GET`.
* `303 See Other`, um redirecionamento temporário que altera o método utilizado para `GET`.
* `301 Moved Permanently`, um redirecionamento permanente.


431 Request Header Fields Too Large - HTTP

431 Request Header Fields Too Large
===================================

O código de stauts de resposta HTTP **`431 Request Header Fields Too Large`** indica que o servidor se recusou a processar a requisição por que os cabeçalhos HTTP da mesma são muito grandes. A requisição *pode* ser resubmetida depois de o tamanho dos cabeçalhos serem reduzidos.

**`431`** pode ser usado quando o **tamanho total** dos cabeçalhos da requisição são muito grandes, ou quando um **único** cabeçalho da requisição é muito grande. Para ajudar aqueles que estão encontrando esse erro, indicar quais dos dois é o problema através do corpo da resposta - idealmente inclua quais são os cabeçalhos que são muito grandes. Isso permite aos usuários a possibilidade de poder arrumar o problema, como limpando os *cookies* deles.

Servidores vão produzir esse status frequentemente se:

* O cabeçalho `Referer` URL é muito longo;
* Existem muitos Cookies sendo enviados na requisição
Status
------
```

431 Request Header Fields Too Large
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 6585, sessão 5: 431 Request Header Fields Too Large | Additional HTTP Status Codes |

Veja também
-----------

* `414 URI Too Long`
* Request header


400 Bad Request - HTTP

400 Bad Request
===============

O código de status de resposta HTTP **`400 Bad Request`** indica que o servidor não pode ou não irá processar a requisição devido a alguma coisa que foi entendida como um erro do cliente (por exemplo, sintaxe de requisição mal formada, enquadramento de mensagem de requisição inválida ou requisição de roteamento enganosa).

**Aviso:** O cliente não deve repetir essa requisição sem modificá-la.

Status
------
```

400 Bad Request
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.5.1: 400 Bad Request | Hypertext Transfer Protocol (HTTP/1.1): Semânticas e conteúdo |

Veja também
-----------

* 400 Bad Request


Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’ - HTTP

Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘\*’
============================================================================================

Motivo
------
```

Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’
```

O que houve de errado?
----------------------

A requisição CORS foi realizada com a flag de credenciais definida, mas o servidor está configurado para usar o coringa (`"*"`) como valor do cabeçalho `Access-Control-Allow-Origin`, o que não permite o uso de credenciais.

Para corrigir o problema do lado do cliente, assegure que a flag de credenciais é `false` ao fazer a requisição CORS.

* Se a requisição foi realizada usando `XMLHttpRequest`, assegure-se que você não setou `withCredentials` (en-US) para `true`.
* Usando Server-sent events (en-US), verifique se `EventSource.withCredentials` (en-US) está `false` (é o valor padrão).
* Se usar a Fetch API, assegure-se que `Request.credentials` (en-US) está como `"omit"`.

Se, em vez disso, você precisar ajustar o comportamento do servidor, você deverá alterar o valor de `Access-Control-Allow-Origin` para permitir acesso para a origem do qual o cliente é carregado.

Veja também
-----------

* CORS errors (en-US)
* Glossary: CORS
* CORS introduction


Reason: CORS header 'Access-Control-Allow-Origin' missing - HTTP

Reason: CORS header 'Access-Control-Allow-Origin' missing
=========================================================

Motivo
------
```

Reason: CORS header 'Access-Control-Allow-Origin' missing
```

O que houve de errado?
----------------------

A resposta à requisição CORS está sem o cabeçalho `Access-Control-Allow-Origin` necessário, que é usado para determinar se o recurso pode ser acessado ou não pelo conteúdo operando dentro da origem atual.

Se o servidor estiver sob seu controle, adicione a origem do site solicitante ao conjunto de domínios de acesso permitido, adicionando-o ao valor do cabeçalho `Access-Control-Allow-Origin`.

Por exemplo, para permitir que um site da origem `https://amazing.site` acesse ao recurso usando CORS, o cabeçalho deve conter:
```

Access-Control-Allow-Origin: https://amazing.site
```

Você também pode configurar um site para permitir que qualquer site o acesse usando o curinga `"*"`. Você só deve usar isso para APIs públicas. As APIs privadas nunca devem usar `"*"` e devem ter um domínio ou domínios específicos definidos. Além disso, o curinga só funciona para solicitações feitas com o atributo `crossorigin` definido como `"anonymous"`.
```

Access-Control-Allow-Origin: *
```

**Aviso:** **Advertência:** Usar o caractere curinga para permitir que todos os sites acessem uma API privada é uma péssima ideia para o que deve ser uma razão óbvia.

Por exemplo, no Apache, adicione uma linha como a seguinte à configuração do servidor (na seção `<Directory>`, `<Location>`, `<Files>` ou `<VirtualHost>` apropriada). A configuração é tipicamente encontrada em um arquivo `.conf` (`httpd.conf` e `apache.conf` são nomes comuns para estes), ou em um arquivo `.htaccess`.
```

Header set Access-Control-Allow-Origin 'origin-list'
```

No Nginx, O comando para configurar este cabeçalho é:
```

add_header 'Access-Control-Allow-Origin' 'origin-list'
```

Veja também
-----------

* CORS errors (Erros do CORS) (en-US)
* Glossário: CORS
* CORS introduction (Introdução ao CORS)


Razão: A requisição CORS não foi bem sucedida - HTTP

Razão: A requisição CORS não foi bem sucedida
=============================================

Razão
-----
```

Razão: A requisição CORS não foi bem sucedida
```

O que deu errado?
-----------------

A requisição HTTP que faz uso do CORS falhou porque a conexão HTTP falhou a nível da camada de transporte ou protocolo. O erro não é diretamente relacionado ao CORS, mas é um tipo de erro fundamental de rede.

Em alguns casos, isso é causado por um plug-in do navegador (um bloqueador de anúncios ou protetor de privacidade) bloqueando a solicitação.

Outras possíveis causas incluem:

* Tentar acessar um recurso https que possui um certificado inválido causará esse erro.
* Tentar acessar um recurso http de uma página com origem https também causará esse erro.
* No Firefox 68, as páginas https não têm permissão para acessar http: // localhost, embora isso possa ser alterado pelo Bug 1488740.
* O servidor não respondeu à solicitação atual (mesmo que tenha respondido ao Preflight request). Um cenário pode ser um serviço HTTP em desenvolvimento que entre em pânico sem retornar nenhum dado.
Veja também
-----------

* Erros de CORS (en-US)
* Glossary: CORS
* Introdução ao CORS


Reason: CORS request not HTTP - HTTP

Reason: CORS request not HTTP
=============================

Razão
-----
```

Razão: Requisição CORS não é HTTP
```

O que deu errado?
-----------------

Requisições CORS devem apenas usar o esquema de URL HTTPS, mas a URL especificada pela requisição é de um tipo diferente. Isso geralmente ocorre se a URL especifica um arquivo local, usando uma URL `file:///`.

Para consertar esse problema, apenas certifique-se que você está usando URLs HTTPS quando emitir requisições que envolvam CORS.

### Segurança de Arquivos Locais no Firefox 68

Quando um usuário abria uma página usando uma URI `file:///` no Firefox 67 ou anterior, a origem da página era definida como sendo o diretório do qual a página era aberta. Recursos existentes no mesmo diretório e nos subdiretórios eram tratados como tendo a mesma origem de acordo com a regra de mesma-origem do CORS.

Em resposta ao CVE-2019-11730, o Firefox, a partir da versão 68, define a origem da página aberta pela URI `file:///` como única. Desta maneira, outros recursos do mesmo diretório ou subdiretório não satisfazem mais à regra de mesma-origem do CORS. Este novo comportamento está habilitado por padrão pela preferência de nome `privacy.file_unique_origin`.

Veja também
-----------

* CORS errors (en-US)
* Glossário: CORS
* CORS introduction
* What is a URL? (en-US)


Identificando recursos na web - HTTP

Identificando recursos na web
=============================

O alvo de uma requisição HTTP é chamada de "resource", ou recurso em português, com a natureza ainda não definida; Isso pode ser um documento, uma foto ou qualquer outra coisa. Cada recurso é identificado por uma Identificação de recursos uniforme, do inglês **Uniform Resource Identifier** (URI) usada pelo HTTP para identificar recursos.

A identidade e a localização de recursos na Web são fornecidas, principalmente por um único URL (Uniform Resource Locator, um tipo de URI). Pode ser que as vezes as a identidade e a localização não são dadas pelo mesmo URI: O HTTP usa um cabeçalho HTTP específico, `Alt-Svc` quando o recurso solicitado quer que o cliente acesse-o de outra localização

URLs e URNs
-----------

### URLs

A forma mais comum de URL é o Uniform Resource Locator (URL) , que é conhecido como endereço de Web.
```

https://developer.mozilla.org
https://developer.mozilla.org/pt-BR/docs/Learn/
https://developer.mozilla.org/pt-BR/search?q=URL
```

Qualquer um desses URLs podem ser digitado na barra de endereços do seu navegador dizendo para carregar a página associada (recurso).

Uma URL é composta por diferentes partes, algumas são estritamente necessárias e outras são opcionais. Um exemplo mais complexo seria algo como isso:
```

http://www.exemplo.com:80/pasta/para/meu-arquivo.html?chave1=valor1&chave2=valor2#AlgumaCoisaNoDocumento
```

### URNs

Um Nome de Recurso Uniforme do inglês Uniform Resource Name (URN) é uma URI que identifica um recurso pelo nome em um namespace particular.
```

urn:isbn:9780141036144
urn:ietf:rfc:7230
```

As duas URNs correspondem

* o livro Nineteen Eighty-Four por George Orwell,
* a especificação 720 da IETF, Hypertext Transfer Protocol (HTTP/1.1): Sintaxe de mensagem e rotas.
Sintaxe daUniform Resource Identifiers (URIs)
---------------------------------------------

### Esquema ou protocolo

![Protocol](/pt-BR/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-protocol@x2.png)

`http://` é o protocolo. Ele indica qual é o protocolo que o navegador irá usar. Usualmente o protocolo é o HTTP, ou sua versão segura, HTTPS. A Web requer um desses dois, mas os navegadores tambem sabem como lidar com outros protocolos como o `mailto:` (para abrir um cliente de email) ou o `ftp:` para fazer uma transferêcia de arquivo, então não fique surpreso se ver alguns desses protocolos. Esquemas comuns são:

| Esquema | Descrição |
| --- | --- |
| data | URI de dados (en-US) |
| file | Nomes de arquivos específicos do host |
| ftp | Protocolo de transferência de arquivo (en-US) |
| http/https | Hyper text transfer protocol (Secure) |
| mailto | Endereço de correio eletrônico (e-mail) |
| ssh | Secure shell |
| tel | telefone |
| urn | Uniform Resource Names |
| view-source | Código fonte de um recurso |
| ws/wss | Conecções de WebSocket (Encriptadas) |

### Autoridade

![Domaine Name](/pt-BR/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-domain@x2.png)

`www.example.com` é o nome de domínio ou autoridade que governa o namespace. Ele indica qual servidor web será solicitado. Alternativamente, é possível utilizar um IP address, mas isso pode ser menos conveniente e não é muito utilizado na Web.

### Porta

![Port](/pt-BR/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-port@x2.png)

`:80` é a porta nesta instância . Ela indica qual é o "portão" técnico usado para acessar os recursos no servidor web. Usualmente ela é omitida se o servidor web utiliza a porta padrão do protocolo HTTP (80 para HTTP e 443 para HTTPS) para garantir o acesso aos recursos. Do contrário, ela se torna obrigatória.

### Caminhos

![Path to the file](/pt-BR/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-path@x2.png)

`/path/to/myfile.html` é o caminho para o recurso no servidor Web. Nos primeiros dias da Web, um caminho era representado pelo caminho físico correspondente no servidor web. Hoje em dia isso é mais uma abstração tratada pelos servidores Web não sendo necessariamente o endereço físico do arquivo em questão.

### Query / Parâmetros

![Parameters](/pt-BR/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-parameters@x2.png)

`?key1=value1&key2=value2` são parâmetros extras fornecidos ao servidor Web. Eles são uma lista de pares chaves/valores separados com o símbolo `&` O servidor web pode usar esses parametros para fazer coisas extras depois retornando o recurso para o usuário. Cada servidor web tem suas regras em relação aos parâmetros, e o unico jeito confiável de saber como um servidor Web especifico trata os parâmetros é perguntando o dono do servidor.

### Fragmentos

![Anchor](/pt-BR/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-anchor@x2.png)

`#SomewhereInTheDocument` é uma âncora para outra parte do próprio recurso. Uma âncora representa uma espécie de "marcador" dentro do recurso, dando ao navegador as instruções para mostrar o conteúdo localizado naquele ponto "marcado". Em um documento HTML, por exemplo, o navegador erá dar scroll para a ancora em um ponto definido; em um vídeo ou audio, o navegor erá tentar ir para o tempo que a âncora representa. Vale ressaltar que a parte após o #, também conhecido como identificador de fragmento, nunca é enviado ao servidor com o pedido.

Notas de uso
------------

Ao usar URLs em conteúdo HTML em geral se deve usar apenas alguns desses esquemas URL. Apenas os esquemas HTTP e HTTPS devem ser usados quando se faz referência a subrecursos — isto é, arquivos carregados como parte de um documento maior. Por razões de segurança, os navegadores estão reduzindo cada vez mais o suporte a FTP para o carregamento de subrecursos.

FTP ainda é aceito em alguns casos específicos de acesso direto, como quando a URL é digitada diretamente na barra do navegador ou como o alvo em um link, ainda que alguns navegadores possam delegar o carregamento do conteúdo FTP para outra aplicação.

Exemplos
--------
```

https://developer.mozilla.org/pt-BR/docs/Learn
tel:+1-816-555-1212
git@github.com:mdn/browser-compat-data.git
ftp://example.org/resource.txt
urn:isbn:9780141036144
```

Especificações
--------------

| Specification | Title |
| --- | --- |
| RFC 7230, sessão 2.7: Uniform Resource Identifiers | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

Veja também
-----------

* O que é uma URL? (en-US)
* Lista de esquemas URI IANA


MIME types - HTTP

MIME types
==========

O **MIME type** é o mecanismo para dizer ao cliente a variedade de documentos transmitidos: a extensão de um nome de arquivo não tem significado na web. Portanto, é importante que o servidor esteja configurado corretamente, de modo que o *MIME-type* correto seja transmitido com cada documento. Os navegadores costumam usar o *MIME-type* para determinar qual ação usar como padrão para fazer quando um recurso é obtido.

Existem muitos tipos de documentos, por isso há muitos *MIME-types*. Neste artigo, listaremos os mais importantes para o desenvolvimento da Web, mas você pode encontrá-los para os tipos de documento aplicáveis neste artigo dedicado: Lista completa de *MIME types* (en-US)*.*

*MIME types* não são a única maneira de transmitir as informações do tipo de documento:

* Os sufixos de nome são usados às vezes, especialmente em sistemas Microsoft Windows. Nem todos os sistemas operacionais consideram esses sufixos significativos (especialmente Linux e Mac OS), e como um tipo MIME externo, não há garantia de que eles estejam corretos.
* Números mágicos. A sintaxe dos diferentes tipos de arquivos permite a inferência de tipo de arquivo, olhando para a estrutura. Por exemplo. Cada arquivo GIF começa com o valor hexadecimal 47 49 46 38 [GIF89] ou arquivos PNG com 89 50 4E 47 [.PNG]. Nem todos os tipos de arquivos têm números mágicos, portanto este não é um sistema 100% confiável.

Na Web, apenas o *MIME type* é relevante e deve ser definido com cuidado. Navegadores e servidores usavam frequentemente heurísticas baseadas em sufixos ou números mágicos para definir o tipo MIME, verificar a coerência ou encontrar o tipo MIME correto quando apenas um tipo genérico foi fornecido.

Sintaxe
-------

### Estrutura geral
```

tipo/subtipo
```

A estrutura de um *MIME type* é muito simples; Consiste de um tipo e um subtipo, duas strings, separados por um '/'. Nenhum espaço é permitido. O tipo representa a categoria e pode ser um tipo *discreto* ou *multipart*. O subtipo é específico para cada tipo.

Um *MIME type* é case-insensitive mas tradicionalmente é escrito tudo em minúsculas.

### Tipos discretos
```

text/plain
text/html
image/jpeg
image/png
audio/mpeg
audio/ogg
audio/*
video/mp4
application/octet-stream
…
```

Tipos *discretos* indicam a categoria do documento, ele pode ser um dos seguintes:

| Tipo | Descrição | Exemplos de subtipos típicos |
| --- | --- | --- |
| `text` | Representa qualquer documento que contenha texto e é teoricamente legivel para o ser humano. | `text/plain`, `text/html`, `text/css, text/javascript` |
| `image` | Representa qualquer tipo de imagens. Os vídeos não estão incluídos, embora imagens animadas (como gif animado) sejam descritas com um tipo de imagem. | `image/gif`, `image/png`, `image/jpeg`, `image/bmp`, `image/webp` |
| `audio` | Representa qualquer tipo de arquivo de audio | `audio/midi`, `audio/mpeg, audio/webm, audio/ogg, audio/wav` |
| `video` | Representa qualquer tipo de arquivo de video | `video/webm`, `video/ogg` |
| `application` | Representa qualquer tipo de dados binários. | `application/octet-stream`, `application/pkcs12`, `application/vnd.mspowerpoint`, `application/xhtml+xml`, `application/xml`, `application/pdf` |

Para documentos de texto sem um subtipo especifico, **`text/plain`** deverá ser usado. Assim como, para documentos binários sem subtipo especifico ou conhecido, **`application/octet-stream`** deverá ser usado.

### Tipos de multipart
```

multipart/form-data
multipart/byteranges
```

*Multipart types* indicam uma categoria de documento que são quebrados em partes distintas, muitas vezes com diferentes tipos MIME. É uma maneira de representar um documento composto. Com exceção de `multipart/form-data`, que são usados em relação de formularios HTML e metodo `POST`, e `multipart/byteranges` que são usados em conjunto com `206` `Mensagem de status de conteúdo parcial para enviar apenas um subconjunto de um documento inteiro, o HTTP não manipula documentos de várias partes de uma maneira específica: a mensagem é simplesmente transmitida ao navegador (o que provavelmente irá propor uma janela Salvar como, sem saber como exibir o documento).`

Importantes *MIME types* para desenvolvedores Web
-------------------------------------------------

### `application/octet-stream`

Este é o valor padrão para um arquivo binario. Como é um arquivo binário desconhecido, os navegadores geralmente não irá executá-lo automaticamente, ou irá perguntar se ele deve ser executado. Eles tratam-na como se o cabeçalho `Content-Disposition` fosse definido com o anexo de valor e propusessem um "Salvar como".

### `text/plain`

Este é o valor padrão para arquivos de texto. Mesmo se realmente significa arquivo textual desconhecido, os navegadores assumem que eles podem exibi-lo.

**Nota:** Note que `text/plain` não significa qualquer tipo de dados textuais. Se eles esperam um tipo específico de dados textuais, eles provavelmente não consideram uma correspondência. Especificamente se eles baixarem um arquivo `text/plain` de um elemento `<link>` declarando arquivos CSS, eles não o reconhecerão como arquivos CSS válidos se forem apresentados com `text/plain`.
 O CSS mime tipo `text/css` deve ser usado.

### `text/css`

 Quaisquer arquivos CSS que têm de ser interpretados como tal em uma página da Web devem ser dos arquivos de `text/css`. Muitas vezes os servidores não reconhecem arquivos com o sufixo .css como arquivos CSS, em vez disso, enviam-nos com o tipo MIME de `text/plain` ou `application/octet-stream`: nesses casos, eles não serão reconhecidos como arquivos CSS pela maioria dos navegadores e serão silenciosamente ignorados.
 Atenção especial tem de ser paga para servir arquivos CSS com o tipo correto.

### `text/html`

Todo o conteúdo HTML deve ser exibido com este tipo. Tipos MIME alternativos para XHTML (como `application/xml+html)` são em sua maioria inúteis hoje em dia (HTML5 unificou esses formatos).

### Images types

Apenas um punhado de tipos de imagem são amplamente reconhecidos e são considerados seguros na Web, prontos para uso em uma página da Web:

| MIME type | Image type |
| --- | --- |
| `image/gif` | GIF images (Compressão sem perdas, substituído por PNG) |
| `image/jpeg` | JPEG images |
| `image/png` | PNG images |
| `image/svg+xml` | SVG images (vector images) |

Há uma discussão para adicionar WebP (image / webp) a esta lista, mas como cada novo tipo de imagem irá aumentar o tamanho de um codebase, isso pode introduzir novos problemas de segurança, então os fornecedores de navegador são cautelosos em aceitá-lo.

 Outros tipos de imagens podem ser encontrados em documentos da Web. Por exemplo, muitos navegadores suportam tipos de imagem de ícones para favicons ou similares.
 Em particular, as imagens do ICO são suportadas neste contexto com o tipo MIME `image/x-icon`.

### Audio and video types

Como as imagens, o HTML não define um conjunto de tipos suportados para usar com os elementos `<audio>` e `<video>` , de modo que apenas um grupo relativamente pequeno deles pode ser Usado na Web. Os formatos de mídia suportados pelos elementos de áudio e vídeo em HTML (en-US) explicam os codecs e formatos de contêiner que podem ser usados.

O tipo MIME de tais arquivos principalmente representam os formatos de contêiner e os mais comuns em um contexto da Web são:

| MIME type | Audio or video type |
| --- | --- |
| `audio/wave` `audio/wav` `audio/x-wav` `audio/x-pn-wav` | Um arquivo de áudio no formato de recipiente WAVE. O codec de áudio PCM (WAVE codec "1") é freqüentemente suportado, mas outros codecs têm suporte mais limitado (se houver). |
| `audio/webm` | Um arquivo de áudio no formato de contêiner WebM. Vorbis e Opus são os codecs de áudio mais comuns. |
| `video/webm` | Um arquivo de vídeo, possivelmente com áudio, no formato de contêiner WebM. VP8 e VP9 são os codecs video os mais comuns usados dentro dele; Vorbis e Opus os codecs de áudio mais comuns. |
| `audio/ogg` | Um arquivo de áudio no formato de contêiner OGG. Vorbis é o codec de áudio mais comum usado em tal recipiente. |
| `video/ogg` | Um arquivo de vídeo, possivelmente com áudio, no formato de contêiner OGG. Theora é o codec video usual usado dentro dele; Vorbis é o codec de áudio usual. |
| `application/ogg` | Um arquivo de áudio ou vídeo usando o formato de contêiner OGG. Theora é o codec video usual usado dentro dele; Vorbis é o codec de áudio usual. |

### `multipart/form-data`

O tipo `multipart/form-data` pode ser usado ao enviar o conteúdo de um formulario HTML preenchido do navegador para o servidor. Como um documento multipart formal, consiste em partes diferentes, delimitado por um limite (uma seqüência de caracteres começando com um traço duplo '--'). Cada parte é uma entidade por si só, com seus próprios cabeçalhos HTTP, `Content-Disposition`, e `Content-Type` Para os campos de upload de arquivos, e os mais comuns (`Content-Length` É ignorada como a linha de limite é usada como o delimitador).
```

Content-Type: multipart/form-data; boundary=aBoundaryString
(Outros cabeçalhos associados ao documento em várias partes como um todo)

--aBoundaryString
Content-Disposition: form-data; name="myFile"; filename="img.jpg"
Content-Type: image/jpeg

(dados)
--aBoundaryString
Content-Disposition: form-data; name="myField"

(dados)
--aBoundaryString
(mais subpartes)
--aBoundaryString--
```

O seguinte formulario:

```html
<form action="http://localhost:8000/" method="post" enctype="multipart/form-data">
  <input type="text" name="myTextField">
  <input type="checkbox" name="myCheckBox">Check</input>
  <input type="file" name="myFile">
  <button>Send the file</button>
</form>
```

Enviará esta mensagem:
```

POST / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
Content-Length: 465

-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myTextField"

Test
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myCheckBox"

on
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myFile"; filename="test.txt"
Content-Type: text/plain

Simple file.
-----------------------------8721656041911415653955004498--
```

### `multipart/byteranges`

O tipo MIME `multipart/byteranges` é usado no contexto de enviar respostas parciais para o navegador. Quando o código de status de conteúdo parcial `206` é enviado, este tipo MIME é usado para indicar que o documento é composto de várias partes, uma para cada um do intervalo solicitado. Como outros tipos de multipart, o `Content-Type` usa a diretiva de limite para definir a seqüência de limites. Cada uma das diferentes partes tem um cabeçalho `Content-Type` com o tipo real do documento e um `Content-Range` com o intervalo que representam.
```

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 385

--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 100-200/1270

eta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="vieport" content
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 300-400/1270

-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: "Open Sans", "Helvetica
--3d6b6a416f9b5--
```

Importância de definir o `MIME type` correto
--------------------------------------------

A maioria dos servidores web envia recursos de tipo desconhecido usando o tipo MIME de application/octet-stream padrão. Por razões de segurança, a maioria dos navegadores não permite definir uma ação padrão personalizada para esses recursos, forçando o usuário a armazená-lo no disco para usá-lo. Algumas configurações de servidor incorretamente exibidas ocorrem com os seguintes tipos de arquivo:

* Arquivos RAR-codificados. Neste caso, o ideal seria definir o verdadeiro tipo de arquivos codificados; Isso muitas vezes não é possível (como pode não ser conhecido para o servidor e esses arquivos podem conter vários recursos de tipos diferentes). Nesse caso, configure o servidor para enviar o tipo MIME `application/x-rar-compressed`.
* Arquivos de áudio e vídeo. Somente recursos com o Tipo MIME correto serão reconhecidos e reproduzidos em elementos `<video>` ou `<áudio>`. Certifique-se de usar o tipo correto para áudio e vídeo.
* Tipos de arquivos proprietários. Preste especial atenção ao servir um tipo de arquivo proprietário. Evite usar o `application/octet-stream` como manipulação especial não será possível: a maioria dos navegadores não permitem definir um comportamento padrão (como "Abertura no Word") para este tipo MIME genérico.
MIME sniffing
-------------

 Na ausência de um tipo MIME, ou em alguns outros casos em que um cliente acredita que estão incorrectamente definidos, os navegadores podem conduzir MIME sniffing, que está adivinhando o tipo MIME correto, olhando para o recurso. Cada navegador executa isso de forma diferente e em circunstâncias diferentes. Existem algumas preocupações de segurança com esta prática,
 Como alguns tipos MIME representam conteúdo executável e outros não. Os servidores podem bloquear MIME sniffing enviando o `X-Content-Type-Options` ao longo do `Content-Type`.

See also
--------

* Properly configuring server MIME types (en-US)
* Media formats supported by the HTML audio and video elements (en-US)


Lista Incompleta de tipos MIME - HTTP

Lista Incompleta de tipos MIME
==============================

Abaixo uma lista de tipos de MIME, associadas por tipos de documentos, ordenados por suas extensões comuns.

Há dois tipo MIME que são importantes para tipos padrões:

* `text/plain` é o tipo padrão para arquivos de texto. Um arquivo de texto deve ser legível para um ser humano, e não deve conter dados binários.
* `application/octet-stream` É um tipo padrão para todos outros casos. Um tipo de arquivo desconhecido deveria usar este tipo. Navegadores tomarão mais cuidado ao manipular esses arquivos, tentando proteger o usuário e prevenir comportamentos perigosos.

IANA é o registrador official de tipos de mídia MIME e mantém uma lista de todos tipos oficiais de MIME. Esta tabela lista alguns tipos de MIME importantes para a Web.

| Extensão | Tipo do documento | Tipo MIME |
| --- | --- | --- |
| `.aac` | Arquivo de audio AAC | `audio/aac` |
| `.abw` | Documento AbiWord | `application/x-abiword` |
| `.arc` | Archive document (multiple files embedded) | `application/octet-stream` |
| `.avi` | Arquivo de audio e vídeo Intercalar AVI | `video/x-msvideo` |
| `.azw` | Formato eBook do Amazon Kindle | `application/vnd.amazon.ebook` |
| `.bin` | Qualquer tipo de dados binários | `application/octet-stream` |
| `.bz` | Arquivo compactado BZip | `application/x-bzip` |
| `.bz2` | Arquivo compactado BZip2 | `application/x-bzip2` |
| `.csh` | C-Shell script | `application/x-csh` |
| `.css` | Cascading Style Sheets (CSS) | `text/css` |
| `.csv` | Comma-separated values (CSV) | `text/csv` |
| `.doc` | Microsoft Word | `application/msword` |
| `.eot` | MS Embedded OpenType fonts | `application/vnd.ms-fontobject` |
| `.epub` | Electronic publication (EPUB) | `application/epub+zip` |
| `.gif` | Graphics Interchange Format (GIF) | `image/gif` |
| `.htm .html` | HyperText Markup Language (HTML) | `text/html` |
| `.ico` | Icon format | `image/x-icon` |
| `.ics` | iCalendar format | `text/calendar` |
| `.jar` | Java Archive (JAR) | `application/java-archive` |
| `.jpeg` `.jpg` | JPEG images | `image/jpeg` |
| `.js` | JavaScript (ECMAScript) | `application/javascript` |
| `.json` | JSON format | `application/json` |
| `.mid` `.midi` | Musical Instrument Digital Interface (MIDI) | `audio/midi` |
| `.mpeg` | MPEG Video | `video/mpeg` |
| `.mpkg` | Apple Installer Package | `application/vnd.apple.installer+xml` |
| `.odp` | OpenDocument presentation document | `application/vnd.oasis.opendocument.presentation` |
| `.ods` | OpenDocument spreadsheet document | `application/vnd.oasis.opendocument.spreadsheet` |
| `.odt` | OpenDocument text document | `application/vnd.oasis.opendocument.text` |
| `.oga` | OGG audio | `audio/ogg` |
| `.ogv` | OGG video | `video/ogg` |
| `.ogx` | OGG | `application/ogg` |
| `.otf` | OpenType font | `font/otf` |
| `.png` | Portable Network Graphics | `image/png` |
| `.pdf` | Adobe Portable Document Format (PDF) | `application/pdf` |
| `.ppt` | Microsoft PowerPoint | `application/vnd.ms-powerpoint` |
| `.rar` | RAR archive | `application/x-rar-compressed` |
| `.rtf` | Rich Text Format (RTF) | `application/rtf` |
| `.sh` | Bourne shell script | `application/x-sh` |
| `.svg` | Scalable Vector Graphics (SVG) | `image/svg+xml` |
| `.swf` | Small web format (SWF) or Adobe Flash document | `application/x-shockwave-flash` |
| `.tar` | Tape Archive (TAR) | `application/x-tar` |
| `.tif .tiff` | Tagged Image File Format (TIFF) | `image/tiff` |
| `.ts` | Typescript file | `application/typescript` |
| `.ttf` | TrueType Font | `font/ttf` |
| `.vsd` | Microsoft Visio | `application/vnd.visio` |
| `.wav` | Waveform Audio Format | `audio/x-wav` |
| `.weba` | WEBM audio | `audio/webm` |
| `.webm` | WEBM video | `video/webm` |
| `.webp` | WEBP image | `image/webp` |
| `.woff` | Web Open Font Format (WOFF) | `font/woff` |
| `.woff2` | Web Open Font Format (WOFF) | `font/woff2` |
| `.xhtml` | XHTML | `application/xhtml+xml` |
| `.xls .xlsx` | Microsoft Excel | `application/vnd.ms-excel application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` |
| `.xml` | `XML` | `application/xml` |
| `.xul` | XUL | application/vnd.mozilla.xul+xml |
| `.zip` | ZIP archive | `application/zip` |
| `.3gp` | 3GPP audio/video container | `video/3gpp` `audio/3gpp` if it doesn't contain video |
| `.3g2` | 3GPP2 audio/video container | `video/3gpp2` `audio/3gpp2` if it doesn't contain video |
| `.7z` | 7-zip archive | `application/x-7z-compressed` |


Formatos de mídia suportados por elementos HTML de áudio e vídeo
================================================================

Os elementos `<audio>` e `<video>` fornecem suporte para a reprodução de mídias de áudio e vídeo sem necessitar de plug-ins. Codecs de áudio e vídeo são usados para manipular arquivos de áudio e vídeo, diferentes codecs oferecem diferentes níveis de compressão e qualidade. Um formato do repositório é usado para armazenar e transmitir o codec de áudio e vídeo ( ambos juntos, no caso de um vídeo com tilha sonora). Existem muitas combinações de codecs e formatos de containers, embora apenas alguns são relevantes para a internet.

Diferentes navegadores não dão suporte para os mesmos formatos de mídias em suas implementações de áudio e vídeo no HTML5, principalmente por causa de questões de patentes. A área de formatos de mídias na internet tem sofrido muito com leis de patentes em muitos países, incluindo os Estados Unidos e países da União Européia (as notas sobre patentes nesse artigo são fornecidas como estão e sem garantias). Este artigo discute a diferença de codecs e combinações de containers relevantes para a internet, incluindo suporte de navegadores em computadores ou outros tipos de dispositivos.

Para exibir um vídeo usando HTML5, que funcione nas últimas versões dos principais navegadores, você pode disponibilizar seu vídeo em dois formatos: WebM e MPEG H.264 AAC, usando o elemento `<source>` desta forma:

```html
<video controls>
  <source src="somevideo.webm" type="video/webm" />
  <source src="somevideo.mp4" type="video/mp4" />
  Desculpe; seu navegador não suporta vídeos HTML5 em WebM com VP8 ou MP4 com
  H.264.
  <!-- Você pode embutir um Flash player aqui, para exibir seu vídeo mp4 em navegadores antigos -->
</video>
```

WebM
----

O formato WebM é baseado em uma versão restrita do container Matroska. Ele sempre usa o codec de vídeo VP8 ou VP9 e o codec de áudio Vorbis ou Opus. WebM tem suporte nativo em navegadores de desktop e dispositivos móveis como Gecko (Firefox), Chrome e Opera, e o suporte para esse formato pode ser adicionado no Internet Explorer e Safari (mas não no iOS) por meio de um plug-in.

Declaração da Microsoft sobre o porquê o IE9 não possui suporte nativo para o WebM.

O formato WebM, especificamente o codec de vídeo VP8, tinha sido acusado de violar patentes por um grupo de empresas respondendo um chamado da MPEG LA para a formação de um conjunto de patentes, mas a MPEG LA concordou em licenciar estas patentes para a Google sob uma "licença perpétua intransferível, livre de direitos autorais". Isto significa, efetivamente, que todas a patentes conhecidas do formato WebM são licenciadas para todos de graça.

Gecko reconhece os seguintes tipos de arquivos WebM:

`video/webm`

Um arquivo de mídia WebM contendo vídeo (e possivelmente áudio também).

`audio/webm`

Um arquivo de mídia WebM contendo apenas áudio.

Ogg Theora Vorbis
-----------------

O formato de container Ogg com o codec de vídeo Theora e o codec de áudio Vorbis é suportados em desktops e dispositivos móveis Gecko (Firefox), Chrome, Opera e o suporte para esses formatos pode ser adicionado ao Safari (exceto iOS) instalando um plug-in. O Internet Explorer não possui suporte para esse formato.

WebM é geralmente mais utilizado que Ogg Theora Vorbis quando disponível, por que ele possui uma melhor qualidade de compressão e tem suporte na maioria dos navegadores. O formato Ogg, contudo, pode ser usado para navegadores mais antigos (por exemplo o Firefox 3.5/3.6 não tem suporte WebM, mas suporta Ogg).

A situação de patente do Theora é similar com a da WebM.

Você pode ler mais sobre criar méidia com Ogg lendo o Theora Cookbook.

Grecko reconhece os seguintes tipos MIME como arquivos Ogg:

`audio/ogg`

Um arquivo Ogg que contem apensa áudio

`video/ogg`

Um arquivo Ogg que contem vídeo (e possivelmente áudio)

`application/ogg`

Um arquivo Ogg com conteúdo não especificado. Usando um dos dois tipos de MIME, mas você pode usar ele se você não sabe qual é o conteúdo do arquivo.

Ogg Opus
--------

O container Ogg pode também conter um áudio codificado usando o codec Opus. Suporte para ele está disponível no Gecko 15.0 e versões superiores, em navegadores no desktop e dispositivos móveis.

Ogg FLAC
--------

O contêiner Ogg pode também conter um áudio codificado usando o codec FLAC. Suporte para ele está disponível no Gecko 51.0 e versões superiores, somente no desktop.

MP4 H.264 (AAC ou MP3)
----------------------

O formato MP4 com o codec de vídeo H.264 e codec de áudio AAC tem suporte nativo para Internet Explorer, Safari e Chrome no desktop e dispositivos móveis, o Opera não possui suporte para este formato. IE e Chrome também possuem suporte para codec de áudio MP3 no container MP4, mas o Safari não tem suporte para isso. Firefox/Firefox para hardware do dispositivo pode manipular o perfil utilizado para codificar o MP4.

**Nota:** Codificação MP4 com um perfil elevado não será executado em um hardware inferior, como o Firefox OS.

O formato de mídia MPEG é coberto por patentes, do qual não é livremente licenciado. Todas as licenças necessárias podem ser compradas da MPEG LA. Desde H.264 o formato não é livre de direitos autorais, é impróprio para a internet aberta, de acordo com a Mozilla [1, 2], Google [1, 2] e Opera. Contudo, desde que os formatos de direitos livres não são suportados pelo Internet Explorer e Safari, a Mozilla decidiu dar suporte para o formato, e a Google nunca cumpriu sua promessa de remover o suporte para o Chrome.

MP3
---

O formato de áudio MP3(.mp3 audio/mpeg; diferente do áudio MP3 no MP4 container acima) é suportado na tag <audio> no Firefox/Firefox para Android/Firefox OS quando o sistema operacional fornece um decodificador MP3, para Internet Explorer, Chrome e Safari.

WAVE PCM
--------

O formato WAVE, com o codec de áudio PCM (codec WAVE "1") tem suporte nos navegadores Gecko(Firefox) e Safari no desktop e dispositivos móveis. Arquivos com o formato WAVE tipicamente tem a extensão ".wav".

**Nota:** **Nota: Veja** RFC 2361 para ver registros do codec WAVE

Gecko reconhece os seguintes tipos MIME em arquivos de áudio WAVE:

* `audio/wave` (preferido; não funciona no Chrome)
* `audio/wav`
* `audio/x-wav`
* `audio/x-pn-wav`
Media Source Extensions (MSE)
-----------------------------

Origem da extesão de mídia é um projeto de trabalho da W3C que planeja ampliar `HTMLMediaElement` (en-US) para permitir que o JavaScript gere fluxo de mídia para reprodução. Permitindo que o JavaScript gere fluxos facilita uma variedade de uso, como o fluxo adaptado e o tempo de mudança de transmissão ao vivo. Isto é atualmente um suporte experimental no Firefox desktop, e em outros navegadores também.

Por exemplo, você pode implementar MPEG-DASH usando JavaScript durante carregamento da decodificação para MSE.

**Nota:** Time Shifting é o processo de consumo de uma transmissão ao vivo, algum tempo após ter acontecido.

Veja também
-----------

* Using audio and video in Firefox
* HTML media support in Firefox
* Media elements (HTML 5 specification)
* `video`
* `audio`


ARIA - Acessibilidade

ARIA
====

Aplicações para a Internet Ricas em Acessibilidade - Accessible Rich Internet Applications (ARIA) definem as formas de tornar o conteúdo e as aplicações da Rede Mundial - *Web* - (especialmente aqueles desenvolvidos com Ajax e JavaScript) mais acessíveis às pessoas com deficiência.

Por exemplo, a ARIA permite a marcação de regiões importantes na página (como uma caixa de busca, um cabeçalho, chamadas "pontos de referência") para facilitar a navegação (agilizam a utilização de leitores de tela, por exemplo), JavaScript para *widgets*, sugestões de preenchimento de formulário e mensagens de erro, atualizações de conteúdo em tempo real e muito mais.

O ARIA é um conjunto de atributos especiais para a acessibilidade, que pode ser adicionado a qualquer linguagem marcação, mas é especialmente adequado para HTML. O atributo da função define qual é o modelo de objeto (tais como um artigo, um alerta, ou algo que deslize). Há atributos adicionais ARIA que fornecem outras propriedades úteis, como a descrição de uma forma, ou o valor atual em uma barra de progresso.

O conjunto ARIA pode ser implementado nos navegadores mais populares e em leitores de tela. No entanto, as implementações variam e as tecnologias mais antigas não as suportam bem. Utilize um ARIA compatível, ou solicite a alguém que o atualize para as tecnologias mais recentes.

**Nota:** Por favor, participe e torne o ARIA melhor para as pessoas! Não tem muito tempo? Envie sugestões para acessibilidade - lista de correspondência da Mozilla, ou #*accessibility* canal IRC*.*

### Começando em ARIA

Apresentando ARIA (en-US)

Uma rápida introdução sobre como tornar um conteúdo dinâmico acessível com ARIA: Veja, também, o clássico ARIA intro by Gez Lemon, de 2008.

Aplicações *Web* e ARIA FAQ (en-US)

Respostas às perguntas frequentes sobre WAI-ARIA e sobre por que é necessário tornar as aplicações *web* acessíveis.

Vídeos de Leitores de Tela Utilizando ARIA

Veja exemplos reais e simplificados de vídeos, por toda a *web*, que incluem o "antes" e o "depois" da acessibilidade.

Usando ARIA com HTML

Um guia prático para desenvolvedores. Traz sugestões sobre quais atributos ARIA usar com os elementos HTML. As sugestões são baseadas em realidades implementadas.

### Melhorias Simples ARIA

Melhorando a Navegação nas Páginas com os Pontos de Referência ARIA

Uma deliciosa introdução à utilização de pontos de referência para beneficiar a navegação pelas páginas da internete por quem utiliza os leitores de tela ARIA. Veja, também, as notas da implementação de pontos de referência ARIA e exemplos de situações reais (atualizadas a partir de 11 de julho).

Melhorando a Acessibilidade nos Formulários (en-US)

O conjunto ARIA não é, apenas, para conteúdo dinâmico! Aprenda como aperfeiçoar a acessibilidade nos formulários HTML utilizando alguns atributos adicionais ARIA.

Regiões dinâmicas (trabalho em progresso) (en-US)

As regiões dinâmicas oferecem sugestões, aos leitores de tela, sobre como controlar as alterações nos conteúdos das páginas.

Utilizando a ARIA Regiões Dinâmicas para Apresentar as Alterações no Conteúdo

Um resumo sobre as regiões dinâmicas, pelos criadores do programa de leitura de tela JAWS. Note que as regiões dinâmicas também são suportadas pela NVDA, no Firefox e VoiceOver, com Safari.

### ARIA para *Widgets* Roteirizados

Navegação pelo Teclado e Foco para *Widgets* em JavaScript (en-US)

A primeira etapa do desenvolvimento de um *widget* acessível com JavaScript é tornà-lo navegável através do teclado. Este artigo descreve as fases dessa operação. O artigo Yahoo! Administrando focos também é de grande ajuda.

Guia de Estilo para Navegação através do Teclado

Um desafio em ARIA é conseguir que os desenvolvedores executem procedimentos estáveis - claramente melhores para quem os utiliza. Este guia de estilos descreve a interface de teclado para os *widgets* comuns.

### Recursos ARIA

A Técnica na Execução de *Widgets*, Tutoriais e Exemplos (en-US)

Precisa de um controle dezlizante, um menu, ou algum outro tipo de *widget*? Encontre, aqui, as maneiras de obtê-los.

Bibliotecas JavaScript UI com ARIA habilitada

Se você está começando um projeto novo, escolha uma biblioteca UI para *widget* com suporte a ARIA já embutido. Atenção: isto é de 2009 — este conteúdo deve ser movido para uma página MDN, onde pode ser atualizado.

Acessibilidade em HTML5 e Aplicações Ricas - Materiais de Oficina CSUN 2012

Inclua apresentações de eslaides e exemplos.

### Lista de Correspondência

ARIA Livre no Grupo Google

Área de perguntas sobre ARIA, bem como de fazer sugestões para melhorar a documentação ARIA encontrada nestas páginas.

### Blogs

As informações ARIA nos blogues tendem a ficar desatualizadas rapidamente. Sem contar que há outras boas informações fora deles, de desenvolvedores que estão tornando o conjunto Aria funcional hoje.

Paciello Group

Cultura Acessível

### Encontrando Erros

Erros nos arquivos ARIA em navegadores, leitores de telas e bibliotecas JavaScript.

### Exemplos

Exemplos de Bibliotecas ARIA (en-US)

Um conjunto de exemplos de arquivos das bibliotecas base, com os quais fica muito fácil aprender.

Demonstração de Biblioteca para a Accessibilidade JS em *Widget*

Dojo, jQuery, Fluid, YUI

Correio Eletrônico Yahoo!

A Yahoo! colocou tudo reunido com o Yahoo! *e-mail*, uma aplicação para a *web* que parece um aplicativo nativo. E funciona muito bem. Em uma análise do *e-mail* Yahoo! pelo leitor de tela, Marco Zehe diz: "Que o bom trabalho permaneça!".

Pesquisa Yahoo!

A Yahoo! tem feito um trabalho incrível no avanço do ARIA, aplicando suas posibilidades de forma plena e compartilhando suas técnicas. A Pesquisa Yahoo! usa uma combinação de pontos de referência ARIA, regiões dinâmicas e *widgets*.

### Esforços pela Padronização

Uma Visão Geral das Atividades WAI-ARIA na W3C

Uma visão geral oficial dos esforços de padronização da WAI-ARIA pela Iniciativa de tornar a *Web* Acessível (Web Accessibility Initiative - WAI)

Especificações WAI-ARIA

As especificações W3C são referências úteis. Note que, nesta fase, é importante testar a compatibilidade, uma vez que as implementações ainda estão inconsistentes.

Práticas Oficiais WAI-ARIA

Conforme as especificações da W3C WAI-ARIA, a excelênca nas práticas oficiais representam o futuro ideal - o dia em que todos os autores possam trabalhar em suas realizações sobre uma base ARIA consistente em navegadores e leitores de tela. A documentação W3C proporcionará a você uma visão aprofundada de ARIA.

Por enquanto, desenvolvedores *web* que implementem ARIA devem priorizar a compatibilidade. Use as melhores documentações das práticas e exemplos baseados em implementações atuais.

A Força-Tarefa da Acessibilidade Open AJAX

Os centros de pesquisa Open AJAX envolvem ferramentas de desenvolvimento, modelos de arquivos e testes automatizados para ARIA.

Em Construção: Técnicas ARIA WCAG 2.0 (en-US)

A comunidade necessita de um conjunto completo de técnicas WCAG voltadas para WAI-ARIA + HTML, a fim de que as organizações possam estar confortáveis ao proclamar que o teor de suas ARIAs habilitadas é compatível com essas técnicas WCAG. É muito importante que as regulamentações, ou políticas, sejam baseadas em WCAG.

### Tópicos Relacionados

* Accessibilidade (en-US), AJAX, JavaScript


Visão geral da acessibilidade nas aplicações web e widgets - Acessibilidade

Visão geral da acessibilidade nas aplicações web e 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.*

```html
<!-- 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](/pt-BR/docs/Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets/tabs_widget.png)

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:*

```html
<!-- 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) :

`aria-checked` (marcada)

indica o estado de uma caixa de seleção, ou de um botão de alternativa (`radio`)

`aria-disabled` (desativado)

indica que um elemento está visível, mas não pode ser editado, tampouco é executável.

`aria-grabbed` (arrastado)

indica o estado "arrastado" para um objeto, em uma operação de "arrastar e soltar".

(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 elemento*s 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.*

```html
<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>
  ...
</ul>
```

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.*

```css
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*.

```js
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.*

```html
<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.*

```css
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.*

```js
var showTip = function (el) {
  el.setAttribute("aria-hidden", "false");
};
```

### Mudança de Atributo (*Role*)

**Nota:** 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, à `<ul>` deve ser dada uma **`role`** de `menubar` e cada `<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*" `<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 `<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 `<div>`, ou `<span>` com uma **`role`** de `button` e o modo « *edit* » utilizando um elemento texto `<input>`.

### Mudanças assíncronas de conteúdo

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

Navegação pelo Teclado
----------------------

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*:

* A tecla TAB deve fornecer o foco para o *widget*, como um todo. Por exemplo, a tabulação em uma barra de menu deve ter seu foco em seu primeiro elemento.
* As teclas de setas devem permitir uma seleção, ou a navegação dentro do *widget*. Por exemplo, as setas "*esquerda*" e "*direita*" devem levar o foco para o item anterior, ou próximo, do menu.
* Quando o widget não estiver dentro de um formulário, as teclas "*Entra*" e "*barra de espaço*" devem selecionar, ou ativar o controle.
* Dentro de um formulário, a tecla "barra de spaço" deve selecionar, ou ativar um controle, enquanto a tecla "Entra" deve submeter sua ação padrão.
* Se houver dúvidas, copie o comportamento das ações padronizadas para ambiente nos controles que você estiver criando.

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
------------

* ARIA
* Web applications and ARIA FAQ
* WAI-ARIA Specification
* WAI-ARIA Best Practices
* DHTML Style Guide


Acessibilidade para plataforma móvel - Acessibilidade

Acessibilidade para plataforma móvel
====================================

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
---

* O constrate de cor **DEVE** seguir os requirementos level AA do WCAG 2.0:
    + Razão de contraste de 4.5:1 para textos normais (com menos de 18 pontos e 14 pontos em negrito.)
    + Razão de contraste de 3:1 para textos grandes (com pelo menos 18 pontos ou 14 pontos em negrito.)
* A informação transportada via cor **DEVE** ser também possível através de outros meios (textos sublinhados para links, etc.)

**Nota:** 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
------------

* Técnicas de esconder conteúdo como zero opacidade, ordem z-index e off-screen placement **NÃO DEVEM** ser exclusivas para visibilidade de manuseio.
* Tudo que não é visível na tela **DEVE** ser verdadeiramente invisível (especialme relevante para apps de páginas únicas com múltiplos *cards*):
    + **USE** o atributo `hidden` ou propriedades de estilo `visibility` ou `display.`
    + A não ser que seja extemamente inevitável, **NÃO USE** o atributo `aria-hidden.`
Foco
----

* Todos os elementos em foco **DEVEM**:
    + Estar no padrão como os links, botões, e campo de formulário que são focalizados por padrão.
    + Controles não padrões **DEVEM ter** um ARIA Role apropriado para eles, como em `button`, `link`, ou `checkbox`.
* O Foco deve ser utilizado com uma ordem lógica e consistente.
Textos Equivalentes
-------------------

* Textos equivalentes **DEVEM** ser declarados para cada elemento dentro do aplicativo que não sejam textos e aos elementos que não são estritamente presentacionais.
    + Use *alt* e *title* quando apropriado (*veja* a postagem de Steve Faulkner Using the HTML title attribute para uma boa referência.)
    + Se os atributos acima não forem aplicáveis, use os ARIA Properties apropriados, como `aria-label`, `aria-labelledby`, ou `aria-describedby`.
* Imagens de textos **DEVEM** ser evitadas.
* Todos controles de formulários **DEVEM** ter etiquetas (`<label>` elements) para melhor benefício dos leitores da tela.
Manipulação de Estado
---------------------

* Controles padrão como botões de rádio e checkboxes são manipuláveis pelo sistema operacional. No entanto, para uso customizado pode-se modificar esses estados via ARIA States como os `aria-checked`, `aria-disabled`, `aria-selected`, `aria-expanded`, e `aria-pressed`.
Orientações gerais
------------------

* O título do aplicativo **DEVE** ser fornecido.
* Cabeçalhos **NÃO DEVEM** ter sua hierarquia quebrada:

```html
<h1>Heading primeiro nível</h1>
<h2>Heading segundo nível</h2>
<h2>Outro Heading segundo nível</h2>
<h3>Heading terceiro nível</h3>
```

* ARIA Landmark Roles **DEVE** ser usado para descrever o aplicativo ou a estrutura do documento, como: `banner`, `complementary`, `contentinfo`, `main`, `navigation`, `search`.
* Eventos de toque só **DEVEM** ser ativados no evento `touchend`.
* Alvos tocáveis **DEVEM** ser largos o suficiente para o usuário interagir (veja o BBC Mobile Accessibility Guidelines para ver as *guidelines* sobre tamanhos de alvos tocáveis .)

**Nota:** 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.

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


Entendendo as Diretrizes de Acessibilidade do Conteúdo Web - Acessibilidade

Entendendo as Diretrizes de Acessibilidade do Conteúdo Web
==========================================================

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 Accessibilityfor 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.

* Perceivable: Users must be able to perceive it in some way, using one or more of their senses.
* Operable: Users must be able to control UI elements (e.g. buttons must be clickable in some way — mouse, keyboard, voice command, etc.).
* Understandable: The content must be understandable to its users.
* Robust: The content must be developed using well-adopted web standards that will work across different browsers, now and in the future.
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:

* all of WCAG 2.0 (verbatim, word-for-word)
* 17 new Success Criteria at the A / AA / AAA levels primarily addressing user needs in these areas:
    + Mobile Accessibility
    + Low Vision
    + Cognitive
* Leia mais sobre o WCAG 2.1:
    + Deque: WCAG 2.1: What is Next for Accessibility Guidelines
    + TPG: Web Content Accessibility Guidelines (WCAG) 2.1
Padrão legal
------------

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? (en-US) e particulamente o Guia de Acessibilidade e a seção de regras (en-US) fornecem mais informações relacionadas.


Usando ARIA para rótulos com campos incorporados - Multipart labels - Acessibilidade

Usando ARIA para rótulos com campos incorporados - Multipart labels
===================================================================

O problema
----------

Você tem um formulário onde existe uma pergunta simples e a resposta é mencionada na própria questão. Um exemplo clássico, que todos nós conhecemos das configurações de nossos navegadores, é a colocação "Deletar o histórico após x dias". "Apagar o histórico após" está à esquerda da caixa de texto, x é o número, por exemplo, 21 e a palavra "dias" vem depois dessa caixa, formando uma sentença de fácil compreensão.

Se você está usando um leitor de tela tem que perceber que, quando vai para esta configuração no Firefox, escuta a pergunta "Deletar o histórico depois de 21 dias?", seguida por um aviso de que você está em uma caixa de texto contendo o número 21. Isso não é legal? Você não precisa navegar ao redor para descobrir a unidade. "Dias" pode, facilmente, ser "meses", ou "anos" em muitos diálogos comuns, não havendo maneira de descobrir, a não ser com comandos para reexaminar a tela.

A solução está em um atributo ARIA chamado **aria-labelledby** (*aria-etiqueta liderada por*). Seu parâmetro é uma cadeia de caracteres (*string*) que consiste de IDs dos elementos HTML que você quer concatenar em um único nome acessível.

Tanto o atributo **aria-labelledby**, como o **aria-describedby** (*aria-descrito por*), são especificados no elemento de formulário que será rotulado, por exemplo uma <input>. Em ambas as situações, as ligações do controle da rotulagem *for/label*, que podem, também, estar presentes, serão substituídas pelo atributo **aria-labelledby**. Se você oferecer o atributo **aria-labelledby** em uma página HTML, então deve, da mesma forma, providenciar uma arquitetura de rótulo que vá, igualmente, apoiar os navegadores mais antigos, que ainda não têm suporte ARIA. Com Firefox 3, seus utilizadores cegos conseguem, automaticamente, melhor acessibilidade com o novo atributo, mas quem utiliza navegadores antigos não sofrerá abandono no escuro, desta forma.

Exemplo:

```html
<input
 aria-labelledby="labelShutdown shutdownTime shutdownUnit"
 type="checkbox" />
<span id="labelShutdown">Shut down computer after</span>
<input
 aria-labelledby="labelShutdown shutdownTime shutdownUnit"
 id="shutdownTime"
 type="text"
 value="10" />
<span id="shutdownUnit"> minutes</span>
```

Uma nota para quem usa JAWS 8
-----------------------------

O JAWS 8.0 tem a sua própria lógica para encontrar os *labels* e isso o faz, sempre, substituir a caixa de texto com o *accessibleName* que uma página HTML recebe. Quanto ao JAWS 8, **eu** ainda não encontrei uma maneira de fazê-lo aceitar o *label* do exemplo acima. Mas o NVDA e o Window-Eyes fazem isso muito bem e a Orca, no Linux, também não apresenta problemas. (Os **autores** do artigo, são: bunnybooboo, kscarfone, StephenKelly, Kritz, Fredchat, Sheppy, Aaronlev)

**Nota:** TBD: adicione mais informação de compatibilidade

Isto pode ser executado sem ARIA?
---------------------------------

O membro da comunidade Ben Millard apontou, numa publicação em um blogue, que os controles podem ser embutidos nos *labels,* como mostrado no exemplo acima, usando HTML 4, controls can be embedded in labels as shown in the above example using HTML 4, simplesmente com a incorporação da entrada (*input*) no rótulo (*label*). Agradecemos pela informação, Ben! É muito útil e deixa claro que algumas técnicas que estão disponíveis há anos escapam, às vezes, até mesmo aos gurus. Esta técnica funciona em Firefox; entretanto, isso não é verdade para muitos outros navegadores, inclusive IE. Para *labels* com controles de formulários embutidos o uso do atributo **aria-labelledby** ainda é a melhor abordagem.


Guia para implementar o leitor de tela ARIA - Acessibilidade

Guia para implementar o leitor de tela ARIA
===========================================

Regiões Ativas
--------------

Este é apenas um guia. Uma marcação de região ativa é uma área complexa que é algo aberto à interpretações. O que segue pretende prover um guia de implementação que respeita a necessidade dos desenvolvedores de leitores de tela para tentar novas coisas. A intenção é chegar a um balanço entre providenciar um guia útil em como usar o significado de marcação pretendido

### Interpretando a marcação de região ativa WAI-ARIA

1. Mudanças ativas são são dicas: Em geral marcação de região ativa é dado pelo autor como dicas, e a tecnologia assistiva pode permitir , site or even region-specific settings, assim como heurística para ajudar com mudanças ativas nas páginas que não têm dicas WAI-ARIA.
2. Opcionalmente, criar uma segunda, queue adicional se o usuário configurar um segundo canal de hardware: Se há dois canais para apresentação (i.e. text-to-speech e display Braile), então duas queues podem ser mantidas para permitir apresentação paralela. Os canais poderiam se configurados pelo usuário para apresentar regiões ativas baseada em vez ou prioridades.
3. Regiões ocupadas: Qualquer alteração numa região marcada com aria-busy="true" não deve ser adicionada à queue até que aquele atributo seja limpo.
4. Prioridade (aria-live ou a partir da vez) tem primeira precedência: itens deveriam ser adicionados à queue baseadas no seu nível de prioridade da propriedade aria-live ou inerente da vez (i.e. role="log" é prioridade por padrão). Itens assertivos são os primeiros então nível de prioridade. Alternativamente, implementações podem escolher ter uma política de limpeza mais items de prioridade, i.e. itens assertivos limpam qualquer item de prioridade da queue.
5. Tempo toma a segunda procedência: Priorizar itens com o mesmo nível de prioridade de acordo com quando o evento ocorre (eventos anteriores vêm primeiro). Itens presentes do mesmo nível de prioridade na ordem do que ocorreu primeiro.
6. Regiões atômicas (aria-atomic="true") com mudanças múltiplas não deveriam estar presentes duas vezes com o mesmo conrteúdo. Como um novo evento para uma região atômica é adicionada à queue e remove um evento anterior para a mesma região. É provavelmente desejável que tenha pelo menos um pequeno timeout antes de apresentar mudanças numa região atômica, com a finalidade de evitar apresentar a região duas vezes para duas mudançasque ocorrem rapidamente uma após a outra.
7. Inclua labels quando estiver apresntando mudanças: se a mudança ocorre em algo com um label de alguma forma semântico, fale o label. Isso é particularmente importante para mudanças em data cells, onde os headers column e row fornecem informação contextual importante.
### Ideias para Configurações e Heurística

1. Permitir uma voz diferente (em text-to-speech) ou outras características de apresentação para setar mudanças ativas seperadamente.
2. Quando não há marcação WAI-ARIA presente, automaticamente apresenta algumas mudanças a mesnos que o usuário configure todas as mudanças ativas para desligado. Por exemplo, mudanças automáticas de fala que são causadas pela própria entrada do usuário, como parte do contexto daquela entrada.
3. Permitir configurações globais para desligar a apresentação de mudanças ativas, apresentar todas as mudanças ativas, use marcação, ou seja "esperto" (use heurística).
### Detalhes para Processamento via APIs Platform Acessibility

Esperamos que o desenvolvedor do navegador irá trabalhar para fornecer implementações consistentes. A imlementação mais completa das regiões ativas atualmente está no Firefox 3. Aqui está como regiões ativas WAI-ARIA são expostas no Firefox 3.


WAI-ARIA Roles - Acessibilidade

WAI-ARIA Roles
==============

Essa página lista referências às atribuções WAI-ARIA discutidos no MDN. Para visualizar a lista completa, veja Using ARIA: Roles, States, and Properties

Utilizando a função "alerta"Esta técnica mostra como utilizar o atributo *role* alert e demonstra seu efeito em navegadores e tecnologias assistivas.


ARIA techniques - Acessibilidade

ARIA techniques
===============

O ARIA define as semânticas que podem ser aplicadas aos elementos, e são divididas em **funções** (definindo um tipo de elemento da interface do usuário) e **estados** e **propriedades** que são suportados por uma função. Os autores devem atribuir uma função ARIA e os estados e propriedades apropriados a um elemento durante seu ciclo de vida, a menos que o elemento já possua semântica ARIA apropriada (através do uso de um elemento HTML apropriado). A adição de semântica ARIA apenas expõe informações extras para a API de acessibilidade de um navegador e não afeta o DOM de uma página.

Funções
-------

### Funções de widget

* button (en-US)
* checkbox (en-US)
* gridcell (en-US)
* link
* menuitem
* menuitemcheckbox
* menuitemradio
* option
* progressbar
* radio
* scrollbar
* searchbox
* separator (when focusable)
* slider
* spinbutton
* switch (en-US)
* tab (en-US)
* tabpanel (en-US)
* textbox
* treeitem (en-US)
### Funções compostas

As técnicas abaixo descrevem cada função composta, bem como suas funções filho obrigatórias e opcionais.

* combobox
* grid (en-US) (incluindo as funções row (en-US), gridcell (en-US), rowheader, columnheader)
* listbox (incluindo a função option)
* menu
* menubar
* radiogroup (veja a função radio)
* tablist (en-US) (incluindo as funções tab (en-US) and tabpanel (en-US))
* tree (en-US)
* treegrid
### Funções da estrutura de documento

* application (en-US)
* article (en-US)
* cell (en-US)
* columnheader
* definition
* directory
* document (en-US)
* feed
* figure (en-US)
* group
* heading (en-US)
* img
* list (en-US)
* listitem (en-US)
* math
* none
* note
* presentation
* row (en-US)
* rowgroup (en-US)
* rowheader
* separator
* table (en-US)
* term
* textbox (en-US)
* toolbar
* tooltip (en-US)
### Funções de ponto de referência

* banner
* complementary (en-US)
* contentinfo (en-US)
* form (en-US)
* main (en-US)
* navigation (en-US)
* region (en-US)
* search (en-US)
### Funções de regiões ativa

* alert
* log
* marquee
* status
* timer (en-US)
### Funções de janela

* alertdialog (en-US)
* dialog (en-US)
Estados e propriedades
----------------------

### Atributos de widget

* aria-autocomplete
* aria-checked
* aria-current
* aria-disabled
* aria-errormessage
* aria-expanded
* aria-haspopup
* aria-hidden
* aria-invalid
* aria-label
* aria-level
* aria-modal
* aria-multiline
* aria-multiselectable
* aria-orientation
* aria-placeholder
* aria-pressed
* aria-readonly
* aria-required
* aria-selected
* aria-sort
* aria-valuemax
* aria-valuemin
* aria-valuenow
* aria-valuetext
### Atributos da região ativa

* aria-live
* aria-relevant
* aria-atomic
* aria-busy
### Atributos de drag & drop

* aria-dropeffect
* aria-dragged
### Atributos de relacionamento

* aria-activedescendant
* aria-colcount
* aria-colindex
* aria-colspan
* aria-controls
* aria-describedby
* aria-details (en-US)
* aria-errormessage
* aria-flowto
* aria-labelledby
* aria-owns
* aria-posinset
* aria-rowcount
* aria-rowindex
* aria-rowspan
* aria-setsize
### Propriedades específicas do MicrosoftEdge

* x-ms-aria-flowfrom (en-US)
Non-standard


ARIA guides - Acessibilidade

ARIA guides
===========

Aplicações de internet ricas acessíveis (**ARIA**) define caminhos para fazer a web mais acessível para pessoas com deficiências. Umas poucas linhas guias para seguirem que garante melhor acessibilidade, como usar drag and drop para colocações de widgets.

* Manipulação de erros em formulários
* Widgets de rotulagens
* Rotulagem de widgets compostos e regiões
* Gerenciamento do foco em Widgets Compostos (aria-activedescendant vs roving tabindex)
* Usando funções de referência
* Manipulação dinâmica de atualizações & Regiões ao vivo
* Virtual vs. Modo não Virtual em AT Produtos
* Usando Drag & Drop
* Notificar usuários de Não-ARIA Leitores de telas
* Estrtura de fixação com papel de apresentação
* Esconder tabela de leiaute (Layout)
* Gerenciamento de diálogos modais e não modais
* Usando ARIA com HTML5
* Como testar ARIA
* ARIA em dispositivos móveis


aria-label - Acessibilidade

aria-label
==========

O atributo `aria-label` define um valor de string que rotula um elemento interativo.

Descrição
---------

Às vezes, o nome acessível padrão de um elemento está ausente ou não descreve com precisão seu conteúdo e não há conteúdo visível no DOM que pode ser associado ao objeto para dar-lhe significado. Um exemplo comum é um botão contendo um SVG ou fonte de ícone (que você não deveria usar) sem nenhum texto.

Nos casos em que um elemento interativo não tem um nome acessível, ou um nome acessível que não é preciso, e não há conteúdo visível no DOM que possa ser referenciado via [`aria-labelledby`](/pt-BR/docs /Web/Accessibility/ARIA/Attributes/aria-labelledby), o atributo `aria-label` pode ser usado para definir uma string que rotula o elemento interativo no qual está definido. Isso fornece ao elemento seu nome acessível.

```html
<button aria-label="Fechar" onclick="myDialog.close()">
  <svg
 aria-hidden="true"
 focusable="false"
 width="17"
 height="17"
 xmlns="https://www.w3.org/2000/svg">
    <path
 d="m.967 14.217 5.8-5.906-5.765-5.89L3.094.26l5.783 5.888L14.66.26l2.092 2.162-5.766 5.889 5.801 5.906-2.092 2.162-5.818-5.924-5.818 5.924-2.092-2.162Z"
 fill="#000" />
  </svg>
</button>
```

`aria-label` destina-se ao uso em elementos interativos, ou elementos feitos para serem interativos por meio de outras declarações ARIA, quando não houver texto apropriado visível no DOM que possa ser referenciado como um rótulo

A maior parte do conteúdo tem um nome acessível gerado a partir do conteúdo de texto de seu elemento de encapsulamento imediato. Nomes acessíveis também podem ser criados por certos atributos ou elementos associados.

Por padrão, o nome acessível de um botão é o conteúdo entre as tags `<button>` de abertura e fechamento, o nome acessível de uma imagem é o conteúdo de seu [`alt`](/pt-BR/docs/Web /HTML/Element/img#alt) e o nome acessível de uma entrada de formulário é o conteúdo do elemento `<label>` associado.

Se nenhuma dessas opções estiver disponível, ou se o nome acessível padrão não for apropriado, use o atributo `aria-label` para definir o nome acessível de um elemento.

`aria-label` pode ser usado em casos onde o texto que poderia rotular o elemento é *não* visível. Se houver texto visível que rotule um elemento, use `aria-labelledby` (en-US).

O propósito de `aria-label` é o mesmo que `aria-labelledby`. Ambos fornecem um nome acessível para um elemento. Se não houver um nome visível para o elemento que você pode referenciar, use `aria-label` para fornecer ao usuário um nome acessível reconhecível. Se o texto do rótulo estiver disponível no DOM e fizer referência ao conteúdo do DOM e à experiência do usuário aceitável, prefira usar `aria-labelledby`. Não inclua ambos. Se ambos estiverem presentes no mesmo elemento, `aria-labelledby` terá precedência sobre `aria-label`.

O atributo `aria-label` pode ser usado com elementos HTML semânticos regulares; não se limita a elementos que tenham um ARIA `role` atribuído.

Não "exagere" o `aria-label`. Por exemplo, use texto visível com `aria-describedby` ou `aria-description`, não `aria-label`, para fornecer instruções adicionais ou esclarecer a interface do usuário. Lembre-se sempre de que você não precisa direcionar instruções apenas para leitores de tela; se forem necessárias instruções, forneça-as a todos (ou, de preferência, torne sua interface do usuário mais intuitiva).

Nem todos os elementos podem receber um nome acessível. Nem `aria-label` nem `aria-labelledby` devem ser usados com elementos não interativos ou papéis estruturais embutidos como `código`, `termo` ou `ênfase` nem papéis cuja semântica não será mapeada para a acessibilidade API, incluindo `presentation`, `none` e `hidden`. O atributo `aria-label` destina-se apenas a elementos interativos. Use `aria-label` para garantir que um nome acessível seja fornecido quando nenhum estiver visível no DOM para todos os elementos interativos, como links, vídeos, controles de formulário, [papéis de referência](/pt-BR/docs/Web/Accessibility/ARIA /Roles#3.\_landmark\_roles) e funções de widget.

Se você der a seus `<iframe>`s um `title`, suas imagens um atributo `alt` e os `<label>`s associados à sua entrada, `aria-label` não é necessário. Mas, se presente, o `aria-label` terá precedência sobre o `title`, `alt` e `<label>` como seu `iframe`, imagem ou nome acessível da entrada, respectivamente.

O `aria-label` só é "visível" para tecnologias assistivas. Se as informações forem importantes o suficiente para serem adicionadas aos usuários AT, considere torná-las visíveis para todos os usuários.

Valores
-------

`<string>`

Uma string de texto que será o nome acessível para o objeto.

API ARIAMixin
-------------

`Element.ariaLabel` (en-US)

A propriedade `ariaLabel` (en-US), parte da interface `Element`, reflete o valor do `aria-label` atributo.

`ElementInternals.ariaLabel` (en-US)

A propriedade `ariaLabel` (en-US), parte da interface `ElementInternals` (en-US), reflete o valor do `aria-label` atributo.

Funções associadas
------------------

Usado em quase todas as funções **exceto** funções que não podem receber um nome acessível pelo autor.

O atributo `aria-label` **NÃO** é suportado em:

* `code` (en-US)
* `caption` (en-US)
* `deletion` (en-US)
* `emphasis` (en-US)
* `generic` (en-US)
* `insertion` (en-US)
* `mark` (en-US)
* `paragraph` (en-US)
* `presentation` (en-US) / `none` (en-US)
* `strong` (en-US)
* `subscript` (en-US)
* `superscript` (en-US)
* `suggestion` (en-US)
* `term` (en-US)
* `time` (en-US)

O atributo `aria-label` destina-se apenas a elementos interativos. Quando colocado em elementos não interativos, como os listados acima, pode não ser lido ou pode confundir seus usuários como um elemento não interativo que age como interativo.

Especificações
--------------

| Specification |
| --- |
| Accessible Rich Internet Applications (WAI-ARIA) # aria-label |

Veja também
-----------

* O elemento `<label>`
* `aria-labelledby` (en-US)