Archivo de la etiqueta: acceso_a_Internet

Problemas de accesibilidad asociados al color.

Fuente:

http://www.juanhidalgoreina.com/2011/03/problemas-de-accesibilidad-asociados-al-color/

Problemas de Accesibilidad asociados al color.

Publicado
14 de marzo, 2011.
Autor
Juan Hidalgo Reina

Primero indicar que es necesario no basarse en el color, tal y como se indica en las WCAG.

En el punto de verificación 2.1 de las WCAG 1.0 se indica ” Asegúrese de que toda la información transmitida a través de los colores también esté disponible sin color, por ejemplo mediante el contexto o por marcadores”.

Pongamos un ejemplo, que ocurre cuando por alguna razón diseñamos una tabla con barras de diferentes tonalidades de rojos, y ponemos unatablita indicando que significa cada tono de rojo. Vale, preciosa tabla, pero y si esa persona tiene por ejemplo Protanopia?. Los usuarios que tiene esta “disfunción visual“, tienen una carencia de sensibilidad al color rojo.

Genial hemos conseguido que los usuarios con esa discapacidad no puedan acceder, ni comprobar la información, solo por que hemos decidido poner ese color.

Puedo decir sin animo de equivocarme que la mayoría de los sitios que certifican Accesibilidad (no digamos los que no certifican), tienen carencias graves en los valores de brillo y contraste de los tonos empleados. Algunas veces por un leve descuido, otro por que el diseñador tiene mayor peso que la necesidad implícita de Accesibilidad, y otras por que no se ha tenido en cuenta. Existen otras situaciones pero prefiero obviarlas por los términos que se suelen emplear.

Información transmitida por el color.

Por ejemplo observemos este ejemplo, en el observamos un error de lo mas común. Indicamos y planteamos una funcionalidad basada en el color. El campo obligatorio está en color rojo.

Uso incorrecto de transmisión de información por el colorUso incorrecto de transmisión de información por el color.

Esto es un grave problema para muchos usuarios, pues en cierta medida anteponemos criterios estéticos y comportamientos visuales corporativos a toda costa, sin valorar ni constatar el perjuicio que estamos ocasionando.

Como se resuelve este tipo de problemas?

Pues simplemente debemos poner por ejemplo, “Los campos obligatoriosestán marcados en rojo y con asterisco”, tal y como aparece en el ejemplo siguiente. La información se sigue transmitiendo por el color, pero tambiénpor el marcado. Independientemente del dispositivo o de la discapacidad visual, el asterisco está perfectamente marcado.

Caso de uso de transmisión de información por el color y marcado.Caso de uso de transmisión de información por el color y marcado.

Brillo y color

El Punto de Verificación 2.2 de las WCAG 1.0 nos indica que lascombinaciones de color de fondo y de primer plano deben ofrecer suficiente contraste para ser visualizadas por personas con discapacidad visual, o tener el suficiente contraste para pantallas en blanco y negro.

Para ello el W3C nos sugiere la utilización de un algoritmo que nos determinará un valor de contraste suficiente.

Por ejemplo debemos tener mucho cuidado con las combinacionesempleadas en el site. Los diseñadores tenemos una facilidad innata por poner tonos imposibles (muchos de mis profesores, dirían que en determinadas situaciones atentan contra la teoría del color), y sobre todo por poner una degradaciones de color, que queden bellísimas pero que a simple vista puedan pasar inadvertidas por muchos usuarios que no tengan ningún tipo de discapacidad visual, por lo que imaginemos lo que puede ocurrir con los que si la tengan.

A continuación os pongo una captura de mi pagina de FACEBOOK, en la que se puede observar como ese tono NO cumple las necesidades requeridas para validar en Brillo y Color.

Problemas de color en FacebookProblemas en el todopoderoso Facebook.

En la captura de imagen anterior, podéis observar una de mis herramientas de cabecera, un magnifico plugin para Firefox(ColorChecker). Os animo a que lo instaléis, y que por ejemplo probéishaciendo click en la casilla de verificación “Selector de texto“,

Revisad por encima las siguiente webs, y comprobad que tipo de problemas de accesibilidad tienen los cuerpos de texto.

http://www.bde.es/webbde/es/

http://www.iberia.es

http://mailchimp.com/

Ahora bien, a pesar de que el W3C en las WCAG 1.0 recomienda la utilización del algoritmo anteriormente citado, el cual se basa en la diferencia de brillo y color, os recomiendo lo que a mi me han recomendado desde que salieron las WCAG 2.0.

Hay que utilizar el nuevo algoritmo de Luminosidad. Por que? pues por que las WCAG 2.0 conllevan una serie de revisiones y mejoras, el nuevo algoritmo ya es una mejora evidente.

Diferencias entre algoritmos

WCAG 1.0 (Algoritmo de Brillo y Color)

  • La diferencia de brillo debe tener un rango igual o superior a 125 como mínimo.
  • La diferencia de color debe tener un valor mínimo de 500.

OJO hay muchos sitios en los que los validadores o chequeadores de color, comentan algunas variaciones realizadas por HP creo recordar.

WCAG 2.0 (Algoritmo de Luminosidad)

  • En función de la tamaño y estilo del texto e incluso de nivel de conformidad, se establecen como ratio mínimo de luminosidad, 3:1, 4.5:1 o 7:1.

Brillo y color en imágenes, logotipos, etc.

Cuando por ejemplo las imágenes lleven texto, esa información debe aparecer si o si en el ALT.

En las WCAG 2.0 los logotipos están exentos de cualquier tipo de restricción por contraste. Anteriormente en las WCAG 1.0 no es que se obligase a cumplir la restricción y ahora en las WCAG 2.0 no, simplemente que antes no se tenían en cuenta algunas particularidades como la implantación, o la experiencia documentada que genera el tiempo transcurrido entre las ambas WCAG .

Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA.

Fuente:

http://olgacarreras.blogspot.com/2011/02/accesibilidad-integrada-en-todas-las.html

Domingo 27 de febrero de 2011.

Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA.

