Autor: Bruno Pulis

Consultor de acessibilidade, apaixonado por HTML e Qualidade de Software. Nas horas vagas toca flamenco e é fã de Star Wars
Consultor de acessibilidade, apaixonado por HTML e Qualidade de Software. Nas horas vagas toca flamenco e é fã de Star Wars

Acessibilidade Web

Introdução

Nesta revisão do livro “Acessibilidade na Web” de Reinaldo Ferraz, compartilho minhas impressões pessoais após concluir a leitura.

Como um tema relevante, a acessibilidade na web ainda é pouco explorada no mercado editorial brasileiro em comparação com o exterior.

No entanto, a obra de Ferraz se destaca entre os cinco livros que ele já publicou, oferecendo insights valiosos sobre o assunto. Descubra mais sobre essa leitura indispensável e confira também a publicação de Talita Pagani, uma referência no tema de acessibilidade.

Lançamento do livro

No dia 21 de março de 2020, Reinaldo Ferraz lançou pela Casa do Código, seu mais novo livro: Acessibilidade na Web: Boas práticas para construir sites e aplicações acessíveis.

Um livro completo para quem quer aventurar com acessibilidade web, o público alvo não é voltado somente para pessoas desenvolvedoras, mas também, útil para consultores, gestores, analista de negócio, produtores de conteúdo e analistas de marketing.

Organização do livro

De forma cronológica, a obra avança de forma linear e vai apronfundando-se ao decorrer dos capítulos, possuindo 15 capítulos.

Eles são sucintos e direto ao ponto, com linguagem acessível e clara. Reinaldo consegue te conduzir através da escrita sem enrolação.

Eu já tinha adquirido a versão digital na pré-venda por ser mais prático. Recentemente, após uma pausa por causa do Covid-19, voltaram com suas atividades para exemplares impressos, meu conselho é: comprem a versão impressa pois é uma referência e livros assim são ótimos para ter sempre por perto, além de auxiliar no estudo pessoal e profissional.

Os temas são específicos acompanhados explicações teóricas e práticas, li e reli a especificação de acessibilidade da W3C alguns exemplos são muitos genéricos, a compreensão muita das vezes fica confusa mas Reinaldo consegue alinhar as duas coisas de forma muito clara.

Teoria e prática

Após cada exemplo apresentando das teorias e práticas, é mostrado com clareza quem será beneficiado com essas recomendações.

Escrita

A escrita é bem tranquila, sem jargões muito técnicos e quando aparecem, Reinaldo tem todo o cuidado de exemplificar de maneira simples e objetiva. As imagens e gráficos são descritos com legendas dando contexto e compreensão. É uma leitura fluída e sem dificuldade de compreensão.

Curiosidade

No primeiro capítulo é uma verdadeira aula da web. Em um determinado ponto é contada a história da especificação da tag <img>, desde sua proposta até a inclusão do tão famoso atributo alt.

É bastante interessante sobre como a especificação de um elemento HTML, foi evoluindo e acompanhá-la, de certa forma, nos inclui nessa evolução.

Além disso, toda fundamentação teórica, possuí referências, no último capítulo é um guia das referências usadas para produzir a obra. Vale a pena verificar.

Mergulhando na acessibilidade

Após essa aula introdutória, Reinaldo nos convida a mergulhar em aspectos pouco falados no meio da comunidade web, como por exemplo, a relação das pessoas com deficiência e as tecnologias assistivas. Nesse ponto exemplifica muito bem e ainda traz recursos complementares como diversos plugins para serem usados na simulaçáo de alguma deficiência.

Explica com maestria os states, properties e roles da WAI-ARIA, em um guia bastante intuitivo e de simples compreensão.

Continuemos com o nosso passeio, além da apresentação das diretrizes de acessibilidade web a famosa WCAG é apresentado os níveis de conformidade e os princípios.

Eliminando barreiras

Reinaldo dedica cinco capítulos do livro para exemplificar a eliminação de barreiras de acesso:

  • na estrutura;
  • na navegação e interatividade;
  • no design;
  • na multimídia e conteúdo não textual.

Gerenciadores de conteúdo (CMS)

Reinaldo faz um comparativo com diversos gerenciadores de conteúdos, os famosos CMS, apontando suas vantagens e desvantagens. Depois, dicas essenciais de como incluir acessibilidade no processo de desenvolvimento de software.

Esse capítulo é bastante importante para gerentes de projetos e analista de negócios para compreenderem a importância da inclusão de todas as pessoas.

Inicia o capítulo com uma frase muito marcante:

Todo time deve estar envolvido com a acessibilidade. Deixar a acessibilidade a cargo de um único profissional pode criar gargalos e dificultar a comunicação entre os times. Se todos (designers, programadores, gestores e produtores de conteúdo) estiverem com a acessibilidade em mente durante suas atividades, a chance de o projeto contemplar mais recursos acessíveis é maior. [FERRAZ, 2020].

Nos capítulos seguintes é realizado uma pesquisa muito completa sobre algumas ferramentas de avaliação de acessibilidade automática, com seus prós e contras digno de montar um infográfico ou artigos sobre o tema.

Também há um capítulo exemplificando a Lei Brasileira de Inclusão (abre em uma nova janela), com os aspectos jurídicos que envolvem a acessibilidade no contexto digital e como se manter dentro da legislação vigente no nosso país.

E para fechar com chave de ouro, o último capítulo é uma aula de consciência ao acesso de como a Web vem tomando um caminho obscuro nas mãos de grandes corporações.

Tim Berners-Lee (abre em uma nova janela), vem alertando isso a um tempo em diversas entrevistas que concedeu sobre o tema. Sua argumentação é que a Web se perdeu do propósito original e que devemos torná-la novamente de todos e para todos.

Reinaldo para finalizar como um bom mestre jedi pontua uma frase que me marcou muito

Acessibilidade não é filantropia. É respeito pelas pessoas e por um mundo efetivamente justo em oportunidades para todos. [FERRAZ, 2020]

Outra frase bem marcante é:

Se o seu site não está pronto para receber todas as pessoas, o seu site é deficiente. [FERRAZ, 2020]

Conclusão

O livro é uma verdadeira aula de quem domina com maestria o assunto. Reinaldo consegue, destrinchar assuntos complexos em exemplos práticos e simples.

Se você tem curiosidade sobre o tema é ativista de acessibilidade assim como eu, essa deve ser sua bíblia, livro de cabeceira.

Se gestor que quer colocar seus produtos digitais em conformidade com as diretrizes de acessibilidade esse é um material que de fato irá ajudar bastante nessa caminhada.

Concluo essa review, incentivando você, leitor que compre e ajude a divulgar produções de livros nacionais, precisamos fomentar mais conteúdo relacionado sobre acessibilidade.

