segunda-feira, fevereiro 13, 2006

Acessibilidade - Brilho e Contraste das Cores

Quando criamos uma página, damos a ela uma cor de fundo e a cor do texto. Muitos utilizam as cores padrão, fundo branco e texto preto, que aliás é a melhor combinação para leitura, mas não quer dizer que você não possa utilizar outras combinações ou que as seus experiêntos não serão acessíveis ou bonitos. O problema é que às vezes você quer forçar um estilo que não é legal, por mais que você consiga ler. apesar de ainda aberto para alterações, a W3C possui dois algorítimos em seu site para analizar se essa combinação oferece uma boa visibilidade: um para o brilho e outro para o contraste das cores.
Para cada cor devem ser aplicadas essas fórmulas:

Brilho =
[(vermelho x 299) + (verde x 587) + (azul x 114)] / 1000
Esse algotítimo usa a fórmula de conversão de RGB para YIQ que diz o brilho percebido para uma cor. Uma diferença maior que 125 é considerada ideal.

Contraste =
[máximo(vermelho 1 e vermelho 2) - mínimo(vermelho 1 e vermelho 2)] +
[máximo(verde 1 e verde 2) - mínimo(verde 1 e verde 2)] +
[máximo(azul 1 e azul 2) - mínimo(azul 1 e azul 2)]
No caso do contraste, a diferença ideal é de 500.

Assim, pelo menos, você sabe que o conteúdo é visível tornando sua página bem acessível. Utilize sempre que pintar uma dúvida, ou se preferir, sempre que criar ou modificar algum elemento com atributo de cor (body, table, td, th, hr).

Abraço!

segunda-feira, fevereiro 06, 2006

Requisitos

Requisitos é um monte de coisa indispensável que o sistema deve fazer. Eles podem ser:
Funcionais - funções e ações do sistema (gerar relatório, permitir manutenção dos cadastros)
Não Funcionais - restrições, padrões e frescuras (tempo de saída automática do sistema [logoff], usabilidade, posicionamento do logo da empresa [isso afeta o visual...])
Essa coisas são definidas pelo usuário e especificadas pelo analista, no caso você, que deve documentar tudo para não ter problemas depois. É na fase de elicitação de requisitos que se conhece os atores (quem age), as necessidades (o que ele quer que o sistema satisfaça) e suas funcionalidades (o que deve fazer para atender as necessidades), tira a medida do projeto (tamanho, custo e esforço, principalmente), cria os casos de uso ligados às funcionalidades (uma historinha passo-a-passo da interação entre os atores e as atividades/ações), regras de negócio a serem seguidas na aplicação, faz o glossário para o cliente e você, e quem ler a documentação, entender tudo que se passa.
É complicado, mas normalmente o cliente muda alguma coisa no decorrer do projeto, inventa uma necessidade ou diz que algo não é mais necessário ou quer diferente, por isso, se esforce para sugar e questionar ao máximo os requisitos que você pegou e, assim, depois se estressar menos com as mudanças. Lembre-se de analisar o impacto dessas mudanças, hein! Cliente é fogo!