Ainda a Pensar

30 novembro, 2005

ALA - 208

Neste número temos artigos para audiências diferentes:

Para o tipógrafo que há em si tem:

Imprimir um livro com CSS: Boom! Trata-se da apresentação de um método de produção de livros impressos baseado em HTML e CSS mediado pelo Prince para produzir um PDF final para impressão. Boom trata-se de um microformato proposto pelos autores: Bert Bos e Hakon Wium Lie.
Poder ao povo de D. Keyth Robinson, que julgo resumir razoavelmente como criar soluções para necessidades de utilizadores fazendo-o de forma mais simples possível. Além disso é bom ouvir os seus utilizadores e/ou visitantes/clientes.
O terceiro artigo (o repescado do número 96) A maldição da Concepção da Informação de Scott Jason Cohen, fala das dificuldades colocadas pelos especialistas em acessibilidade e usabilidade e os problemas que algum conservadorismo dos arquitectos de informação pode trazer à evolução da web.

28 novembro, 2005

Sítio de Eleição

Por vezes é necessário criar uma visualização de dados complexos e não sabemos como. Aqui http://www.visualcomplexity.com/ poderá encontrar algo para as suas necessidades/desejos.

Erros comuns em XHTML

Não fechar elementos vazios (elementos sem marcador de final)
- Incorrecto: <br>
- Correcto: <br />
Não fechar elementos não vazios
- Incorrecto: <p>Isto é um parágrafo.<p>Isto é um outro parágrafo.
- Correcto: <p>Isto é um parágrafo.</p><p>Isto é outro parágrafo.</p>
Aninhar elementos de forma imprópria (os elementos têm que ser fechado pela ordem inversa)
- Incorrecto: <em><strong>Isto é algum texto.</em></strong>
- Correcto: <em><strong>Isto é algum texto.</strong></em>
Não especificar texto alternativo para imagens (usar o atributo alt, que ajuda a tornar as páginas acessíveis a utilizadores com dispositivos que não carregam imagens ou têm dificiência visual)
- Incorrecto: <img src="/peles/comuns/imagens/alimentadoporblabla.png" />
- Correcto: <img src="/peles/comuns/imagens/alimentadoporblabla.png" alt="Blabla" />
Colocar texto directamente no corpo do documento (isto não é um erro em XHTML 1.0 Transitional)
- Incorrecto: <body>Bem vindo à minha página.</body>
- Correcto: <body><p>Bem vindo à minha página.</p></body>
Aninhar elementos bloco dentro de elementos em linha
- Incorrecto: <em><h2>Introdução</h2></em>
- Correcto: <h2><em>Introduction</em></h2>
Não colocar pelicas à volta de valores de atributos
- Incorrecto: <td rowspan=3>
- Correcto: <td rowspan="3">
Usar e comercial fora de entidades (usar & para mostrar o caracter «e comercial»)
- Incorrecto: <title>Carros & Camiões</title>
- Correcto: <title>Carros & Camiões</title>
Uso de e comercial fora de entidades em URLs (usar & em vez de & também em ligações)
- Incorrecto: <a href="index.php?page=noticias&estilo=5">Notícias</a>
- Correcto: <a href="index.php?page=noticias&estilo=5"gt;News</a>
Uso de nomes de elementos ou atributos em maísculas
- Incorrecto: <BODY><P>A Melhor Página de Sempre</P></BODY>
- Correcto: <body><p>A Melhor Página de Sempre</p></body>
Minimização de atributo
- Incorrecto: <textarea readonly>SÓ DE LEITURA</textarea>
- Correcto: <textarea readonly="readonly">SÓ DE LEITURA</textarea>

Esta é uma lista muito abreviada dos erros encontrados

25 novembro, 2005

XHTML para leigos

Se dissermos «qual é a coisa qual é ela que antes de o ser já o era?» Então um ouvinte terá que adivinhar qual será a resposta.

Se dissermos tudo o que sobe tem que cair. Nada de tentar adivinhar, uma frase simples e com início e fim adequados. Faz sentido que algo que seja lançado para o alto tenha que voltar à terra. O não voltar desafia a gravidade não estando de acordo com aquilo que vemos no dia a dia.