Patrocine publicações nacionais existe muita gente boa produzindo conteúdo em terras tupiniquis.

Seja um incentivador e não um detrator, compre e-books, livros, ajude a comunidade web a crescer e principalmente ajude a web ser de TUDO para TODOS.

Referências

  • Anúncio da publicação do livro de acessibilidade, 2020. Disponível em: Twitter Acesso em: 19 de julho de 2020;
  • Acessibilidade na Web: Boas práticas para construir sites e aplicações acessíveis, 2020. Disponível em: Livro disponível na Casa do Código Acesso em: 19 de julho de 2020;
  • Casa do Código, 2020. Disponível em : Casa do código Acesso em: 19 de julho de 2020;
  • Sobre Reinaldo Ferraz, 2020. Disponível em: Sobre Reinaldo Ferraz Acesso em: 19 de julho de 2020;
  • Como citar ebook, kindle e epub, 2020. Disponível em: Como citar ebook, kindle e epub Acesso em: 19 de julho de 2020;
  • Biografia de Tim Berners-Lee, 2020. Disponível em: Tim Berners-Lee Acesso em: 19 de julho de 2020;
  • Lei Brasileira de Inclusão, 2020. Disponível em: Lei Brasileira de inclusão Acesso em: 19 de julho de 2020.
Categoria: Indicações Tags: acessibilidade Deixe um comentário

PHPUnit: como otimizar a performance dos testes

Testes são uma das partes mais importantes na concepção de um produto digital. Através deles obtemos garantia que determinada funcionalidade cumpre com os requisitos e atende ao cliente de maneira satisfatória.

Para alcançar esse objetivo devemos ter em mente que a entrega dos testes deve ser a mais rápida possível. Com na pirâmide de testes, os unitários são rápidos, baratos e fáceis de implementar.

Subindo o nível na pirâmide o grau de complexidade aumenta e por consequência sua execução também.

Esse post irá cobrir três partes: a apresentação do problema, o uso do xdebug e configurações extras no PHP.

Esse post é a resolução de um problema que estava enfrentando no meu time. Nossos testes no backend estavam demorando cerca de 32 minutos para rodar uma suíte com 600 testes e aproximadamente 2000 asserções , confesso que estava me incomodando profundamente.

Segunda-feira iniciei um processo de investigação nos testes e o primeiro passo foi detectar os testes lentos. Mas como iria fazer isso?

Identificando os testes lentos

Pesquisando na web encontrei o artigo do Elton Minetto, onde ele apresenta um pacote chamado phpunit-speedtrap. No post do Elton ele explica passo a passo como configurar o speedtrap.

O speedtrap executa juntamente com os testes e ao final da execução exibe os 10 primeiros testes mais lentos. Com um ponto de partida, continuei a investigar e juntamente com os desenvolvedores descobrimos que alguns testes estavam com um gargalo muito grande.

Por enquanto esses testes ainda não foram refatorados, mas está no nosso radar em corrigí-los para melhorar a performance dos testes.

Logo após isso, questionei os desenvolvedores sobre outros pontos que poderiam estar afetando a execução dos testes, eles me informaram que poderia ser a extensão de debug do PHP, chamada Xdebug que vem habilitada com o framework de testes que utilizamos, o PHPUnit.

Xdebug

Meu próximo passo foi pesquisar referências na web sobre a possível lentidão dos testes relacionado ao Xdebug. Para minha sorte encontrei diversas informações a respeito que mostravam como desabilitar ou até mesmo criar filtros para melhorar a performance dos testes.

Tentei desabilitar a extensão do Xdebug no arquivo php.ini, localmente porém não tive sucesso. Eu sabia que poderia realizar esse tipo de teste, mas iria precisar de um devops para configurar essa opção no servidor.

Mais uma vez o Elton Minetto salvando a pátria. Dessa vez ele aborda em um artigo publicado em 2016, a relação da lentidão dos testes com o Xdebug, a título de comparação ele conta no artigo que possuía uma base de código que sem o Xdebug habilita terminava em 1.08 , ao habilitar o Xdebug transformou para 22.26 minutos.

Ou seja, deve um aumento significativo. Infelizmente, a opção que era apresentada no artigo não consegui realizar pois precisaria de instalar um novo pacote no servidor. 😭

Conhecendo o xdebug-filter

Seguindo o lema de ser brasileiro e não desistir nunca, persisti em buscar outras alternativas para resolver meu problema. Encontrei um artigo no próprio site do Xdebug, explicando sobre a relação da cobertura de código com o Xdebug.

Ele é frequentemente usado em combinação com PHP_CodeCoverage como parte padrão do PHPUnit. O PHPUnit atribuí uma coleção de cobertura de código para o Xdebug que por sua vez, inicia a cobertura do código por meio do método xdebug_start_code_coverage() e interrompe através do xdebug_stop_code_coverage().

Para cada teste ele utiliza o xdebug_get_code_coverage() para recuperar os resultados.

Sua saída principal é detalha quais linhas nos quais os arquivos foram “atingidos” durante a execução do código.

Usando o Xdebug para tais atividades podemos ter um impacto adicional no desempenho, pois ele irá certificar de algumas informações como:

  • analisar quais linhas de código possuem código executável;
  • quais linhas de código podem ser atingidas;
  • também podem instrumentar para descobrir quais ramificações;
  • caminhos em funções e métodos foram seguidos.

Filtros para o resgate

Desde a versão 2.6 do Xdebug é possível criar filtros para a cobertura de código. Com um filtro, podemos incluir através de uma whitelist caminhos e prefixos que podem ser executados e também é possível negar através de uma blacklist.

Um exemplo, seria informar ao PHPUnit para coletar informações somente da sua pasta src onde fica sua base de código e os outros arquivos ele iria desconsiderar, assim, dependências do Composer, arquivos de configuração seria descartados na cobertura do código.

Existem algumas formas de criar esse filtro, eu criei o filtro baseado nesse artigo. Com um filtro configurado corretamente podemos esperar um ganho de velocidade duas vezes maior.

Esses são alguns relatos de pessoas que usaram os filtros:

This is the effect on the unit test suite of @opencfp with/out xdebug filter. 44.39 vs. 15.34 seconds. I’d call that “much faster”. Great job @derickr!
(Integration tests were omitted) pic.twitter.com/LeNdaxBOOV

— Holger W🌞ltersdorf (@hollodotme) January 17, 2018

Without the filter 6 seconds
With the filter about 4.9 seconds

Anyway specifically you want me to beta test? 🙂

— Cees-Jan Kiewiet (@WyriHaximus) January 17, 2018

Antes de aplicar a técnica de filtros do Xdebug os testes estavam tinham uma execução de aproximadamente 32 minutos. 😱

Habilitando o filtro

Para criarmos o filtro basta utilizar dois comandos que irão reduzir drasticamente o tempo de execução dos testes.

