Productos de apoyo y tecnologías de la información y las telecomunicaciones - Alex, estudiante de UNED quisiera que la lengua de signos estuviera más presente en la universidad: En las clases o tutorías, en los vídeos y programas de radio. Usa un sistema de interpretación en legua de signos por videoconferencia para comunicarse con un profesor y hacerle una consulta sobre una de sus asignaturas. Participante: Álex González, estudiante de UNED.
Todo tipo de información sobre accesibilidad en la Web: errores de accesibilidad, ejemplos de páginas inaccesibles, noticias, software, hardware, productos de apoyo, consejos, pautas y guías de accesibilidad, WAI, WCAG, Norma EN 301 549, legislación, etc.
Buscador
miércoles, 30 de octubre de 2019
lunes, 28 de octubre de 2019
Ana estudia Filología Hispánica y es sorda
Productos de apoyo y tecnologías de la información y las telecomunicaciones - Ana Sánchez, estudiante de la UNED, es muy aficionada al cine. Para disfrutarlo necesita que la película tenga subtítulos, o que la sala de proyección disponga de un bucle magnético. También usa el bucle magnético para hablar a través de su teléfono móvil, aunque principalmente se comunica con los demás gracias a aplicaciones de mensajería instantánea para móvil. Echa de menos que los programas de radio estén disponibles en texto. Las tecnologías de hogar digital le hacen sentirse más segura y cómoda cuando está en casa. Participante: Ana Sánchez, estudiante de la UNED.
viernes, 25 de octubre de 2019
Carlos estudia Psicología y es una persona con baja visión
Productos de apoyo y tecnologías de la información y las telecomunicaciones - Carlos Javier Cortina, estudiante de la UNED. usa su ordenador ayudado de un magnificador de pantalla que además sintetiza en voz los contenidos visuales. Estudia temas de Psicología en su reproductor MP3 o Daisy, mientras espera un autobús. Utiliza un mini-GPS vocal para orientarse mientras camina por la ciudad. Lee las cartas que el banco le envía con su tele-lupa o su escáner-OCR. Participantes Carlos Javier Cortina, estudiante de la UNED.
miércoles, 23 de octubre de 2019
Víctor estudia Ciencias Empresariales y es ciego
Productos de apoyo y tecnologías de la información y las telecomunicaciones - Victor Alberto Lorenzo, estudiante de la UNED, utiliza el ordenador, la telefonía móvil, busca en internet recursos para hacer un trabajo de empresariales, lee documentos, etc. Para ello utiliza lectores de pantalla y línea braille. Participantes Victor Alberto Lorenzo, estudiante de la UNED.
martes, 22 de octubre de 2019
Accessibility Object Model
Accessibility Object Model es una nueva tecnología que permite modificar las propiedades de accesibilidad de una página web desde JavaScript. En Meaning without markup: Accessibility Object Model se explica cómo funciona esta tecnología y se ofrecen algunos ejemplos sencillos.
lunes, 21 de octubre de 2019
Accesibilidad de los colores
El artículo Contrast and Color Accessibility explica con mucho detalle los requisitos relacionados con el color y el contraste de WCAG.
El contenido es:
El contenido es:
- Page 1: Understanding WCAG 2 Contrast and Color Requirements
- Introduction
- Defining Colors
- WCAG 2 "Contrast Ratio"
- 1.4.3 Contrast (Minimum)
- 1.4.6 Contrast (Enhanced)
- 1.4.11 Non-text Contrast
- 1.4.1 Use of Color
- Page 2: Evaluating Contrast and Color Use
- Page 3: Evaluating Contrast with Chrome DevTools
viernes, 18 de octubre de 2019
¿Se usa Orca?
Hace unos días me preguntaron por el uso de Orca, el lector de pantalla más conocido para Linux, o quizás el único que existe.
¿Se usa Orca? En el último Screen Reader User Survey #8 de WebAIM, ni se nombra.
¿Orca es un buen lector de pantalla? En el análisis Practical Screen Reader Comparison: A user-oriented approach no obtenía buenos resultados, quedaba el peor, pero bueno, es un estudio de 2011:
¿Se usa Orca? En el último Screen Reader User Survey #8 de WebAIM, ni se nombra.
¿Orca es un buen lector de pantalla? En el análisis Practical Screen Reader Comparison: A user-oriented approach no obtenía buenos resultados, quedaba el peor, pero bueno, es un estudio de 2011:
Screen Reader
|
Points
|
Percentage
|
JAWS
|
85.5
|
93%
|
HAL
|
85.5
|
93%
|
NVDA
|
69
|
75%
|
VoiceOver
|
58
|
63%
|
Orca
|
54
|
59%
|
miércoles, 16 de octubre de 2019
Duda sobre cómo se navega con un lector de pantalla
Un estudiante mío está desarrollando una página web y le ha surgido la siguiente duda:
Me ha surgido una duda leyendo documentación y aprendiendo a utilizar VoiceOver de MacOS. Mi idea era que un usuario pudiera navegar por cada Chunk con el tabulador con información adicional, pero no sé hasta qué punto eso concuerda con la especificación. Por ejemplo, si una lección sigue esta secuencia de Chunks:
La idea era que el usuario empezara navegando con el tabulador y el lector de pantalla avisara con un “Chunk Heading… [contenido]” y al volver a presionar el tabulador “Chunk Text…[contenido]” y así hasta llegar al final de la lección, pero mi duda es si esto se debería hacer o va contra la especificación.
Y mi respuesta:
Tienes que distinguir dos posibles tipos de usuarios mediante teclado: el que puede ver y el que no.
El que puede ver normalmente es una persona con discapacidad motora que tiene dificultad para usar el ratón, pero también puede ser un usuario "pro" que prefiere el teclado porque es más rápido o un usuario norma con una "discapacidad temporal" (por ejemplo, se le ha roto el ratón). Estos usuarios pueden usar los cursores para realizar scroll up/down, así que no necesitan el tabulador para desplazarse por el contenido y leerlo, pero sí que necesitan el tabulador para desplazarse por los elementos de interacción. También les ayuda que pongas un enlace al final de la página para volver al principio de la página.
El que no puede ver usará un lector de pantalla, como VoiceOver, y conocerá todo los atajos que proporciona (y si no los conoce... es su problema, que los aprenda). La lista de comandos es enorme:
https://help.apple.com/voiceover/info/guide/10.8/spanish.lproj/_1203.html
El que no puede ver tiene dos problemas: cómo desplazarse por el contenido y leerlo (el que puede ver no tiene este problema) y cómo desplazarse por los elementos de interacción. Lo segundo lo hace con el tabulador, como el resto de usuarios. Lo primero no lo puede hacer con los cursos igual que lo hacemos nosotros porque no puede ver, así que tiene atajos para desplazarse a nivel de carácter, palabra, frase y párrafo:
Leer el párrafo del cursor de VoiceOver
VO + P
Leer el párrafo siguiente
VO + Mayúsculas + Av Pág
Leer el párrafo anterior
VO + Mayúsculas + Re Pág
Leer la frase del cursor de VoiceOver
VO + S
Leer la frase siguiente
VO + Comando + Av Pág
Leer la frase anterior
VO + Comando + Re Pág
Leer la línea del cursor de VoiceOver
VO + L
Leer la línea siguiente
VO + Flecha abajo
Leer la línea anterior
VO + Flecha arriba
Leer la palabra del cursor de VoiceOver
VO + W
Deletrear la palabra del cursor de VoiceOver
VO + W + W
Deletrear fonéticamente la palabra del cursor de VoiceOver
VO + W + W + W
Leer la palabra siguiente
VO + Flecha derecha
Leer la palabra anterior
VO + Flecha izquierda
Leer el carácter del cursor de VoiceOver
VO + C
Leer el carácter del cursor de VoiceOver
VO + C + C
Leer el carácter siguiente
VO + Mayúsculas + Flecha derecha
Leer el carácter anterior
VO + Mayúsculas + Flecha izquierda
La página web no tiene que proporcionar ningún mecanismo para ello, más allá de usar correctamente HTML. Por ejemplo, si creas "falsos párrafos", texto separado mediante BR, para el lector de pantalla no existirán esos párrafos que nosotros sí que vemos.
Para lo que me preguntas, no tienes que usar el tabulador, tienes que usar correctamente HTML. En concreto, los usuarios de lector de pantalla se desplazan por una página mediante los encabezados h1, h2, h3, etc.:
Buscar el encabezamiento siguiente
VO + Comando + H
Buscar el encabezamiento anterior
VO + Comando + Mayúsculas + H
Buscar el siguiente encabezamiento del mismo nivel
VO + Comando + M
Buscar el anterior encabezamiento del mismo nivel
VO + Comando + Mayúsculas + M
Y también usan la lista de encabezados, que en el caso de VoiceOver está disponible a través del Web Item rotor:
https://www.apple.com/voiceover/info/guide/_1134.html#mchlp2719
Por tanto, lo que quieres hacer lo tienes que hacer con un buen uso de los encabezados. Deberías usar h1 para el título del curso, h2 para el título de la lección y a partir de h3 para los chunks.
Me ha surgido una duda leyendo documentación y aprendiendo a utilizar VoiceOver de MacOS. Mi idea era que un usuario pudiera navegar por cada Chunk con el tabulador con información adicional, pero no sé hasta qué punto eso concuerda con la especificación. Por ejemplo, si una lección sigue esta secuencia de Chunks:
- Heading
- Text
- Text
- Heading-Text
- Bulleted-List
- Multiple-Answers
La idea era que el usuario empezara navegando con el tabulador y el lector de pantalla avisara con un “Chunk Heading… [contenido]” y al volver a presionar el tabulador “Chunk Text…[contenido]” y así hasta llegar al final de la lección, pero mi duda es si esto se debería hacer o va contra la especificación.
Y mi respuesta:
Tienes que distinguir dos posibles tipos de usuarios mediante teclado: el que puede ver y el que no.
El que puede ver normalmente es una persona con discapacidad motora que tiene dificultad para usar el ratón, pero también puede ser un usuario "pro" que prefiere el teclado porque es más rápido o un usuario norma con una "discapacidad temporal" (por ejemplo, se le ha roto el ratón). Estos usuarios pueden usar los cursores para realizar scroll up/down, así que no necesitan el tabulador para desplazarse por el contenido y leerlo, pero sí que necesitan el tabulador para desplazarse por los elementos de interacción. También les ayuda que pongas un enlace al final de la página para volver al principio de la página.
El que no puede ver usará un lector de pantalla, como VoiceOver, y conocerá todo los atajos que proporciona (y si no los conoce... es su problema, que los aprenda). La lista de comandos es enorme:
https://help.apple.com/voiceover/info/guide/10.8/spanish.lproj/_1203.html
El que no puede ver tiene dos problemas: cómo desplazarse por el contenido y leerlo (el que puede ver no tiene este problema) y cómo desplazarse por los elementos de interacción. Lo segundo lo hace con el tabulador, como el resto de usuarios. Lo primero no lo puede hacer con los cursos igual que lo hacemos nosotros porque no puede ver, así que tiene atajos para desplazarse a nivel de carácter, palabra, frase y párrafo:
Leer el párrafo del cursor de VoiceOver
VO + P
Leer el párrafo siguiente
VO + Mayúsculas + Av Pág
Leer el párrafo anterior
VO + Mayúsculas + Re Pág
Leer la frase del cursor de VoiceOver
VO + S
Leer la frase siguiente
VO + Comando + Av Pág
Leer la frase anterior
VO + Comando + Re Pág
Leer la línea del cursor de VoiceOver
VO + L
Leer la línea siguiente
VO + Flecha abajo
Leer la línea anterior
VO + Flecha arriba
Leer la palabra del cursor de VoiceOver
VO + W
Deletrear la palabra del cursor de VoiceOver
VO + W + W
Deletrear fonéticamente la palabra del cursor de VoiceOver
VO + W + W + W
Leer la palabra siguiente
VO + Flecha derecha
Leer la palabra anterior
VO + Flecha izquierda
Leer el carácter del cursor de VoiceOver
VO + C
Leer el carácter del cursor de VoiceOver
VO + C + C
Leer el carácter siguiente
VO + Mayúsculas + Flecha derecha
Leer el carácter anterior
VO + Mayúsculas + Flecha izquierda
La página web no tiene que proporcionar ningún mecanismo para ello, más allá de usar correctamente HTML. Por ejemplo, si creas "falsos párrafos", texto separado mediante BR, para el lector de pantalla no existirán esos párrafos que nosotros sí que vemos.
Para lo que me preguntas, no tienes que usar el tabulador, tienes que usar correctamente HTML. En concreto, los usuarios de lector de pantalla se desplazan por una página mediante los encabezados h1, h2, h3, etc.:
Buscar el encabezamiento siguiente
VO + Comando + H
Buscar el encabezamiento anterior
VO + Comando + Mayúsculas + H
Buscar el siguiente encabezamiento del mismo nivel
VO + Comando + M
Buscar el anterior encabezamiento del mismo nivel
VO + Comando + Mayúsculas + M
Y también usan la lista de encabezados, que en el caso de VoiceOver está disponible a través del Web Item rotor:
https://www.apple.com/voiceover/info/guide/_1134.html#mchlp2719
Por tanto, lo que quieres hacer lo tienes que hacer con un buen uso de los encabezados. Deberías usar h1 para el título del curso, h2 para el título de la lección y a partir de h3 para los chunks.
lunes, 14 de octubre de 2019
¿Por qué la web de La Moncloa hace referencia a WCAG 1.0?
En la web de La Moncloa:
Podemos ver esto en el pie de página:
¿Cómo es posible que la web de La Moncloa haga referencia a WCAG 1.0 que es del año 1999?
viernes, 11 de octubre de 2019
La ONCE abre sus 60.000 libros digitales a todos los ciegos del mundo
Una noticia muy importante, La ONCE abre sus 60.000 libros digitales a todos los ciegos del mundo:
La ONCE pone a disposición de 285 millones de personas ciegas del mundo su biblioteca digital, compuesta por más de 60.000 volúmenes, en una iniciativa sin parangón internacional, dado que supone la mayor puesta a disposición del mundo de textos accesibles en lengua castellana.Se supone que los libros estarán disponibles en marrakech.once.es, pero ahora mismo solo hay una página con un formulario para iniciar sesión, sin información sobre cómo registrarse.
[...]
España, representada por la ONCE, se convierte así en el primer país europeo que materializa el Tratado de Marrakech y pone a disposición de usuarios y entidades autorizadas de todo el mundo su acervo bibliográfico adaptado y accesible a personas ciegas o con deficiencia visual de todo el mundo. Para ello, la Organización española acaba de poner en marcha una web que permitirá a usuarios de todo el mundo acceder a esta información cumpliendo una serie de requisitos marcados por el citado tratado de Marrakech y por la Organización Mundial de la Propiedad Intelectual (OMPI), que garantizan el correcto uso de los textos disponibles.
Según la Wikipedia, el Tratado de Marrakech:
conocido oficialmente como «Tratado de Marrakech para facilitar el acceso a las obras publicadas a las personas ciegas, con discapacidad visual o con otras dificultades para acceder al texto impreso», es un tratado multilateral impulsado por la Organización Mundial de la Propiedad Intelectual (OMPI), que fue firmado en Marrakech, Marruecos, el 28 de junio de 2013. Este tratado entró en vigor a partir del 30 de septiembre de 2016.
El tratado de Marrakech hace referencia a las excepciones al derecho de autor, que posibilitan la creación de versiones accesibles de obras protegidas, a personas con discapacidades que impliquen dificultades de acceso a la lectura convencional. Este instrumento establece una serie de normas para que los países que forman parte de la Organización Mundial de Propiedad Intelectual (OMPI), ratifiquen el tratado e implementen excepciones en sus legislaciones locales, tanto para la creación como para la importación y exportación de obras en formatos accesibles. Así mismo,los países que hayan ratificado el Tratado tendrán la potestad de intercambiar documentos en formatos accesibles entre ellos.Más información en El Tratado de Marrakech explicado.
miércoles, 9 de octubre de 2019
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:
Automated tools for testing accessibility have evolved to a point where you don’t have to look hard to find dozens of examples of thorough and reliable tools that test for adherence to Web Content Accessibility Guidelines. There are browser extensions, command-line tools, tools that can be integrated with continuous integration systems…
At every level of integration, these 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.
Consider the following scenarios:
These issues (and many more) are very easy to miss — and they are very common. If you’re not using an automated testing tool, your site probably has similar issues.
I spent several weeks comparing these three tools in preparation for a presentation at DrupalCon Nashville. Each has a browser extension and an array of options for testing on the command line with continuous integration possibilities. They are all effective for testing a wide range of issues. The differences mainly lie in the user experience and in the scope of the tools.
An Important Caveat
Before you leap to the conclusion that an automated accessibility tool is going to do all of the work that is required to make your website accessible, we need to talk about what these tools cannot do. If your aim is to provide a truly accessible experience for all users, a deeper understanding of the issues and the intent behind the guidelines is required.
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. Here is a great article on key factors in making your website accessible. 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.
Whether you are a developer, a QA tester, or a site owner, and whatever your technical skill level is, automated accessibility testing tools can and should become an indispensable part of your testing toolkit.
Automated tools for testing accessibility have evolved to a point where you don’t have to look hard to find dozens of examples of thorough and reliable tools that test for adherence to Web Content Accessibility Guidelines. There are browser extensions, command-line tools, tools that can be integrated with continuous integration systems…
At every level of integration, these 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.
Consider the following scenarios:
- A content editor removes the contents of an h2 tag, unaware that the tag remains, causing confusion for screen reader users.
- The theme of a website contains a ‘skip to content’ link at the top, that linked to a ‘content’ div out of the box. The developer renamed that div, breaking the link. Now keyboard-only users have no way to skip to content, and have to tab through every navigation link.
- A designer prefers placeholder text to a field label, unaware that this may display an unlabeled field to those using a screen reader.
These issues (and many more) are very easy to miss — and they are very common. If you’re not using an automated testing tool, your site probably has similar issues.
I spent several weeks comparing these three tools in preparation for a presentation at DrupalCon Nashville. Each has a browser extension and an array of options for testing on the command line with continuous integration possibilities. They are all effective for testing a wide range of issues. The differences mainly lie in the user experience and in the scope of the tools.
An Important Caveat
Before you leap to the conclusion that an automated accessibility tool is going to do all of the work that is required to make your website accessible, we need to talk about what these tools cannot do. If your aim is to provide a truly accessible experience for all users, a deeper understanding of the issues and the intent behind the guidelines is required.
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. Here is a great article on key factors in making your website accessible. 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.
Whether you are a developer, a QA tester, or a site owner, and whatever your technical skill level is, automated accessibility testing tools can and should become an indispensable part of your testing toolkit.
lunes, 7 de octubre de 2019
Lo que pasa cuando se usa la Web con un lector de pantalla durante un día
Muy interesante lo que se cuenta en I Used The Web For A Day Using A Screen Reader:
This was an interesting and challenging experience, and the hardest article of the series to write so far.
I was taken aback by little things that are obvious when you stop and think about them. For instance, when using a screen reader, it’s almost impossible to listen to music at the same time as browsing the web! Keeping the context of the page can also be difficult, especially if you get interrupted by a phone call or something; by the time you get back to the screen reader you’ve kind of lost your place.
My biggest takeaway is that there’s a big cultural shock in going to an audio-only experience. It’s a totally different way to navigate the web, and because there is such a contrast, it is difficult to even know what constitutes a ‘good’ or ‘bad’ screen reader experience. It can be quite overwhelming, and it’s no wonder a lot of developers avoid testing on them.
But we shouldn’t avoid doing it just because it’s hard. As Charlie Owen said in her talk, Dear Developer, the Web Isn’t About You: This. Is. Your. Job. Whilst it’s fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can’t just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.
Let us do our jobs responsibly, and let’s make life a little easier for ourselves, with my last tip of the article:
Tip #13: Test on a screen reader, little and often.
I’ve tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I’d have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.
Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.
This was an interesting and challenging experience, and the hardest article of the series to write so far.
I was taken aback by little things that are obvious when you stop and think about them. For instance, when using a screen reader, it’s almost impossible to listen to music at the same time as browsing the web! Keeping the context of the page can also be difficult, especially if you get interrupted by a phone call or something; by the time you get back to the screen reader you’ve kind of lost your place.
My biggest takeaway is that there’s a big cultural shock in going to an audio-only experience. It’s a totally different way to navigate the web, and because there is such a contrast, it is difficult to even know what constitutes a ‘good’ or ‘bad’ screen reader experience. It can be quite overwhelming, and it’s no wonder a lot of developers avoid testing on them.
But we shouldn’t avoid doing it just because it’s hard. As Charlie Owen said in her talk, Dear Developer, the Web Isn’t About You: This. Is. Your. Job. Whilst it’s fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can’t just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.
Let us do our jobs responsibly, and let’s make life a little easier for ourselves, with my last tip of the article:
Tip #13: Test on a screen reader, little and often.
I’ve tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I’d have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.
Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.
martes, 1 de octubre de 2019
XXI Jornadas Formativas Cocemfe Alicante
Este miércoles 2 de octubre comienzan las XXI Jornadas Formativas Cocemfe Alicante: Comunicación y Nuevas Tecnologías como agentes de cambio en el ámbito de la discapacidad, que tienen como objetivos:
- Ampliar la mirada sobre temas de actualidad, cuestionar prejuicios, generar conciencia e inspirar con ideas diferentes para lograr una resignificación en temas relacionados con la discapacidad.
- Hasta el campus se desplazarán profesionales de medios para reflexionar sobre lenguaje inclusivo, expertos en inteligencia artificial, influencers y emprendedores de apps.
- También habrá lugar para el humor. En el descanso del miércoles 2, contaremos con la actuación de Fran Fernández, monologuista de Magma Comedy. ¡Ven, aprende y disfruta!
El miércoles 2 de octubre, a las 12:20 horas participaré en la sesión ¿Cómo usar la inteligencia artificial y la tecnología para mejorar la vida de las personas con discapacidad? junto con:
- Sergio Luján – Especialista en Tecnología y Accesibilidad Web en Discapacidad de la UA.
- Pedro Pernías – Director General para el Avance de la Sociedad Digital de la Conselleria de Innovación, Universidades, Ciencia y Sociedad Digital.
- Alba Alier – Asesora de Tecnología de Apoyo de BJ Adaptaciones.
- Presenta: Asunción González – Junta Directiva de Cocemfe Alicante.
lunes, 30 de septiembre de 2019
Resultados de la octava encuesta del WebAIM sobre el uso de lectores de pantalla
Ya se han publicado los resultados de la octava encuesta del WebAIM sobre el uso de lectores de pantalla que se abrió en agosto de 2019: Screen Reader User Survey #8 Results.
La encuesta recibió 1224 respuestas válidas, un número muy alto de respuestas, pero menor que las 2515 y 1792 respuestas que se recibieron en la sexta y séptima encuesta respectivamente.
En cuanto a porcentaje de preferencia de los usuarios, el lector de pantalla principal ha dejado de ser JAWS, ahora es NVDA con un 40.6%, seguido de JAWS con un 40.1%. El tercero es VoiceOver con un 12.9% y el resto de lectores de pantalla tienen un porcentaje de uso muy pequeño.
El navegador que más se usa es Chrome, con un 44.4%, seguido de Firefox con 27.4% e Internet Explorer 11 con 10.9%.
Por último, los resultados de las encuestas anteriores:
La encuesta recibió 1224 respuestas válidas, un número muy alto de respuestas, pero menor que las 2515 y 1792 respuestas que se recibieron en la sexta y séptima encuesta respectivamente.
En cuanto a porcentaje de preferencia de los usuarios, el lector de pantalla principal ha dejado de ser JAWS, ahora es NVDA con un 40.6%, seguido de JAWS con un 40.1%. El tercero es VoiceOver con un 12.9% y el resto de lectores de pantalla tienen un porcentaje de uso muy pequeño.
El navegador que más se usa es Chrome, con un 44.4%, seguido de Firefox con 27.4% e Internet Explorer 11 con 10.9%.
Por último, los resultados de las encuestas anteriores:
- Screen Reader User Survey #7 Results (Diciembre 2017)
- Screen Reader User Survey #6 Results (Septiembre 2015)
- Screen Reader User Survey #5 Results (Enero 2014)
- Screen Reader User Survey #4 Results (Mayo 2012)
- Screen Reader User Survey #3 Results (Diciembre 2010)
- Screen Reader User Survey #2 Results (Octubre 2009)
- Survey of Preferences of Screen Reader Users (Diciembre 2008)
Etiquetas:
Encuesta,
Lector de pantalla,
WebAIM
viernes, 27 de septiembre de 2019
lunes, 23 de septiembre de 2019
Análisis de la accesibilidad para diferentes tipos de discapacidad
En Bureau of Internet Accessibility han preparado lo siguiente:
By testing according to the Web Content Accessibility Guidelines (WCAG) 2.1, BoIA tests for the experiences of a variety of abilities. But, what are we actually looking for when we test websites and apps for accessibility barriers?
By testing according to the Web Content Accessibility Guidelines (WCAG) 2.1, BoIA tests for the experiences of a variety of abilities. But, what are we actually looking for when we test websites and apps for accessibility barriers?
- Part 1: Accessibility testing for people with visual disabilities
- Part 2: Accessibility testing for people with auditory disabilities
- Part 3: Accessibility testing for people with cognitive, learning, and neurological disabilities
- Part 4: Accessibility testing for people with physical disabilities
- Part 5: Accessibility testing for people with speech disabilities
viernes, 20 de septiembre de 2019
Las próximas Jornadas Formativas Cocemfe Alicante 2-3 de octubre
Las XXI Jornadas Formativas Cocemfe Alicante: Comunicación y Nuevas Tecnologías como agentes de cambio en el ámbito de la discapacidad están convocadas para el 2 y 3 de octubre y se celebrarán en el Salón de Actos del Edificio Germán Bernácer de la Universidad de Alicante.
Estas jornadas tienen como objetivo:
Estas jornadas tienen como objetivo:
- Ampliar la mirada sobre temas de actualidad, cuestionar prejuicios, generar conciencia e inspirar con ideas diferentes para lograr una resignificación en temas relacionados con la discapacidad.
- Hasta el campus se desplazarán profesionales de medios para reflexionar sobre lenguaje inclusivo, expertos en inteligencia artificial, influencers y emprendedores de apps.
- También habrá lugar para el humor. En el descanso del miércoles 2, contaremos con la actuación de Fran Fernández, monologuista de Magma Comedy. ¡Ven, aprende y disfruta!
El miércoles 2 de octubre, a las 12:20 horas participaré en la sesión ¿Cómo usar la inteligencia artificial y la tecnología para mejorar la vida de las personas con discapacidad? junto con:
- Sergio Luján – Especialista en Tecnología y Accesibilidad Web en Discapacidad de la UA.
- Pedro Pernías – Director General para el Avance de la Sociedad Digital de la Conselleria de Innovación, Universidades, Ciencia y Sociedad Digital.
- Alba Alier – Asesora de Tecnología de Apoyo de BJ Adaptaciones.
- Presenta: Asunción González – Junta Directiva de Cocemfe Alicante.
lunes, 16 de septiembre de 2019
Entrevista sobre educación inclusiva y diseño universal para el aprendizaje
Del 3 al 5 de septiembre el Centro de Capacitación en Educación a Distancia (CECED) de la Universidad Estatal a Distancia (UNED) de Costa Rica, llevó a cabo una jornada de reflexión del Diseño Universal para el Aprendizaje (DUA) y la accesibilidad educativa. Durante esa jornada realicé una visita y me entrevistaron: Sergio Luján Mora: Educación inclusiva a través del Diseño Universal para el Aprendizaje.
viernes, 13 de septiembre de 2019
Normativa de accesibilidad que se aplica en España
En la página Normas Accesibilidad del Portal Administración Electrónica he encontrado este documento que resume la normativa existente:
miércoles, 11 de septiembre de 2019
Por política comercial no podemos abrir cuentas a personas sordas
Sorprendente lo que he podido leer en Accesibilidad universal “Por política comercial no podemos abrir cuentas a personas sordas”:
Ignacio Benítez, sordo de nacimiento, se llevó una alegría al conocer que Openbank podría informarle de las condiciones de una hipoteca a través de un chat de WhatsApp. "A lo largo de mis 34 años he sido discriminado muchas veces, por lo que esta opción me pareció una buena forma de romper barreras y de acceder por mí mismo a un servicio sin necesidad de que mediase un intérprete", comenta a EL PAÍS RETINA a través de SVIsual, una aplicación que posibilita comunicaciones telefónicas entre personas con discapacidad auditiva y oyentes. Pero tras un breve intercambio de mensajes de texto el pasado seis de septiembre, el agente de Openbank finalizó la conversación con el siguiente mensaje: "Perdona, Ignacio. He consultado la situación y te informo de que, por política comercial, no podemos abrir cuentas a personas con sorderas agudas o totales, ya que no tenemos la posibilidad de una comunicación telefónica, clave en la relación con Openbank".
Benítez, que forma parte del Comité de Diversidad e Inclusión de Accenture, se quedó "alucinado e impotente" ante ese trato que considera "superofensivo". Tras escribir a distintas asociaciones de usuarios para reclamar sus derechos, compartió su experiencia en las redes sociales y ese mismo día el asunto llegó hasta Ezequiel Szafir, CEO de Openbank, quien enseguida contactó directamente con el afectado para pedirle disculpas y manifestarle su "vergüenza" ante la respuesta "errónea" de su compañía, que no sigue ninguna política comercial como la indicada en el mensaje de WhatsApp. "Es una contestación aberrante debida a un error humano. Rarísimo, violentamente innecesario. No sabemos por qué el compañero del call center respondió así, porque precisamente al ser 100% digital somos el banco perfecto para Ignacio, que puede abrir una cuenta desde internet sin necesidad de hablar con nadie. La tecnología sirve para tirar abajo barreras y nosotros lo demostramos", comenta Szafir a EL PAÍS RETINA.
En España, el 26,2% de las personas con discapacidad afirma que ésta le impide el uso de internet, según el Observatorio estatal de la discapacidad.
Suscribirse a:
Entradas (Atom)