Como consultor de usabilidad y accesibilidad es fundamental, cuando formas parte del grupo de trabajo que va a desarrollar una aplicación Web, conocer el marco metodológico del Diseño Inclusivo para incluir los requisitos de accesibilidad y usabilidad a lo largo de todo el proceso de desarrollo. Ello permitirá crear aplicaciones usables y accesibles cuya calidad perdure en el tiempo.

El objetivo de este artículo es difundir el marco metodológico AWA para el desarrollo de aplicaciones web accesibles, pues es un excelente ejemplo de metodología de Diseño Inclusivo que ayuda a comprender las bases en las que se debe asentar un desarrollo que tenga la accesibilidad y la usabilidad presentes en todas las fases del proceso.

Para ampliar información o contactar con su autora recomiendo acceder directamente a su web:AWA (Accessibility for Web Applications) También recomiendo su presentación Tutorial: Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software (PDF)

Índice del artículo

  1. Introducción: marco metodológico AWA
  2. Pre-requisitos para la aplicación de AWA
  3. Fases y actividades
  4. Estructura del soporte metodológico AWA
  5. Checklist de seguimiento del cumplimiento de requisitos y mecanismos
  6. Casos reales: portal corporativo con Drupal.

Introducción: marco metodológico AWA.

AWA (Accessibility for Web Applications) es el marco metodológico para el desarrollo de aplicaciones web accesibles elaborado por Lourdes Moreno es su tesis doctoral: “AWA, Marco metodológico específico en el dominio de la accesibilidad para el desarrollo de aplicaciones Web”, 2010 [PDF, 8.5 MB].

El objetivo del trabajo es ofrecer un soporte metodológico para incorporar los requisitos de accesibilidad en todo el proceso de desarrollo de una aplicación web, aportando sistematización y un enfoque DCU que situé al usuario como protagonista. El marco de trabajo es el Diseño Inclusivo que involucra a los usuarios con necesidades especiales y a expertos en este tipo de necesidades y discapacidades. El estándar de referencia a lo largo del trabajo son las WCAG (1.0 y 2.0) y el cumplimiento de las mismas en las páginas web finales de la aplicación Web.

Uno de los errores habituales es afrontar la revisión de la accesibilidad cuando el desarrollo está muy avanzado, siendo más costoso y complicado aplicar los requisitos necesarios. Por otra parte, cuando la accesibilidad no se ha sistematizado en el desarrollo es mucho más difícil mantenerla durante el ciclo de vida de la aplicación Web.

Los objetivos finales son pues:

  1. conseguir que las páginas web finales generadas por la aplicación sean accesibles según las WCAG y usables desde el punto de vista del usuario,
  2. garantizar la calidad, es decir, que esta accesibilidad sea estable en todo el ciclo de vida de la aplicación web.

Es una propuesta flexible para que pueda ser aplicada a cualquier proceso de desarrollo de software que cumpla con los pre-requisitos mínimos.

Pre-requisitos para la aplicación de AWA.

La aplicación de esta metodología tiene como pre-requisito que la aplicación siga una arquitectura de modelo de más de dos capas (MVC) donde la lógica de negocio esté separada de la presentación, pues la separación de la presentación, la estructura y el contenido es un requisito imprescindible del diseño accesible. Además asegurará que las funcionalidades implementadas sólo en cliente (como AJAX) no dejen de funcionar.

Por otro la lado, la tecnología cliente deberá estar basada en estándares del W3C (XHTML, CSS, etc.) y tecnología servidor que no deje código en el lado del cliente (a excepción de AJAX que podrá ser utilizado junto con soluciones WAI-ARIA).

Fases y actividades.

Presupone un proceso de desarrollo con un enfoque iterativo y un ciclo de vida incremental, cuyas fases y actividades son:

Espiral en la que se señalan las fases y actividades que se enumeran a continuación:

Comunicación con el cliente:

  1. Análisis de negocio: identificación de metas y objetivos de la aplicación.
  2. Actividad de formulación: captura de requisitos que involucre a todos los participantes.

Planificación:

  1. Estimación de costes.
  2. Evaluación de riesgos.
  3. Planificación del desarrollo para definir tareas y plazos de cada incremento (plan de iteración)

Ingeniería:

  1. Análisis:
    1. Definición de requisitos técnicos, identificación de elementos de contenido y análisis del diseño gráfico.
    2. Requisitos de interacción: relación de los elementos de contenido y su funcionalidad asociada.
    3. Análisis de navegación: mecanismos de navegación que se van a proporcionar.
  2. Diseño:
    1. Diseño del contenido y diseño gráfico.
    2. Diseño de la estructura y el comportamiento de la aplicación en sí, incluyendo arquitectura, navegación e interfaz.
  3. Modelado: creación de modelos antes de la construcción.

Construcción:

  1. Implementación: de los modelos procedentes de la fase de ingeniería para construir la aplicación Web. Integración con software intermedio.
  2. Pruebas: para asegurar la calidad:
    1. Verificación: comprobación de que la aplicación es correcta desde la perspectiva del diseñador en relación al contenido, arquitectura, presentación, interfaz y navegación
    2. Validación: comprobación de que la aplicación hace y tiene la apariencia que el cliente esperaba.

Despliegue:

  1. Evaluación e interacciones de cambios.

Estructura del soporte metodológico AWA.

Estructura de soporte metodológico AWA: AWA_ Organización, AWA_Interacción y AWA_WCAG proponen AWA_Requisitos que activan AWA_Mecanismos

Componentes.

AWA_Organización.
Mecanismos para integrar planes y políticas de accesibilidad en la organización y equipo de desarrollo.

Se articula en torno a la elaboración de un Plan de accesibilidad (creación del grupo de accesibilidad, determinar la política de accesibilidad con el nivel de conformidad deseado, mecanismos para compartir el conocimiento sobre accesibilidad y plan de formación, seleccionar tecnologías accesibles, etc.) y laGestión de la accesibilidad (procesos a nivel interno pero también externo como la elaboración de requisitos para proveedores externos o la gestión de sugerencias de los usuarios)

Consultar mapa conceptual de AWA_Organización

AWA_Interacción.
Mecanismos para integrar un enfoque de DCU con inclusión, teniendo como instrumento base el estándar  ISO 13470:1999 (PDF, p.121) que se introduce en las páginas 121 y siguientes.