Isto é muito semelhante às diferenças entre o XHTML e o HTML 4.01. Em XHTML, tudo o que tem um princípio tem que ter um fim. Em HTML, tal não se passa. Pode começar um parágrafo mas, nunca o acabar. Pode ter uma lista de coisas e nunca terminar cada item. Se tivermos que comunicar com alguém que nunca termina as frases, tal será confuso no mínimo.

Pense nisto da seguinte forma: o HTML foi pensado como um pacote, com uma dobra em cada lado. Contudo mesmo a especificação estrita é tem ainda alguma maleabilidade, ou seja o pacote não necessita estar fechado. Não sei o que é que pensa mas é mais provável comer uma bolacha dum pacote fechado de um aberto sabe quem há quanto tempo.

Exemplos:

Abaixo encontrará um exemplo de código HTML válido mesmo sob o tipo de documento HTML 4.01 estrito:



     <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN" 
                                              "http://www.w3.org/TR/html4/strict.dtd">
     <html>
     <HEAD>
     <meta http-EQUIV="Content-TyPe" content="text/html; 
                                                                CHARSET=utf-8">
     <titlE>Testing HTML 4.01</TITLe>
     </head>
     <body>
     <P>This is some sloppy HTML 4.01!
     <oL>
     <LI>List item one
     <LI>List item two
     <li>List item three</LI>
     </Ol>
     </BODy>
     </HTmL>

Para comparação eis o mesmo reescrito em XHTML 1.1:


     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
     <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
     <head>
     <meta http-equiv="content-type" content="application/xhtml+xml; 
         charset=utf-8" />
     <title>Testing XHTML 1.1</title>
     </head>
     <body>
     <p>This is some clean XHTML 1.1!</p>
     <ol>
     <li>List item one</li>
     <li>List item two</li>
     <li>List item three</li>
     </ol>
     </body>
     </html>

Como pode comprovar o segundo exemplo é mais legível (desde que saiba sintaxe HTML). Tudo excepto o DOCTYPE está em minúsculas e tudo que tem um início tem um fim explicíto. Não é só mais fácil, evita que o navegador faça algum trabalho de adivinhação sobre o local onde seria suposto encontrar-se os marcadores de fecho. Por exemplo um <li> pode ser fechado no final da linha, mas também é possível envolver coisas dentro de itens de lista.

Um navegador não sabe até atingir o marcador de abertura seguinte se deve fechar o marcador anterior ou se o deve deixar aberto. Assim não há só confusão para uma pessoa que leia o código, mas para a reprodução da página. Implicitamente esta lógica extra necessária provoca um aumento do tempo de carregamento, independentemente do caso de uns tantos bytes extra necessários ao fecho dos marcadores de cada vez que são abertos. O código limpor é reproduzido mais rapidamente, ponto parágrafo. Para prova de tal verifique estes artigo (não o código do sítio).

Terminador por si:

No final do Terminator 2, Arnold diz "não posso acabar comigo". No caso do XHTML isto é bom. Se tudo o que começa tem que ser terminado há alguns pontos nos quais o HTML mesmo que bem formado tem uns quantos problemas. No exemplo acima, há um desses pontos no marcador meta descrevendo o tipo de conteúdo.

Em HTML um meta termina com um ">" significando que tecnicamente ele se mantem aberto. O XHTML corrige isto terminando-se a sí próprio o meta com um traço de fracção final "/>". Outros marcadores com o mesmo comportamento são img, br e hr – todos são tipicamente deixados "em aberto" no HTML, terminando-se a sí próprios no XHTML. Isto torna muito mais fácil uma leitura sabendo que sempre que encontrar um "/>" se está na presença do fim do marcador.

Resumo:

Deixando de lado toda a argumentação para servir XHTML como text/html ou como application/xhtml+xml, prefiro XHTML devido à rigidez inerente à sua validação. Isto claro que não quer dizer que o HTML não possa ser escrito com um padrão muito próximo em mente o problema é que não não é exigído. Veja se me entende não estou a dizer que o XHTML é a forma mais apropriada de fazer as coisas.

Isto não é uma atitude pedante. Sei perfeitamente que o HTML pode ser tão estruturado e semântico quando o XHTML. Roger Johansson e Robert Nyman são perítos em desenvolvimento de web e ambos usam HTML 4.01 estrito de maneira adequada. Ambos fecham tudo e usam código em minúsculas. Robert escreveu um artigo sobre html versus xhtml. Roger é claramente um apaixonado pelo fecho adequado dos marcadores como pode ser comprovado no seu artigo.

