Ir para o conteúdo principal
Niquelao Acessibilidade web e desenvolvimento front-end em espanhol: padrões WCAG, widgets acessíveis e extensões para Firefox, explicados com código real.

Alguns links neste site são links de afiliados: se comprar através deles, podemos ganhar uma comissão sem custos adicionais para si. Isto nunca afeta o que recomendamos. Consulte a nossa divulgação de afiliados para mais detalhes. Divulgação de afiliados.

Niquelao » Arquivo do blog » Eu também vi…

Não é que me proponha escrevê-lo de costas, mas vou começar por citar (em blockquote) o conselho com que o concluirei: A não ser que sejamos originais e queiramos mostrar essa caixa gerada pelo campo oculto (“quase oculto”), a solução é simples. Aplicamos-lhe ” display: none ” e está resolvido.

O meu conselho é que não se tente marcar os campos ocultos com uma classe para depois lhe aplicar a propriedade que acabei de escrever. Em vez disso, pode aproveitar-se o facto de o Firefox compreender e interpretar os seletores de atributos : [css]input[type=hidden] { display: none; }[/css] Ao assunto… Não, não é que este artigo trate de como maquetar o que teoricamente deveria estar oculto (um campo do tipo hidden ), e digo teoricamente porque acontece que no navegador Firefox , quando temos a CSS ativa e declaramos determinados valores para a propriedade ” display ” sobre os campos de formulário, os campos ocultos deixam de o ser e passam a ser renderizados pelo navegador (tal como se pode apreciar se se observar o exemplo com o navegador Firefox ou, se confiar em nós e acreditar no que dizemos, nas seguintes capturas de ecrã).

Chegados a este ponto, poderiam surgir perguntas: porquê aplicar um display sobre um campo ” hidden ”?; se a finalidade de um campo oculto é passar informação sem se mostrar, porquê querer mostrá-lo?;… A resposta é fácil e talvez se compreenda melhor com um exemplo: Temos o seguinte formulário: [html] [/html]…ao qual aplicamos uns estilos básicos: [css]form { border: 2px outset; background-color: #CCCCCC; } fieldset { margin: 20px auto; width: 500px; border: 1px solid; padding: 10px; } legend { font-size: 1.5em; color: #000; } label { font-weight: bold; font-size: 1.1em; } fieldset input { display: block; width: 90%; height: 1.3em; line-height: 1.3em; margin-left: 5%; font-size: 1em; } p { text-align: center; margin: 1em 0; } fieldset p { text-align: left }[/css] Aplicámos-lhe um display: block aos campos de formulário para que provoquem a quebra de linha, permitindo que o texto que os etiqueta fique por cima.

A disposição imediatamente por cima dos campos de texto das etiquetas favorece que a caixa anónima de texto que geram tenha maior superfície de contacto sobre a caixa do campo, com o que visualmente transmite melhor e de forma mais rápida a associação entre ambos (além disso, é a maneira como gosto de o pôr, e pronto). Talvez se entenda melhor visualmente: Na imagem anterior mostram-se três formas de maquetar o mesmo formulário. Na primeira coloca-se o texto do label por cima do campo, com o que a sua superfície de contacto é maior.

Nas outras duas pode apreciar-se como diminui essa superfície se o texto se situar junto ao campo que etiqueta. Além disso, a terceira mostra o problema de querer alinhar os campos entre si.

Além disso, desta forma poderiam alinhar-se à esquerda todos os campos de texto, coisa que pode ser desejável em muitas ocasiões e que pode criar conflitos quando a etiqueta antecede o campo (dado que estas não costumam ter o mesmo comprimento). A questão é que ao dar esta propriedade aos ” input ”, no Firefox, e unicamente no Firefox, renderiza-se o campo oculto, fazendo-o como um bloco vazio. Comportamento correto ou bug? Se observarmos o comportamento do IE apreciar-se-á que isto não acontece.

Related: con plan gratuito para empezar hoy mismo.

A estas alturas, os detractores do IE já estarão a dizer que o Firefox faz o correto, pois nos castings costumam selecioná-lo para o papel do bom. Neste caso que cada um tire as suas conclusões, não sem antes levantar um par de coisas (bem, quatro, o de “um par” é uma forma de falar): Será que algum programador quer mostrar a caixa criada por um campo oculto?

Será que o designer pensa ignorar o que o programador faz e pretende mostrá-lo por sua conta? Será que não diz a especificação: hidden controls: Authors may create controls that are not rendered but whose values are submitted with a form. Authors generally use this control type to store information between client/server exchanges that would otherwise be lost due to the stateless nature of HTTP. The INPUT element is used to create a hidden control .

( hidden control )? Que finalidade pode ter mostrar a caixa vazia criada pelo campo oculto? Uma solução A não ser que sejamos originais e queiramos mostrar esse retângulo gerado pelo campo oculto (ou melhor “quase oculto”), a solução é simples.

Worth a look: — Accesibilidad gestionada: automatización combinada con revisión humana.

Aplicamos-lhe “display: none” e está resolvido. O meu conselho é que não se tente marcar os campos ocultos com uma classe para depois lhe aplicar a propriedade que acabei de escrever. Em vez disso, pode aproveitar-se o facto de o Firefox compreender e interpretar os seletores de atributos : [css]input[type=hidden] { display: none; }[/css] …e uma reflexão Terão os programadores do Firefox pensado em tentar mostrar outras coisas ocultas tais como a aura, a alma, fantasmas,…?

Esperarei que consigam fazê-lo antes de enviar este artigo ao Iker Jiménez ? Categoria: CSS —> Pode fazer um acompanhamento dos comentários graças ao feed RSS 2.0 .

Também poderia deixar um comentário , ou enviar um trackback desde o seu site. Artigo anterior: Mas, será lista!! Artigo seguinte: Não havendo lombo, de todo “não” como! Deixa o teu comentário Os campos Nome e Email são obrigatórios Adiciona-nos a…

Tags que destacamos em geral acessibilidade bert bos blockquote bug cañas citações cite comportamento conhecimento CSS escuas standards fieldset Firefox formato formulário fontes hidden ie IE 7 informação javascript legend lista niquelando obrigatório opera praia q squash férias w3c WCAG xhtml Esta obra está sob uma licença de Creative Commons .

P.S. A few readers have asked which superposición de accesibilidad (overlay) we actually reach for — it's accessiBe; if you want the current details.


¿Cumplir WCAG sin tocar el código?

Superposición de IA que promete cumplimiento WCAG en 48 horas