Arquivo da categoria: Acessibilidade na internet

Customizando links

Além do aspecto visual, customizar links é importante por causa da Acessibilidade. Não estou falando aqui da acessibilidade para pessoas cegas e etc, estou falando de acessibilidade para pessoas que enxergam também. Eu gosto muito de usar o browser sem a barra de status. O problema de se fazer isso é que eu nunca sei para onde um link vai. Quando estou lendo um texto e há um link interessante, quase nunca tenho a indicação de que aquele link vai me levar para fora do site, ou vai me levar para o download arquivo e etc… Por isso é interessante que você, se puder, indique ao leitor qual o tipo de link ele está prestes a clicar. Abaixo dou algumas dicas de seletores complexos que podem te ajudar com este trabalho.

Os seletores complexos são uma ferramenta fascinante. Os seletores complexos pinçam aqueles elementos difíceis, no meio da estrutura HTML, sem identificação de classes ou IDs.

O nosso problema aqui é selecionar links cujo os endereços podem variar, levando o usuário para uma página externa ou um arquivo. Os seletores complexos ajudarão a selecionar estes links sem a ajuda de classes ou IDs extras. Veja os exemplos abaixo e divirta-se:

Para formatar um link que leva para um PDF, por exemplo veja o HTML:
<a href=”arquivo.pdf”>Arquivo PDF</a>

O CSS ficaria assim:

a[href $=’.pdf’]
{
padding-left: 18px;
background: transparent url(icopdf.gif) no-repeat center left;
}

O resultado: link de arquivo PDF

O código acima aplica o estilo nos links onde o valor do HREF terminam com .PDF.
Seguindo a mesma dinâmica:

a[href ^=”mailto:”]
{
padding-left: 18px;
background: transparent url(icomailto.gif) no-repeat center left;
}

Neste exemplo customizamos os links cujo valor do HREF comece com MAILTO.

Veja uma lista de alguns seletores complexos e como eles podem te ajudar com outros elementos.

Fonte: http://www.tableless.com.br/customizando-links

Deixe um comentário

Arquivado em Acessibilidade na internet

Javascript e acessibilidade

Dando continuidade a nossa série sobre acessibilidade, confira algumas dicas para desenvolver sites dinâmicos tendo um mínimo de cuidado com screen readers e navegadores com JavaScript desabilitado.

É muito comum o desenvolvedor ficar empolgado ao descobrir recursos, plugins, animações e efeitos JavaScript e acabar exagerando no produto final. Também é muito comum, como disse a Thaiana, que acessiblidade esteja ligado exclusivamente a sites governamentais. Aos poucos este cenário está mudando.

Além de tornar o seu site acessível à pessoas com necessidades especiais, as técnicas abaixo serão úteis também quando o navegador do usuário estiver com JavaScript desabilitado. E se mesmo assim você ainda não estiver convencido, pense que, quanto menos JavaScript, mais otimizado e estável será o seu site/sistema.

O problema

Acessibilidade, basicamente, significa tornar o seu site/sistema compatível com dispositivos leitores de tela. O que este dispositivo faz é tentar converter todo o conteúdo presente em uma página para uma saída especial, seja ela voz (text-to-speech) ou braille. Por isso a importância da semântica no HTML e, por isso também, a importância do JavaScript não acabar atrapalhando o funcionamento do seu site.

Dependendo da forma como você utilizou JavaScript, parte do conteúdo pode passar batida no screen reader. Isso acontece muito com animações (conteúdos escondidos) e eventos que não são nativos do elemento, como tentar utilizar onClick em um parágrafo.

<noscript>

A prioridade número 1 nas regras para acessibilidade é tornar todo o conteúdo disponível quando o navegador não estiver com JavaScript habilitado. Procure implementar alternativas HTML parecidas com o conteúdo estabelecido por seus scripts.

No entanto, é importante ressaltar que o noscript só vai funcionar quando o javascript estiver dasabilitado no navegador (ele não vai funcionar se o JavaScript estiver com erro, por exemplo). Alguns screen readers tentam interpretar JS, portanto, utilizar JavaScript NÃO significa tornar seu site pouco acessível. Depende da forma como você implementa seus scripts.

Muita gente é a favor da extinção da tag <noscript>. O que eles defendem é que basta você desenvolver seus scripts de forma não-obstrutiva. Seu script pode ser executado ou não – independente disso ele não afetará a funcionalidade básica da página.

Preciso mesmo usar JavaScript?

Sempre que for utilizar algum efeito ou interação em JavaScript você deve se perguntar se ele é mesmo necessário. Ou ainda, não daria pra fazer a mesma coisa utilizando apenas HTML e CSS?