Doug Bowman, outra lenda no campo usa XHTML 1.0 estrito, mas serve-o como text/html, sem grande problema. Vejo a lógica por detrás dos argumentos de ambos os lados sobre quererem continuar a trabalhar adequadamente com navegadores obsoletos, etc.

Voltemos ao assunto principal: Resolvemos os mistérios da humanidade? Não. Este artigo está aqui para provar as vantagens de um doctype sobre outro? Não. Só quiz dar uma revisão geral sobre o que me levou inicialmente para o XHTML e porque prefiro continuar a usar. O aspecto fundamentar é que independentemente do que escolha se lhe mantenha fiel. Não tente misturar - mantenha os marcadores em minúsculas e feche-os.

Ou seja no fim disto tudo. Faça uma selecção de um standards e depois aja em conformidade com o mesmo. Uma disputa sobre que standard seguir é fútil.

24 novembro, 2005

Esquadria azul à volta de uma imagem

Tornar uma imagem a ligação para outra página é muito simples, o HTML que segue trata disso:


 <a href="http://aindaapensar.blogspot.com/">
 <img src="/aindaapensar.png" 

                alt="logotipo de aindaapensar">
 </a>

No entanto irá verificar que aparece uma esquadria azul à volta da imagem. Esta esquadria serve para informar os utilizadores que a imagem é uma ligação. Claro que há algo a dizer para indicar o que é que ou não uma ligação.

Hoje a generalidade dos designers da web tornam óbvio através das concepções do anúncios ou botões de navegação aqueles elementos que são ligações e nos quais se pode carregar. Então como é que apagamos essa esquadria?

Aqueles que gostam de aplicar as recomendações devem usar folhas de estilo e assim o código será algo como:


 <a href="http://aindaapensar.blogspot.com/">
 <img src="/aindaapensar.png" 

             alt="logotipo de aindaapensar" 

             style="border-style: none">
 </a>

Ou ainda melhor remetendo a regra para a folha de estilo separada:


img
{
 border-style: none;
}

E no elemento header da sua página fazer uma menção à folha de estilo:


 <link href="/folha_de_estilo.css" 

                 rel="stylesheet" type="text/css">

Este método irá automaticamente remover a esquadria azul de todas as imagens que usem este ficheiro css e no caso desta regra não ser ultrapassada por outra mais específica.

23 novembro, 2005

div versus span

Para quem não sabe um elemento div é um elemento bloco e um elemento span é um elemento em linha.

Para os curiosos podem dirigir-se à fonte do html

O que é que é isso de elemento bloco e elemento em linha?

Campos escaláveis

As listas de discussão podem não ser a leitura mais agradável que se possa ter mas permite que um principiante aprenda umas coisas.

Por exemplo quando o utilizador altera o tamanho do tipo de letra é razoável esperar que o campo de pesquisa também veja o seu tamanho aumentar para que isso suceda basta na nossa folha de estilo incluir algo como:


form input {
      width: 15em;
      height: 1.3em;
      font-size: .9em;
}

Nem todos os navegadores respondem a isto de forma imediata alguns necessitam de ser refrescados para ajustarem a altura por exemplo de um select

Com o código acima aumenta a largura e altura do campo assim como o tamanho do tipo da letra.

RSS

No blogue da equipa de RSS da Microsoft diz-se que:

...a nossa experiência de vários anos com o HTML no IE ensinou-nos os problemas a longo prazo que resultam de sermos demasiado liberais naquilo que aceitamos de terceiros. Assim, adoptamos o seguinte princípio para o IE7 e a plataforma RSS no Windows Vista: só iremos suportar alimento XML bem formado.

O que me der na mona

Estou a experimentar uma alternativa ao blogger, o wordpress em "O que me der na mona". Até agora a primeira coisa que me salta à vista é que o processo de produção de colocação na net de um texto permite uma classificação coisa que este directamente não faz. Assim provavelmente a minha secção de Web Standards em Portugal vai passar para lá ficando neste blogue pequenos excertos de html, javascript, css, ruby e outras coias mais associadas a puro código.

As minhas observações sobre web design, arquitectura de informação, web 2.0 e outras devem passar para lá (claro que mantendo-se aqui o que já cá está.)

22 novembro, 2005

background-color e color

