Buscador

miércoles, 18 de abril de 2018

Certificación en accesibilidad web

Información proporcionada por las dos principales organizaciones en España que ofrecen el servicio de certificación de accesibilidad para sitios web:

AENOR - Certificación de Accesibilidad para sitios web

La accesibilidad permite el acceso a la web y sus contenidos independientemente del tipo de hardware, software, infraestructura de red, idioma, localización geográfica y capacidades de los usuarios. Cubre la mayoría de las discapacidades que pueden tener las personas (deficiencias físicas, visual, auditiva y cognitiva), y también las necesidades de las personas de edad avanzada. Es por ello, un elemento básico para la igualdad de oportunidades y la no discriminación.

El desarrollar una web accesible tiene otros beneficios adicionales, como el mejorar la usabilidad y el posicionamiento en los buscadores, la reutilización de contenidos e interoperabilidad, reduce la carga en el servidor y el ancho de banda necesario, etc.

La marca AENOR N de Accesibilidad TIC es una garantía para las organizaciones, los usuarios y los responsables web de que las páginas de internet son y se mantienen accesibles.

Algunas de sus características son:

  • Permite certificar los niveles de accesibilidad AA y AAA, para la norma UNE 139803 Requisitos de accesibilidad para contenidos Web y, por ello, de las pautas de accesibilidad de la WAI (Web Accessibility Initiative).
  • Refleja el cumplimiento del nivel de accesibilidad exigido por la legislación (nivel AA).
  • Se aplica a cualquier tipo de contenido, con especial énfasis en los contenidos Web a los que se accede mediante aplicaciones de usuario.
  • La certificación incluye la realización de una inspección técnica de accesibilidad, la revisión del plan de acciones para corregir los problemas identificados y la verificación de las correcciones realizadas. Además, se revisará el back office o sistema de gestión de la accesibilidad.
  • Incluye la realización de verificaciones semestrales del nivel de cumplimiento de los requisitos de accesibilidad y la revisión de las correcciones realizadas.
  • Incluye la realización de auditorías anuales de la metodología de mantenimiento o sistema de gestión de la accesibilidad, conforme a los requisitos establecidos por AENOR en el Reglamento RP A90.01.
  • Organiza y aglutina los compromisos, el conocimiento y la experiencia de AENOR, Fundación CTIC y ESI respecto a la accesibilidad web.
  • Esta certificación se dirige a los propietarios y/o responsables del mantenimiento de la accesibilidad de la web, y concede el derecho a identificar la web utilizando la marca N de AENOR de Accesibilidad.



Auditoría y certificación en accesibilidad web - ILUNION consultoría

Analizamos la accesibilidad de contenidos web y otras tecnologías para verificar el grado de adecuación a los estándares de accesibilidad, realizando una descripción de las barreras identificadas y proponiendo soluciones para su eliminación, garantizando el cumplimiento de las directrices internacionales y de la legislación vigente en cuanto a la accesibilidad de los contenidos.

Certificamos la accesibilidad de algunas tecnologías (Web, aplicaciones móviles, etc.), ofreciendo un distintivo de calidad a las organizaciones que apuestan por la accesibilidad TIC. Además, realizamos revisiones periódicas de las tecnologías certificadas para asegurar el mantenimiento de los niveles de accesibilidad alcanzados.

lunes, 16 de abril de 2018

"Personas", con comillas, para evaluar la accesibilidad

En experiencia de usuario se emplea el término persona (así se usa en inglés) para representar un usuario concreto. Se intenta que sea lo más realista posible e incluso se le da un nombre:
The purpose of personas is to create reliable and realistic representations of your key audience segments for reference. These representations should be based on qualitative and some quantitative user research and web analytics. Remember, your personas are only as good as the research behind them. Effective personas:
  • Represent a major user group for your website
  • Express and focus on the major needs and expectations of the most important user groups
  • Give a clear picture of the user's expectations and how they're likely to use the site
  • Aid in uncovering universal features and functionality
  • Describe real people with backgrounds, goals, and values

En Understanding disabilities and impairments: user profiles se describe un conjunto de "personas" (aquí lo llaman "user profiles") para discapacidad:
These profiles outline:
  • the sorts of barriers some users face when they use digital services
  • best practice advice on how to design services that everyone can use

viernes, 13 de abril de 2018

Simuladores en línea de daltonismo (ceguera de color)

Hace un par de meses se publicó en microsiervos el artículo Simuladores en línea de ceguera de colores. En el artículo se comentan dos simuladores:
Y también un simulador de visión de bebé, Tiny Eyes.


miércoles, 11 de abril de 2018

Versión accesible de Twitter

EasyChirp es una versión accesible de Twitter. Las principales características que anuncia son:

  • Tweet an image with a caption and long description.
  • A built-in shorten URL tool with choice of service.
  • Search, user search, and saved searches.
  • View, subscribe, and create Twitter Lists.
  • Works great with or without JavaScript.
  • Fully keyboard accessible.
  • Inline threading of tweets; displays reply "conversation".
  • In addition to old and new desktop browsers, I work on virtually any user-agent (even Lynx, a text-only browser), with screen readers and Braille displays, and tablets and mobile devices.