Pense duas vezes antes de implementar qualquer tipo de script. Analise não só a questão da acessibilidade, mas também performance e manutenção.

Não invente eventos e não fique preso ao mouse

Procure utilizar eventos JavaScript apenas em elementos que estão aptos a recebê-los. Por exemplo, não utilize onClick em um <li>. Geralmente, os eventos de interação devem estar associados a links e botões.

Lembre-se também que nem sempre vai ser utilizado o mouse, logo, eventos como onMouseOver e onMouseOut seriam inválidos. Ofereça alternativas globais, como onFocus, onBlur, onClick (que, no teclado, seria executado com a tecla Enter) – visando usuários que utilizam outros dispositivos.

Um problema grave são menus ativados no mouseover. Nesse caso o usuário não teria como acessar todas as páginas – ele não poderia navegar por toda a estrutura do site.

Essas regras estão também diretamente ligadas a conteúdos carregados via AJAX. Dependendo da forma como você ativa o evento, o screenreader vai ler ou não o conteúdo recém adicionado.

WAI-ARIA

Procurando estabelecer um padrão para acessibilidade e conteúdos dinâmicos foi criada a especificação WAI-ARIA (Accessible Rich Internet Applications). O que ela faz é adicionar novas formas de identificar e habilitar funcionalidades dinâmicas através de propriedades nas tags HTML. Recentemente o jQuery UI adicionou suporte total ao framework ARIA tornando assim seus widgets e elementos de interface acessíveis a usuários com alguma necessidade especial.

O ARIA, por exemplo, pode definir regiões em um site e habilitar o movimento via tab entre essas regiões, ao invés de elemento por elemento. O WAI-ARIA também possibilita definir papéis (roles) para elementos como menu, menuitem, banner, application etc.

Este é um assunto muito rico e ainda pouco explorado. Para mais informações visite a especificação do WAI-ARIA no site do W3C e também este tutorial sobre os papéis disponíveis no ARIA.

Deixe um comentário

Arquivado em Acessibilidade na internet, Javascript

Javascript e acessibilidade

É muito comum o desenvolvedor ficar empolgado ao descobrir recursos, plugins, animações e efeitos JavaScript e acabar exagerando no produto final. Também é muito comum, como disse a Thaiana, que acessiblidade esteja ligado exclusivamente a sites governamentais. Aos poucos este cenário está mudando.

Além de tornar o seu site acessível à pessoas com necessidades especiais, as técnicas abaixo serão úteis também quando o navegador do usuário estiver com JavaScript desabilitado. E se mesmo assim você ainda não estiver convencido, pense que, quanto menos JavaScript, mais otimizado e estável será o seu site/sistema.

O problema

Acessibilidade, basicamente, significa tornar o seu site/sistema compatível com dispositivos leitores de tela. O que este dispositivo faz é tentar converter todo o conteúdo presente em uma página para uma saída especial, seja ela voz (text-to-speech) ou braille. Por isso a importância da semântica no HTML e, por isso também, a importância do JavaScript não acabar atrapalhando o funcionamento do seu site.

Dependendo da forma como você utilizou JavaScript, parte do conteúdo pode passar batida no screen reader. Isso acontece muito com animações (conteúdos escondidos) e eventos que não são nativos do elemento, como tentar utilizar onClick em um parágrafo.

<noscript>

A prioridade número 1 nas regras para acessibilidade é tornar todo o conteúdo disponível quando o navegador não estiver com JavaScript habilitado. Procure implementar alternativas HTML parecidas com o conteúdo estabelecido por seus scripts.

No entanto, é importante ressaltar que o noscript só vai funcionar quando o javascript estiver dasabilitado no navegador (ele não vai funcionar se o JavaScript estiver com erro, por exemplo). Alguns screen readers tentam interpretar JS, portanto, utilizar JavaScript NÃO significa tornar seu site pouco acessível. Depende da forma como você implementa seus scripts.

Muita gente é a favor da extinção da tag <noscript>. O que eles defendem é que basta você desenvolver seus scripts de forma não-obstrutiva. Seu script pode ser executado ou não – independente disso ele não afetará a funcionalidade básica da página.

Preciso mesmo usar JavaScript?

Sempre que for utilizar algum efeito ou interação em JavaScript você deve se perguntar se ele é mesmo necessário. Ou ainda, não daria pra fazer a mesma coisa utilizando apenas HTML e CSS?

Pense duas vezes antes de implementar qualquer tipo de script. Analise não só a questão da acessibilidade, mas também performance e manutenção.

Não invente eventos e não fique preso ao mouse