O primeiro comando cria o arquivo xdebug-filter.php dentro do diretório build ele será gerado no diretório raiz da aplicação. Na minha pesquisa não verifiquei se podemos colocar ele em outro diretório.

# dump filter file
# Caso não tenha configurado globalmente o PHPUnit rode assim.
php vendor/bin/phpunit --dump-xdebug-filter build/xdebug-filter.php

# Configurado globalmente
phpunit --dump-xdebug-filter build/xdebug-filter.php

Após executar o comando do xdebug-filter sua saída é exatamente essa:

<?php
  declare(strict_types=1);

  if (!\function_exists('xdebug_set_filter')) {
    return;
  }

  \xdebug_set_filter(
    \XDEBUG_FILTER_CODE_COVERAGE,
    \XDEBUG_PATH_WHITELIST,
    ['seu-path-aqui']
  )

Executando os testes

Após a configuração iremos rodar nossa suíte de testes com o seguinte comando:

# Configuração local do PHPUnit
php vendor/bin/phpunit --prepend build/xdebug-filter.php --coverage-html build/coverage-report

# Configurado globalmente
phpunit --prepend build/xdebug-filter.php --coverage-html build/coverage-report

Com o arquivo do xdebug-filter iremos referenciá-lo nas configurações. Após aplicar as modificações do xdebug-filter, os testes executaram em 8 minutos.

Tive um ganho aproximadamente de 80% de execução! O processo agora está mais rápido e todo mundo feliz.

Dicas para o phpunit.xml

O arquivo phpunit.xml é o setup de configuração para suíte de testes que utilizam PHPUnit.

Vou mostrar alguns paramêtros que podem ser passados que irão melhorar a performance. Ele vem com uma série de paramêtros pré-configurados.

O primeiro paramêtro é o cacheResult="true", que permite o PHPUnit execute somente os testes que falharam anteriormente, com uma suíte grande testes isso é um ganho de tempo de resposta absurdo.

Podemos também usar os paramêtros stopOnFailure="true" que irá executar a suíte de testes até no momento que ela encontra alguma falha, bloqueando os restantes testes. O stopOnError="true" executa a suíte até encontrar algum erro bloqueando assim, a execução dos outros testes restantes.

O meu arquivo do phpunit.xml ficou da seguinte forma:

<?xml version="1.0" encoding="UTF-8">
  <phpunit
        backupGlobals="false"
        backupStaticAttributes="false"
        bootstrap="vendor/autoload.php"
        cacheResult="true"
        colors="true"
        convertErrorsToExceptions="true"
        convertNoticesToExceptions="true"
        convertWarningsToExceptions="true"
        processIsolation="false"
        stopOnFailure="false"
        stopOnError="false">
        <testsuites></testsuites>
        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>

        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>
    </testsuites>
    <filter>
      <whitelist addUncoveredFilesFromWhitelist="false" processUncoveredFilesFromWhitelist="true">
        <directory suffix=".php">./app</directory>
        <exclude>
          <file>./app/Modules/User/routes.php</file>
        </exclude>
      </whitelist>
    </filter>
</phpunit>

Conclusão

Ficou claro para mim que a curiosidade a gana para resolver esse problema foi o fator primordial, com isso tive vários aprendizados. Sempre seja curioso e tenta ao máximo melhorar as condições de trabalho do time.

Garantir a qualidade está também nos pequenos detalhes que podem refletir em grandes conquistas. Todas as referências de artigos que foram pesquisados estão logo abaixo.

Para se aprofundar

Categoria: Qualidade de Software Deixe um comentário

HTML Semântico: repensando sobre seu uso

Introdução

O HTML é o bloco de construção mais básico da web. É o responsável por definir duas características importantíssimas: significado e a estrutura do conteúdo da web.

Além dessas características primordiais, também contribui para um melhor posicionamento de nossas páginas na web, ocasionando assim, maior visibilidade e lucro.

Outro fator não menos importante, é a promoção do conteúdo para todas as pessoas, visto que, uma vez escrito corretamente consegue atingir todos os públicos, garantindo assim a interoperabilidade do conteúdo, sem se preocupar com plataformas ou devices.

Um breve contexto

O ano é 2020, frameworks de frontend, especialmente de javascript nascem a cada seis segundos com a promessa quase messiânica de resolver nossos problemas.

Basta rodar um comando e voilá, seu projeto está pronto só esperando fazer o que é necessário: codar.

O desenvolvedor satisfeito com a agilidade fica contente e inicia seu trabalho feliz com tudo isso, começa a criar componentes “reutilizáveis”, utiliza JSX, Typescript, Webpack, Sass, Styled Components e mais de milhares de dependências do nosso amado NPM.

Passa-se alguns dias e seu projeto vai para produção, mas será que a escrita da forma mais básica cumpre os princípios básicos de significado e conteúdo?

Bom, essa analogia demonstra a realidade de muitos de nós, pensamos nas melhores arquiteturas, tecnologias e abordagens de DevOps e o pobre e velho HTML, coitado, é deixado de lado.

Frameworks são excelentes ferramentas, mas não são uma bala de prata, devemos ter cuidados e prudência, afinal você não precisa de um canhão para matar uma formiga.

Uma tendência

Atualmente a maioria dos projetos web tem alguma lib ou framework de javascript por trás, por um lado isso é excelente, a web evoluiu e fazer frontend não é a mesma coisa do que 10 anos atrás.

Lembro dos dias áureos de Dreamwever, CSS puro e VanillaJS. Era muito difícil fazer certas coisas, hoje nossa realidade é bem mais simples, temos excelentes libs, como o React e VueJS para construir componentes reutilizáveis.

Essas libs por sua vez possuem frameworks para deixar o desenvolvimento, digamos “vitaminado”, e, ser mais rápida a produção de nossas apps.

O problema é que a maioria desses frameworks possuem erros grotescos de html, ao ponto de renderizar um componente de select, por exemplo, com várias divs aninhadas.

Um exemplo do framework Vuetify com o componente select:

<v-select :items="items" label="Standard"></v-select>

Aparentemente é um componente simples e elegante, mas qual é sua saída no código HTML? Sua saída é parecida com isso:

<div class="v-input theme--light v-text-field v-text-field--is-booted v-select"></div>
  <div class="v-input__control">
    <div role="button" aria-haspopup="listbox" aria-expanded="false" aria-owns="list-1359" class="v-input__slot">
      <div class="v-select__slot">
          <label for="input-1359" class="v-label theme--light" style="left: 0px; right: auto; position: absolute;">Standard</label>
          <div class="v-select__selections">
              <input id="input-1359" readonly="readonly" type="text" aria-readonly="false" autocomplete="off">
          </div>
          <div class="v-input__append-inner">
              <div class="v-input__icon v-input__icon--append">
                <i aria-hidden="true" class="v-icon notranslate mdi mdi-menu-down theme--light"></i>
              </div>
          </div>
          <input type="hidden">
      </div>
        <div class="v-menu"></div>
    </div>
    <div class="v-text-field__details">
        <div class="v-messages theme--light">
            <div class="v-messages__wrapper"></div>
        </div>
    </div>
  </div>