Se articula en torno a dos principios fundamentales:

  1. Involucrar a todos los usuarios, incluyendo al usuario con discapacidad en todo el proceso
  2. Considerar las características del usuario con discapacidad y la diversidad de contextos de uso en la Web.

Engloba técnicas de usabilidad con inclusión como: perfiles de usuario,personasescenariosprototipotormenta de ideascardsortingevaluación heurísticacuestionarios, entrevistas y encuestas, que se detallan en las páginas 129 y siguientes.

Consultar mapa conceptual de AWA_Interacción

En este capítulo 5 me parece muy interesante la tabla de correspondencia entre los criterios heurísticos de usabilidad y los criterios de conformidad de las WCAG 2.0 (PDF) (tabla que se explica en las páginas 155 y siguientes). Recurso muy útil para saber qué aspectos de la accesibilidad se están teniendo en cuenta cuando la usabilidad se incluye en un proyecto.

AWA_WCAG.
Abstracción de las WCAG (1.0 y 2.0) de manera que su tratamiento pueda ser incluido desde el inicio del proceso de desarrollo de una aplicación Web.

Puesto que no todos los requisitos pueden ser incorporados desde el diseño se distingue estos (AWA_WCAG Diseño) de los que son a nivel de implementación (AWA_WCAG Implementación: presentación con CSS, acceso por teclado, cambio de contexto o compatibilidad con terceras tecnologías) y de los que han sido definidos para ser incorporados en la actividad de evaluación (AWA_WCAG Evaluación)

Consultar los mapas conceptuales de AWA_WCAG para las actividades de diseño, implementación y evaluación

Requisitos.

AWA_Requisitos.
Como resultado se definen unos requisitos de accesibilidad que tienen tres objetivos principalmente:

  1. seguir las WCAG 1.0 y 2.0,
  2. seguir un enfoque DCU con Inclusión
  3. tener en cuenta la gestión de la accesibilidad considerando los requisitos de accesibilidad desde la organización como punto de partida.

En la notación de los requisitos se incluye el componente, por ejemplo:AWA_RequisitoOrganización PLAN 01.02: Declaración de Política de accesibilidad

Los AWA_RequisitosWCAG que hay que incorporar en la actividad de diseño se describen en las páginas 150 y siguientes, incluyendo por cada uno una tabla de correspondencia con las WCAG 1.0 y las WCAG 2.0. También se pueden consultar estas tablas accediendo en la web a cada una de las pautas WCAG 1.0 y WCAG 2.0

Consultar una tabla simplificada de correspondencias entre las WCAG 1.0, las WCAG 2.0, los AWA_Requisitos y los grupos de usuarios beneficiados.

Los AWA_Requisitos activan mecanismos de accesibilidad denominados AWA_Mecanismos.

Mecanismos.

AWA_Mecanismos.
Articulan la incorporación de los AWA_Requisitos desde el inicio del proceso. En la notación de los requisitos se incluye el componente, por ejemploAWA_MecanismoOrganización PLAN 01.02/02: Determinar Declaración de Política de Conformidad.

Checklist de seguimiento del cumplimiento de requisitos y mecanismos

Consultar checklist de seguimiento del cumplimiento de requisitos y mecanismos (PDF).

Casos reales.

En el capítulo 7 se explican casos reales de aplicación, uno de ellos el de la web del Centro Español de subtitulado y Audiodescripción (CESyA) gestionada con Drupal.

Se explica el enfoque de Diseño Inclusivo en la captura de requisitos combinando las técnicas de perfiles de usuario, personas y escenarios.

Se detalla la utilización de la técnica Card Sorting (manual abierta, automática con WebSort y manual cerrada) para adecuar la arquitectura de la Información al modelo mental de los usuarios.

La elaboración de un prototipo de bajo coste y reuniones Visual Brainstorming antes de abordar el diseño gráfico, así como la elaboración posterior de un prototipo software funcional, evaluándolo por expertos (evaluación heurística) y mediante pruebas de usuarios con y sin discapacidad (consultar cuestionarios a los participantes en el test de usuarios y a los testers (PDF)).

Aplicando todo lo anterior se crearon las plantillas de Drupal y se validó su accesibilidad.

Me parecen fundamentales todos los mecanismos que se llevaron a cabo en Drupal para asegurar que la inclusión de contenido a través del gestor diera lugar a contenido accesible y por tanto páginas que cumplen los niveles de conformidad AA.

Para ello se incluyó un editor de contenido con criterios de accesibilidad que transformara los datos introducidos en código válido. Por ejemplo, al incluir una noticia se pide el título (que se incluirá como encabezado), el idioma (aplicará en el código la identificación del idioma si no se corresponde con el idioma de la página), etc.

Me gustaría destacar las características y restricciones que debe tener el editor de contenido de un CMS para que el contenido resultante sea accesible:

  1. Edit text: permite escribir texto plano e incluye una opción guiada donde no se puede incluir tags (X)HTML
  2. Specify language: puedes seleccionar el idioma mediante una select.
  3. Add header: permite incluir un encabezado de un nivel específico, pero si existe un nivel de encabezado ya definido que englobe el actual documento, el nivel relativo se ajustará a ese nivel global, siendo relativo a éste. Se puede especificar también su idioma.
  4. Add image: siendo obligatorio la URI y el texto alternativo, y opcionalmente el longdesc
  5. Add multimedia: permite incluir vídeo siendo obligatoria la URL, el recurso de subtitulado y audiodescripción, y su lenguaje.
  6. Add link: siendo obligatorio la URI y pudiendo incluir un title y el lenguaje de la página de destino.
  7. Add abbreviation: que permita incluir un contenido con texto abreviado, pudiendo especificar su idioma.
  8. Add acronym: permite incluir un acrónimo, pudiendo especificar su idioma.
  9. Add list: añade una lista de diversos tipos.
  10. Add table: permite incluir una tabla, indicando filas, columnas, encabezados, resumen, etc..
  11. Add form: añade un formulario, permitiendo incluir los elementos típicos de formularios HTML mediante “Add element”. “Specify action” permite indicar la acción que realizará el formulario al ser enviado.
  12. Finish editing: finaliza la edición del contenido, comprobando que éste cumple con las especificaciones definidas y lo inserta en el sistema de persistencia, quedando a la espera de una revisión de accesibilidad (AWA_RequisitoWCAG EVA 01) para su publicación definitiva.