Procure utilizar eventos JavaScript apenas em elementos que estão aptos a recebê-los. Por exemplo, não utilize onClick em um <li>. Geralmente, os eventos de interação devem estar associados a links e botões.

Lembre-se também que nem sempre vai ser utilizado o mouse, logo, eventos como onMouseOver e onMouseOut seriam inválidos. Ofereça alternativas globais, como onFocus, onBlur, onClick (que, no teclado, seria executado com a tecla Enter) – visando usuários que utilizam outros dispositivos.

Um problema grave são menus ativados no mouseover. Nesse caso o usuário não teria como acessar todas as páginas – ele não poderia navegar por toda a estrutura do site.

Essas regras estão também diretamente ligadas a conteúdos carregados via AJAX. Dependendo da forma como você ativa o evento, o screenreader vai ler ou não o conteúdo recém adicionado.

WAI-ARIA

Procurando estabelecer um padrão para acessibilidade e conteúdos dinâmicos foi criada a especificação WAI-ARIA (Accessible Rich Internet Applications). O que ela faz é adicionar novas formas de identificar e habilitar funcionalidades dinâmicas através de propriedades nas tags HTML. Recentemente o jQuery UI adicionou suporte total ao framework ARIA tornando assim seus widgets e elementos de interface acessíveis a usuários com alguma necessidade especial.

O ARIA, por exemplo, pode definir regiões em um site e habilitar o movimento via tab entre essas regiões, ao invés de elemento por elemento. O WAI-ARIA também possibilita definir papéis (roles) para elementos como menu, menuitem, banner, application etc.

Deixe um comentário

Arquivado em Acessibilidade na internet, Javascript

Javascript e acessibilidade

Confira algumas dicas para desenvolver sites dinâmicos tendo um mínimo de cuidado com screen readers e navegadores com JavaScript desabilitado.

É muito comum o desenvolvedor ficar empolgado ao descobrir recursos, plugins, animações e efeitos JavaScript e acabar exagerando no produto final. Também é muito comum, como disse a Thaiana, que acessiblidade esteja ligado exclusivamente a sites governamentais. Aos poucos este cenário está mudando.

Além de tornar o seu site acessível à pessoas com necessidades especiais, as técnicas abaixo serão úteis também quando o navegador do usuário estiver com JavaScript desabilitado. E se mesmo assim você ainda não estiver convencido, pense que, quanto menos JavaScript, mais otimizado e estável será o seu site/sistema.

O problema

Acessibilidade, basicamente, significa tornar o seu site/sistema compatível com dispositivos leitores de tela. O que este dispositivo faz é tentar converter todo o conteúdo presente em uma página para uma saída especial, seja ela voz (text-to-speech) ou braille. Por isso a importância da semântica no HTML e, por isso também, a importância do JavaScript não acabar atrapalhando o funcionamento do seu site.

Dependendo da forma como você utilizou JavaScript, parte do conteúdo pode passar batida no screen reader. Isso acontece muito com animações (conteúdos escondidos) e eventos que não são nativos do elemento, como tentar utilizar onClick em um parágrafo.

<noscript>

A prioridade número 1 nas regras para acessibilidade é tornar todo o conteúdo disponível quando o navegador não estiver com JavaScript habilitado. Procure implementar alternativas HTML parecidas com o conteúdo estabelecido por seus scripts.

No entanto, é importante ressaltar que o noscript só vai funcionar quando o javascript estiver dasabilitado no navegador (ele não vai funcionar se o JavaScript estiver com erro, por exemplo). Alguns screen readers tentam interpretar JS, portanto, utilizar JavaScript NÃO significa tornar seu site pouco acessível. Depende da forma como você implementa seus scripts.

Muita gente é a favor da extinção da tag <noscript>. O que eles defendem é que basta você desenvolver seus scripts de forma não-obstrutiva. Seu script pode ser executado ou não – independente disso ele não afetará a funcionalidade básica da página.

Preciso mesmo usar JavaScript?

Sempre que for utilizar algum efeito ou interação em JavaScript você deve se perguntar se ele é mesmo necessário. Ou ainda, não daria pra fazer a mesma coisa utilizando apenas HTML e CSS?

Pense duas vezes antes de implementar qualquer tipo de script. Analise não só a questão da acessibilidade, mas também performance e manutenção.

Não invente eventos e não fique preso ao mouse

Procure utilizar eventos JavaScript apenas em elementos que estão aptos a recebê-los. Por exemplo, não utilize onClick em um <li>. Geralmente, os eventos de interação devem estar associados a links e botões.