</div>

Já no bom e velho HTML, o componente de select se parece com isso.

<select>
  <option>Selecione uma opção</option>
  <option>1</option>
  <option>2</option>
  <option>3</option>
</select>

Simples, não?

Exemplos assim, estão recheados aos montes pela web. A WebAIM uma empresa que presta treinamentos e consultorias sobre acessibilidade web, realizou no ano de 2019 uma pesquisa onde mapeou 1 milhão de páginas e detectou problemas relacionados a acessibilidade. E pasmem, a maioria dos problemas não era coisas hiper complexas, mas extremamente simples.

Abaixo uma tabela demonstrando os problemas mais recorrentes nas páginas.

Falhas mais comuns de acessibilidade na web. Fonte: The WebAIM Million

Tipo de falha da WCAG% de home pages em Fevereiro de 2020% de home pages em Fevereiro de 2019
Baixo contraste86.3%85.3%
Imagens sem texto alternativo66.0%68.0%
Links vazios59.9%58.1%
Faltando label em formulários53.8%52.8%
Botões vazios28.7%25.0%
Linguagem do documento ausente28.0%33.1%

Fica nítido uma coisa, temos um problema gritante com a semântica e estrutura

HTML semântico

Quando falamos sobre semântica, estamos falando sobre o conteúdo ter significado. Assim como um livro ou TCC respeita uma estrutura lógica de hierarquia de informação o HTML também possuí.

Nele podemos marcar corretamente: datas, cabeçalhos, sessões, citações longas e curtas, paragráfos, ênfase e diversos outros recursos.

Um dos grandes problemas na web não é a falta de acessibilidade, mas escrita incorreta de HTML, CSS e Javascript.

O nosso problema é que não conseguimos fazer o básico bem feito e logo queremos usar frameworks para resolver nossos problemas…

Muitos desenvolvedores não conseguem escrever um HTML semântico, mas sabem criar um componente super complexo que um componente nativo do HTML resolveria.

Eu sempre tenho um mantra comigo: Sempre utilize componentes nativos. SEMPRE!, mas existem casos que não é possível, nossa função é informar que não utilizando um componente nativo podemos perder em semântica, acessibilidade, posicionamento e até mesmo grana.

Essa semana a Talita Pagani iniciou uma conversa no twitter sobre o mesmo tema. Você pode ver um trecho logo abaixo.

“Nós não temos um problema de acessibilidade.

Nós temos um problema de falta de conhecimento básico em HTML.

Grande parte dos problemas de acessibilidade encontrados durante inspeções vem de marcação HTML ruim.”

Como avaliadora de acessibilidade, tenho a mesma percepção. #a11y https://t.co/GM0bQS4k3s

— Talita Pagani (@talitapagani) April 28, 2020

Esse assunto no Twitter me fez lembrar de outra conversa com o Reinaldo Ferraz em um BrazilJS. Estávamos falando sobre o estado atual da acessibilidade web no Brasil e os avanços que temos feito. Ele disse uma frase que me marcou muito:

> Estamos em um momento que as pessoas precisam reaprender como escrever HTML. Só assim, conseguiremos tornar a web mais inclusiva.

Conclusão

A minha dica é desacelerar e voltar a base, não adianta nada saber os melhores frameworks e técnicas de desenvolvimento frontend, sendo que, o essencial não está bem fundado.

Isso me lembra a Parábola dos dois fundamentos, segue um trecho:

Todo aquele, pois, que escuta estas minhas palavras, e as pratica, assemelhá-lo-ei ao homem prudente, que edificou a sua casa sobre a rocha;
E desceu a chuva, e correram rios, e assopraram ventos, e combateram aquela casa, e não caiu, porque estava edificada sobre a rocha.
E aquele que ouve estas minhas palavras, e não as cumpre, compará-lo-ei ao homem insensato, que edificou a sua casa sobre a areia;
E desceu a chuva, e correram rios, e assopraram ventos, e combateram aquela casa, e caiu, e foi grande a sua queda.
(Mateus 7:24-27)

Uma fundação com estrutura sólida nos dá segurança e confiança, mas uma fundação sem segurança e instável é passível de diversas falhas.

A fundação HTML, CSS, Javascript devem ser sólidas, frameworks vem e vão.
Que tal refletirmos e escrevermos de forma semântica?

Para aprofundar

Escolhi alguns links para aprofundar no assunto.

Referências:

Categoria: Desenvolvimento acessível 3 Comentários

Para que serve o atributo lang no HTML?

Se você está começando ou já tem experiência com HTML, com certeza já deve ter notado o atributo lang no seu código.

Mas afinal, qual é a utilidade dele?

Nesse artigo, vou te mostrar sua utilidade e importância.

Por que isso é importante

O atributo lang faz parte da família dos atributos globais do HTML, eles podem ser usados sem restrição em quase todos os elementos.

Seu objetivo é fornecer um mecanismo de internacionalização do conteúdo.

Podemos usar de duas formas:

  • definir o idioma do documento inteiro;
  • definir o idioma para partes do documento.

Podemos definir os idiomas através de uma lista de idiomas.

Usando o idioma para o documento inteiro:

<!-- um documento HTML em espanhol -->
<html lang="es">

Usando para partes do documento

<!-- um documento HTML em espanhol com uma palavra em inglês -->
<p>Acepta su <span lang="en">feedback</span></p>

Qual a relação do atributo lang com acessibilidade?

Na WCAG existem dois critérios relacionados ao idioma:

Idioma da página

A intenção deste Critério de Sucesso é garantir que os desenvolvedores forneçam informações para apresentar conteúdo textual em outros idioma corretamente.

Quem se beneficia?

  • pessoas que usam leitores de tela;
  • pessoas com dificuldade em ler material escrito com fluência e precisão;
  • pessoas com certas dificuldades cognitivas;
  • pessoas que dependem de legendas para mídia sincronizada.

Exemplos

Uma página produzida na Alemanha e escrita em HTML inclui conteúdo em alemão e inglês, mas a maior parte do conteúdo está em alemão. A língua padrão é identificada como alemão (de) pelo atributo lang no elemento HTML.

<!-- um documento HTML com conteúdo em alemão -->
<html lang="de">

Idiomas em partes

Seu objetivo é garantir que o browser pode apresentar as frase de forma correta. Esse critério apresente o conteúdo considerando:

  • entonação;
  • pronúncia;
  • sotaque;
  • particularidades da língua.