lunes, 9 de abril de 2018

Cómo realizar un estudio de usabilidad para analizar la accesibilidad

Nielsen Norman Group, la empresa de los dos guruses de la usabilidad, ofrece la guía How to Conduct Usability Studies for Accessibility. Lástima que sea de pago, la licencia individual cuesta $82.

Los temas que cubre son:
  • Learn how to adapt standard usability testing practices to accommodate people with disabilities
  • Testing for accessibility and usability throughout the project lifecycle
  • How we conducted our accessibility studies
  • Supplement the general guidelines with empirical tests of your own design with your own users
  • Trust, consent forms, pictures, and video
  • Using video and still cameras
  • Conducting studies at the user's home or office
  • Screen reader and braille sessions
  • Motor skill assistive technology sessions
  • Recruiting and preparing participants
  • Quantitative and qualitative study tips
  • Metrics to collect
  • Sample documents for accessibility studies
  • Recruiting screener used in the quantitative part of the study
  • Checklist used in the quantitative part of the study
  • Facilitation notes used in the quantitative part of the study
  • Question sheet used in the quantitative part of the study
  • Consent forms

viernes, 6 de abril de 2018

CSS puede influir negativamente en la accesibilidad de los usuarios de lectores de pantalla

El artículo Screen Readers and CSS: Are We Going Out of Style (and into Content)? analiza cómo algunas propiedades de CSS influyen en la interpretación de las páginas web por parte de los lectores de pantalla.

La conclusión es que los resultados son diferentes según la combinación de lector de pantalla y navegador que se utilice, así que toca probar, probar y probar:
All of this really highlighted the value of accessibility-minded development and pre-launch testing—in a wide variety of browser-screen reader combinations—to ensure that all website visitors enjoy a consistent, equivalent experience.

miércoles, 4 de abril de 2018

Accesibilidad web y autismo

El pasado 2 de abril se celebró el día mundial del autismo.

En How web accessibility affects people with autism explican:

The Web Content Accessibility Guidelines (WCAG) 2.0 are the most popular standard for web accessibility, and have been cited by the U.S. Department of Justice as an acceptable metric for compliance  with the Americans with Disabilities Act. WCAG 2.0 contains several guidelines to help people with four different classes of disabilities: vision, hearing, motor, and cognitive. 
People on the autism spectrum have a wide range of conditions, and many of them can face difficulties with cognition when using the internet. Some of the most relevant WCAG 2.0 recommendations for people with autism are:
  • Navigation and layout should be consistent across the entire site. Performing the same or similar actions on similar user interface elements should produce similar results.
  • The site should still be usable at larger text sizes and should still function with images and styles disabled. However, images, icons, and graphics that help with comprehension can be included.
  • Clutter and distractions should be minimized. Style and white space should separate content and direct the user’s attention as appropriate.
  • The text should be as simple as possible, while providing definitions for any non-standard terms, such as idioms, jargon, and abbreviations and acronyms. Correct grammar and spelling are important.
  • Users should have as much control as possible over the site’s behavior. Avoid time limits on content or automatic refreshes whenever possible. Provide clear instructions and error messages when filling out forms.

martes, 3 de abril de 2018

Comparecencia de José Ángel Carrey en el Congreso de los Diputados

José Ángel Carrey, presidente de la Associació Catalana per a la Integració del Cec (ACIC), varias veces ha denunciado públicamente la falta de accesibilidad de la web de Renfe:
Hace unas pocas semanas, José Ángel Carrey realizó una comparecencia en el Congreso de los Diputados:



En el instante 1:03:19 le preguntan por la accesibilidad de Renfe:


Y empieza diciendo "Renfe tiene muchos problemas de accesibilidad"... Vale la pena escucharlo.

lunes, 2 de abril de 2018

Cómo usar los encabezados correctamente

Muy fácil de entender el artículo How to structure headings for web accessibility que incluye varios ejemplos:
When is a heading not a heading? Serious question, the answer lies behind one of the most common accessibility problems on the web.
Headings are much more than a big bold title, they provide a solid structure to the webpage. Think of headings as an outline of your webpage.
The structure should be portrayed both in a visual and technical manner, so people can see the structure, and screen readers are able to identity the structure in order to read it out.
Users who can see the page decide within seconds whether or not the content is relevant to them by skimming through headings, glancing over sub-headings keeping an eye out for significant keywords. Breaking up content with headings allows the page to be easily scanned by the user
Without a heading structure, you force users to do extra work to find the information they’re looking for, who has the time and luxury?
From an accessibility point of view the structure in the code should align with the visual presentation and make sense as a “table of contents” for the page.
Use headings to introduce content, they are labels not statements.
Dos buenos ejemplos:


Y un mal ejemplo:

viernes, 30 de marzo de 2018

Subtítulos automáticos en las emisiones en directo en YouTube