Esta revisión manual del contenido incluido en el editor para que pueda publicarse tiene en cuenta los puntos de las tabla de la página 241.

Liberada la versión 1.1 de la herramienta AChecker (en inglés).

Entre las nuevas características de esta herramienta, se encuentran la opción de pegar desde el portapapeles evaluaciones de accesibilidad, validación de CSS, 10 nuevos colores para revisión de accesibilidad de contraste y otras opciones.

Fuente:

http://sourceforge.net/news/?group_id=239965&id=296942&goback=.gde_41800_member_42497678

AChecker 1.1 Released.

New features in this release include paste from clipboard accessibility evaluations, CSS validation, 10 new colour contrast accessibility checks, and more.

AChecker 1.1 Released
February 2, 2011

AChecker 1.1 has been released. AChecker is a free open source Web content accessibility evaluator used to assess Web pages for conformance with international accessibility standards. This release adds a number of significant new features. Thanks to the Department of Computer Science at the University of Bologna, Italy, for their contributions to this release.

Use the Public AChecker to evaluate your Web site:
http://www.achecker.ca

Download AChecker to install a copy of your own:
http://www.atutor.ca/achecker/download.php

AChecker Details:
http://atutor.ca/achecker/

New in this release:
CSS Evaluator: Access the validity of external stylesheets, embedded stylesheets, and inline styles while evaluating the accessibility of a Web page.

Colour Contrast Evaluation: Ten new accessibility checks have been added to evaluate foreground and background colour contrast to ensure text is readable by everyone.

Paste HTML from Clipboard: Evaluators can now paste the source HTML of a Web page into AChecker to have it evaluated. This makes it possible to assess pages that are not accessible from the Web, such those on an Intranet, or on a local personal computer.

Updater: Administrators can now keep their AChecker installation up to date in between releases with the AChecker Updater. The Updater lets them apply patches to fix bugs, to add new features as they become available, and to add new accessibility checks as they are created.

AChecker Translator Site: There are currently English and Italian translations of AChecker. Sign-up for a translator account on atutor.ca, if you don’t already have one, and help translate AChecker into your language.

AChecker Translation:
http://atutor.ca/my/translate_acheck.php

…and there have been many bug fixes and accessibility check adjustments.

IDRC Inclusive Design Graduate Program
The Inclusive Design Research Centre (IDRC), developers of AChecker, ATutor and other accessible open source applications, is launching an innovative new Master’s program in Inclusive Design at OCAD University in Toronto, Canada. The program is intended for anyone with an undergraduate degree related to information and communication technologies, systems or practices (ICT) or experience working in the field and interested in learning how to design ICT systems and practices accessibly. The program responds to the growing demand for individuals with expertise in digital inclusion and accessibility. The majority of the program is offered online and can be completed at a distance.

For more details see:
http://www.ocad.ca/programs/graduate_studies/inclusive_design.htm

Muestras de cómo hacer la administración de WordPress más accesible a los lectores de pantalla (en inglés).

Fuente (artículo en inglés):

http://www.badeyes.com/?p=293&goback=.gde_41800_member_44305147

Tips on How to Make WordPress Admin More Accessible to Screen Readers

By Geof Collis.
February 19, 2011.

I’ve been using WordPress now for almost 3 years, I’ve found it to be a fantastic piece of work and highly recommend it to anyone wanting to create a website, there are many Themes to choose from or if you have the skills you can create your own.

Most people might think WordPress is a Bloggin platform only but it is also a great Content Management System (CMS) as well and there are thousands of Plugins you can choose from to enhance your website and you dont need any real programming knowledge.

Over the years I’ve been asked how it works with Screen Readers, in my case JAWS that I’ve finally got around to compiling some tips that make it more accessible and I’ve listed them below.

Note: I wrote these tips as a JAWS screen reader user only, other Screen Readers may use different commands for the same function.

Profile Page

The very first thing to do after you’ve installed WordPress is to go to your “Profile” page, usually the 3rd link from the top or whatever Username you used to set up WordPress.

Once there you can either look for the check box ” Disable the visual editor when writing and select it or just hit your ‘F’ key and it should take you directly to the check box.

Scroll down near the bottom of the page and click on “Update Profile”

Posts and Pages

Next we make our way to “New Post”, should be 5th link from the top, after “LogOut” .

Once you’re there look for the link “Screen Options” or use your page find function (ctrl plus f) and type “Screen” and hit enter, once there hit enter to open the menu, tab down until you reach “Number of Columns” and select 1 column, continue tabbing until you hear “Screen Options” again hit enter to close the menu.

Next we use our links list dialogue menu function and find “Pages”, once there look for “Add New” or hit your ‘h’ key twice, it should take you directly the link then access it and follow the above directions as we did for Posts.

Widgets

When you start feeling comfortable with WordPress you might want to begin using “Widgets”, in that case pull up your links list dialogue menu and look for “Appearance” click on it then bring up the menu again and then click on “Widgets”.

When you land on the page use your page find command and look for “Screen options” again select “Enable accessibility mode”.

Creating a Post or Page

Now that you’ve implemented the above settings it’s time to create a Post or Page.

We’ll start with a Post, the quick steps are the same for a Page:

Once the page loads hit your ‘F’ key, it should take you directly to the “Title” field and hit enter, type your Title then hit enter again when you’ve finished and you’ll be taken to the main body where you can either cut and paste your text from a text editor or type away, hitting enter anytime you want a new paragraph, WordPress recognizes it and codes it accordingly.

WordPress also recognizes HTML code such as hyperlinks, semantic markup etc so dont be afraid to use it, there are also keyboard commands if you’re feeling adventurous.

When you are finished hit alt p and the Post/Page will be published or you can Preview it in the “Publish” section first.

Recommended Plugins