Além disso, os leitores de telas conseguem diferenciar palavras de outro idioma. Fornecendo todas as particularidades do idioma.

Ponto importante: essa configuração pode ser desabilitada no leitor de telas.

Quem se beneficia?

Todas as pessoas que se beneficiam com o critério 3.1.1 Idioma da página.

Exemplos

Uma site com internaciolização que possui links para versões da página em outros idiomas (por exemplo, Alemão, Francês, Holandês, Catalão e etc.). O texto de cada link é o nome do idioma.

O idioma de cada link é indicado através de um atributo. lang

<ul>
  <li><a href="..." lang="de">Deutsch</a></li>
  <li><a href="..." lang="it">Italiano</a></li>
  <li><a href="..." lang="fr">Français</a></li>
  ...
  <li><a href="..." lang="zh-hant">繁體中文</a></li>
</ul>

Quando usar atributo lang?

O atributo lang deve ser usado sempre, ele é obrigatório.

Use o axe dev tools para validar uma página sem o atributo.

Print do axe dev tools informando que o uso do atributo lang é obrigatório.

Conclusão

Percebemos que o atributo é extremamente importante para nossas páginas web e sua implementação é bastante simples. Existem casos em sites multilíngues que o atributo pode ser alterado dinamicamente via linguagens de programação. Meu conselho é: sempre que iniciar o desenvolvimento de uma página defina a linguagem e não tenha esse tipo de problema.

Gostou? Tem alguma dúvida ou sugestão? Escreva um comentário.

Referências

  • [1] Atributos globais > Lang. Mozilla Developer Network, 2019. Disponível em: Atributo lang. Acesso em: 14 de jan. de 2020.
  • [2] 3.1.1 – Language of Page (Level A). WUHCAG, 2019. Disponível em Language of Page. Acesso em 14 de jan. de 2020.
Categoria: Desenvolvimento acessível 3 Comentários

Review: TDC BH 19

The Developer Conference BH 2019

Nos dias 13 a 15 de junho, aconteceu a primeira edição mineira do TDC, um evento que acontece desde 2006.

O TDC é um evento composto por trilhas, onde cada participante pode escolher uma trilha específica para acompanhar os assuntos desenvolvidos nelas.

O interessante das trilhas são os conteúdos focados ao tema tratado e palestras objetivas. Das trilhas que participei — Lounge de Diversidade e Carreiras e Testes — pude perceber que as palestras foram objetivas e claras nos temas que tratavam.

O local

O evento aconteceu na UniBH – Campus Buritis, numa área onde conseguiram aproveitar bem o espaço.

A única objeção, talvez, seria a distância do local. Por se tratar de um bairro mais distante em Belo Horizonte — para mim não foi um grande problema, pois na minha região havia diversas linhas de ônibus que poderia utilizar — não é um local que tenha um fácil acesso para todos.

Credenciamento

Dos eventos que já participei (e olha que não foram poucos rs) para mim o TDC brilhou nesse quesito, com várias cabines para as pessoas serem atendidas, essa etapa não teve nenhum problema. O meu credenciamento, por exemplo, foi extremamente rápido e cordial.

Outro diferencial foi a entrada do evento, onde os seguranças tinham um leitor de código de barras que lia cada vez que você entrava e saia do local.

Expositores

A disposição de cada expositor foi estratégica e muito bem montada, todos foram bem cordiais, mostrando interesse em fazer networking e, obviamente, com vários brindes.

Internet

Um dos problemas mais recorrentes de eventos de TI é a conexão com a internet. No TDC, porém, não tive nenhum problema em conectar com as redes disponibilizadas pelo evento. Permaneceram estáveis em tempo integral e com uma boa velocidade.

Carregamento de dispositivos

O evento possuía um stand com diversas tomadas para dar carga nos aparelhos, possibilitando assim, todos estarem ligados sem perder nenhum momento do evento.

Salas para as trilhas

O maior espaço era a Trilha Stadium, um espaço montado com uma forma de palestra muda, onde os participantes utilizaram um aparelho com uma rádio-transmissão infravermelha para ouvir a palestra.

Confesso que como palestrante achei um pouco diferente, uma nova experiência eu diria.

Palestra

Nesse evento tive o prazer e a oportunidade de poder palestrar sobre Acessibilidade mais uma vez.

Gostaria de deixar meu agradecimento ao Thiago Marques pelo incentivo e apoio para mandar uma proposta de palestra.

Além do Thiago me incentivar, ele palestrou e foi coordenador do Lounge de Diversidade e Carreiras. Sempre um prazer poder assisti-lo, Thiago inspira nas pessoas a ser empático com uma causa que muitos esquecem ou não tem conhecimento de sua existência.

Mentoria para palestrantes

Um recurso muito interessante no site do TDC é a sessão de Mentoria para palestrantes, realizada pelo Bruno Souza, onde o intuito é dar dicas de oratória para palestrantes de primeira viagem ou pessoas que queiram aprimorar sua desenvoltura em como comunicar o conteúdo.

Assisti uma live no YouTube e o conteúdo foi bastante rico e incentivador.

Envio da proposta

Lembro de escrever a proposta e pensar que não iria ser aprovada — bateu uma síndrome de impostor na hora (rs)!
Confesso que fiquei extremamente feliz, por receber a notícia que o tema da minha palestra tinha sido escolhido para o evento.

O processo para enviar a palestra foi muito organizado e o tempo de resposta também. Meu tema foi: Always bet on a11y em uma tradução literal “Sempre aposte em acessibilidade”, onde expus sobre as vantagens de sempre apostar e abraçar os padrões web e como eles podem melhorar a interação entre os usuários e os negócios das empresas.

Você pode consultar a minha palestra no Speaker Deck. Além da minha palestra, o TDC cordialmente deu alguns brindes para os palestrantes.

Além de mim, a Monetizze também foi representada pelo Bruno Vasconcelos na Trilha de UX, onde ele falou sobre o desenvolvimento de uma cultura de ux.

Bruno Vasconcelos palestrando na trilha de UX

Almoço

O evento possuía uma estrutura com um ticket para almoço dando direito a uma bebida e um lanche de food truck, além da possibilidade de comer em lanchonetes da própria faculdade.

Um ponto positivo, pois, sair para comer próximo a faculdade poderia sair caro e demorar, em razão da quantidade de pessoas. Não houve uma fila grande para todos poderem almoçar e tudo estava alinhado conforme o esperado.

Coffee Break

Geralmente os intervalos de eventos de tecnologia acabam rápido, mas dessa vez o TDC cumpriu com maestria e não deixou ninguém com fome. Ele contava com uma variedade de alimentos como: frutas, café, chá, sucos, bolos.

Inclusão

Uma das coisas mais impressionantes para mim, como defensor da acessibilidade, foi assistir as palestras sendo inclusivas com as pessoas com deficiência.