Lembre-se também que nem sempre vai ser utilizado o mouse, logo, eventos como onMouseOver e onMouseOut seriam inválidos. Ofereça alternativas globais, como onFocus, onBlur, onClick (que, no teclado, seria executado com a tecla Enter) – visando usuários que utilizam outros dispositivos.

Um problema grave são menus ativados no mouseover. Nesse caso o usuário não teria como acessar todas as páginas – ele não poderia navegar por toda a estrutura do site.

Essas regras estão também diretamente ligadas a conteúdos carregados via AJAX. Dependendo da forma como você ativa o evento, o screenreader vai ler ou não o conteúdo recém adicionado.

WAI-ARIA

Procurando estabelecer um padrão para acessibilidade e conteúdos dinâmicos foi criada a especificação WAI-ARIA (Accessible Rich Internet Applications). O que ela faz é adicionar novas formas de identificar e habilitar funcionalidades dinâmicas através de propriedades nas tags HTML. Recentemente o jQuery UI adicionou suporte total ao framework ARIA tornando assim seus widgets e elementos de interface acessíveis a usuários com alguma necessidade especial.

O ARIA, por exemplo, pode definir regiões em um site e habilitar o movimento via tab entre essas regiões, ao invés de elemento por elemento. O WAI-ARIA também possibilita definir papéis (roles) para elementos como menu, menuitem, banner, application etc.

Este é um assunto muito rico e ainda pouco explorado. Para mais informações visite a especificação do WAI-ARIA no site do W3C e também este tutorial sobre os papéis disponíveis no ARIA.

Fonte: http://www.tableless.com.br

Por Davi Ferreira

Deixe um comentário

Arquivado em Acessibilidade na internet

Navegação Breadcrumb

O que é breadcrumb navigation ?

Imagine que você quer comprar uma HD e vai procurar na internet.

Você vai no buscador, procura por “seagate 250Gb” e ele te indica uma página que contém o produto.

Logo no topo, você irá encontrar alguns links em sequência, mais ou menos assim:

Informática>Discos Rígidos e Removíveis>Seagate > 250GB

e logo abaixo a descrição do produto.

Breadcrumb Demonstração

Breadcrumb Demonstração

Você se pergunta: Pra que isso?

Esse tipo de elemento é chamado Breadcrumb Navigation. São elementos que ajudam você a navegar melhor pelo site. No exemplo acima, se você quisesse procurar por Hd’s de outros tamanhos de armazenamento, mas da seagate, você intuitivamente clicaria no link >Seagate e acharia uma pagina falando dos vários tipos de hd’s da seagate, incluindo seus vários tamanhos de armazenamento. Logo, você deixará seu usuário mais feliz pela questão de usabilidade.

Outra coisa importante: se o usuário chegou à página do produto diretamente pelo link do buscador, e ele der clicar no botão “Voltar” do navegador, ele voltará para o buscador, o que é ruim para você, pois haverá mais chances do cliente ir para outro site procurar pelo produto. Mas se ele ver mais elementos de breadcrumb navigation, maior a chance do cliente permanecer no seu site procurando por mais coisas.

E por fim, como isso diminuirá o esforço do cliente para atingir uma página, isso qualificará melhor suas páginas. E para um questão de SEO, testes dizem que isso agiliza a indexação das páginas.

Dica de breadcrumb navigation: Colocar varios links para paginas importantes em pontos estratégicos da página, como no menu ou no rodapé.

Dica 2 de breadcrumb navigation: Esquema de paginação sugerido pelo meu amigo Rafael no seu post de acessibilidade. Ex:

<<Previous | 1 | 2 | 3 | 4 | 5 | Next>>

Mas cuidado, não saia colocando link pra tudo pra nao poluir a pagina e para o crawler não achar que você é um spammer. E tome cuidado com os conteúdos duplicados gerados pelos links.

Fonte: MestreSEO

Deixe um comentário

Arquivado em Acessibilidade na internet, CSS . Cascading Style Sheets, Padrões W3C

Verifique como anda a integração entre os navegadores e o HTML5

Browser Securitiy Deep Dive
No endereço http://html5test.com, programadores interessados podem verificar como anda a integração entre os navegadores mais usados e a HTML5. Para ver que tipo de suporte é oferecido, o internauta deve acessar esse site usando sempre o browser que pretende colocar à prova. Para cada navegador o site emite um score, uma nota. Em 12/6, os scores eram:

* Apple Safari 5.0: 208
* Google Chrome 5.03: 197
* Microsoft IE7: 12
* Microsoft IE8: 27
* Mozilla Firefox 3.66: 139
* Opera 10.6: 159