Algumas pessoas quando vêm o relatório do validador de CSS acham sem importância os avisos em especial quando estes se referem a cores de texto e cores de fundo (color e background-color).

Quando não se especifica uma ou outra o que pode suceder é que um visitante do sítio ter uma configuração específica em que ambas em determinados elementos sejam coincidentes e nesse caso o visitante deixará de poder ler o conteúdo pois a página lhe vai parecer vazia.

21 novembro, 2005

Web Standards em Portugal

Parem a Impressão, parem a impressão! O novo sítio da Universidade de Lisboa passou a validar!

Não sei em que dia é que isto terá sucedido mas o novo sítio da Universidade de Lisboa passou a validar.

A utilização de tabelas para criar a disposição dos vários elementos mantêm-se (mas já esteve mais longe).

Resumindo a componente mecânica já está! Falta a componente mais humana (semântica).

É pena que haja pelo menos uma página na UL(no interior) com erros ligeiros (falta de fecho de parágrafo) quando deviam validar página a página (teste unitário) para saberem o que mudar.

O CSS também valida com alguns avisos em especial com falta de cores de fundo em elementos com cor (de texto) ou vice-versa.

Continuam a usar atributos que já não se esperaria usarem td com width .

Já agora depois de transformarem as tabelas que não são tabelas em div e torna-se em algo importante um sítio de um estabelecimento de ensino superior a seguir as regras.

18 novembro, 2005

Verificar CSS