Confesso que me encheu de orgulho poder presenciar mais um evento que de fato se importa com a diversidade do público.

TDC Inspire e TDC4Kids

Duas iniciativas muito interessantes que aconteceram no meio dessa gama de palestras foi o TDC Inspire e o TDC4Kids.

TDC Inspire

De acordo com o próprio site do TDC, o Inspire visa:

Despertar e incentivar o interesse dos jovens para área de tecnologia, contribuindo para uma escolha profissional pautada nos desafios do futuro.
Ele é oferecido gratuitamente para 40 estudantes do terceiro ano do ensino médio regular e/ou profissionalizante das escolas públicas.[1]

Logo após a mentoria do TDC Inspire os jovens apresentaram no Stadium o protótipo de suas ideias. Era visível o orgulho dos mentores pelo empenho e esforço dos jovens com suas ideias, muitas delas passíveis de serem implementadas.

TDC4Kids

O TDC4Kids busca estimular e favorecer o uso de tecnologias pelas crianças, promovendo o aprendizado baseado em projetos em um ambiente lúdico e divertido.
Todas as atividades realizadas são pensadas para despertar as habilidades e aptidões necessárias para o futuro através da programação, empreendedorismo e design.
No formato de circuito, as crianças podem participar de todo os workshops, circulando entre as diversas propostas, participando conforme o seu interesse[2]

Conclusão

O TDCBH foi uma experiência única em todos os sentidos. Não poderia deixar de dar um enorme agradecimento para Yara Senger e equipe, aos coordenadores das trilhas, voluntários e palestrantes.

Muito obrigado por trazer um evento de grande qualidade para Belo Horizonte.

E sim como foi dito, foi um sonho realizado e que venha o TDCBH 2020!

Referências

Categoria: Indicações Deixe um comentário

21 qualidades de um bom QA

Post traduzido e adaptado por Bruno Pulis e escrito originalmente por Try QA.

Atualmente, toda organização está usando tecnologia. De grandes mídias a gigantes têxteis, fundos mútuos a startups, cada uma tem seus requisitos exclusivos de software e automação. Embora o desenvolvimento e a implementação do software sejam vitais para essas organizações, há uma necessidade crescente de bons testadores de software que adoram testar.

Uma pergunta comum é: “Como se tornar um testador de software? Antes de entrar nos detalhes técnicos dos testes de software , é importante garantir que você tenha as características necessárias para um testador.

Os testadores de software são a espinha dorsal de todas as organizações, porque eles são os responsáveis por garantir a qualidade do projeto ou produto. Mas como você identifica o o melhor dos melhores entre os testadores? Aqui estão 21 qualidades e características que são geralmente vistas em grandes testadores:

Tenha uma mente criativa

Esse é um dos traços mais indispensáveis de um ótimo testador de software. Os profissionais de teste precisam pensar muito além do que é esperado do software e dos usuários. Eles devem ser capazes de pensar como os usuários podem fazer coisas que certamente não estão explicitadas nos requisitos de software ou como podem abusar do software.

Seja analítico

Essas habilidades são essenciais para a análise de requisitos e para a compreensão do feedback do cliente ao definir a estratégia de teste. As habilidades analíticas também são imprescindíveis para obter informações, a fim de criar soluções de teste inteligentes. Os testadores precisam compreender os dados coletados nos testes e analisá-los quanto ao comportamento específico do produto ou aplicativo.

Mantenha sua curiosidade

A característica é indispensável quando se trata de considerar as consequências. Os testadores curiosos costumam pensar imediatamente , para que possam determinar problemas em áreas onde ninguém mais pode pensar em procurar.

Saiba ouvir

Uma ótima qualidade dos testadores ouvir os outros. Eles devem saber que sempre há espaço para melhorias. Eles também devem prestar atenção se alguém estiver dando alguma idéia ou implicação, pois isso certamente os ajudará a melhorar a qualidade do programa de software em teste. Você pode descobrir alguns cenários que outras pessoas podem perder se não estiverem prestando atenção.

Seja proativo

A responsabilidade de um ótimo testador não é apenas validar softwares contra os requisitos estabelecidos. Ótimos testadores são apaixonados pelo seu trabalho e fornecem sugestões para melhorar o produto. Às vezes, os testadores apaixonados se tornam gerente de produto ou PO’s.

Aprenda rápido

Ótimos testadores devem estar bem familiarizados com a tecnologia. Eles sempre devem estar abertos para aprender novas ferramentas de automação, acompanhar as últimas tecnologias, usar as mais recentes técnicas durante os testes, aprender com suas experiências e aprender a ter novas ideias.

Tenha conhecimento do domínio

Para executar uma sessão de teste bem-sucedida e projetar testes eficazes, bons testadores devem ter um bom conhecimento do domínio da aplicação. Eles devem ter uma visão profunda de como os usuários finais explorarão o programa. Eles também devem gastar tempo para entender a terminologia de seu domínio específico e ajudar a conceber cenários estratégicos de casos de negócios.

Soluções orientadas a necessidade do cliente

Os grandes testadores devem sempre tentar fazer seus clientes felizes. Eles devem entender que os clientes não possuem as mesmas habilidades técnicas que os testadores. Os clientes podem não ter experiência no domínio ou na tecnologia e podem não ter todos os cenários e casos de uso que possam surgir. Eles devem fazer o melhor uso possível de suas habilidades de teste, tendo em mente a mentalidade de seus clientes enquanto entregam o produto que eles realmente exigem.

Automação de teste e conhecimento técnico

Eles devem ter um conhecimento técnico sólido para determinar quais testes devem ser automatizados em qual camada, executar testes constantemente, utilizar a disponibilidade de várias ferramentas de teste, fornecer métricas válidas para a organização e escolher as melhores e mais apropriadas. conjunto de ferramentas para ajudar no esforço de teste.

Organização e priorização

Um grande testador deve ter a capacidade de identificar e organizar primeiro os testes essenciais e, posteriormente, priorizar a execução com base na relevância do teste. Além disso, ao avaliar os esforços de teste, bons testadores devem considerar o histórico de defeitos.

Boa comunicação

Devemos ter a capacidade de se comunicar com pessoas não técnicas e técnicas. Eles também devem possuir a capacidade de se comunicar efetivamente de forma escrita ou oral e transmitir os detalhes de um problema à equipe de desenvolvimento. Um bom documento passo a passo para reproduzir o defeito ajuda os desenvolvedores a concentrarem seus esforços na correção do problema, e não na comunicação.

Capacidade de relatar problemas

Ninguém estará interessado em saber o número de casos de teste executados pelos testadores de software. É por isso que um bom testador deve ser bom em relatar seu status atual no final do dia. Eles devem fornecer relatórios de erros detalhados e eficazes e também anexar capturas de tela, se possível, juntamente com o relatório.