These are some of the Plugins I’ve tested and useed for various sites, I found them easy to use and accessible.

All in One SEO Pack

Automatically optimizes your WordPress blog for Search Engines (Search Engine Optimization).

All in One SEO Pack

Exec-PHP

The Exec-PHP plugin executes PHP code in posts, pages and text widgets.

Exec-PHP

Post-Expirator

Allows you to add an expiration date (hourly) to posts which you can configure to either delete the post or change it to a draft.

Post Expirator

Post Teaser

Post Teaser generates excerpts of posts for the main, archive and category pages, also generate a word count, image count, and estimated reading time.

This is highly customizable and is great if you have other Users Posting since you dont need to insert <!- -more- -> to break off the Post, you specify the number of characters.

Post Teaser

WordPress Stats

Simple, concise stats with no additional load on your server by plugging into WordPress.com’s stat system.

WordPress.com Stats

Subscribe2

An opt in mailing list that sends a list of subscribers an email notification when new posts are published to your blog

Subscribe2

Tweet This

Popular Twitter plugin inserts “Tweet This” links so your readers can share
posts with one click. Automatically tweets new posts via OAuth.

Tweet This

WP-Title2

This plugin allows you to add and edit a Heading for your Posts, Pages and Custom Post Types, different from the Title (which is used in the navigation links). Very useful if you use WordPress as a CMS and is good for Search Engine Optimization (SEO).

WP Title 2

Una autoridad de Internet acusa a EE UU de “secuestrar” dominios.

Fuente:

http://www.elpais.com/articulo/tecnologia/autoridad/Internet/acusa/EE/UU/secuestrar/dominios/elpeputec/20110222elpeputec_3/Tes

Una autoridad de Internet acusa a EE UU de “secuestrar” dominios.

El presidente de GNSO denuncia su desactivación unilateral por parte de las autoridades.

Barcelona – 22/02/2011.

El gobierno de Internet está siendo amenazado por la presión de las autoridades estadounidenses que proceden a la “desactivación” unilateral de dominios prescindiendo de los organismos mundiales que tienen atribuída la tarea de gestionarlos. Así se manifiesta en una entrevista a AFP Stéphane Van Gelder, el presidente del GNSO (Generic Names Supporting Organization) organismo de ICANN.

“Desde hace un año, las agencias que luchan contra el crimen, sea la Interpol, el FBI y policías de distintos estados, llegan a ICANN y al GNSO con demandas sobre la desactivación de sitios y dominios en Internet”, explica. “Hemos sido convocados dos veces por la Casa Blanca para tratar de la lucha contra la falsificación y se nos ha pedido cómo combatir este fenómeno…y se hecho de forma agresiva”. Gelder asegura que ha habido enormes presiones sobre ICANN y que las autoridades atacan a actores sobre los que pueden actuar “porque no pueden combatir a la mafia”.

Según el presidente de GNSO, las autoridades estadounidenses han procedido a bloquear un centenar de dominios terminados en .com, cuya gestión está delegada en la compañía Verisign, de los que dependen a menudo miles de otros sitios, desde blogs a páginas personales. “Algunos eran sitios dedicados al comercio de la falsificación, pero muchos otros no tenían nada de ilegítimos. Por ejemplo, tras la desactivación del dominio mooo.com, acusado de albergar contenidos pornográficos, se clausuraron por error 84.000 sitios que dependían de este dominio y que no tenían nada que ver con este tipo de prácticas. En esta campaña de bloqueos de dominios, uno de los sitios afectados ha sido rojadirecta.

Gelder califica esta política de inquietante “toma de rehenes” y la considera una cirugía sin anestesia y con un gran cuchillo. “Son acciones directas que no respetan el sistema establecido. Es el Gobierno el que decide que hay una ofensa y bloquea el sitio”, al margen de las atribuciones que sobre la administración de los dominios tienen GSNO e ICANN.

ICANN fue creada en 1990 por la Administración Clinton y delegó en ella las atribuciones que hasta entonces tenía el Gobierno estadounidense en la gestión de los dominio de Internet. Se trató de ofrecer una estructura de administración multilateral que no resultara sospoechosa a otros Estados. ICANN es un organismo privado sin ánimo de lucro sometido a las leyes de California. Algunos países, como India o China, reclaman que esta gestión pase a manos de Naciones Unidas, pero este paso es visto con recelo por otros Gobiernos ya que la diplomacia retrasaría la toma de decisiones y daría un papel clave a Gobiernos que practican la censura sistemática sobre la Red.

Con todo, el presidente de Estados Unidos Barack Obama quiere dar más poder a los gobiernos en la decisión de qué nuevos dominios de Internet deben introducirse. La propuesta de su administración consistiría en dar derecho de veto.

Curso “Experto Universitario en Accesibilidad y Usabilidad” en Buenos Aires, Argentina..

Un curso de excelente nivel con un equipo docente de lujo.

Fuente:

http://hfnoticias.com.ar/noticia/index/249/4604

Curso “Experto Universitario en Accesibilidad y Usabilidad”

Inicio: miércoles 30 de marzo de 2011
Duración: 2 cuatrimestres
Carga Horaria: 150 horas (martes y miércoles de 18:30 a 21 hs.)
Lugar: Medrano 951 – CABA

Fundamentos.

La accesibilidad web surge como estándar para asegurar a las personas con discapacidad las mismas oportunidades que al resto de la gente para acceder a la información, para integrarse plenamente a la sociedad y acceder a sus servicios y beneficios
La accesibilidad web para sitios públicos es obligatoria por ley en muchos países. En Argentina será obligatoria para 2012, en virtud de la ley 26.653 recientemente sancionada.
Internacionalmente los estándares de accesibilidad son desarrollados por el World Wide Web Consortium (W3C).
Hace pocos años ha sido aprobada la Convención Internacional sobre los Derechos de las Personas con Discapacidad y ratificada por nuestro país. Este marco legal ampliará a nivel mundial la legislación que hace obligatoria la accesibilidad web.
Las pautas de accesibilidad tienen muchos elementos en común con las buenas prácticas de posicionamiento en los motores de bús-queda, brindando así este beneficio adicional.
Los criterios de usabilidad han crecido en las últimas décadas, paralelos a la maduración de la web, dando pautas de calidad.
La disciplina de la experiencia de usuario ha ampliado la perspectiva del estudio y diseño en relación con las interacciones de los usuarios, considerando sus múltiples dimensiones
Los campos de la accesibilidad y de la usabilidad tienen una cantidad de aspectos conceptuales en común, algunos autores enfatizan esto con el concepto de la usabilidad universal.