Existe um conjunto essencial de regras HTML5 suportado por todos os browsers que não pertencem à família IE. Isso abre a possibilidade de serem criados modelos HTML5, disponibilizados para a maioria dos internautas.

Html 5

Html 5

Fonte: idgnow.uol.com.br

Deixe um comentário

Arquivado em Acessibilidade na internet, Browsers

Conteúdo, Flash e HTML

Steve Jobs fez um texto explicando os motivos pelos quais a Apple não suporta e nem suportará Flash em seus aparelhos. Sugiro que você leia o artigo antes de continuar. Aqui tem uma versão traduzida. A Web foi criada para facilitar o compartilhamento de informação. Este objetivo é muito claro quando estudamos sua história.

Steve Jobs fez um texto explicando os motivos pelos quais a Apple não suporta e nem suportará Flash em seus aparelhos. Sugiro que você leia o artigo antes de continuar. Aqui tem uma versão traduzida.

A Web foi criada para facilitar o compartilhamento de informação. Este objetivo é muito claro quando estudamos sua história. Você pode enviar um email, um tweet ou uma mensagem no gTalk e a pessoa do outro lado ter essa informação na hora. É muito melhor do que esperar dias para receber uma folha de papel. A ideia da web é compartilhar e oferecer informação de fácil acesso. Não importa se isso seja uma mensagem de 140 caractéres ou se um portal de notícias completo.

Essa informação, por sua vez, precisa estar disponível a qualquer hora para ser consumida e reutilizada. Um exemplo clássico disso são os blogs. Os posts são acessíveis se você visitar a página ou por meio de RSS. Você pode acessar essa informação também pelo Google ou qualquer outro sistema de busca que exista. Se quiser, você pode usar seu dispositivo móvel para acessar essa informação aonde quer que esteja. Se você instalar em seu mobile uma App que baixa o conteúdo, melhor ainda, porque você poderá consumir essa informação offline.
O HTML foi criado para que isso tudo funcione perfeitamente. O HTML foi criado para construir uma web interoperável. Uma web que seja acessível em qualquer parte do planeta com qualquer tipo de dispositivo ou meio de acesso.

Não quero tirar o peso dos erros do W3C em demorar para reformular a linguagem. A W3C precisou de um empurrãozinho de vários desenvolvedores insatisfeitos pela falta de atitude e demora do W3C para reformular o HTML. Estes desenvolvedores por sua vez querem uma web mais pública, mais integrável, mais aberta. Estes objetivos estão sendo seguidos à risca agora com o desenvolvimento do HTML5 e do CSS3. Sugiro que leia o texto do W3C explicando qual é o objetivo real do HTML. A brief history of HTML.

Quando falamos sobre a importância de separar o desenvolvimento web em camadas, queremos que o desenvolvedor web entenda que há um motivo por trás de toda essa metodologia. Aquela ideia de que “Conteúdo é Rei” precisa ser levada ao pé da letra. O HTML é o coadjuvante de toda essa história. O conteúdo é o protagonista. Você trabalha com web porque existe conteúdo, caso contrário, qual seria o motivo para se ter internet?

Concordo com o tio Steve quando ele não aceita suportar Flash em seus aparelhos. O Flash corre para o caminho contrário de todos os objetivos do W3C, da Apple e de todo mundo que luta por uma web mais interoperável. Entenda que também não sou contra Flash. O Flash teve o seu papel. Ajudou muito a web durante um tempo. Felizmente esse tempo já passou.

Já passou o tempo dos sites mais “interativos” (odeio essa palavra quando quero me referir ao Flash), mais animados e etc . O HTML5 juntamente com o CSS3 leva o desenvolvimento para web para um novo patamar. Um patamar onde a informação está lá esperando para ser utilizada quantas vezes for necessária, onde for necessária e por qualquer meio de acesso. Seja esse meio acesso um simples sistema de leitura de tela ou um dispositivo ultrarevolucionário.

Toda aquela história de semântica, código simples e com significado, é regra e precisa ser seguida. HTML mal escrito, com tags indicando significados errôneos para o conteúdo é tão ruim quanto o Flash. Talvez seja até pior. Ter cuidado é necessário, é muito trabalhoso também, sem dúvida, mas é uma das partes mais importantes da produção.

A web só existe por causa do conteúdo. Se a informação desaparece ou se torna difícil de ser acessada, a web perde o sentido. Se você é desenvolvedor web e não trabalha para que essa informação fique cada mais semântica, acessível, abundante, você não é um profissional de internet, vocé qualquer coisa, menos isso.

Fonte: Tableless

Deixe um comentário

Arquivado em Acessibilidade na internet, Informação