Como é que posso verificar se o CSS está correctamente formado e se está de acordo com os Standards do W3C?: O W3C tem um validador de CSS o qual verifica URL, submissão de um ficheiro (CSS ou HTML com folha de estilos <style> ou cópia de CSS directamente para uma caixa de texto para verificação.; Existe para o Firefox um plug in para responsáveis por desenvolvimento de sítios que tem ligações para uma série de validadores entre eles este.

17 novembro, 2005

Como Centrar Conteúdos

Um problema comum para web designers é centrar conteúdos numa página web

O modelo actual do (X)HTML e do CSS é ver cada documento Web como uma área não limitada e, uma janela de navegador como uma vista para esse documento e não uma parte do mesmo. Daí ser impossível centrar um documento em qualquer janela de navegador.

No entanto por vezes é absolutamente necessário centrar verticalmente uma página ou páginas. Há essencialmente três formas de o fazer: através da combinação de JavaScript e posicionamento absoluto CSS; ou através de métodos arcaicos HTML (usando um arranjo de uma só célula de tabela); ou podemos usar regras de estilo CSS para esticar o documento até 100% da janela do navegador em altura e depois centrar verticalmente o resto da página. O método QuircksMode pode ser usado para esticar o documento. É realmente simples. Só é necessário encontrar o elemento (X)HTML que é para o navegador o equivalente da sua janela - a combinação html e body é suficiente para a generalidade dos principais navegadores e depois definir uma divaninhada com posicionamento absoluto.

(Pode ainda ajustar-se as características desta div com atributos overflow, min/max width/heightetc.)

O código resultante seria algo como (substituir ... por valores adequados ao seu caso):


<... (veja o método QuircksMode para decidir que doctype...>
<html>
   <head>
      <title>Processo de Centragem Vertical da Victoria
                   - Página de Teste</title>
      <style type="text/css">
         html, body   { background-color: blue;
                        height: 100%; 
                        margin: 0;
                        padding: 0;
                        color: yellow; 
                        text-align: center; }
         div#centered { border: 0; 
                        background-color: white;
                        height: 50%;
                        width: 50%;
                        position: absolute;
                        left: 25%;
                        top: 25%;
                        color: black; }
      </style>
   </head>
   <body>
      <div id="centered">
         div centrada verticalmente
            (<a href="http://vmalek.murphy.cz" 
                   title="Processo de Centragem 
                          Vertical da Victoria">
                          Ver comentários acima</a>).
      </div>
   </body>
</html>

Web Standards em Portugual

Para quem ache que tudo o que escrevo é para deitar abaixo, tal não é de facto verdade.

Como já tinha anteriormente dito em Portugal existem responsáveis pelo desenvolvimento de sítios web que levam a sério os web standards.

Hoje irem tentar aqui colocar páginas de entidades que já estejam a aproximar-se desse alvo a atingir, não por si, mas porque isso facilitará a vida as seus visitantes.

log
As páginas validam o XHTML e o CSS. Gostaria de perceber porque é que num sítio com padrão elevado (para a média nacional) depois se falha (ou então porque é que se dicide desta forma) nos detalhes. Está quase lá em termos de standards.

Em termos gráficos já tenho um problema um pouco maior com a página. O sítio é na minha opinião demasiado frio, quase sem grafismos, a não ser os botões de navegação e o próprio logo. Além disso não é suficientemente flexível pois se ampliarmos os tipos o aspecto começa a ficar excessivamente degradado (excepto no Opera claro). Talves fosse melhor começar a treinar as pessoas que desenvolvem sítios torná-los à prova de bala.

Algo curioso é os sítios instituicionais por ela produzidos não alcançarem o padrão em termos de web standards do próprio sítio. Será que o sítio apresenta uma evolução. Por último, foi a única empresa de desenvolvimento, em que vi código tão bom.

Esta lista irá, julgo/espero, crescer à medida que for encontrando sítios assim ou melhores (claro que na minha opinião).

16 novembro, 2005

Um Profissional Nunca Pode Deixar de Aprender

Um profissional nunca pode deixar de aprender

Nos últimos tempos tenho lido artigos que levantam o mesmo problema: os profissionais da web que se recusam a actualizar as suas capacidades e insistem em usar métodos desactualizados não se podem chamar a si próprios profissionais da Web.

Há quem me possa achar elitista ao dizê-lo. Mas pense sobre o assunto. Porque é que os profissionais da web não necessitariam de saber sobre o seu metier. Acho esta atitude - tida por muito gente neste meio e por muita gente fora dele - insultuosa para aqueles que diariamente trabalham de forma árdua para se manterem actualizados e ao corrente das melhores práticas.

Gosto que outros expressem as suas opiniões sobre este assunto. Ian Loyd entrevistou Andy Clarke. Eis uma citação que subscrevo:

Há tantos sítios na web, blogues e publicações derigidas para ajudar as pessoas a aprenderem sobre standards e técnicas de acessibilidade que deixou de haver desculpas para não produzir código semântico ou CSS. Pessoas que continuam a produzir disposições de páginas baseadas em tabelas, imagens para espacejamento ou que ignorem a acessibilidade (eu acrescento a usabilidade) não se devem chamar a si próprias profissionais da web.

Esta foi uma forma abreviada de dizer aquilo com que concordo. No caso de desejar comentar esta citação dê um salto a Acessibilidade - Sem luvas

Estou completamente de acordo com o que o Andy diz. Não há razão para tratar alguém como profissional se essa pessa não envida qualquer esforço para aprender e se manter actualizado. Veja bem não estou a apontar o dedo aos que não sabem, aos que são tão novos no meio que ainda não aprenderam mas que estão dispostos a aprender sobre desenvolvimento e concepção modernos para web.

A Molly Holzschlag no seu artigo web standards e novo profissionalismo diz:

O cerne da questão é simples: temos que saber do nosso mêtier! E o que não sabemos, temos que ter disposição para dizer que não conhecemos e que estamos abertos a aprender.

A palavra chave aqui é mêtier. Há tanta gente no meio que parece que não se interessa pelo que faz. Há muitas pessoas que só fazem o que for preciso para que a tarefa termine, que é uma expressão comum para defender o uso de métodos desactualizados.

Estas palavras da Molly surgem num contexto de degradação obervado no sítio da Disney no Reino Unido substituindo um sítio concebido com base em web standards por um sítio concebido com uma grande mixordia de tabelas.

Sei pouco sobre desenvolvimento de web. Mas quando não sei algo, trato de o admitir e ir à procura. Ou pergunto a alguém que o saiba.

Finalmente John Oxton, que exprimiu a citação seguinte em Porque é que agora é ex-html (algumas palavras censuradas):

O que eu desejo é HTML que dê um pontapé no ... se não for tratado de forma adequada. HTML que não tomasse xxxx, com uma mensagem bem destacada (VÁ TRATAR DE APRENDER A USAR-ME!) a pessoas que se recusem a aprender esta linguagem super simples e que não queiram refinar a sua compreenção.

John fala de XHTML servido como XML. Sei que muitos não acreditam no deixar que o navegador (user agent seria um termo mais correcto) apresente mensagens de erro ao visitante de um sítio, em vez de tentar (o user agent), entender o que o autor queria de facto dizer/mostrar. Deixemos de lado esta controvérsia e, imaginemos que todos os navegadores mostram tais mensagens de erro. Não sucederia que muitos dos chamados profissionais da web se preocupariam em aprender como resolver esses erros?

Bem sei que se o HTML tivesses sido tão estrito desde o início, a web não se teria tornado no que é hoje, pois, a curva de aprendizagem, teria sido muito difícil de ultrapassar para muita gente. Mas a web está mais madura agora do que há uma década, quando apareceram os primeiros navegadores gráficos. Chegou a altura para os profissionais da web também amadurecerem.

Alguns dos Grandes Podem Mostrar o Caminho

Amanha veremos como se comportam as empresas em Portugal.

Boas Práticas

Boas práticas de Desenvolvimento

Alguém pergunta se há uma forma correcta de começar um projecto. Acrescenta que o que quer dizer é se se deve começar por escrever o HTML todo e depois escrever as regras CSS ou se se deve fazer as duas coisas de forma alternada? Diz ainda, que está a tentar encontrar um processo lógico a seguir de forma a tornar a tarefa mais fácil de compreender e terminar.

Qual é a minha opinião?

Julgo ser mais fácil desenvolver a totalidade do HTML e documentar a estrutura elementar, as classes e identificações antes de começar o CSS.

Pode parecer aborrecido e pode suceder ser necessário voltar ao HTML mais tarde quando se estiver a resolver problemas levantados por navegadores mal comportados, mas este processo assegura que:

O nosso HTML fica bem estruturado e faz sentido sem CSS e/ou JavaScript;
Ficamos com documentação para passar aos responsáveis pela manutenção e mais importante para provar que o nosso código era claro;
Podemos dar o HTML aos responsáveis pelo desenvolvimento para o transformarem em modelos (templates) ou converterem em ASP.NET, de forma a assegurar que se trabalha em paralelo;
Alguns sistemas de gestão de conteúdos fornecem diferentes classes aos editores como estilos num editor WYSIWYG, e tal significa que podemos criar um pequeno guia de estilo para ser preenchido mais tarde quando construir o CSS.

15 novembro, 2005

Web Standards em Portugual

Sítios Portugueses construídos em conformidade com os web standards

Existe na rede um sítio onde alguns designers se registam dando a conhecer que concebem sítios da web em conformidade com os standards.

Nesse sítio, - W3 Compliant Sites - encontram-se inscritos 1088 designers entre os quais 7 portugueses.

Fiz uma visita a cada um dos sítios por eles indicados como estando em conformidade com os web standards.

Dessas visitas destaco os seguintes designers

Carlos Paula Simões
1. cb2web.com e
2. Hotel Anjo Azul
As páginas validam usando as ferramentas clássicas, o código está segregado como é correcto, o design no sítio do hotel é simples e eficaz (mas um pouco apagado não se destacando).
Hugo C. Silva
1. Vigopor
Apresenta uma página com HTML 4.01 Transitional, mas apresenta alguns problemas. Sem Flash ou sem JavaScript não há navegação. Além disso usa tabelas para criar a disposição do sítio.
Ivo Gomes
1. Portal das Curiosidades
2. Sítio de Ivo Gomes
O Design não é há prova de bala, se ampliarmos o texto meia duzia de vezes ficamos com um menu funcional mas com mau aspecto

Um dos melhores sítios que conheço, por um profissional
Já agora excelente artigo sobre prototipagem em papel
Vitor Costa
1. Nova Esfera??
Existem ligações que usam o mesmo texto para apontar para recursos diferentes. Algumas inconsistências no CSS. Não se pode ampliar muito fica tudo sobreposto. O excesso de controlo conduz à sua falta.

Os web designers/responsáveis pelo desenvolvimento de sítios que têm sítios em conformidade poderiam inscrever-se de modo a darem mais visibilidade a esse facto. Aqueles que se tenham inscrito e cujos sítios tenham deixado de estar conformes deviam ter a ombridade de retirarem os seus sítios da lista.

Porque acham que não estou inscrito, porque sei que o design não é meu e porque há páginas que sei de antemão que não estão conformes.

14 novembro, 2005

Web e Dislexia

Concepção de páginas web para leitores dislexicos

A chegada da WWW aos ecrãs dos nossos computadores significa que sofre das falhas de qualquer novo meio:

A generalidade dos sítios web é construído com excesso de pressa
Os web designer são relativamente novos no meio
O texto é frequentemente apresentado num formato eligível, mesmo em texto branco/amarelo sobre fundo preto
Navegar num website não é fácil
Alguns anunciantes tratam de arranjar algo para chamar à atenção mesmo que seja irritante
Alguns designers vêm as páginas web como perítos de computadores em vez do ponto de vista de pessoas normais que leem as suas páginas
Preseume-se que todas as pessoas que visitam as páginas sabem/podem usar deligentemente o seu computador
Os designers são tentados a criar formas de levar as pessoas a manterem-se no sítio em vez de fornecerem ligações úteis que levem as pessoas a visitar outras fontes de informação
e em último lugar, a generalidade das páginas na web foi/é construída por homens, (por acaso gostaria de ver mais páginas concebidas por mulheres)! Falta um pouco de percepção feminina e empatia.

Largura de coluna

Nada há de pior do que ler aquele texto que ocupa todo o espaço disponível no ecrã (da ponta esquerda até ao extremo direito). Há medida que os olhos tentam varrer o ecrã torna-se extremamento difícil ler a linha seguinte. O ponto de fuga perde-se no mar de texto. Exemplo 1 Exemplo 2

Claro que é muito mais fácil de ler a coluna mais estreita, com cerca de 60 a 70 caracteres do que o texto mais largo. É por esta razão que os jornais usam colunas.

Justificado ou não?

O Texto justificado é aquele em que as palavras são espacejadas pelo processador de texto de forma a que ambos os lados esquerdo e direito de cada coluna sejam linhas rectas. O texto não justificado - como o desta página - deixa uma arestas escadeada ao longo do lado direito.

Para um leitor dislexico, o texto justificado, que tem espacejamento mal distribuido entre palavras, cria padrões visuais de espaço em branco que são difíceis de ignorar. Esses espaços distraem o leitor que deixa de saber onde está a ler.

O espaço não justificado é muito mais fácil de ler, embora não esteja na moda em algumas revistas de design, ou pretenções a tal.

Cor do fundo

Alguns leitores dislexicos são particularmente sensíveis ao contraste do texto num fundo branco. Isto pode provocar um movimento aparente e a desfocagem do texto.

Pode evitar-se esta dificuldade se não se usar fundo totalmente branco. Algo como backgound-color: #ffffE5; é suficiente. O texto pode ser mais difícil de ler se for escrito sobre um padrão. (Exemplo)

Para páginas que sejam usadas frequentemente por dislexicos adultos ou adolescentes, pode ser adicionado um comutador de fundo de página, como o existente no cimo desta entrada.

Tipos de letra

Infelizmente a generalidade dos programas de computador por omissão usam letras com serif, como a Times New Roman. Este tipo de letra é tradicionalmente associada à impressão. Uma letra com serif é aquela cujas extremidades têm variação de espessura de traço.

A utilização de um tipo de letra como o "Arial" permite uma página mais clara, para dislexicos.

Tamanho do tipo de letra

Os ecrãs estão cada vez maiores, mas a maior parte das pessoas continua a ver às páginas da web em monitores pequenos. É difícil ler um texto com tamanhos demasiadamente pequenos.

Evitar itálicos

As letras em itálico estão ligeiramente deitadas e são normalmente usadas nos livros para dar enfâse a algo. Contudo, quando vistas num monitor por uma pessoa dislexica são difícies de ler.

No caso da letra ser de uma tamanho muito pequeno tornam a sua leitura impossível.

É preferível realçar palavras usando negrito.

Imagens e Fotografias

Não precisa ser disléxico para saber que uma página com imagens é mais agradável de ser vista do que uma só com texto. As imagens ajudam a quebrar a página em pequenas porções e para um disléxico, dão um estímulo visual imediato e uma memória visual para o futuro.

Pode ver a desilusão na cara de uma criança quando chega a uma página sem imagens. Infelizmente desenvolvemos a opinião que livros com imagens/desenhos são para as crianças, os adultos lêm livros sem imagens. Pode ser apropriado em certas circunstâncias, mas mesmo num texto académico é um alívio ver um gráfico! (Mau exemplo)

Caixas de Texto e Balas

Podem ser usadas caixas de texto e balas de forma a enfatisar ou realçar aspectos importantes.
Servem ainda para quebrar um secção extensa de texto denso.
As balas servem ainda para realçar aspectos chave, em especial se estiverem separadas por espaço em branco extra para ajudar a clarificar.

Imagens em movimento

Imagens a piscar distraiem não só pessoas com problemas visuais, mas todos nós.

Um sentido de direcção afecta os leitores dislexicos. Quantas vezes já tivemos problemas com um web designer "excessivamente criativo".

A regra de outro é haver uma lista de ligações simples em cada página ligando a todas as outras páginas ou secções do sítio

Frases curtas

Frases alongadas contêm mais do que uma ideia. É perfeitamente possível repartir frases compridas criando frases mais curtas e simples. Isto não torna as frases intelectualmente inferiores.

As mesmas ideias podem ser traduzidas claramente em frases curtas. Isto dá um intervalo a um leitor dislexico após cada frase. Não há limite de comprimento fixo para uma frase complicada e comprida que de tão comprida o nosso cérebro deixa de interpretar. Um bom exemplo

Parágrafos curtos

Os artigos dos jornais são normalmente bons exemplos de como se deve repartir o texto para melhorar a legibilidade.

Por vezes os artigos são feitos de forma a que haja parágrafos a cada frase.

Tal pode não estar de acordo com as convenções de Português correcto ou de escrita de ensaios, mas tal é outro assunto.

A prioridade quando se lê um jornal ou uma página da web é legibilidade e os parágrafos - mesmo os com uma linha só - devem ser sempre espacejados com uma linha em branco entre cada.

Escrever para programas de leitura (tecnologias assistivas)

Os leitores dislexicos podem ler as suas páginas de web usando leitores de ecrã. Esses programas têm limitações e portanto devem ser seguidas algumas linhas de orientação:

Se tiver um ponto final nos cabeçalhos (h1 a h6) tal faz com que a voz faça uma pausa e baixe o tom no final;
Use ponto e vírgula, virgulas ou ponto finl após elementos numa lista com balas iniciais, caso contrário podem ser lidas como texto contínuo;
Não escreva palavras só com maísculas pois podem ser lidas como letras individuais pelo programa;
Separe os elementos de uma lista com balas com espaço adicional;
Use um ponto parágrafo após uma ligação para o separar do texto que se lhe segue.

Bibliografia

Guia de Estilo da Associação Britância de Dislexia.
: O estilo na qual esta informação foi produzida de forma a facilitar a compreensão pelo leitor. O formato com que se apresenta informação pode torná-la acessível e será vital se a informação contida é para ser compreendida por todos
Uma perspectiva de um disléxico sobre acessibilidade de conteúdo electrónico.
: Cobre as quatro áreas principais de acessibilidade: apresentação, conteúdo, estrutura e navegação
10 linhas de orientação para melhorar a acessibilidade para pessoas com dislexia.: Bases para a melhoria da ligebilidade e acessibilidade por pessoas dislexicas

13 novembro, 2005

Erros Comuns

Quando pertencemos a uma lista de correio tão específica como a CSS-D esperamos não ver a não ser por parte de principiantes (sem desprimor para eles, visto todos o termos sido e alguns assim se manterem), dizia que esperamos não ver código como este


.caixa {
   border: 1px solid black;
}

#azul {
   background-color: blue;
}

#encarnado{
   background-color: red;
}

Pois não será normal só haver um elemento azul e um elemento encarnado numa página, nem será normal dar nomes a class ou id que tenham a haver com o seu aspecto visual, mas sim nomes que tenham a haver com a sua funcionalidade.


Molly Holzschlag mencionou num artigo sobre como atribuía nomes a estes atributos estes atributos indicando no mesmoa livro/artigo as desvantagens de dar nomes de acordo com a apresentação.





Publicada por



Carlos Afonso




à(s)

10:01 da manhã





Sem comentários:


        

          
        
12 novembro, 2005

          
        






Treehouse #2





Saiu o #2 do Treehouse
Neste número são incluídos textos de Ryan Campbell (código), Alex McClung (design), Nathan Smith (negócios), entrevistas com Peter-Paul Koch, Lisa McMillan, Josh Williams e críticas de livros "Foundations of Ajax", "Thinking with Type", "The World is Flat".





Publicada por



Carlos Afonso




à(s)

5:30 da tarde





Sem comentários:




Mensagens mais recentes


Mensagens antigas

Página inicial




Subscrever:
Mensagens (Atom)