Atento aos detalhes

Os grandes testadores estão atentos aos detalhes. Essa qualidade é útil ao validar lógica de negócios complexa e garantir que todos os cenários sejam cobertos. Também ajuda a evitar multas ou custos mais altos de correção de defeitos encontrados no final do ciclo ou após o lançamento da produção.

Orientados ao negócio

Um ótimo testador de software deve ser capaz de entender o software do ponto de vista comercial, apreciar os requisitos dos clientes, ter a capacidade de entender as pessoas do ponto de vista não técnico. Ele também deve ser capaz de entender como os problemas de negócios podem ser convertidos em soluções técnicas.

Capacidade intelectual

Devem ser inteligentes o suficiente para usar sua capacidade lógica, a fim de operar em um ambiente de teste de alto nível. Eles devem ter a capacidade de solucionar problemas da origem de um problema e resolvê-lo da melhor maneira possível.

Bom observador

Manter o controle dos itens secundários e dos principais projetos discutidos é extremamente importante para um grande testador. Em um ambiente dinâmico como uma startup, as coisas mudam rapidamente. É importante poder acessar o impacto da mudança e ficar por dentro das mudanças. Além disso, acompanhar o andamento do teste e fazer as alterações necessárias, se necessário, também é muito crucial.

Boa gestão de tempo

A maioria das equipes fica restrita pela quantidade de tempo disponível para desenvolvimento e teste. Os testadores precisam entender sua prioridade e gerenciar bem seu tempo. Eles precisam saber o que deve ser testado e o que deve receber menos prioridade.

Quais tarefas devem ser executadas primeiro e quais podem ser realizadas no final, o que deve ser automatizado e o que deve ser testado manualmente.

Quão importante é a documentação comparada com a execução real do caso de teste, no tempo determinado? Eles devem ser capazes de responder a essas e outras perguntas e ajudar seus gerentes a tomar a decisão certa.

Seja perseverante

Grandes testadores nunca desistem. Eles são pacientes o suficiente para encontrar o maior número possível de bugs. Eles exploram o software, constantemente tentam fazer novas melhorias e aceitam todos os desafios e complexidades dos testes de maneira positiva e paciente.

Identificar e gerenciar riscos

Eles devem ser capazes de entender o processo adequado de gerenciamento de riscos – identificação de riscos, análise de riscos e redução de riscos. O teste de software deve ser baseado na incorporação de processos de teste orientados a riscos.

Orientados à qualidade

Ótimos profissionais de software não comprometem a qualidade em nenhum estágio de teste. Os resultados orientados à qualidade sempre levam a defeitos no software livre e garantem uma qualidade de primeira.

Trabalho em equipe

Os testadores de software devem ser capazes de trabalhar bem dentro e fora da equipe. A troca de ideias, conhecimentos, experiências e pensamentos pode aumentar a qualidade e a eficiência da solução, para que os grandes testadores sempre estejam ansiosos para coordenar bem com os membros de sua equipe e outras equipes.

Conclusão

Tais características auxiliam o desenvolvimento profissional do analista de qualidade de software. Desta forma, contribuem também para a evolução do produto e do time em âmbito geral.

Identificou alguma característica citada aqui? Faltou alguma que na sua opinião é importante, me diga nos comentários

Categoria: Qualidade de Software Deixe um comentário

DevFest BH 2017

O local

O Devfest da edição mineira, foi no One Bussiness Center na Raja Gabália. Uma excelente acomodação para um evento desse porte. Além, do local ser bem conservado e contar com estacionamento próprio, a equipe do GDG BH deu um show no quesito de organização.

A organização

Era nítido a sincronização da equipe para suprir as necessidades dos participantes e palestrantes. A todo tempo viamos a equipe se comunicando via rádio para deixar o evento impecavél e de fato conseguiram. Via um ar de cuidado misturado com um pouco de preocupação no Yan Magalhães toda vez que entrava na sala dos palestrantes, mas era uma preocupação que tudo ocorre-se bem, saiba tu brilhou jovem. ❤

As palestras

As palestras foram divididas em três ambientes e cada apresentadora ficou responsável por cada trilha, vale ressaltar que durante vários eventos que já participei esse foi o primeiro e ter somente apresentadoras. Que outros eventos possam se inspirar nesse modelo.

A minha palestra foi na última trilha contando com dois monitores e um projetor, não tive nenhum problema técnico para a apresentação do tema, o que eu mais gostei foi a presença de duas pessoas surdas e uma com baixa visão que puderam atestar o preço da falta de acessibilidade em nossos produtos.

Estamos juntos (we are together)

Esse evento foi diferente porque foi o primeiro que vi a preocupação em questões acessíveis. Recebi elogios das pessoas com deficiência que citei anteriormente, segundo elas, adoraram foi bastante gratificante.

Mesmo não estando muito bem de saúde por um mau súbito no dia anterior, uni forças para palestrar e o resultado foi recompensador. Sai de lá com sentimento de dever cumprido.

Ter amigos na platéia me incentivando foi emocionante para mim obrigado a todos que compareceram ❤

Um pouco de filosofia

O slogan do evento #wearetogether, se assemelha bastante com uma filosofia africana bastante conhecida por uma distribuição linux o Ubuntu. O significado se refere a humanidade com os outros. Trata-se de um conceito amplo sobre a essência do ser humano e a forma como se comporta em sociedade.

Para os africanos, ubuntu é a capacidade humana de compreender, aceitar e tratar bem o outro, uma ideia semelhante à do “amor ao próximo”.

Ubuntu significa generosidade, solidariedade, compaixão com os necessitados, e o desejo sincero de felicidade e harmonia entre os seres humanos.

Semelhantemente a um trecho de um livro conhecido “ame teu próximo como a ti mesmo”

Isso é ser #wearetogether é posso te afirmar o DevfestBH2017 mostrou que é possível ser empático e humano de maneira magistral.

Que mais eventos voltados para tecnologia possam ter esse tipo de preocupação e compreender que cada vez mais o maior valor são as pessoas.

Categoria: Indicações Deixe um comentário

Review: Node School BH 17

Fala galera, nos dois últimos sábados aconteceram o Node School BH uma iniciativa open-source para promover workshop’s presenciais e partilhar conhecimento.

O evento contou com mentores para auxiliar os participantes em suas dúvidas e explicações voltadas ao mundo da programação. Foi a minha primeira edição como mentor e gostei bastante de poder gastar meu tempo em ajudar aqueles interessados em Node e Javascript.

Localização

Ele foi realizado no Guaja Café Co-working, até então não tinha ido lá gostei bastante. O ambiente é agradável e aconchegante, se você trabalha remotamente ou é um freelancer e procura um lugar em Belo Horizonte tranquilo com boa ambientação,gente bonita e boa localização vale a pena dar uma conferida nele.