Destinatarios.

Este curso se dirige tanto a diseñadores web, desarrolladores web, webmasters, programadores, docentes y profesores que trabajen en TIC, así como a quienes ocupen posiciones gerenciales en esas áreas. El curso también es útil para profesionales de las áreas psico-sociales que se interesen en estudios y evaluaciones de las TIC, así como para quien desee profundizar su comprensión de los actuales desafíos de calidad e inclusión.

Objetivos Generales.

Alcanzar los conocimientos y competencias para incluir en el diseño, desarrollo y dirección de proyectos web criterios de accesibilidad y usabilidad basados en estándares y buenas prácticas.

Competencias del Egresado.

El egresado adquirirá competencias para:
Conocer los estándares y buenas prácticas en el ámbito de la accesibilidad y la usabilidad y ser capaz de aplicarlos al diseño y desarrollo de sitios web y a la dirección de proyectos web.
Evaluar la accesibilidad de sitios web, utilizando las metodologías y herramientas adecuadas.
Realizar pruebas de usabilidad de sitios web y evaluar la experiencia de usuario frente a los mismos.
Participar en investigaciones relacionadas con las interacciones de los usuarios con las tecnologías de la información.

Cuerpo Docente.

Area Accesibilidad: Karina Rojo, Carlos Benavidez, Martin Baldasarre, María Dolores García, Jorge Plano.
Area Usabilidad: Enrique Stanziola, Gonzalo Auza, Juan Manuel Carraro, Eduardo Mercovich.
Coordinadora académica: Lorena Paz.
Coordinador general: Jorge Plano.

Modalidad de trabajo.

El curso se desarrollará con una modalidad teórico-práctica, con ejercitación de los conceptos adquiridos, la cual incluirá la construc-ción de páginas y la evaluación de sitios.
Habrá clases por parte de reconocidos expertos nacionales y se realizarán teleconferencias con expertos del exterior.
Los cursantes deberán desarrollar diversos trabajos prácticos y un trabajo final.

Certificación.

Los participantes que hayan tenido el 80% de asistencia y aprueben las evaluaciones, obtendrán un certificado extendido por la Uni-versidad Tecnológica Nacional Facultad Regional Buenos Aires.

Requisitos necesarios.

Quienes aspiren a realizar este curso deberán cumplir con los siguientes requisitos:
Experiencia en algunas de estas áreas web: diseño, programación, producción de contenidos, dirección de proyectos, evaluación de sitios.
No se requieren títulos previos.
Poseer conocimientos básicos de html, css y scripts.

Consultas e inscripción.

Comunicarse por info@sceu.frba.utn.edu.ar o 4867-7545  4867-7545

Organización.

Inicio: miércoles 30 de marzo de 2011
Duración: 2 cuatrimestres
Carga Horaria: 150 horas (martes y miércoles de 18:30 a 21 hs.)
Lugar: Medrano 951 – CABA

Respuesta a 25 dudas habituales sobre accesibilidad web.

Como en tantos otros casos, recomiendo directamente leer el original, ya que la bitácora de Olga Carreras no tiene desperdicio para los que estamos en las cuestiones relacionadas con el diseño web y la accesibilidad web.

Fuente:

http://olgacarreras.blogspot.com/2011/01/respuesta-25-dudas-habituales-sobre.html

domingo 30 de enero de 2011.

Respuesta a 25 dudas habituales sobre accesibilidad web

En los artículos Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidadTécnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad incluía las respuestas a 15 dudas de accesibilidad basándome en el documento “Techniques for WCAG 2.0” de las WCAG 2.0

A continuación listo el enlace a las 15 dudas ya resueltas en esos artículos anteriores y el ancla a las 10 nuevas dudas que se resuelven en este artículo.

  1. ¿Mi sitio Web es inaccesible si utiliza ventanas emergentes?
  2. ¿Mi sitio Web es inaccesible si utiliza frames?
  3. ¿Mi sitio Web es inaccesible si utiliza tablas para maquetar?
  4. ¿Mi sitio Web es inaccesible si utiliza Flash?
  5. ¿Mi sitio Web es inaccesible si utiliza javascript?
  6. ¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?
  7. ¿Cómo debo presentar el texto: justificado o alineado a la izquierda?
  8. ¿Cómo he de marcar correctamente las abreviaciones y acrónimos?
  9. ¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?
  10. ¿Cómo se especifica correctamente el color de fondo y de primer plano?
  11. ¿Cómo marcar adecuadamente un emoticon?
  12. ¿Es correcto que aparezca en el código HTML un H2 antes que un H1?
  13. ¿Es recomendable incluir una opción de “Leer está página”?
  14. ¿Cuánto se ha de poder ampliar el tamaño de un texto?
  15. ¿Cómo marcar la pronunciación de una palabra?
  16. ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?
  17. ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?
  18. ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?
  19. ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?
  20. ¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?
  21. ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?
  22. ¿Cuándo puedo ponerle a una imagen alt=””?
  23. ¿Es correcto que el contenido de un input se borre al coger el foco?
  24. ¿Qué se considera texto grande y texto pequeño?
  25. ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?

16. ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?

Es el típico ejemplo de “Leer más” o “Más información” en un listado de noticias.

En las WCAG 1.0 se especifica en relación al punto de verificación 13.1 Identifique claramente el objetivo de cada vínculo que si en la página hay dos o más vínculos con el mismo texto deben remitir al mismo recurso y de lo contrario se han de diferenciar por el atributo “title”:

Si hay más de un vínculo en una página con el mismo texto, todos estos vínculos deben remitir al mismo recurso. Esta coherencia ayudará al diseño de la página tanto como a la accesibilidad.