En YouTube live streams will soon include automatic captions explican que YouTube ya incorpora la posibilidad de crear subtítulos en tiempo real para las emisiones en directo (live stream). Por ahora solo está disponible en inglés.

En Use automatic captioning se dan algunos consejos para su uso:
If the live stream doesn't show automatic captions, it could be due to one or more of the following reasons:
  • The feature hasn’t been enabled for the channel, as we are slowly rolling out to channels with more than 10k subscribers.
  • Channel is streaming in ultra low or low latency (such as a mobile live stream). Live automatic captions are only available for normal latency streaming.
  • The language in the video is not yet supported by automatic captions.
  • The video has poor sound quality or contains speech that YouTube doesn't recognize.
  • There are multiple speakers whose speech overlaps or multiple languages at the same time. 

jueves, 29 de marzo de 2018

Inclusive Design at Microsoft

En Inclusive Design at Microsoft se puede encontrar información sobre el compromiso de Microsoft con el desarrollo inclusivo.

El manual es muy interesante por dos cosas. Por un lado, porque el documento está publicado con una licencia  Creative Commons AttributionNonCommercial-NoDerivatives (CC BY-NC-ND).

Por otro lado, y gracias a lo anterior, significa que los elementos gráficos del manual se pueden emplear de forma gratuita, siempre que se respete la licencia anterior. Por ejemplo, los siguientes elementos:


miércoles, 28 de marzo de 2018

martes, 27 de marzo de 2018

Segunda encuesta para profesionales de la accesibilidad web

En junio de 2014, el WebAIM lanzó la primera encuesta para profesionales de la accesibilidad web. Los resultados de la primera encuesta del WebAIM para profesionales de la accesibilidad web mostraron algunos datos curiosos. Por ejemplo, en la pregunta sobre los lectores de pantalla se observó una disparidad respecto a los resultados obtenidos en la encuesta a usuarios de lectores de pantalla.

Ahora el WebAIM ha lanzado Survey of Web Accessibility Practitioners #2, que estará abierta hasta el 30 de abril de 2018.


lunes, 26 de marzo de 2018

viernes, 23 de marzo de 2018

Las novedades de WCAG 2.1

Muy interesante el artículo The new guidelines in WCAG 2.1 explained, que explica las novedades que tendrá la nueva versión de Web Content Accessibility Guidelines que seguramente se aprobará este próximo verano.

miércoles, 21 de marzo de 2018

Construcción de menús accesibles

Muy interesante el artículo Building Accessible Menu Systems de Smashing Magazine.

lunes, 19 de marzo de 2018

Ejemplos de vídeos con audiodescripción

La página Web Accessibility Perspectives: Explore the Impact and Benefits for Everyone tiene vídeos sobre accesibilidad web y discapacidad. Cada vídeo aparece con dos versiones, normal y con audiodescripción.

Algunos ejemplos:


viernes, 16 de marzo de 2018

La accesibilidad web beneficia a todo el mundo

En el artículo Quality ⊃ Good Design ⊃ Inclusive Interface he encontrado la siguiente definición:

Universal web accessibility helps us create sites that are usable by the widest, most diverse audience, rather than creating bolt-on solutions that might benefit one group at the expense of another.

Y algunos ejemplos de cómo la accesibilidad web nos beneficia a todos:

I can't easily see low-contrast web content
- a user with cataracts
- any user accessing your web page on a mobile phone in bright sunlight

I can't easily manipulate your web page
- a user with a hand amputation
- any user standing in a crowded train, holding on to a bar for balance

I can't listen to your web content
- a user with hearing loss
- any user without headphones, accessing a web page in quiet restaurant

I can't easily manipulate small or fiddly UI controls
- a user with loss of fine motor control
- any user accessing a web page while also walking

I can't make sense of long complicated text passages on your web page
- a user with an attention deficit disorder
- any user reading web content while distracted by a crying child

miércoles, 14 de marzo de 2018

Cómo silenciar JAWS para que solo funcione con los navegadores web

Un truco muy útil para los que usamos un lector de pantallas para revisar la accesibilidad de las páginas web: Shut up JAWS.

lunes, 12 de marzo de 2018

Cómo automatizar las pruebas de accesibilidad

En el artículo Automating Your Accessibility Tests se explica un método para automatizar las pruebas de accesibilidad:
Accessibility is one of those things we all wish we were better at. It can lead to a bunch of questions like: how do we make our site better? How do we test what we have done? Should we spend time each day going through our site to check everything by hand? Or just hope that everyone on our team has remembered to check their changes are accessible?
This is where automated accessibility tests can come in. We can set up automated tests and have them run whenever someone makes a pull request, and even alongside end-to-end tests, too.
Automated tests can’t cover everything however; only 20 to 50% of accessibility issues can be detected automatically. For example, we can’t yet automate the comparison of an alt attribute with an image’s content, and there are some screen reader tests that need to be carried out by hand too. To ensure our site is as accessible as possible, we will still need to carry out manual tests, and I will cover these later.