En A warning about automated accessibility "warnings":
There are a lot of people out there who want automated accessibility testing. I see the question asked all the time on Twitter, especially by those that may be new to accessibility. Often they may not know exactly what to focus on to fix their issues, and just want a report, or linting errors, to tell them what to fix and why.
Fortunately for them, there are quite a few tools out there than can be run as part of development build processes, as one-off instances via browser extensions, and there are even services that will run continuous testing against your website or application.
These testing tools are really great for helping people find flagrant accessibility issues. However, just because a warning pops up, or your “accessibility score” doesn’t reach a perfect 100%, you should still verify that these warnings are actually issues to solve for.
[...]
Automated tests are just one tool we can use to help ensure we’re building accessibly compliant websites and applications. However, it’s important to understand the results you’re receiving, and to be able to verify if an issue, or best practice, is truly an issue to act on.
For instance, warnings to check text against background images is common place with many automated checkers. It can be incredibly difficult to automatically determine color contrast in such situations, so a warning will be flagged for a manual check. It is a good thing to be reminded to verify such instances. While it may seem daunting to be met with a large number of issues to “review”, it’s far better than receiving no guidance at all.
Sometimes you may come across gaps in the assertions these tools are based on. Or a best practice may dictate that you don’t double up ARIA roles on their native elements, when that’s absolutely what you need to do to ensure cross-browser and assistive technology feature parity.
So please do use these tools, they can be incredibly helpful. It just behooves us to ensure that we’re not chasing down “100% accessibility scores” when it’s usable and inclusive user experiences we should really be focused on.
viernes, 29 de marzo de 2019
miércoles, 27 de marzo de 2019
Sobre el uso de abbr
Consejos de Short note: The abbreviation appreciation society:
WHY SUX?
A solution
Provide an expansion of the abbreviation/acronym, neuronym even, in plain text on first use, use an <abbr> to mark up the abbreviation, which provides a hint to user agents on how to announce/display the content:
WHY SUX?
- The title attribute content is only practically available to mouse users.
- The title attribute display for mouse users with low vision is problematic, to say the least.
- The title attribute content is available to users of JAWS and NVDA screen reader users if they enable it, by default it’s ignored.
- VoiceOver simply does not announce the title attribute content on <abbr>
- No amount of clever tricks with ARIA, CSS and JavaScript will make it not suck.
A solution
Provide an expansion of the abbreviation/acronym, neuronym even, in plain text on first use, use an <abbr> to mark up the abbreviation, which provides a hint to user agents on how to announce/display the content:
lunes, 25 de marzo de 2019
Informes sobre accesibilidad de e-learning
Dos informes que ya tienen algunos años:
Accesibilidad de plataformas e-learning, recursos educativos y libros electrónicos
En este contexto, el Observatorio de la Accesibilidad TIC de Discapnet se ha centrado en este estudio en los recursos educativos online, en las plataformas de e-learning y en los libros educativos electrónicos. Para la selección de la muestra se han tenido en cuenta criterios objetivos, como las principales fuentes públicas de recursos educativos para alumnos y profesores, las plataformas e-learning más utilizadas por las universidades españolas e internacionales, o las principales editoriales de material educativo electrónico en nuestro país. En el siguiente apartado se recoge la muestra de recursos, plataformas y libros analizados y los criterios que han llevado a determinarla.
Accesibilidad de Plataformas Educativas
En este contexto, el Observatorio de la Accesibilidad TIC de Discapnet se ha centrado en este estudio en sitios web de empresas y organizaciones que ofrecen formación online utilizando alguna de las plataformas educativas más comunes. Para la selección de la muestra se han considerado tanto las plataformas para la gestión de grupos de tamaño limitado (como Moodle y Sakai, que ya fueron analizadas en el observatorio de Discapnet en 2013) y aquellas más novedosas que ofrecen cursos de tipo más abierto y que van dirigidas a grupos de mayor tamaño (los conocidos como MOOCs). En el siguiente apartado se recoge la muestra de sitios web analizados y los criterios que han llevado a determinarla.
El estudio pretende ofrecer una panorámica sobre el estado actual de la accesibilidad de una selección de plataformas educativas, de modo que se cuente con un diagnóstico que permita orientar a los responsables de su creación, gestión y publicación en la mejora de las condiciones de accesibilidad, y a los usuarios en cuanto a las posibilidades que ofrece cada uno.
Accesibilidad de plataformas e-learning, recursos educativos y libros electrónicos
En este contexto, el Observatorio de la Accesibilidad TIC de Discapnet se ha centrado en este estudio en los recursos educativos online, en las plataformas de e-learning y en los libros educativos electrónicos. Para la selección de la muestra se han tenido en cuenta criterios objetivos, como las principales fuentes públicas de recursos educativos para alumnos y profesores, las plataformas e-learning más utilizadas por las universidades españolas e internacionales, o las principales editoriales de material educativo electrónico en nuestro país. En el siguiente apartado se recoge la muestra de recursos, plataformas y libros analizados y los criterios que han llevado a determinarla.
Accesibilidad de Plataformas Educativas
En este contexto, el Observatorio de la Accesibilidad TIC de Discapnet se ha centrado en este estudio en sitios web de empresas y organizaciones que ofrecen formación online utilizando alguna de las plataformas educativas más comunes. Para la selección de la muestra se han considerado tanto las plataformas para la gestión de grupos de tamaño limitado (como Moodle y Sakai, que ya fueron analizadas en el observatorio de Discapnet en 2013) y aquellas más novedosas que ofrecen cursos de tipo más abierto y que van dirigidas a grupos de mayor tamaño (los conocidos como MOOCs). En el siguiente apartado se recoge la muestra de sitios web analizados y los criterios que han llevado a determinarla.
El estudio pretende ofrecer una panorámica sobre el estado actual de la accesibilidad de una selección de plataformas educativas, de modo que se cuente con un diagnóstico que permita orientar a los responsables de su creación, gestión y publicación en la mejora de las condiciones de accesibilidad, y a los usuarios en cuanto a las posibilidades que ofrece cada uno.
viernes, 22 de marzo de 2019
miércoles, 20 de marzo de 2019
La importancia de los encabezados
El artículo The Importance of Heading Levels for Assistive Technology explica lo importante que son los encabezados para la navegación por una página web:
The HTML specification describes six heading elements: h1, h2, h3, h4, h5, and h6. The number in each of these heading elements reflects its priority, with h1 being the most general and h6 being the most specific.
This is an important thing to know! WebAIM’s 2017 Screen Reader survey tells us that navigating via headings is the most important way people who rely on assistive technology locate information. Because of this, it’s important to craft your website’s headings properly.
lunes, 18 de marzo de 2019
Guía de estilo para crear contenido apropiado para las personas con dislexia
La Dyslexia Style Guide 2018: Creating Dyslexia Friendly Content de la British Dyslexia Association:
This Style Guide provides principles that can help ensure that written material
considers the difficulties experienced by some dyslexic people and allows for the use
of text to speech to facilitate ease of reading. Adopting best practice for dyslexic
readers has the advantage of making all written communication easier on the eye for
everyone.
When making changes consider all the ways that you use written communications,
such as emails, presentations, web pages and printed materials. Consider these
principles in combination with other accessibility guidance such as the Web
Accessibility Content Guidelines (WCAG).
crowded. Alternatives include Verdana, Tahoma, Century Gothic, Trebuchet,
Calibri, Open Sans.
• Font size should be 12-14 point or equivalent (e.g. 1-1.2em / 16-19 px). Some
dyslexic readers may request a larger font.
• Larger inter-letter / character spacing (sometimes called tracking) improves
readability, ideally around 35% of the average letter width. If letter spacing is
excessive it can reduce readability.
• Inter-word spacing should be at least 3.5 times the inter-letter spacing.
• Larger line spacing improves readability and should be proportional to inter-word
spacing; 1.5 / 150% is preferable.
• Avoid Underlining and italics as this can make the text appear to run together and
cause crowding. Use bold for emphasis.
• Avoid text in uppercase / capital letters and small caps, which can be less familiar
to the reader and harder to read.
through your content.
In Word, you’ll find these tools in the ‘Home’ tab:
• For headings, use a font size that is at least 20% larger than the normal text. If
further emphasis is required, then use bold.
• Use formatting tools for text alignment, justification, indents, lists, line and
paragraph spacing to support assistive technology users.
In Word, you’ll find these tools in the ‘Layout’ tab:
• Add extra space around headings and between paragraphs.
• Ensure hyperlinks look different from headings and normal text.
distracting surrounds.
• Use sufficient contrast levels between background and text.
• Use dark coloured text on a light (not white) background.
• Avoid green and red/pink, as these colours are difficult for those who have colour
vision deficiencies (colour blindness).
• Consider alternatives to white backgrounds for paper, computer and visual aids
such as whiteboards. White can appear too dazzling. Use cream or a soft pastel
colour. Some dyslexic people will have their own colour preference.
• When printing, use matt paper rather than gloss. Paper should be thick enough to
prevent the other side showing through.
• Avoid multiple columns (as used in newspapers).
• Lines should not be too long: 60 to 70 characters.
• Use white space to remove clutter near text and group related content.
• Break up the text with regular section headings in long documents and include a
table of contents.
• Be concise; avoid using long, dense paragraphs.
• Use short, simple sentences in a direct style.
• Use images to support text. Flow charts are ideal for explaining procedures.
Pictograms and graphics can help to locate and support information in the text.
• Consider using bullet points and numbering rather than continuous prose.
• Give instructions clearly.
• Avoid double negatives.
• Avoid abbreviations where possible; always provide the expanded form when first
used.
• Provide a glossary of abbreviations and jargon.
This Style Guide provides principles that can help ensure that written material
considers the difficulties experienced by some dyslexic people and allows for the use
of text to speech to facilitate ease of reading. Adopting best practice for dyslexic
readers has the advantage of making all written communication easier on the eye for
everyone.
When making changes consider all the ways that you use written communications,
such as emails, presentations, web pages and printed materials. Consider these
principles in combination with other accessibility guidance such as the Web
Accessibility Content Guidelines (WCAG).
Readable Fonts
• Use sans serif fonts, such as Arial and Comic Sans, as letters can appear lesscrowded. Alternatives include Verdana, Tahoma, Century Gothic, Trebuchet,
Calibri, Open Sans.
• Font size should be 12-14 point or equivalent (e.g. 1-1.2em / 16-19 px). Some
dyslexic readers may request a larger font.
• Larger inter-letter / character spacing (sometimes called tracking) improves
readability, ideally around 35% of the average letter width. If letter spacing is
excessive it can reduce readability.
• Inter-word spacing should be at least 3.5 times the inter-letter spacing.
• Larger line spacing improves readability and should be proportional to inter-word
spacing; 1.5 / 150% is preferable.
• Avoid Underlining and italics as this can make the text appear to run together and
cause crowding. Use bold for emphasis.
• Avoid text in uppercase / capital letters and small caps, which can be less familiar
to the reader and harder to read.
Headings and Structure
• Use headings and styles to create consistent structure to help people navigatethrough your content.
In Word, you’ll find these tools in the ‘Home’ tab:
• For headings, use a font size that is at least 20% larger than the normal text. If
further emphasis is required, then use bold.
• Use formatting tools for text alignment, justification, indents, lists, line and
paragraph spacing to support assistive technology users.
In Word, you’ll find these tools in the ‘Layout’ tab:
• Add extra space around headings and between paragraphs.
• Ensure hyperlinks look different from headings and normal text.
Colour
• Use single colour backgrounds. Avoid background patterns or pictures anddistracting surrounds.
• Use sufficient contrast levels between background and text.
• Use dark coloured text on a light (not white) background.
• Avoid green and red/pink, as these colours are difficult for those who have colour
vision deficiencies (colour blindness).
• Consider alternatives to white backgrounds for paper, computer and visual aids
such as whiteboards. White can appear too dazzling. Use cream or a soft pastel
colour. Some dyslexic people will have their own colour preference.
• When printing, use matt paper rather than gloss. Paper should be thick enough to
prevent the other side showing through.
Layout
• Left align text, without justification.• Avoid multiple columns (as used in newspapers).
• Lines should not be too long: 60 to 70 characters.
• Use white space to remove clutter near text and group related content.
• Break up the text with regular section headings in long documents and include a
table of contents.
Writing Style
• Use active rather than passive voice.• Be concise; avoid using long, dense paragraphs.
• Use short, simple sentences in a direct style.
• Use images to support text. Flow charts are ideal for explaining procedures.
Pictograms and graphics can help to locate and support information in the text.
• Consider using bullet points and numbering rather than continuous prose.
• Give instructions clearly.
• Avoid double negatives.
• Avoid abbreviations where possible; always provide the expanded form when first
used.
• Provide a glossary of abbreviations and jargon.
viernes, 15 de marzo de 2019
Inicio del curso gratuito "Discapacidad y envejecimiento activo. Soportes tecnológicos" segunda edición
Este 18 de marzo se inicia la segunda edición del curso Discapacidad y envejecimiento activo. Soportes tecnológicos. en el que participó con el módulo sobre accesibilidad web.
El contenido del curso es:
El contenido del curso es:
- Módulo 1. Accesibilidad e inclusión social
- Módulo 2. Accesibilidad en la Web y Participación social
- Módulo 3. Educación para la salud, intervención social y TIC
- Módulo 4. TIC y vida independiente
- Módulo 5. TIC y tratamiento de la memoria
- Módulo 6. Las TIC en los Recursos Sociales
- Módulo 7. Aplicaciones de la Telemedicina
- Módulo 8. Experiencias internacionales y TIC
miércoles, 13 de marzo de 2019
Las administraciones están obligadas a implementar la normativa de accesibilidad de webs y apps del sector público
Publicado en la sección de noticias del CERMI, Las administraciones están obligadas a implementar la normativa de accesibilidad de webs y apps del sector público y a exigir su cumplimiento:
La profesora titular de Derecho Civil de la Universidad de Granada y patrona de la Fundación Derecho y Discapacidad, Esperanza Alcaín, ha señalado este lunes que “las administraciones no solo están obligadas a implementar la normativa en materia de accesibilidad de páginas webs y aplicaciones móviles del sector público, sino que también tienen que exigir su cumplimiento a toda la sociedad”.
Así se ha manifestado esta experta durante la presentación de una guía jurídica y técnica de orientación para el cumplimiento del Real Decreto 1112/2018, de 7 de septiembre, con el que se incorpora al ordenamiento jurídico español la Directiva (UE) 2016/2102, del Parlamento Europeo y del Consejo, de 26 de octubre de 2016, sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público, que incluye la Administración General del Estado, administraciones autonómicas y locales, las entidades públicas y privadas dependientes de ellas, las universidades públicas, la Administración de Justicia, el Congreso de los Diputados, el Senado, el Consejo de Estado, el Consejo Económico y Social, el Consejo General del Poder Judicial, el Tribunal Constitucional, el Tribunal de Cuentas, el Defensor del Pueblo y el Banco de España, entre otros.
lunes, 11 de marzo de 2019
Cuando se diseña para las personas con discapacidad, todos nos beneficiamos
When we design for disability, we all benefit es una charla TEDx en la que se defiende que un diseño inclusivo no solo ayuda a las personas con discapacidad, sino a todas las personas:
"I believe that losing my hearing was one of the greatest gifts I've ever received," says Elise Roy. As a disability rights lawyer and design thinker, she knows that being Deaf gives her a unique way of experiencing and reframing the world -- a perspective that could solve some of our largest problems. As she says: "When we design for disability first, you often stumble upon solutions that are better than those when we design for the norm."
miércoles, 6 de marzo de 2019
Informes de la Oficina de Atención a la Discapacidad
En Informes de la OADIS están disponibles los informes emitidos por la Oficina de Atención a la Discapacidad desde el año 2005 hasta la actualidad.
En el informe anual del año 2017, entre alguno de los expedientes podemos encontrar:
Y muchos otros.
En el informe anual del año 2017, entre alguno de los expedientes podemos encontrar:
- Ausencia de accesibilidad a la pagina. web de la Asamblea de Madrid
- Ausencia de accesibilidad a la página web del Ayuntamiento de Madrid
- Ausencia de subtitulación en página web de la Guardia Civil
- Ausencia de subtitulación en canal YouTube y vídeos de la Policía Naciona
- Barreras identificadas en páginas web de organismos públicos-Ayuntamiento Burgos
- Barreras identificadas en páginas web de organismos públicos- Defensor del Pueblo Navarra
Y muchos otros.
lunes, 4 de marzo de 2019
Características de accesibilidad de los navegadores web
Las características que ofrecen los navegadores web para mejorar la experiencia de usuario relacionada con la accesibilidad:
viernes, 1 de marzo de 2019
Cómo navega una persona con un lector de pantalla
Muy interesante lo que se explica en How A Screen Reader User Accesses The Web: A Smashing Video. Incluye un vídeo con una sesión de navegación de una persona ciega con un lector de pantalla.
miércoles, 27 de febrero de 2019
Conocer a las personas con discapacidad
Eso no se pregunta es un programa de Telemadrid que tiene como objetivo combatir los prejuicios y la discriminación de ciertos colectivos:
Y otro sobre las personas en silla de ruedas:
Ciegos, gitanos, musulmanes, negros, obesos, religiosos, transexuales, parados de larga duración, personas con Asperger, de baja estatura, síndrome de Down, en silla de ruedas... Doce colectivos marginados responden a preguntas anónimas ante la cámara en un tono desenfadado, sin dramatismo y con humor, para combatir los prejuicios y la discriminación.Hay un vídeo sobre las personas ciegas:
Y otro sobre las personas en silla de ruedas:
lunes, 25 de febrero de 2019
Errores de accesibilidad en el sitio web de Apple
En How to learn from Apple's mistakes on website accessibility se explican algunos errores de accesibilidad del sitio web de Apple:
There were multiple difficulties noted. The key issues were:
- Insufficiently labelled input fields (meaning screenreaders are left unsure of what information is needed in the boxes they're asked to enter information into)
- Links with identical text, that lead to different locations. While this is not a failure of WCAG (Web Content Accessibility Guidelines), it is not good practise.
- Dynamic content not made accessible to screenreader users, e.g. auto-suggest search results
Further difficulties noted in the complaint were:
- Unable to browse and purchase electronics such as the iPhone, iPad, and MacBook Pro laptop
- Inability to make service appointments online
- Trouble finding a store
viernes, 22 de febrero de 2019
Curso gratuito "Discapacidad y envejecimiento activo. Soportes tecnológicos" segunda edición
Ya está abierta la inscripción a la segunda edición del curso Discapacidad y envejecimiento activo. Soportes tecnológicos. en el que participó con el módulo sobre accesibilidad web. El curso comienza el 18 de marzo de 2019 y tiene una duración estimada de 8 semanas.
El contenido del curso es:
El contenido del curso es:
- Módulo 1. Accesibilidad e inclusión social
- Módulo 2. Accesibilidad en la Web y Participación social
- Módulo 3. Educación para la salud, intervención social y TIC
- Módulo 4. TIC y vida independiente
- Módulo 5. TIC y tratamiento de la memoria
- Módulo 6. Las TIC en los Recursos Sociales
- Módulo 7. Aplicaciones de la Telemedicina
- Módulo 8. Experiencias internacionales y TIC
lunes, 18 de febrero de 2019
En España se tiene que aplicar WCAG 2.1
En Las guías del Observatorio de Accesibilidad Web se actualizan a WCAG 2.1, del Portal Administración Electrónica del Gobierno de España, se confirma que en España se debe aplicar WCAG 2.1:
El 20 de septiembre de 2018 entró en vigor el Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público(Abre en nueva ventana) , que traspone al ordenamiento jurídico español la Directiva (UE) 2016/21022(Abre en nueva ventana) .
En el Real Decreto se establecen como requisitos de accesibilidad a cumplir los indicados en la norma armonizada que la Comisión Europea ha publicado el 21 de diciembre de 2018 mediante la Decisión de Ejecución (UE) 2018/2048. Este estándar armonizado está basado en la última versión de la norma EN 301 549 V2.1.2 (2018-08)(Abre en nueva ventana) “Requisitos de accesibilidad de productos y servicios TIC” que a su vez, a un nivel técnico, converge en última instancia con las nuevas WCAG 2.1(Abre en nueva ventana) del W3C (Pautas de Accesibilidad para el Contenido Web).
Bajo este nuevo marco, el Ministerio de Política Territorial y Función Pública, a través del Observatorio de Accesibilidad Web, ha adaptado las guías previamente existentes que se ven afectadas por los nuevos requisitos del estándar armonizado y, por consiguiente, por las WCAG 2.1.
El 20 de septiembre de 2018 entró en vigor el Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público(Abre en nueva ventana) , que traspone al ordenamiento jurídico español la Directiva (UE) 2016/21022(Abre en nueva ventana) .
En el Real Decreto se establecen como requisitos de accesibilidad a cumplir los indicados en la norma armonizada que la Comisión Europea ha publicado el 21 de diciembre de 2018 mediante la Decisión de Ejecución (UE) 2018/2048. Este estándar armonizado está basado en la última versión de la norma EN 301 549 V2.1.2 (2018-08)(Abre en nueva ventana) “Requisitos de accesibilidad de productos y servicios TIC” que a su vez, a un nivel técnico, converge en última instancia con las nuevas WCAG 2.1(Abre en nueva ventana) del W3C (Pautas de Accesibilidad para el Contenido Web).
Bajo este nuevo marco, el Ministerio de Política Territorial y Función Pública, a través del Observatorio de Accesibilidad Web, ha adaptado las guías previamente existentes que se ven afectadas por los nuevos requisitos del estándar armonizado y, por consiguiente, por las WCAG 2.1.
viernes, 15 de febrero de 2019
Inclusive Components
El sitio web Inclusive Components es un blog con patrones de diseño accesibles. Se define como:
A blog trying to be a pattern library. All about designing inclusive web interfaces, piece by piece.
miércoles, 13 de febrero de 2019
Los problemas de las personas sordas y algunos consejos
Muy interesante el artículo Inclusive Design and Deafness que proporciona los siguientes consejos:
- Caption for video and spoken sounds and/or provide transcripts for podcasts.
- Provide (colored) light when using sound to give an alert or action. (E.g. public transport check- in and -out terminals.)
- Make screens readable with good use of colors, e.g, red for warning, yellow for notice, green for good, etc. (E.g. public transport check- in and -out terminals.)
- Don’t require a phone number unless you provide text and/or WhatsApp service.
- Don’t be available only by phone, provide email, WhatsApp and/or live chat.
- Provide a ‘Comments’ text field so people can indicate for example if they are deaf and prefer to not communicate by phone.
- Avoid the use of a donotreply@yourdomain.com email. Especially with important emails.
- Make sure your digital form/database takes into account if a client is deaf, blind, uses a wheelchair, etc. This way people can keep track and not make mistakes with their clients. E.g. a doctor office or hospital must be able to register such things with general patient information. (I know for a fact those systems don’t make that possible.)
- I’ve been informed that the new privacy laws make this difficult. As long as this is an optional field filled in per request of the client it should not be a problem. I rather have they register I’m deaf than get phone calls I can’t do anything with. We shouldn’t use GDPR laws as an easy way out of being inclusive.
- When organizing a congress, provide live captions. They are not only useful for deaf and HoH people. But also for hearing people who might have missed something or are not fluid at the language being spoken. Reading it at their pace helps.
- In the Netherlands, there is only a handful of text transcribers that can transcribe in English for me. It has happened that I had to miss a congress last minute because the transcriber was sick. Also going to congresses abroad is not really viable for me. I would have to pay myself for the plane ticket, hotel, etc. for the transcriber. Imagine if all congresses had live transcription as a standard. I would be able just like everybody else, to decide last minute if I want to attend, what I want to attend and where I want to go to attend. That is being deaf inclusive.
lunes, 11 de febrero de 2019
Relación entre accesibilidad y usabilidad
En el siguiente vídeo se explica la relación que existe entre estas dos dimensiones que son factores esenciales para la calidad de un sitio web:
viernes, 8 de febrero de 2019
Los captchas apestan
Los captchas son una gran barrera de accesibilidad. Incluso los captchas que se anuncian como accesibles suelen ser no accesibles.
En Catpchas Suck se muestran algunos ejemplos reales de lo terribles que pueden llegar a ser los captchas, tanto desde el punto de vista de la usabilidad como de la accesibilidad.
Además, se ofrecen algunas alternativas:
Check out these articles on Captcha alternatives:
9 Captcha Alternatives That Won’t Wreck Your UX (dtelepathy.com)
Not all of the 9 methods are accessible, so focus your attention on number 3 – “Biometric security”, number 4 – “Text message verification” and number 6 – “The honeypot method”.
Think Your Site Needs A CAPTCHA? (usertesting.com)
Same as with the previous article: not all alternatives they suggest are accessible. Focus your attention on “Honeypots”, “Timestamps” and “Verified sign in”.
En Catpchas Suck se muestran algunos ejemplos reales de lo terribles que pueden llegar a ser los captchas, tanto desde el punto de vista de la usabilidad como de la accesibilidad.
Además, se ofrecen algunas alternativas:
Check out these articles on Captcha alternatives:
9 Captcha Alternatives That Won’t Wreck Your UX (dtelepathy.com)
Not all of the 9 methods are accessible, so focus your attention on number 3 – “Biometric security”, number 4 – “Text message verification” and number 6 – “The honeypot method”.
Think Your Site Needs A CAPTCHA? (usertesting.com)
Same as with the previous article: not all alternatives they suggest are accessible. Focus your attention on “Honeypots”, “Timestamps” and “Verified sign in”.
jueves, 7 de febrero de 2019
Análisis de la accesibilidad de los sitios web de los colegios en Estados Unidos
En Accessibility in mind? A nationwide study of K-12 Web sites in the United States se ha publicado un estudio de la accesibilidad de los sitios web de los colegios en Estados Unidos.
El resumen del artículo dice:
El resumen del artículo dice:
Web site accessibility is a serious civil rights concern that has historically been difficult to measure and to establish success criteria for. By conducting automated accessibility analyses via the WAVE tool, we calculated accessibility norms of a statistically appropriate, random sample of K–12 school Web sites across the U.S. (n = 6,226) and merged results with national datasets to determine how school demographics influence accessibility. Results indicated that schools across all demographic groups generally struggle to make their Web sites fully accessible to their universe of diverse users and revealed that the concrete, highest-impact steps that schools nationwide need to take to improve accessibility include improving poor contrast between text and backgrounds, providing alternative text to images and other visual elements, and labeling form controls.
miércoles, 6 de febrero de 2019
La importancia de usar etiquetas (labels) en los formularios
El artículo Labels Required explica por qué es importante identificar los controles de los formularios:
Using the label element checks all of the boxes for inclusivity when properly formatted: it's directly associated with a form element (either with the for attribute or by nesting the element inside the label), displayed as text by standard browsers, and spoken by screen readers. Clicking or tapping on a label will focus the associated element (or select the checkbox or radio option), and when you focus directly on the element, screen readers will read the label. Ensuring that both visual and auditory cues are present and intelligible are critical when you consider that in WebAIM's annual screen reader study screen reader users report relying on a mix of both, with the majority using audio exclusively.Hay otras alternativas a label, pero en este artículo se explica que no siempre funcionan:
It's possible to use markup other than label, but when you do, users may see or hear blank form elements and have no idea what to enter.
At first glance, placeholder does a very similar job to label: it's displayed as text (within text inputs, specifically) and read aloud by screen readers. The placeholder has a purpose, though, that diverges from that of a label. It's meant to be a suggestion, formatting guideline, or hint that is ultimately replaced by user input. So while a placeholder may seem like a worthy label alternate on the first pass through a form, once a data value is entered, that label is gone. And that's just one of several reasons why placeholder is an inadequate substitute label. It's much more valuable when used as a guide.
The aria-label attribute provides label text to screen readers for identifying interactive elements, or elements with ARIA roles, and it produces the same audio feedback as the label element. There's no reason to use both on the same form field, and we actually recommend against trying.La conclusión es clara:
Out of the box, the label element is all we need to indentify fields in an accessible way. Used in combination with accessible hiding and other helper elements, like placeholder or icons, we can ensure that a form element's purpose is clearly communicated to all users.
martes, 5 de febrero de 2019
Consejos para el rediseño de la web de Renfe
Renfe ha sacado a contratación el rediseño de su sitio web.
En Twitter podemos encontrar muchas sugerencias para su mejora, por ejemplo, este hilo:
En Twitter podemos encontrar muchas sugerencias para su mejora, por ejemplo, este hilo:
La noticia de que Renfe invertirá 700.000€ en mejorar su web nos ha alegrado tanto a @marcborras y a mi que hemos decidido hacer un hilo con 17 predicciones de cosas que esta vez, ya sí que sí, seguro que van a arreglar. Empezamos 👇 pic.twitter.com/y4SR7fFSgZ— Carlos Sánchez (@chocotuits) 3 de febrero de 2019
lunes, 4 de febrero de 2019
La web de Renfe será accesible... o quizás no
La semana pasada se publicó la noticia Renfe invertirá 700.000 euros para arreglar su web de una vez por todas:
Renfe ha pisado el acelerador nada más aprobar su plan estratégico. Si el mismo día en el que se puso en marcha la operadora anunció la licitación del primer paquete de trenes para renovar su flota, hoy es el día de su página web. La operadora ferroviaria ha licitado el contrato, valorado en 700.000 euros, para renovar su principal canal digital de contacto con sus clientes.Y sorprendente este dato:
La mejora de la web de Renfe es una de las medidas más demandadas por sus usuarios desde hace años. Esto ha provocado que esta licitación haya sido una de las primeras en ponerse en marcha. Una decisión muy simbólica que tanto el presidente de la compañía, Isaías Táboas, como su director de estrategia, Manel Villalante, han querido priorizar para ponerla en marcha lo antes posible.
El proyecto licitado tiene por objetivo mejorar la usabilidad de la web de Renfe. Uno de los elementos más destacados en el plan estratégico de la operadora. En el caso de la web la intención es desterrar todos los actuales problemas que genera la actual y dotarla de las capacidades que permitan mejorar el rendimiento y el posicionamiento de los contenidos.
Hay que recordar que la última gran renovación del principal canal digital de Renfe se realizó hace 10 años. Un periodo en el que regularmente se han ido introduciendo mejoras pero que el tiempo ha dejado anticuado.
En concreto, entre enero y agosto el 46,8% del total de billetes se vendió a través de la web. Renfe comercializó 16,8 millones de plazas de tren a través de su portal de Internet.Y todo ello, a pesar de los problemas de usabilidad y accesibilidad que tiene la web de Renfe.
viernes, 1 de febrero de 2019
Accesibilidad web y discapacidad cognitiva
La discapacidad cognitiva es una de las menos tratadas en la información sobre accesibilidad web. Por ejemplo, con la publicación de WCAG 2.1 se ha empezado a contemplar en WCAG, antes "se olvidaba" porque es más difícil.
El artículo Web accessibility for cognitive, learning and neurological impairment ofrece una lista de condiciones que se engloban dentro de la discapacidad cognitiva:
Y ofrece unos consejos para mejorar la accesibilidad web:
El artículo Web accessibility for cognitive, learning and neurological impairment ofrece una lista de condiciones que se engloban dentro de la discapacidad cognitiva:
- ADHD (Attention Deficit Hyperactivity Disorder) — difficulty focusing (e.g., on a single task, for longer periods, easy to be distracted etc.).
- Autism — difficulty in interacting with social communication.
- Mental health disabilities (mood disorder, anxiety, schizophrenia, delirium) — people with this disabilities can be affected in their day-by-day activities by the medications’ side effects (e.g., blurred vision, memory impairments, tremors etc.).
- Memory impairments — both short and long-term memory impairment.
- Perceptual disabilities (learning disabilities) — difficulty in processing sensory information (auditory, tactile and visual information).
- Seizure disorders (migraines, epilepsy) — reaction to audio and visual stimulation.
Y ofrece unos consejos para mejorar la accesibilidad web:
- Using headings, subheadings, and lists for structuring the information. Structuring information in this way will help people to easily scan the page, to see the essential information of that all content and, in the same time, will help the machine to skim a page with a screen reader. What does it mean to skim a page? Is to jump from heading to heading, in this way reading just the main information presented in that whole.
- Make sure that the line length doesn’t exceed 70–80 characters. Short sentences are easy to read by any kind of users.
- Using more white space in your Webpage. Having a spatiality in your Webpage will help users with different cognitive, learning and neurological impairment to structure the information and to understand it easier.
- Consistency in colors, font, and locations of the elements in the Webpage. Consistency is one of the principles of user experience and it’s very important that your product has it. A lot of users are following a pattern while navigating on a Website, and changing their pattern can put them into the difficulty of using it.
- Implementing keyboard support. For those people with impairment it easy to have implemented the keyboard navigation (through shortcuts, commands) than the mouse navigation because, in that way, they will not need to follow the cursor of the mouse on the screen, an activity that for their condition requires a lot of focus. Also, this method will help not just this category of people, but users in general because the keyboard using while navigation increased in the last couple of years.
- Offering alternatives for multimedia content. Having a description for non-text content, it will not only help the screen-reader software to transmit de correct information to the user (to not skip an image, just because it does not have a description) but the users, too. When a Web page can’t open all the images, it’s recommended that in that place to have a short description, in this way, the user will know what that image is about. Also, this behavior needs to be implemented for video and audio elements, too.
miércoles, 30 de enero de 2019
¿Sitio web accesible para las personas ciegas?
Me he topado con el sitio web Paths to Literacy. Se supone que debe ser accesible para las personas ciegas porque pone "for students who are blind or visually impaired". Sin embargo, me encuentro esto:
Las tres imágenes debajo de "Latest Posts" son enlaces a los respectivos artículos publicados. El texto alternativo de esas imágenes es:
Las tres imágenes debajo de "Latest Posts" son enlaces a los respectivos artículos publicados. El texto alternativo de esas imágenes es:
- Collage of book covers showing characters who are blind
- Male adult's hands reading braille
- Blurred image of cars on a street
El texto alternativo representa el contenido de la imagen, pero para nada representa la función de la imagen que en este caso es enlazar con cada uno de los artículos. Ese texto artículo es inútil.
lunes, 28 de enero de 2019
Enseñando a programar a niños ciegos
En Microsoft's pods teach blind children how to code se comenta una experiencia de programación con niños ciegos y un sistema llamado Code Jumper desarrollado por Microsoft.
viernes, 25 de enero de 2019
Newsletters para estar al día sobre accesibilidad web
En Digital Accessibility Newsletters se recogen algunos de los newsletters sobre accesibilidad web que conozco. Para mí, los mejores son:
WebAIM
Accessibility Weekly
Frontend Focus
También recomiendo el siguiente, que no aparece en esa lista:
https://mediaaccess.org.au/
WebAIM
Accessibility Weekly
Frontend Focus
También recomiendo el siguiente, que no aparece en esa lista:
https://mediaaccess.org.au/
miércoles, 23 de enero de 2019
Cómo escribir un buen texto alternativo
En Considerations when writing alt text se dan algunos consejos para escribir un buen texto alternativo.
lunes, 21 de enero de 2019
Formularios de búsqueda no accesibles
En Unlabelled search fields se explica cómo etiquetar correctamente un formulario de búsqueda para que sea accesible.
La típica implementación como la siguiente está mal:
<input type="search" placeholder="…">
<button type="submit">
Search
</button>
Algunas alternativas son:
<input aria-labelledby="searchtext" type="search" placeholder="…">
<button type="submit" id="searchtext">
Search
</button>
O también:
<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>
En el artículo también se repasan las implementaciones de BBC, Medium, Google, Twitter y otros sitios web populares.
La típica implementación como la siguiente está mal:
<input type="search" placeholder="…">
<button type="submit">
Search
</button>
Algunas alternativas son:
<input aria-labelledby="searchtext" type="search" placeholder="…">
<button type="submit" id="searchtext">
Search
</button>
O también:
<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>
En el artículo también se repasan las implementaciones de BBC, Medium, Google, Twitter y otros sitios web populares.
viernes, 18 de enero de 2019
El sitio web de Domino's Pizza tiene que ser accesible en EEUU
En BIG WIN FOR WEB ACCESSIBILITY IN DOMINO’S PIZZA CASE podemos leer:
the ADA applied to Domino’s website and app because the Act mandates that places of public accommodation, like Domino’s, provide auxiliary aids and services to make visual materials available to individuals who are blind.El juicio contra Domino's Pizza.
miércoles, 16 de enero de 2019
Versión texto, NO, NUNCA
Es bastante sorprendente que todavía haya gente que ofrezca una "versión texto" o "versión solo texto" como solución para la accesibilidad de un sitio web. Pensaba que ya nunca más me encontraría con ello, pero me equivoqué.
Tiene en el pie de página un enlace Versión texto que muestra esta página:
Podemos ver que el URL de esa página es https://www.umh.es/acc/, supongo que "acc" debe ser por "accesible".
lunes, 14 de enero de 2019
Denuncias por falta de accesibilidad web en EEUU en el año 2018
En 2018 ADA Web Accessibility Lawsuit Recap Report han publicado un resumen de las denuncias por falta de accesibilidad web que ha habido en EEUU durante el año 2018.
Se contabilizan 2285 denuncias, un incremento del 181% sobre las 814 presentadas en el año 2017:
Existe un patrón de los sitios web denunciados, principalmente están relacionados con el comercio, los servicios de alimentación, viajes y hospitales, banca y finanzas, entretenimiento y diversión y autoservicio (máquinas tipo cajero automático):
Se contabilizan 2285 denuncias, un incremento del 181% sobre las 814 presentadas en el año 2017:
The UsableNet research team has been tracking 2018 federally filed ADA web accessibility-related lawsuits. In 2018, we tracked 2285 lawsuits—up 181% over 2017 which had 814.Igualito, igualito, igualito que en España.
Existe un patrón de los sitios web denunciados, principalmente están relacionados con el comercio, los servicios de alimentación, viajes y hospitales, banca y finanzas, entretenimiento y diversión y autoservicio (máquinas tipo cajero automático):
Although many industries are involved across the cases, six stand out for the additional attention they get. Retail, food service, travel/hospitality, banking/financial, entertainment and leisure, and self-service, have the majority of cases, reflecting a general pattern over 2017 and 2018 toward these types of organizations.
viernes, 11 de enero de 2019
¿Qué herramienta de evaluación de la accesibilidad web debería usar?
En Which accessibility testing tool should you use? proponen:
Browser extensions (I’m using Chrome for the purposes of this post)
WAVE Web Accessibility Evaluation ToolLighthouseaXe browser extensionWCAG Accessibility Audit Developer UISiteImprove Accessibility Checker
Other tools
Tenon.io (free and paid plans available)
miércoles, 9 de enero de 2019
Crear un sitio web accesible alternativo no es una buena solución
Lo de crear un sitio web "versión solo texto" pensaba que era algo que había pasado a la historia, pero parece que no es así...
En Airline Fined for Separate Disabled-Accessible Website podemos leer que la compañía aérea SAS ha sido sancionada con una multa de $200,000 porque creó una versión accesible separada de su sitio web principal:
En Airline Fined for Separate Disabled-Accessible Website podemos leer que la compañía aérea SAS ha sido sancionada con una multa de $200,000 porque creó una versión accesible separada de su sitio web principal:
Offering a separate website for those with disabilities does not comply with the U.S. Department of Transportation’s (DOT) website accessibility requirements, the agency made clear with a $200,000 fine to the Scandinavian Airlines System (SAS).
The DOT established website accessibility requirements that require any U.S. or foreign air carrier that has a website and that operates at least one aircraft seating more than 60 passengers to ensure that its public-facing webpages on its primary website are accessible to individuals with disabilities. Set forth at 14 CFR Part 382, the rule had two phases of implementation.
By December 12, 2015, covered entities needed to ensure that core travel information and services on the airline’s primary website met the Web Content Accessibility Guidelines 2.0 Level AA Standard. Airlines had until December 12, 2016, to achieve compliance for all remaining webpages on the primary site.
But in February 2017, the DOT’s Office of Aviation Enforcement and Proceedings discovered that SAS’ primary website was not accessible to persons with disabilities. Instead, the airline created an “assistive version” of its primary website at a separate and distinct URL.
This separate site violated the DOT rule, the agency said.
“In the preamble to the rule the Department explained that to create a separate accessible website would ‘likely perpetuate the problem of unequal access as carriers allot fewer resources than needed over time to properly maintain the second site,’” according to the DOT consent order with SAS. “The Department also stated that it is a ‘well-established principle of disability non-discrimination law that separate or different aids, benefits or services can only be provided to individuals with disabilities (or a class of such individuals) when necessary to provide aids, benefits or service that are as effective as those provided to others.’”
SAS’ failure to comply also constituted unfair and deceptive practices and an unfair method of competition, the agency said.
In response, SAS argued it “held a good faith belief” that the assistive version of its website was a conforming alternate version that brought its primary site into compliance, pointing the finger at a third-party vendor that “assured” the airline the alternative site met the requirements of the DOT rule. SAS no longer has an alternative separate website designed for individuals with disabilities, and its primary website is accessible.
The DOT Enforcement Office and SAS reached an agreement over the charges. While the airline did not admit to the violations asserted by the agency, it agreed to cease and desist from future similar violations and pay a compromise civil penalty of $200,000. Of the total amount, $100,000 was due immediately, with the remaining $100,000 due and payable if SAS violates the consent order within one year.
“This compromise assessment is appropriate considering the nature and extent of the violations described herein and serves the public interest,” according to the consent order. “It represents a strong deterrent to future similar unlawful practices by SAS and other carriers.”
lunes, 7 de enero de 2019
Beyoncé denunciada por falta de accesibilidad web
En Beyoncé's Parkwood Entertainment sued over website accessibility podemos leer:
A class action lawsuit claims that Beyoncé’s official website violates the Americans With Disabilities Act (1990) by denying visually impaired users equal access to its products and services, according to the Hollywood Reporter.
Web accessibility requires photos to be coded with alt-text so that screen-readers used by visually impaired users can speak the alternative text. Dan Shaked, attorney for plaintiff Mary Conner, said: “There are many important pictures on beyonce.com that lack a text equivalent … As a result, Plaintiff and blind beyonce.com customers are unable to determine what is on the website, browse the website or investigate and/or make purchases.”
The Guardian has contacted representatives for Beyoncé for comment.
Conner is described in the suit as having “no vision whatsoever”. Shaked describes music as “the one and only form of entertainment that truly presents an even playing field between the visually impaired and the sighted”. Conner’s hopes of attending a Beyoncé concert were restricted by her lack of access to the website, the suit claims.
The complaint lists further issues including the lack of accessible drop-down menus and navigation links, and the inability to navigate using a keyboard instead of a mouse.
The proposed lawsuit includes “all legally blind individuals in the United States who have attempted to access Beyonce.com and as a result have been denied access to the enjoyment of goods and services offered by Beyonce.com, during the relevant statutory period.”
Conner seeks a court injunction that would require Beyoncé’s company to make the site accessible to blind and visually impaired customers in accordance with ADA rules, and is pursuing damages for those who have “been subject to unlawful discrimination”.
A class action lawsuit claims that Beyoncé’s official website violates the Americans With Disabilities Act (1990) by denying visually impaired users equal access to its products and services, according to the Hollywood Reporter.
Web accessibility requires photos to be coded with alt-text so that screen-readers used by visually impaired users can speak the alternative text. Dan Shaked, attorney for plaintiff Mary Conner, said: “There are many important pictures on beyonce.com that lack a text equivalent … As a result, Plaintiff and blind beyonce.com customers are unable to determine what is on the website, browse the website or investigate and/or make purchases.”
The Guardian has contacted representatives for Beyoncé for comment.
Conner is described in the suit as having “no vision whatsoever”. Shaked describes music as “the one and only form of entertainment that truly presents an even playing field between the visually impaired and the sighted”. Conner’s hopes of attending a Beyoncé concert were restricted by her lack of access to the website, the suit claims.
The complaint lists further issues including the lack of accessible drop-down menus and navigation links, and the inability to navigate using a keyboard instead of a mouse.
The proposed lawsuit includes “all legally blind individuals in the United States who have attempted to access Beyonce.com and as a result have been denied access to the enjoyment of goods and services offered by Beyonce.com, during the relevant statutory period.”
Conner seeks a court injunction that would require Beyoncé’s company to make the site accessible to blind and visually impaired customers in accordance with ADA rules, and is pursuing damages for those who have “been subject to unlawful discrimination”.
viernes, 4 de enero de 2019
La accesibilidad empieza con un buen uso de HTML
En HTML: A good basis for accessibility se explica:
A great deal of web content can be made accessible just by making sure the correct HTML elements are used for the correct purpose at all times. This article looks in detail at how HTML can be used to ensure maximum accessibility.
Semantic HTML doesn't take longer to write than non-semantic (bad) markup if you do it consistently from the start of your project, and it also has other benefits beyond accessibility:
A great deal of web content can be made accessible just by making sure the correct HTML elements are used for the correct purpose at all times. This article looks in detail at how HTML can be used to ensure maximum accessibility.
Semantic HTML doesn't take longer to write than non-semantic (bad) markup if you do it consistently from the start of your project, and it also has other benefits beyond accessibility:
- Easier to develop with — as mentioned above, you get some functionality for free, plus it is arguably easier to understand.
- Better on mobile — semantic HTML is arguably lighter in file size than non-semantic spaghetti code, and easier to make responsive.
- Good for SEO — search engines give more importance to keywords inside headings, links, etc., than keywords included in non-semantic <div>s, etc., so your documents will be more findable by customers.
miércoles, 2 de enero de 2019
Experiencias en desarrollos tecnológicos accesibles: Experiencia Ecuador
Conferencia impartida en la III Jornada de Accesibilidad Digital organizada por el Instituto Tecnológico de Costa Rica (TEC) del 25 al 28 de octubre de 2016 en San José (Costa Rica):
lunes, 31 de diciembre de 2018
Herramientas para revisión del contraste del color
Una lista enorme, muy enorme, de herramientas para revisar el contraste del color: Color Contrast Tools.
miércoles, 26 de diciembre de 2018
Un mal uso de los colores que crea un problema de accesibilidad para las personas con ceguera al color
En ATG Event Ticketing Website se explica un problema de accesibilidad que presenta el sitio web de venta de entradas más importante del Reino Unido.
Voy a usar la herramienta Coblis — Color Blindness Simulator para simular diferentes tipos de ceguera al color. Como se verá en las siguientes imágenes, hay combinaciones de colores que no se pueden diferenciar claramente.
Claro, cuando los dos colores que no se distinguen claramente están juntos, se pueden diferenciar porque su luminosidad es diferente (uno es más claro/oscuro que el otro). Pero cuando están separados, es muy difícil saber cuál es cual.
RED-BLIND/PROTANOPIA
GREEN-BLIND/DEUTERANOPIA
BLUE-BLIND/TRITANOPIA
MONOCHROMACY/ACHROMATOPSIA
Voy a usar la herramienta Coblis — Color Blindness Simulator para simular diferentes tipos de ceguera al color. Como se verá en las siguientes imágenes, hay combinaciones de colores que no se pueden diferenciar claramente.
Claro, cuando los dos colores que no se distinguen claramente están juntos, se pueden diferenciar porque su luminosidad es diferente (uno es más claro/oscuro que el otro). Pero cuando están separados, es muy difícil saber cuál es cual.
RED-BLIND/PROTANOPIA
GREEN-BLIND/DEUTERANOPIA
BLUE-BLIND/TRITANOPIA
MONOCHROMACY/ACHROMATOPSIA
BLUE CONE MONOCHROMACY
lunes, 24 de diciembre de 2018
Cómo una persona con ceguera al color trabajo con el color
Muy interesante lo que se explica en Cómo interpretar los códigos hexadecimales de color incluso siendo daltónico:
David DeSandro de Metafizzy explica en esta presentación de las dotConferences cómo desarrollar el superpoder de interpretar los códigos de color hexadecimales que habitualmente se usan en HTML/CSS/Photoshop. La técnica no es complicada, aunque requiere conocer algunos detalles. En el caso del propio DeSandro tiene más mérito porque además es daltónico: "No puedo fiarme de mi percepción visual del color a la hora de trabajar con los diseños, así que desarrollé esta habilidad como una forma de cubrir esa necesidad".
lunes, 17 de diciembre de 2018
La accesibilidad de los videojuegos: ¿por qué me debería preocupar?
Conferencia impartida en el Tercer Congreso Internacional en Sistemas de Información y Ciencias de la Computación, INCISCOS 2018, celebrado en Quito (Ecuador) del 14 al 16 de noviembre de 2018.
La industria de los videojuegos es en la actualidad la principal industria del entretenimiento a nivel mundial. Esta situación no es coyuntural, sino que se espera que siga siendo así durante los próximos años.
Desgraciadamente, los videojuegos suelen presentar numerosas barreras de accesibilidad que dificultan o impiden que las personas con discapacidad puedan disfrutar de ellos. Además de la situación de discriminación que supone esto en general, la falta de accesibilidad de los videojuegos puede ser un problema muy grave en el caso de los videojuegos llamados "serios" que son empleados en la enseñanza y en la capacitación profesional.
El objetivo principal de la conferencia es concienciar a los estudiantes de informática, computación y estudios similares que estarán entre el público de la importancia de tener en cuenta la accesibilidad durante el desarrollo de los videojuegos.
La industria de los videojuegos es en la actualidad la principal industria del entretenimiento a nivel mundial. Esta situación no es coyuntural, sino que se espera que siga siendo así durante los próximos años.
Desgraciadamente, los videojuegos suelen presentar numerosas barreras de accesibilidad que dificultan o impiden que las personas con discapacidad puedan disfrutar de ellos. Además de la situación de discriminación que supone esto en general, la falta de accesibilidad de los videojuegos puede ser un problema muy grave en el caso de los videojuegos llamados "serios" que son empleados en la enseñanza y en la capacitación profesional.
El objetivo principal de la conferencia es concienciar a los estudiantes de informática, computación y estudios similares que estarán entre el público de la importancia de tener en cuenta la accesibilidad durante el desarrollo de los videojuegos.
lunes, 10 de diciembre de 2018
Entrevista a Jonathan Chacón
Entrevista a Jonathan Chacón, desarrollador e investigador en accesibilidad, usabilidad y nuevas tecnologías; defiende los conceptos de diseño universal y accesibilidad como criterios de calidad en el software y el hardware.
Defiende la idea de un diseño accesible desde la base evitando parches y mantiene la idea de la tecnología como único camino para alcanzar una sociedad realmente inclusiva para todos ya que todos tenemos capacidades y discapacidades.
Busca divulgar y compartir la idea de una tecnología responsable por y para las personas ejerciendo su cargo de comisionado del colegio de ingeniería en informática de Cataluña para la accesibilidad y usabilidad.
Ha trabajado como consultor, desarrollador e investigador tecnológico en proyectos de biometría, visión artificial, interfaces de usuario inteligentes siempre siguiendo la filosofía del diseño para todos.
Actualmente es responsable de accesibilidad y experiencia de usuario en la startup Tech4Freedom.
Ha publicado varias aplicaciones en la AppStore bajo su sello Tyflos Accessible Software y artículos sobre accesibilidad, usabilidad y tecnología en su sitio web Programar a ciegas así como colaborador en artículos y libros de investigación, diseñador y desarrollador para proyectos educativos e inclusivos.
Defiende la idea de un diseño accesible desde la base evitando parches y mantiene la idea de la tecnología como único camino para alcanzar una sociedad realmente inclusiva para todos ya que todos tenemos capacidades y discapacidades.
Busca divulgar y compartir la idea de una tecnología responsable por y para las personas ejerciendo su cargo de comisionado del colegio de ingeniería en informática de Cataluña para la accesibilidad y usabilidad.
Ha trabajado como consultor, desarrollador e investigador tecnológico en proyectos de biometría, visión artificial, interfaces de usuario inteligentes siempre siguiendo la filosofía del diseño para todos.
Actualmente es responsable de accesibilidad y experiencia de usuario en la startup Tech4Freedom.
Ha publicado varias aplicaciones en la AppStore bajo su sello Tyflos Accessible Software y artículos sobre accesibilidad, usabilidad y tecnología en su sitio web Programar a ciegas así como colaborador en artículos y libros de investigación, diseñador y desarrollador para proyectos educativos e inclusivos.
viernes, 7 de diciembre de 2018
Playboy denunciado por falta de accesibilidad en su sitio web
Hace unos días se publicó la noticia Playboy.com Sued by Blind Man Who Says He Can’t Fully ‘Enjoy’ the Website, en la que podemos leer:
Playboy.com was sued Wednesday by a legally blind man who says that the site, as well as Playboyshop.com, aren’t equally accessible to the blind and visually impaired.
In the class-action suit, filed Wednesday in federal court in New York, Donald Nixon says that he and other visually-impaired customers are unable to “fully and equally use or enjoy” the site’s offering. And that definitely goes on the Turn-Offs list.
“Due to the inaccessibility of Defendant’s Website, blind and visually-impaired customers such as Plaintiff, who need screen-readers, cannot fully and equally use or enjoy the facilities, products, and services Defendant offers to the public on its Website,” the suit reads. “The access barriers Plaintiff encountered have caused a denial of Plaintiff’s full and equal access in the past, and now deter Plaintiff on a regular basis from visiting the Website, presently and in the future.”
According to the suit, Nixon employs screen-reading software to access the internet. During his visits to the site, the lawsuit says, Nixon “encountered multiple access barriers” that “denied Plaintiff full and equal access to the facilities, goods and services offered to the public and made available to the public; and that denied Plaintiff the full enjoyment of the facilities, goods and services of the Website, by being unable to learn more information, the ability to browse products available for delivery, find information on promotions and coupons, and related goods and services available online.”
miércoles, 5 de diciembre de 2018
Cómo crear una declaración de accesibilidad web
El W3C ha publicado HOW TO CREATE ACCESSIBILITY STATEMENTS, que describe el uso de la nueva herramienta Developing an Accessibility Statement para crear una declaración de accesibilidad web.
El Real Decreto 1112/2018, de 7 de septiembre, establece en el Artículo 15:
Artículo 15. Declaración de accesibilidad.
1. Las entidades responsables de las webs y aplicaciones para móviles
proporcionarán una declaración de accesibilidad detallada, exhaustiva y clara sobre la
conformidad de sus respectivos sitios web y aplicaciones para dispositivos móviles con lo
dispuesto en este real decreto. Dicha declaración será actualizada periódicamente, como
mínimo una vez al año, o cada vez que se realice una revisión de accesibilidad conforme
a lo especificado en el artículo 17.
Esta declaración de accesibilidad se proporcionará en un formato accesible haciendo
uso de las instrucciones y del modelo de declaración de accesibilidad que se establezca
conforme a lo dispuesto en el apartado 3.
En el caso de los sitios web, la declaración se publicará en el sitio web
correspondiente estando disponible su acceso desde todas las páginas del sitio web con
un enlace denominado «Accesibilidad» o su equivalente en el idioma en el que se
encuentre disponible la página.
En el caso de las aplicaciones para dispositivos móviles, la declaración estará
disponible en el sitio web de la entidad obligada que haya desarrollado la aplicación
concreta para dispositivos móviles junto con el enlace para su descarga o bien se
facilitará junto con otra información disponible al descargar la aplicación de las
plataformas de distribución de aplicaciones.
2. La declaración de accesibilidad comprenderá, como mínimo, la siguiente
información:
a) Una explicación sobre aquellas partes del contenido que no sean accesibles y
las razones de dicha inaccesibilidad, así como, en su caso, las alternativas accesibles
que se ofrezcan.
b) Un enlace y descripción del mecanismo de comunicación en los términos que se
establecen en los artículos 10, 11 y 12 del presente real decreto.
c) Un enlace al procedimiento de reclamación regulado en el artículo 13 al que
cualquier persona interesada pueda recurrir en caso de que la respuesta a la
comunicación o a la solicitud sea insatisfactoria.
3. Mediante Orden de la Ministra de Política Territorial y Función Pública se
aprobarán instrucciones específicas para la generación y puesta a disposición de las
declaraciones de accesibilidad de aplicación en todo el territorio nacional de acuerdo con
los requisitos especificados en el modelo europeo.
El Real Decreto 1112/2018, de 7 de septiembre, establece en el Artículo 15:
Artículo 15. Declaración de accesibilidad.
1. Las entidades responsables de las webs y aplicaciones para móviles
proporcionarán una declaración de accesibilidad detallada, exhaustiva y clara sobre la
conformidad de sus respectivos sitios web y aplicaciones para dispositivos móviles con lo
dispuesto en este real decreto. Dicha declaración será actualizada periódicamente, como
mínimo una vez al año, o cada vez que se realice una revisión de accesibilidad conforme
a lo especificado en el artículo 17.
Esta declaración de accesibilidad se proporcionará en un formato accesible haciendo
uso de las instrucciones y del modelo de declaración de accesibilidad que se establezca
conforme a lo dispuesto en el apartado 3.
En el caso de los sitios web, la declaración se publicará en el sitio web
correspondiente estando disponible su acceso desde todas las páginas del sitio web con
un enlace denominado «Accesibilidad» o su equivalente en el idioma en el que se
encuentre disponible la página.
En el caso de las aplicaciones para dispositivos móviles, la declaración estará
disponible en el sitio web de la entidad obligada que haya desarrollado la aplicación
concreta para dispositivos móviles junto con el enlace para su descarga o bien se
facilitará junto con otra información disponible al descargar la aplicación de las
plataformas de distribución de aplicaciones.
2. La declaración de accesibilidad comprenderá, como mínimo, la siguiente
información:
a) Una explicación sobre aquellas partes del contenido que no sean accesibles y
las razones de dicha inaccesibilidad, así como, en su caso, las alternativas accesibles
que se ofrezcan.
b) Un enlace y descripción del mecanismo de comunicación en los términos que se
establecen en los artículos 10, 11 y 12 del presente real decreto.
c) Un enlace al procedimiento de reclamación regulado en el artículo 13 al que
cualquier persona interesada pueda recurrir en caso de que la respuesta a la
comunicación o a la solicitud sea insatisfactoria.
3. Mediante Orden de la Ministra de Política Territorial y Función Pública se
aprobarán instrucciones específicas para la generación y puesta a disposición de las
declaraciones de accesibilidad de aplicación en todo el territorio nacional de acuerdo con
los requisitos especificados en el modelo europeo.
lunes, 3 de diciembre de 2018
Día Internacional de las Personas con Discapacidad
El Día Internacional de las Personas con Discapacidad se observa en todo el mundo cada 3 de diciembre de acuerdo a la resolución 47/3 de la Asamblea General adoptada el 14 de octubre de 1992, con el objetivo de llamar la atención y movilizar apoyos para aspectos clave relativos a la inclusión de personas con discapacidad en la sociedad y en el desarrollo.
jueves, 29 de noviembre de 2018
Libro "Accesibilidad Web. WCAG 2.1 de forma sencilla"
Olga Revilla y Olga Carreras han publicado el libro Accesibilidad Web: WCAG 2.1 de forma sencilla.
El contenido del libro es:
El contenido del libro es:
- Introducción a la Accesibilidad Web donde se explican los orígenes, los perfiles implicados y cómo implantar una política de Accesibilidad Web en una Organización.
- Las Pautas WCAG: qué son y cómo se organizan, qué novedades hay de la versión 2.0 a la versión 2.1 y motivaciones para seguirlas.
- Requisitos de Conformidad: los 5 requisitos que toda página debe cumplir, los niveles de conformidad, y cómo comunicar que tu sitio es accesible.
- Evaluar la accesibilidad con la metodología WCAG-EM: qué pasos hay que dar y cómo declarar la conformidad según este análisis.
- Principio 1: Perceptible. Nuestro sitio web puede ser visitado por personas con muy diferentes necesidades y preferencias perceptivas, pero también por robots (buscadores, traductores automáticos...).
- Principio 2: Operable. Los diseñadores web somos conscientes de los diferentes ispositivos, productos de apoyo y contextos de uso de los usuarios para manejar el sitio web, por lo que debemos crear los elementos que componen la interfaz de tal manera que cualquiera pueda utilizarlos.
- Principio 3: Comprensible. Si los usuarios no comprenden lo que les decimos, o les hacemos sentirse perdidos, tenemos un problema.
- Principio 4: Robusto. La evolución de la tecnología nos obliga a adaptarnos tanto a nosotros como a nuestros sitios web.
- Documentos PDF accesibles. Técnicas específicas de esta tecnología y cómo implementarlas paso a paso.
- ARIA, el aliado (casi) desconocido. Aprende a aplicar correctamente el estándar WAI-ARIA, imprescindible para comprender e interactuar mediante un lector de pantalla con componentes como acordeones, menús desplegables o pestañas. Incluimos diferentes ejemplos de código.
- Recursos y Herramientas. Selección de validadores y asistentes para revisar el cumplimiento de las pautas.
- Resúmenes y esquemas. Diagramas conceptuales y tablas resúmenes para avanzar más rápido.
- Glosario. Definiciones de los términos más complejos utilizados en el libro.
miércoles, 28 de noviembre de 2018
lunes, 26 de noviembre de 2018
Comparativa de tres herramientas de evaluación de la accesibilidad web
En Comparing 3 Top Automated Accessibility Testing Tools: WAVE, Tenon.io, and Google Lighthouse, se comparan tres herramientas de evaluación automática de la accesibilidad web. La conclusión es:
The advantages and limitations of automated tools: a few examples
Automated Tools Will Suffice for the following:
Human Intervention Is Required for the following:
While automated tools can discover many critical issues, there are even more issues that need human analysis. If there is a vague or misleading alt tag, that is just as bad from a usability standpoint as a missing alt tag, and an automated tool won’t catch it. You need someone to go through the site with a sharp and trained eye.
In the end, to fully test for accessibility issues, a combination of automated and manual testing is required. Automated testing tools provide a good starting point for testing, point to patterns of errors that humans can then look out for, and can catch issues before they go to production.
The advantages and limitations of automated tools: a few examples
Automated Tools Will Suffice for the following:
- Does the image have alt text?
- Does the form field have a label and description?
- Does the content have headings?
- Is the HTML valid?
- Does the application UI follow WCAG guideline X?
Human Intervention Is Required for the following:
- Is the alt text accurate given the context?
- Is the description easy to understand?
- Do the headings represent the correct hierarchy?
- Is the HTML semantic?
- Does the application UI behave as expected?
While automated tools can discover many critical issues, there are even more issues that need human analysis. If there is a vague or misleading alt tag, that is just as bad from a usability standpoint as a missing alt tag, and an automated tool won’t catch it. You need someone to go through the site with a sharp and trained eye.
In the end, to fully test for accessibility issues, a combination of automated and manual testing is required. Automated testing tools provide a good starting point for testing, point to patterns of errors that humans can then look out for, and can catch issues before they go to production.
viernes, 23 de noviembre de 2018
Accesibilidad en vídeos y contenidos multimedia
En Accesibilidad en vídeos y contenidos multimedia se explica lo siguiente sobre los subtítulos:
- Transcripción de los diálogos: los subtítulos deben ser fieles y equivalentes al diálogo de los personajes y en el mismo orden de reproducción, por lo tanto se deben transcribir de forma adecuada y sincronizada con el vídeo para evitar la pérdida de coherencia.
- Tipografía: debe ser legible (como por ejemplo la Helvética o la Lucida grande), con un tamaño de fuente mediano (entre 18 y 22 pt) que optimice su lectura, con un interlineado sencillo, y que ocupen como máximo dos líneas de 35 o 37 caracteres en cada una de ellas. Debemos asegurarnos también que son compatibles y se visualizan correctamente tanto para Windows como Mac.
- Tiempo de exposición: Hay que tener en cuenta que los espacios en blanco, los signos de puntuación y los emoticonos, cuentan también como caracteres. Como regla general se define que se deberían mostrar entre 12 y 19 caracteres por segundo (52 milisegundos de exposición para un carácter y unas 150 palabras por minuto). En todo caso, no debería ser inferior a 0,7 para frases cortas (entre 10 y 12 caracteres).
- Textos: no se deben separar las palabras, mientras que las líneas deberán separarse preferiblemente cuando coincidan con comas, puntos, conjunciones o con las pausas que marque el personaje al hablar.
- Ubicación: centrados y en la parte inferior del vídeo. Si en el propio vídeo ya sale algún tipo de contenido en esa ubicación, los subtítulos se pondrían en la zona superior a estos.
- Contraste: deben tener un contraste suficiente con el vídeo, de tal forma que sean perfectamente legibles. Se recomienda el color blanco, amarillo, verde o cian sobre fondo negro.
- Si existen dos interlocutores, personajes, narradores o voz en off: cada uno de ellos tendrá un color diferente e identificativo, y el texto de cada uno de ellos deberá ocupar una línea.
- Si existen efectos sonoros: deberán describirse y mostrarse entre paréntesis cuando corresponda.
- Destellos y parpadeos: hay que tener en cuenta que los contenidos con parpadeos o destellos, pueden causan ataques de epilexia fotosensitiva a ciertos usuarios , por lo tanto hay que cumplir lo siguiente:
- Destellos: no se pueden provocar más de 3 por segundo a no ser que el área de destello sea inferior al 25% del área central de la visión del ojo (10 grados del campo visual).
- Parpadeo: como máximo puede durar 5 segundos.
jueves, 22 de noviembre de 2018
Por qué modificar el valor de tabindex no es una buena idea
En Why using `tabindex` values greater than “0” is bad, Karl Groves realiza un análisis del uso del atributo tabindex en HTML:
Recently Tenon received a support request from a customer complaining that their site had thousands of issues in Tenon about their use of tabindex. The customer believed that their use of tabindex was a good thing because the tab order made sense. Here’s a cleaned-up version of the response I sent to them:
There’s another piece of using explicit tabindex that people often misunderstand when they use it: Users don’t just load up the site and start tabbing through the page. While sighted keyboard-only users might do this, the reality is that very few of the so-called “sighted keyboard-only users” truly use only the keyboard. People with motor impairments might do other things, such as use specialized pointing devices or voice dictation software. Depending on the UI and the tasks they’re there to perform, they might swap back and forth between voice dictation and keyboard. Or they might use their specialized pointing devices and keyboard.
Blind screenreader users don’t just load the page and start tabbing through it, either. Again, depending on the UI and the tasks they’re there to perform, they might pull up a list of headings on the page in order to see what the page is about. Or, they might even just hit “H” to get taken to the first heading on the page. In fact, I’d argue that they’re just as likely to hit the “H” key as they are to hit the “Tab” key as their first keystroke on the page.
After tabbing through all of the things that have a tabindex greater than “0” the user will navigate to all other focusable elements in the order in which they appear in the DOM. In doing so, they will skip over the things that have already received focus. In some cases, this may cause a mismatch between the visual order and the focus order. For a sighted/ partially sighted keyboard-only user, this mismatch between what get focus vs. what they expect to get focus will be confusing.
We feel that the above reasons make it clear that tabindex creates more problems than it solves and that the use of tabindex should be avoided.
Recently Tenon received a support request from a customer complaining that their site had thousands of issues in Tenon about their use of tabindex. The customer believed that their use of tabindex was a good thing because the tab order made sense. Here’s a cleaned-up version of the response I sent to them:
It creates maintenance headaches
The longer the tabindex values exist on the site, the more likely that maintenance of the site will cause the tabindex values to become inaccurate. Websites are never really “done”. Once they go into production, maintenance, changes, and bug fixes happen. Along the way, things move around, new links are added, old links are removed and over time someone slips and the tabindex values become out of sync with the desired interaction order.It strips away user control
The use of an explicit tab order undermines the user’s ability to control their interaction with the site. Web pages that dictate an explicit tab order tend to do so for one of two reasons: to overcome a bad tab order or due to a misunderstanding of how the tab order should work. Using tabindex to fix a bad tab order is the wrong approach. Modifying DOM order so that the tab order matches the visual order might be difficult, but the pay off is much greater than using tabindex.There’s another piece of using explicit tabindex that people often misunderstand when they use it: Users don’t just load up the site and start tabbing through the page. While sighted keyboard-only users might do this, the reality is that very few of the so-called “sighted keyboard-only users” truly use only the keyboard. People with motor impairments might do other things, such as use specialized pointing devices or voice dictation software. Depending on the UI and the tasks they’re there to perform, they might swap back and forth between voice dictation and keyboard. Or they might use their specialized pointing devices and keyboard.
Blind screenreader users don’t just load the page and start tabbing through it, either. Again, depending on the UI and the tasks they’re there to perform, they might pull up a list of headings on the page in order to see what the page is about. Or, they might even just hit “H” to get taken to the first heading on the page. In fact, I’d argue that they’re just as likely to hit the “H” key as they are to hit the “Tab” key as their first keystroke on the page.
It may cause a mismatch between visual order and interaction order
An element with an explicit tabindex value greater than “0” will receive keyboard focus before focusable elements with no tabindex value (or tabindex="0"). In other words, tabindex="0" says “put this in the tab order where it would normally occur based on its source order” while an explicit tabindex value greater than “0” causes the item to be placed at that number within the tab order (barring any gaps in the order, which will be ignored).After tabbing through all of the things that have a tabindex greater than “0” the user will navigate to all other focusable elements in the order in which they appear in the DOM. In doing so, they will skip over the things that have already received focus. In some cases, this may cause a mismatch between the visual order and the focus order. For a sighted/ partially sighted keyboard-only user, this mismatch between what get focus vs. what they expect to get focus will be confusing.
It may make user support difficult
Last, an explicit tab order can cause frustration when doing user support. Customers with disabilities who reach out to the company for support may be given directions for workarounds that don’t match reality. Well-meaning support staff might say “The X-link is the 5th link on the page” when in reality it isn’t the 5th but something else.We feel that the above reasons make it clear that tabindex creates more problems than it solves and that the use of tabindex should be avoided.
miércoles, 21 de noviembre de 2018
Accesibilidad de los diagramas de flujo realizados con SVG
En Accessible SVG flowcharts se explica cómo crear diagramas de flujo accesibles realizados con SVG.
lunes, 19 de noviembre de 2018
Ejemplo de uso de un sistema de reconocimiento de voz
¿Se puede usar el ordenador solo con la voz? El siguiente vídeo lo muestra:
Además, este vídeo también tiene audiodescripción, es decir, aprovecha los silencios para explicar lo que se está viendo en la imagen. Y también tiene subtítulos. Y también una persona que interpreta el audio a la lengua de signos española. Con todo esto, el vídeo es accesible.
Además, este vídeo también tiene audiodescripción, es decir, aprovecha los silencios para explicar lo que se está viendo en la imagen. Y también tiene subtítulos. Y también una persona que interpreta el audio a la lengua de signos española. Con todo esto, el vídeo es accesible.
viernes, 16 de noviembre de 2018
Un botón es un botón, un enlace es un enlace y lo demás no debe ser ni un botón ni un enlace
En You can’t create a button se explica un error de accesibilidad tremendamente común: tratar un enlace como si fuera un botón, un botón como si fuera un enlace, o cualquier otra cosa como un div o un span en un enlace o un botón.
miércoles, 14 de noviembre de 2018
Una buena accesibilidad no asegura que el sitio web sea también usable
Accesibilidad y usabilidad son cosas distintas, pero que también están relacionadas. En el artículo Websites and apps: How to make accessibility user-friendly se comentan algunos aspectos de esta relación de opuestos y semejantes que se atraen y repelen a la vez.
lunes, 12 de noviembre de 2018
Nueva herramienta de accesibilidad de Firefox
Las herramientas de desarrollador del navegador Firefox han incorporado una nueva opción, Accessibility Inspector.
Esta herramienta permite acceder a la información de una página web que es expuesta a los productos de apoyo con los lectores de pantalla.
viernes, 9 de noviembre de 2018
Resultados de la segunda encuesta dirigida a usuarios con baja visión
WebAIM ha publicado los resultados de su segunda encuesta dirigida a usuarios con baja visión: Survey of Users with Low Vision #2 Results.
Los resultados más interesantes son:
Los resultados de la primera encuesta se publicaron en mayo de 2013.
Los resultados más interesantes son:
- 75% of respondents report multiple types of visual impairment. 61.3% have light or glare sensitivity and 46.8% have contrast sensitivity.
- 51.4% of respondents report using some type of high contrast mode. 71.2% of users that adjust page contrast prefer light text on a dark background.
- 45.2% of respondents use a screen reader, 48.4% screen magnification software, and 44% browser zoom controls. Other types of settings and AT are commonly used.
- JAWS is the most common screen reader, followed by NVDA and VoiceOver. Narrator is rarely used (.8%).
- Only 8% were detected as having increased the default text size. Very few respondents adjust paragraph, line, word, or letter spacing.
- 60.4% always or often use a keyboard for web page navigation. This is a very high number of users that rely on keyboard accessibility.
- 22% of respondents don’t enlarge web content, while 18% of respondents enlarge to over 400%.
- Dedicated screen magnification software is not highly common. Most users rely on OS settings for magnification.
- 64.3% use iOS devices. Only 7.8% don’t use a mobile device at all.
Los resultados de la primera encuesta se publicaron en mayo de 2013.
miércoles, 7 de noviembre de 2018
lunes, 5 de noviembre de 2018
viernes, 2 de noviembre de 2018
Los nuevos criterios de WCAG 2.1 para las personas con baja visión
En Understanding WCAG 2.1 – Reviewing Low Vision Success Criteria explican los nuevos criterios de WCAG 2.1 relacionados con la baja visión.
El artículo incluye un vídeo:
El artículo incluye un vídeo:
miércoles, 31 de octubre de 2018
Los nuevos criterios de WCAG 2.1 para las personas con discapacidad que acceden desde dispositivos móviles
En Understanding WCAG 2.1 – Reviewing Mobile Success Criteria se explican los nuevos criterios de WCAG 2.1 que tienen como objetivo mejorar la accesibilidad para las personas con discapacidad que acceden desde dispositivos móviles.
El artículo incluye un vídeo:
El artículo incluye un vídeo:
lunes, 29 de octubre de 2018
Los nuevos criterios de WCAG 2.1 para las personas con discapacidad cognitiva o del aprendizaje
En Understanding WCAG 2.1 – Reviewing Cognitive Success Criteria, se explican los nuevos criterios de WCAG 2.1 para mejorar la accesibilidad para las personas con discapacidad cognitiva o del aprendizaje.
El artículo incluye un vídeo:
El artículo incluye un vídeo:
viernes, 26 de octubre de 2018
Curso gratuito "Diseño accesible, diseño para todas las personas"
Según información que he recibido:
La Universidad de Jaén, con el apoyo de Fundación ONCE y el Real Patronato sobre Discapacidad, organiza el II curso Diseño accesible, diseño para todas las personas, que se impartirá online, abierto y con carácter gratuito. Se trata de un curso de capacitación, innovador y abierto, dirigido a todos los interesados en la accesibilidad universal y el diseño para todas las personas.
El curso pretende dar a conocer, desde una perspectiva general, el nuevo paradigma de accesibilidad universal y diseño para todas las personas; identificar los problemas de accesibilidad relacionados con los entornos físicos, virtuales y sociales; difundir buenas prácticas en la accesibilidad universal y el diseño para todas las personas en diferentes países latinoamericanos, y conocer la implicación del tercer sector en la facilitación de la aplicación del nuevo paradigma, el caso de Fundación ONCE.
La Universidad de Jaén, con el apoyo de Fundación ONCE y el Real Patronato sobre Discapacidad, organiza el II curso Diseño accesible, diseño para todas las personas, que se impartirá online, abierto y con carácter gratuito. Se trata de un curso de capacitación, innovador y abierto, dirigido a todos los interesados en la accesibilidad universal y el diseño para todas las personas.
El curso pretende dar a conocer, desde una perspectiva general, el nuevo paradigma de accesibilidad universal y diseño para todas las personas; identificar los problemas de accesibilidad relacionados con los entornos físicos, virtuales y sociales; difundir buenas prácticas en la accesibilidad universal y el diseño para todas las personas en diferentes países latinoamericanos, y conocer la implicación del tercer sector en la facilitación de la aplicación del nuevo paradigma, el caso de Fundación ONCE.
miércoles, 24 de octubre de 2018
Diseñando para las diferencias cognitivas
La introducción del artículo Designing for Cognitive Differences dice:
Inclusive design is designing to be inclusive of as many users as possible, considering all aspects of diversity in users. With increased understanding, compassionate discussions around how to design for disabilities are becoming increasingly common in the web industry. But even with this growth, there are misconceptions: accessibility is still frequently thought of as “design for blind people” when it’s so much more than that. Users with limited motor functions and those who are hearing-impaired require separate considerations, for instance. But accessibility and inclusiveness also mean considering more than just physical symptoms. What about users with cognitive differences like inattention, anxiety, and depression?
Many affective and anxiety disorders qualify as disabilities, with inattention causing challenges on the web as well. Whatever the cause, inattention, anxiety, and depression can have a major impact on internet usage for users dealing with them. The unique issues presented by cognitive differences and the design considerations they require can be tricky to understand for people who have never dealt with them. Through this article, I’ll share some methods to accommodate these users’ unique needs.
martes, 23 de octubre de 2018
lunes, 22 de octubre de 2018
Los límites de las herramientas automáticas
Muy interesante el artículo The Power (and Limits) of Automated Accessibility Testing:
For WCAG 2.0 AA conformance testing (the generally-accepted goal for accessibility compliance) automated tests represent only 10 percent of our test plan, 6 percent when you factor in tests across multiple browsers or screen readers.
[...]
Automation is a good way to tell if "something" is wrong, but it won't find all the compliance issues on a site, especially a complex one. There are only two WCAG 2.0 guidelines that we rely on automation alone to test: Page Titled and Parsing. All other guidelines may require manual review depending on the setup of your site.
[...]
What does automation miss? It's terrible at simulating keyboard and screen reader navigation, which may mean that a site passes automation but can't be used at all by someone with motor or visual disabilities. (We see that a lot.) Automation is terrible at telling what you can see when the site is zoomed. It can't tell where you need headers, or if a link has a clear enough description, or if you're moving around a navigation element that needs to be in a predictable place. Automation can't tell if you're relying on color to indicate something a color blind user won't be able to see. It's terrible with error messages, because it isn't entering anything into your forms. It won't tell you if your captcha makes your form impossible for a screen reader user to submit. Automation probably won't bother testing your site in a mobile view.
Automation should be your first attack. It's ours. But it's not enough. Don't trust anyone who tries to convince you it is. Double check the site with a free screen reader like VoiceOver or NVDA, tab through it with your keyboard, zoom in and see what happens. It’s the users of your site, not the robots, that need accessibility.
viernes, 19 de octubre de 2018
Curso gratuito "Digital Accessibility: Enabling Participation in the Information Society"
Un curso gratuito, de tipo MOOC, sobre accesibilidad digital: Digital Accessibility: Enabling Participation in the Information Society.
El contenido del curso es:
El contenido del curso es:
- What is digital accessibility?
- Digital accessibility and business
- Relationship between ‘usability’, ‘accessibility’ and ‘user experience’
- Challenges and barriers met by disabled people
- Video and audio barriers and subtitles, captioning and audio description
- Desktop, laptop, mobile and self-service terminal accessibility
- Creating, checking and evaluating document, web and self-service terminal accessibility
- Input and output devices e.g. screen reader, Braille, switch access technologies
- Digital and web accessibility guidelines, standards and principles of Universal Design
miércoles, 17 de octubre de 2018
"personas con discapacidad", expresión recomendada
Hace un par de días, Fundéu publicó la aclaración personas con discapacidad, expresión recomendada:
La expresión personas con discapacidad es la preferible para referirse a aquellas personas que tienen algún tipo de limitación física, intelectual o sensorial.
Según la Convención Internacional sobre los Derechos de las Personas con Discapacidad de la Organización de la Naciones Unidas, personas con discapacidad es la expresión adecuada para referirse a quienes «tengan deficiencias físicas, mentales, intelectuales o sensoriales a largo plazo que, al interactuar con diversas barreras, puedan impedir su participación plena y efectiva en la sociedad, en igualdad de condiciones con las demás».
Como se ve en esa convención y en los documentos de las organizaciones que representan a estas personas, se prefiere en general la fórmula persona con discapacidad al uso del sustantivo discapacitado, que, si bien no es reprochable desde el punto de vista lingüístico, supone aludir a la persona por una sola de sus características, en este caso la discapacidad.
Tampoco se recomienda la voz minusválido, utilizada durante mucho tiempo y aún presente en documentos y trámites diversos. Aunque se trata de una palabra correctamente formada, se desaconseja su uso en los medios de comunicación, ya que en la actualidad se interpreta, en especial por los colectivos citados, como peyorativa.
Asimismo se desaconsejan palabras o expresiones con matiz claramente despectivo (como anormal, subnormal, deficiente, incapaz, inválido, impedido), así como las que denotan sufrimiento (como sufre, padece o arrastra una discapacidad).
Sobre el uso correcto del lenguaje he escrito un par de veces en el pasado:
- ¿Minusválido, inválido, disminuido, incapacitado o discapacitado? (12/1/2006)
- People-first language (8/10/2013)
- Cómo escribir con un lenguaje inclusivo (19/9/2014)
- Guía de Lenguaje Positivo y Comunicación Incluyente (23/10/2017)
- Guía APA el uso de lenguaje no discriminatorio e inclusivo (6/11/2017)
lunes, 15 de octubre de 2018
Qué esperar de WCAG 2.1
WCAG 2.1 se publicó en junio de 2018, ya no es algo nuevo, pero vale la pena releer cosas como Understanding WCAG 2.1: What to Expect, donde se explican las novedades de WCAG 2.1.
El artículo incluye un vídeo:
El artículo incluye un vídeo:
viernes, 12 de octubre de 2018
Chrome DevTools Accessibility Reference
En Accessibility Reference se explica el funcionamiento del módulo de revisión de la accesibilidad web que existe en Chrome DevTools:
miércoles, 10 de octubre de 2018
Centro de Normalización Lingüística de la Lengua de Signos Española
El Centro de Normalización Lingüística de la Lengua de Signos Española (CNLSE) tiene como objetivo:
En la siguiente imagen podemos ver cómo se han olvidado de poner un texto alternativo correcto en las imágenes del panel de navegación de la izquierda:
En concreto, han puesto:
que todas las personas, independientemente de tener una discapacidad, de la edad o de acceder a la web desde tecnologías poco convencionales, puedan navegar por las páginas de este sitio web sin encontrar dificultades de acceso.Sin embargo, una vez más, en casa del herrero, cuchara de palo, y el sitio web de CNLSE no es accesible para todas las discapacidades. Digo una vez más porque ya escribí sobre este problema, pero de otro sitio web, en Unas personas con discapacidad que se olvidan del resto de las personas con discapacidad.
En la siguiente imagen podemos ver cómo se han olvidado de poner un texto alternativo correcto en las imágenes del panel de navegación de la izquierda:
En concreto, han puesto:
- "Imagen del banner" en el title del enlace.
- "Imagen del banner" en el title de la imagen.
- "Imagen del banner" en el alt de la imagen.
Suscribirse a:
Entradas (Atom)