Entrada do Guaja Coworking. Na imagem existem três mulheres sentadas ao fundo em uma mesa de madeira clara e um homem com um notebook aberto em um sofá.

O NodeSchool

O evento teve ínicio com um Coffee Break, depois fomos para as apresentações dos mentores e dos participantes.
A parte mais curiosa foi as apresentações dos participantes tínhamos pessoas de áreas distintas, como: advocacia, marketing, geografia, design e programadores. E conseguimos vislumbrar um pouco das expectativas e objetivos em relação ao Workshop.

Logo após, o Wharley iniciou uma apresentação de sua carreira como desenvolvedor de software e me impressionou a força de vontade e determinação, mesmo em meio a várias dificuldades ele permaneceu firme naquilo que acredita e isso me inspirou de uma forma bastante profunda e me deixou pensando algo que um amigo me disse uma vez:

O único que irá sabotar sua carreira e você mesmo.

Moral da história, correr atrás dos nossos objetivos com garra e determinação é o que te faz alguém bem sucedido.

O mais legal de Workshops e eventos é o contato com as pessoas, descobrir realidades diferentes e tão comuns ao mesmo tempo, poder se doar para ajudar pessoas em crescer profissionalmente não tem preço ou tempo que pague. Por causa de um NodeSchool em 2015 o Wharley, hoje é um desenvolvedor de software. Tivemos um testemunho vivo de como eventos da comunidade pode mudar a vida das pessoas.

A lição que retiro disso é seja mais humano, ajude as pessoas a se desenvolverem, incentive a irem em eventos, meetups, workshop’s e assim, quem sabe, você não inspira pessoas como a história de Wharley nos inspirou em um dia de sábado?

Categoria: Indicações Deixe um comentário

GAAD: Global Accessibility Awareness Day 17

Fala pessoal, nesse post vou contar um pouco de como foi participar no Global Acessibility Awarenss da edição de Belo Horizonte promovido pelo IXDABH.

Objetivos do evento

O objetivo é promover conversas sobre acessibilidade com metodologias usadas no mercado ou desenvolvidas por conta própria, que promovam a acessibilidade e inclusão digital (web, softwares, celulares, etc) e pessoas com necessidades diferentes.

O Global Acessibility Awarness Day ou #GAAD2017 é um evento mundial na data de 18 de Março, sobre conscientização e promoção da Acessibilidade no meio digital.

História do evento

A ideia do GAAD começou com um post em um blog escrito pelo Joe Devon um desenvolvedor de web de Los Angeles, Jennison Asuncion, um profissional de acessibilidade de Toronto, descobriu o post do blog do Joe por acidente, através do Twitter.

Depois de ler o post, Jennison contactou Joe imediatamente e eles uniram as forças, impulsionando a respeitada e extensa network de ambos para realizar o evento.

Eventos Online

Países participantes

  • Belo Horizonte, Brasil
  • Itália
  • Estados Unidos
  • Índia
  • Suíça (17/05)
  • Alemanha
  • Austrália
  • Tchecoslováquia
  • África do Sul
  • Dinamarca
  • Holanda;
  • Canadá
  • Japão
  • Inglaterra
  • Suécia.

Acesse os locais atualizados do GAAD17

O convite

Eu entrei no grupo de IXDABH e vi sobre o evento é logo marquei minha presença. Uns dias depois, o Alan Vasconcelos me enviou um e-mail convidando para ministrar um Dojo de acessibilidade, obviamente aceitei de prontidão.

Apresentações

O Alan iniciou se apresentando e colocando em xeque o Design Universal excelente tema para se abordar nesse evento, visto que um dos conceitos mais fortes é perda do público alvo.

Logo após, fiz uma breve apresentação, comentando sobre alguns dados estatísticos da população com algum tipo de deficiência no Brasil e sobre leis federais para adequar os sites na questão da Acessibilidade.

O Dojo

Criamos duas personas para contar suas estórias sobre a dificuldade de navegação na web, possuem contextos diferente e necessidades diferentes.
O dojo se dividiu em duas etapas: análise do problema e resolução dos problemas encontrados.

Provocamos alguns erros na marcação do HTML, como por exemplo:

  • retirada do atributo Lang
  • ausência de atributo for nos formulários
  • hierarquia de títulos de forma errônea.

A seguir, vou compartilhar as estória das personas que criamos para aplicar o teste.

Estória da Beatriz

Beatriz adora ficar de bobeira na internet. Aos 36 anos de idade, às vezes ela passa horas no Facebook, ou mesmo, lendo textões no Medium. Ela também gosta de saber o que está acontecendo com o mundo, por meio dos grandes portais de notícias como El Paìs e BBC Brasil. Ou seja, Beatriz é uma internauta típica, exceto por um detalhe: Beatriz é cega.

Sendo uma internauta experiente (sim, ela já teve um e-mail do BOL, usou internet discada e pesquisou no Cadê), Beatriz tem uma grande desenvoltura com as tecnologias assistivas como leitores de tela, teclas de atalho e até displays em Braile. Mas isso não quer dizer que sua vida na Web seja fácil. A grande parte dos sites de hoje são pesados e cheios de barreiras de acessibilidade.

Minha mão chega a doer de tanto apertar o Tab. Pra quê tanto menu, gente? Eu só quero chegar ao texto! Isso sem falar quando o texto não está estruturado corretamente:

Outro dia, eu estava com uma dúvida sobre imposto de renda e achei um site do governo com todas as instruções que eu queria. Mas aí, fui procurar o título do texto, porém só encontrava o nome do site.

Estória do Roberto

Roberto é um advogado de 61 anos que usa muito a internet para consultar leis, jurisprudências e demais casos que o auxiliam no seu trabalho. Mas, às vezes, Roberto tem muita dificuldade em clicar nos links do portal jurídico.

Fui fazer uma busca avançada e não conseguia acertar aquela “bolinha” para marcar a opção: “Buscar apenas os Decretos-lei”. Será que não dava pra ser maior?

Roberto também não fica muito satisfeito com o contraste:

Poxa… um texto cinza, em cima de uma caixa cinza-claro, não ficou legal… E que letrinha miúda é essa, gente?

Desenvolvimento

Trabalhamos em cima dessas duas estórias e analisamos e propusemos as soluções corretas, no meio do Dojo, os irmãos Fot que estavam palestrando sobre inclusividade no mercado de trabalho, desceram e participaram do Dojo conosco, um detalhe ambos são cegos, o que foi muito enriquecedor para o momento.
Eles testaram o site juntamente conosco mostrando as dificuldades que encontram no dia a dia para navegar em sites da web.

Conclusão

Para mim foi uma experiência única e enriquecedora, pois percebi que é possível tornar a web mais inclusiva e acessível a todos os públicos.

Categoria: Indicações Deixe um comentário