Si dos o más vínculos van referidos a objetivos diferentes pero comparten el mismo texto, distinga los vínculos especificando un valor diferente para el atributo “title” de cada elemento A.

En “Técnicas HTML para las Pautas de Accesibilidad de los Contenidos Web 1.0” del W3C.

Las WCAG 2.0 también tienen dos criterios de conformidad (2.4.4 de nivel A y 2.4.9 de nivel AAA) que obligan a que se clarifique el propósito de un vínculo. Una de las técnicas suficientes para cumplir con el criterio de conformidad 2.4.4 es la “H33: Supplementing link text with the title attribute”. Esta técnica consiste también en incluir el atributo “title” para clarificar el destino del vínculo cuando la información complementaria proporcionada por el atributo “title” es algo que el usuario debe saber antes de seguir el enlace.

Sin embargo, la propia técnica H33 de las WCAG 2.0 desaconseja el uso del atributo “title” para clarificar el destino de un vínculo por la falta de soporte del atributo “title” en muchos user-agent. De hecho, esta técnica no es válida para cumplir con el criterio de conformidad 2.4.9, que también se refiere a clarificar el destino de un vínculo pero es más estricto por ser de nivel AAA.

En esta técnica se recomiendan otras dos técnicas suficientes alternativas al uso de “title”:

  • o bien que el enlace tenga el texto completo (sería la técnica H30) por ejemplo: “Leer más sobre el artículo ‘WCAG 2.0′” en vez de “Leer más”
  • o bien ocultar mediante CSS el texto del enlace que sigue a “Leer más” (sería la técnica C7), lo cual resulta muy útil cuando el texto del enlace puede llegar a ser demasiado extenso. También se permite incluir un enlace o botón para ver u ocultar las versiones largas de los enlaces (serían las técnicas G189SCR30)

Estas alternativas permitirían cumplir con los criterios de conformidad 2.4.4 (nivel A) y 2.4.9 (nivel AAA).

En cuanto a la opción de ocultar por CSS parte del texto del enlace, es necesario que la ocultación del texto se haga de forma accesible para los lectores de pantalla, es decir, no se debe utilizar display:none sino localizarlo fuera de pantalla.

El ejemplo correcto sería el siguiente:

En la CSS:

a span { height: 1px; width: 1px; position: absolute; overflow: hidden; top: -10px; }

En la página:


 <dl>
 <dt>Winnie the Pooh </dt>
    <dd><a href="winnie_the_pooh.html">
        <span>Winnie the Pooh  </span>HTML </a> </dd>
    <dd><a href="winnie_the_pooh.pdf">
        <span>Winnie the Pooh  </span>PDF </a> </dd>
 <dt>War and Peace</dt>
    <dd><a href="war_and_peace.html">
        <span>War and Peace  </span>HTML</a></dd>
    <dd><a href="war_and_peace.pdf">
        <span>War and Peace  </span>PDF </a> </dd>
 </dl>

Hay otra manera de cumplir con la pauta 2.4.4 (nivel A), pero que sin embargo no será válida para cumplir con la pauta 2.4.9 (nivel AAA), y por tanto es menos aconsejable, pues las WCAG 2.0 alientan a cumplir más criterios de los estrictamente necesarios para alcanzar un determinado nivel de adecuación.

Esta última alternativa es que será válido el enlace “Leer más” cuando esté correctamente contextualizado. Por ejemplo, en el caso de un párrafo (sería la técnica H78) el W3C propone el siguiente ejemplo:

Sería incorrecto:

<p>Coming soon to a town near you...the final 15 in the
National Folk Festival lineup.</p>
<p><a href="final15.html">[Read more...]</a></p>

Pero sería correcto:

<p>Coming soon to a town near you...the final 15 in the
National Folk Festival lineup.
<a href="final15.html">[Read more...]</a>
</p>

De igual manera, hay otras técnicas para indicar cómo se puede asociar correctamente un enlace con su contexto (en listas, tablas, etc.)

17. ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?

La pauta 4.1 (prioridad 1) de las WCAG 1.0 indica Identifique claramente los cambios en el idioma del texto del documento y en cualquier texto equivalente. De la misma manera, el criterio de conformidad 3.1.2 de las WCAG 2.0 también obliga a identificar los cambios de idioma pero establece una serie de excepciones. No es necesario identificar el cambio de idioma de:

  • los nombres propios
  • los términos técnicos, por ejemplo: Homo sapien, Alpha Centauri, hertz, habeas corpus (ejemplos textuales de la explicación del criterio)
  • las palabras en un idioma indeterminado
  • las palabras o frases que se hayan convertido en parte natural del texto que las rodea.

Para resolver las dudas que esto puede ocasionar recomiendan: If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.

18. ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?

La pauta 1.4.2 (nivel A) de las WCAG 2.0 indica que sólo es necesario si el sonido dura más de 3 segundos: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)

19. ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?

Es una práctica habitual utilizar :focus{outline:0;} o peor aun onfocus="blur()" para evitar que las imágenes queden punteadas alrededor cuando cogen el foco.

Las WCAG 1.0 indican mediante el punto de verificación 9.4 (de prioridad 3 y de prioridad 2 en la Norma UNE 139803) que es necesario poder acceder mediante el tabulador a vínculos, controles de formulario y objetos. Sin embargo no se especifica si es necesario que el foco sea visible.

Esto se corrige en las WCAG 2.0 Su criterio de conformidad 2.4.7 (nivel AA) especifica claramente que el foco debe ser visible, de hecho incluye como fallos habituales las dos prácticas comentadas:

Por tanto, no sólo se debe poder acceder mediante el tabulador a toda imagen que sea enlace, sino que además cuando coja el foco este debe ser visible como se aprecia en este ejemplo:

Logotipo del W3C con borde punteado porque ha recibido el foco

20. ¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?

Una duda habitual es la anchura que debe tener (en número de carácteres) un bloque de texto para su óptima legibilidad. Hay muchos estudios al respecto, unos recomiendan entre 80-100 caracteres y otros entre 60-80 por ser el ancho preferido de los usuarios. Se pueden consultar esos estudios en el artículo “Columnas, anchos de línea y legibilidad” de Juan Carlos García.

¿Dicen algo al respecto las WCAG? El criterio de conformidad 1.4.8 (nivel AAA) indica queel ancho de un bloque de texto no debe ser mayor de 80 caracteres.

For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Lines should not exceed 80 characters or glyphs (40 if CJK), where glyphs are the element of writing in the writing system for the text.

En relación con este requisito, las técnicas que aseguran que sea así aunque se redimensione el navegador son :

En este criterio de conformidad también se especifica que el espacio entre líneas(interlineado) debe ser, al menos, un espacio y medio dentro de los párrafos y el espacio entre párrafos, al menos, de 1.5 veces mayor que el espacio entre líneas.

People with some cognitive disabilities find it difficult to track text where the lines are close together. Providing extra space between lines and paragraphs allows them to better track the next line and to recognize when they have reached the end of a paragraph. It is best if there are several different options, for instance, space-and-a-half and double spacing for line spacing. By space and a half within paragraphs we mean that top of one line is 150% further from the top of the line below it than would be true when the text is ‘single spaced’ (the default spacing for the font). By Paragraph spacing that is 1.5 times larger than the line spacing we mean that the spacing from the top of the last line of 1 paragraph is 250% farther from the Top of the first line of the next paragraph (i.e., that there is a blank line between the two paragraphs that is 150% of the single space blank line).

21. ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?

La técnica G174 de las WCAG 2.0 ofrece como alternativa para cumplir con los criterios de conformidad 1.4.3 y 1.4.6 referentes al contraste de color, el utilizar la cláusula de “Version alternativa” de los requisitos de conformidad e incluir un botón o enlace para visualizar la página en alto contraste. Un ejemplo de una web que ofrece una versión en alto contraste es: Media, del Ministerio de Educación.

Pero para que se utilice con éxito esta técnica es necesario:

  • El botón o enlace a la versión alto contraste debe cumplir con los requerimientos de contraste.
  • La versión alto contraste debe tener el mismo contenido y funcionalidad.
  • La versión alto contraste debe cumplir con todos los demás requisitos de accesibilidad.

Los dos últimos requisitos no deben suponer un problema si simplemente se carga una CSS diferente.

22. ¿Cuándo puedo ponerle a una imagen alt=””?

¿Qué entendemos por imagen decorativa? Cualquier imagen que no forma parte del contenido significativo de la página y que por tanto debería ser ignorada por los lectores de pantalla. Según la definición incluida en el criterio de conformidad 1.1.1serving only an aesthetic purpose, providing no information, and having no functionality

Las imágenes decorativas deberían estar definidas en las CSS, pero si se incluyen en las páginas deben tener alt=""

El error cómun F39. Failure of Success Criterion 1.1.1 due to providing a text alternative that is not null (e.g., alt=”spacer” or alt=”image”) for images that should be ignored by assistive technologyindica además que aunque es válido alt=" " (ojo, se admite un espacio en blanco pero no que contenga &nbsp;es más recomendable usar alt="".

Además las imágenes decorativas no podrán tener el atributo “title” o este deberá estar vacío (ver técnica H67)

NO se puede considerar que una imagen es decorativa (y por tanto no puede estar definida en la CSS ni tener alt=""):

  • si es un enlace, a no ser que sea un icono que acompaña a un texto y el enlace los englobe a los dos, en cuyo caso el alt del icono sí deberá ser vacío (ver técnica H2)
  • si incluye texto, a no ser que dicho texto sea también decorativo, entendiendo como tal (vercriterio de éxito 1.4.9): Text is only purely decorative if the words can be rearranged or substituted without changing their purpose. Example: The cover page of a dictionary has random words in very light text in the background.

23. ¿Es correcto que el contenido de un input se borre al coger el foco?

En el criterio de éxito 3.2.2 se especifica que un cambio de contenido no siempre es un cambio de contexto. En este caso es válido que se borre el texto de un input al coger el foco pues supone un cambio de contenido pero no un cambio de contexto.

Por el contrario, no sería válido el comportamiento que se implementa a veces en los campos de fecha o de número de cuenta, en los que al terminar de incluir el contenido del campo el foco salta automáticamente al siguiente campo, pues en este caso sí que es un cambio de contexto. Según se especifica, si se implementa este comportamiento se debe incluir una explicación antes de los campos: consultar la ténica G13: Describing what will happen before a change to a form control that causes a change of context to occur is made

24. ¿Qué se considera texto grande y texto pequeño?

En el criterio de conformidad 1.4.3 se indica:

large scale (text)

with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.

Note 3: The actual size of the character that a user sees is dependent both on the author-defined size and the user’s display or user-agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.

Note 4: When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.

Note 5: The 18 and 14 point sizes for roman texts are taken from the minimum size for large print (14pt) and the larger standard font size (18pt). For other fonts such as CJK languages, the “equivalent” sizes would be the minimum large print size used for those languages and the next larger standard large print size.

En cuanto al texto incluido en las imágenes se especifica:

Note: Because different image editing applications default to different pixel densities (ex. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size. When creating images of large-scale text, authors should ensure that the text in the resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text. For example, for a 72 PPI image, an author would need to use approximately 19 pt and 24 pt font sizes in order to successfully present large-scale images of text to a user.

25. ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?

El criterio de conformidad 3.3.4 (nivel AA) indica que es necesario que:

  • los envíos sean reversibles,
  • o bien que se puedan comprobar los datos y dar la oportunidad al usuario de corregirlos,
  • o bien que se ofrezca un mecanismo para revisar, confirmar y corregir la información antes de enviarla.

El criterio 3.3.4 sólo obliga a las páginas que:

  • causen compromisos legales
  • supongan una transación económica
  • modifiquen o borren datos controlables por el usuario
  • envíen respuestas del usuario a algún tipo de prueba

Sin embargo, el criterio de conformidad 3.3.6, que es de nivel AAA y por tanto es más estricto,obliga a cualquier tipo de envío de información.Se pueden consultar las distintas formulas para implementar estas opciones en las técnicas asociadas a este criterio 3.3.4

Artículos relacionados: