El libro oficial de formación básica de NVDA, que incluye conceptos que van desde los primeros pasos para empezar con Windows y NVDA hasta explorar la web o usar el navegador de objetos (ebook, publicado el 14 de junio de 2018).
El libro de formación básica de NVDA es el primer módulo del conjunto oficial de material de formación de NV Access para aprender a usar el lector de pantalla libre NVDA. Ideal para nuevos usuarios o usuarios existentes que quieran mejorar sus habilidades.
Entre los temas incluidos se encuentran: primeros pasos con NVDA y Windows, configuración básica, redacción y edición de texto, formateado de documentos, gestión de archivos, multitarea, exploración de la web, y utilización del cursor de revisión y el navegador de objetos. Formatos incluidos en el paquete: ePub, HTML, Docx (Microsoft Word) y KFX (Amazon Kindle).
Al adquirir el libro de nuestra web, ayudas a mantener la comunidad de NVDA en español y permites que podamos descubrir complementos, traducir documentación y ofrecer un punto de encuentro único y robusto para todos los usuarios de habla hispana de NVDA.
Si quieres ver algunas muestras del libro antes de animarte a comprarlo, te dejamos el capítulo 1, con la introducción, y el capítulo 12, que habla sobre el cursor de revisión.
martes, 9 de octubre de 2018
Publicado el libro "Formación básica de NVDA"
En Libro “Formación básica de NVDA” podemos leer:
lunes, 8 de octubre de 2018
Cursos en línea sobre accesibilidad web
viernes, 5 de octubre de 2018
Webinar "Usabilidad y accesibilidad en la enseñanza online: Plataformas y recursos de aprendizaje fáciles de usar y para todos"
La Universidad Internacional de Andalucía organiza el webinar Usabilidad y accesibilidad en la enseñanza online: Plataformas y recursos de aprendizaje fáciles de usar y para todos (Webinar) el próximo 15 de octubre. Su contenido es:
- ¿Qué es la usabilidad?
- El papel de la usabilidad en la docencia online: Plataformas y contenidos
- Principales barreras de usabilidad en el aprendizaje online.
- Más allá de la usabilidad: Mejorando la experiencia de usuario en el aprendizaje en línea
- Accesibilidad y diseño para todos en la docencia y aprendizaje online
- Técnicas rápidas de evaluación de la usabilidad y accesibilidad.
miércoles, 3 de octubre de 2018
Sématos
Sématos es un banco de palabras y expresiones en la lengua de signos alemana, catalana, española, francesa e internacional.
Este sitio web incluye secciones organizadas por temas, por ejemplo informática.
Este sitio web incluye secciones organizadas por temas, por ejemplo informática.
martes, 2 de octubre de 2018
Herramienta para evaluar la accesibilidad de todo un sitio web
Dinolytics es una nueva herramienta, basada en WAVE de WebAIM, que permite evaluar la accesibilidad de todo un sitio web.
lunes, 1 de octubre de 2018
Nueva herramienta para evaluar el contraste del color de los enlaces
El WebAIM ha lanzado una nueva herramienta para evaluar el contraste del color de los enlaces:
La explicación de la necesidad de esta nueva herramienta se encuentra en:
viernes, 28 de septiembre de 2018
Diseño accesible, universal o inclusivo, ¿es lo mismo?
En el artículo The Same, But Different: Breaking Down Accessibility, Universality, and Inclusion in Design explican las diferencias y semejanzas de tres términos relacionados, accesible, universal e inclusivo:
Accessibility is a goal
We use the term accessibility to describe a vast network of activity, but, in the most basic terms, when we talk about a site or an app, we describe its progress toward accessibility in basic terms — it’s good, it’s bad, it’s ugly. The goal of everyone I know in the accessibility community is to make things better for as large an audience as possible. So here’s definition number one:
Accessibility is the goal to ensure that products support each individual user’s needs and preferences.
Universal design is for everyone, literally
Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.
Inclusive design expands with your audience
Unlike universal design, there are not yet generally agreed-upon definitions for inclusive design, or the practices it encompasses. Some attempts borrow heavily from the above definition of universal design. Some are more mission statements than definitions. Some are explicitly connected with disability, while others are broader in scope. All of them have some value, in that they confront the reader with the idea that it is always within their capacity to do more.
The definition of inclusive design that I identify most with comes from the Inclusive Design Research Centre at OCAD U in Toronto:
We have defined Inclusive Design as: design that considers the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference.
Inclusive design is a term that leads people to think about an expanding audience, with expanding wants and needs, which, in turn, gives them more to think about as they design products. When I say, “I’m working on inclusive design,” I get substantially fewer blank stares than when I said, “I work on accessibility.” More often than not, the connection to the needs of people with disabilities comes through on its own.
Accessibility is a goal
We use the term accessibility to describe a vast network of activity, but, in the most basic terms, when we talk about a site or an app, we describe its progress toward accessibility in basic terms — it’s good, it’s bad, it’s ugly. The goal of everyone I know in the accessibility community is to make things better for as large an audience as possible. So here’s definition number one:
Accessibility is the goal to ensure that products support each individual user’s needs and preferences.
Universal design is for everyone, literally
Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.
Inclusive design expands with your audience
Unlike universal design, there are not yet generally agreed-upon definitions for inclusive design, or the practices it encompasses. Some attempts borrow heavily from the above definition of universal design. Some are more mission statements than definitions. Some are explicitly connected with disability, while others are broader in scope. All of them have some value, in that they confront the reader with the idea that it is always within their capacity to do more.
The definition of inclusive design that I identify most with comes from the Inclusive Design Research Centre at OCAD U in Toronto:
We have defined Inclusive Design as: design that considers the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference.
Inclusive design is a term that leads people to think about an expanding audience, with expanding wants and needs, which, in turn, gives them more to think about as they design products. When I say, “I’m working on inclusive design,” I get substantially fewer blank stares than when I said, “I work on accessibility.” More often than not, the connection to the needs of people with disabilities comes through on its own.
jueves, 27 de septiembre de 2018
Accesibilidad al 90%
Visto en Twitter en un mensaje de la Fundación Once:
La accesibilidad web a veces se queda así, a medias.
La accesibilidad web a veces se queda así, a medias.
miércoles, 26 de septiembre de 2018
Lenguaje inclusivo
En Teaching Students with Disabilities se puede leer:
In order to create an inclusive classroom where all students are respected, it is important to use language that prioritizes the student over his or her disability. Disability labels can be stigmatizing and perpetuate false stereotypes where students who are disabled are not as capable as their peers. In general, it is appropriate to reference the disability only when it is pertinent to the situation. For instance, it is better to say “The student, who has a disability” rather than “The disabled student” because it places the importance on the student, rather than on the fact that the student has a disability.En Disability Language Style Guide y Terms to Avoid When Writing About Disability se puede encontrar más información sobre los términos que se puede o no se puede usar.
martes, 25 de septiembre de 2018
Compatibilidad de WAI-ARIA y los lectores de pantalla
En WAI-ARIA - Screen reader compatibility han recogido información sobre la compatibilidad de WAI-ARIA con los lectores de pantalla más populares:
La mejor combinación es JAWS con Internet Explorer 11.
lunes, 24 de septiembre de 2018
viernes, 21 de septiembre de 2018
jueves, 20 de septiembre de 2018
Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público
Ayer se publicó en el Boletín Oficial del Estado 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.
Este Real Decreto surge a partir de 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 tiene como objetivo (artículo 1):
El artículo 2 indica a quién se aplica:
Artículo 2. Ámbito subjetivo.
1. Este real decreto se aplica al sector público que comprende:
a) La Administración General del Estado.
b) Las Administraciones de las comunidades autónomas.
c) Las entidades que integran la Administración Local.
d) El sector público institucional, en los términos establecidos en el artículo 2.2 de
la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las
Administraciones públicas
e) Las asociaciones constituidas por las Administraciones, entes, organismos y
entidades que integran el sector público.
2. Lo dispuesto en este real decreto también será de aplicación a la Administración
de Justicia.
El artículo 3 indica a qué se aplica:
Artículo 3. Ámbito objetivo de aplicación.
1. Este real decreto se aplica tanto a los sitios web, independientemente del
dispositivo empleado para acceder a ellos, como a las aplicaciones para dispositivos
móviles de los organismos del sector público y otros obligados incluidos en el ámbito de
aplicación del artículo 2.
2. El contenido accesible de los sitios web y de las aplicaciones para dispositivos
móviles incluye la información tanto textual como no textual, los documentos y formularios
que se pueden descargar, los contenidos multimedia pregrabados de base temporal, las
formas de interacción bidireccional, el tratamiento de formularios digitales y la
cumplimentación de los procesos de identificación, autenticación, firma y pago con
independencia de la plataforma tecnológica que se use para su puesta a disposición del
público.
3. Están excluidos de este real decreto y se regularán por su normativa específica
los contenidos multimedia en directo y pregrabado de base temporal de los sitios web y
aplicaciones para dispositivos móviles de prestadores del servicio público de
radiodifusión y sus filiales, así como los de otros organismos o sus filiales que cumplan
un mandato de servicio público de radiodifusión.
4. Asimismo, quedan excluidos del ámbito de aplicación del presente real decreto
los siguientes contenidos:
a) Formatos de archivo de ofimática publicados antes de la entrada en vigor de este
real decreto, salvo que los mismos sean necesarios para tareas administrativas activas
relativas a las funciones realizadas por los sujetos obligados por este real decreto.
b) Contenido multimedia pregrabado de base temporal publicado antes de la
entrada en vigor de este real decreto.
c) Contenido multimedia en directo de base temporal salvo lo dispuesto en otra
legislación específica que obligue al respecto.
d) Servicios de mapas y cartografía en línea, siempre y cuando la información
esencial se proporcione de manera accesible digitalmente en el caso de mapas
destinados a fines de navegación.
e) Contenidos de terceros que no estén financiados ni desarrollados por el sujeto
obligado ni estén bajo su control.
f) Reproducciones de bienes de colecciones del patrimonio que no puedan hacerse
plenamente accesibles por alguna de las siguientes causas:
1.° Incompatibilidad de los requisitos de accesibilidad con la conservación del bien
de que se trate o con la autenticidad de la reproducción.
2.° Indisponibilidad de soluciones automatizadas y rentables que permitan extraer
el texto de manuscritos u otros bienes de colecciones del patrimonio y transformarlos en
contenidos compatibles con los requisitos de accesibilidad.
g) Contenidos de extranet e intranet entendidos como sitios web accesibles
únicamente para un grupo restringido de personas y no para el público en general,
publicados antes del 23 de septiembre de 2019, hasta que dichos sitios web sean objeto
de una revisión sustancial.
h) Contenidos de sitios web y aplicaciones para dispositivos móviles que tengan la
condición de archivos o herramientas de archivo por contener únicamente contenidos no
necesarios para el desarrollo de cualesquiera tareas administrativas activas, siempre que
no hayan sido actualizados ni editados con posterioridad a la entrada en vigor de este
real decreto.
El artículo 6 indica los requisitos que se deben cumplir:
Artículo 6. Presunción de conformidad con los requisitos de accesibilidad.
1. Se presumirá que el contenido de los sitios web y aplicaciones para dispositivos
móviles que cumpla las normas armonizadas o partes de éstas cuyas referencias hayan
sido publicadas en el «Diario Oficial de la Unión Europea» es conforme a los requisitos
de accesibilidad establecidos en el artículo 5 que estén cubiertos por dichas normas o
partes de ellas.
2. En caso de que no se hayan publicado las referencias de las normas
armonizadas a que se refiere el apartado 1, se presumirá que el contenido de las
aplicaciones para dispositivos móviles que cumpla las especificaciones técnicas o partes
de éstas, que la Comisión haya adoptado mediante los correspondientes actos de
ejecución, es conforme a los requisitos de accesibilidad establecidos en el artículo 5 que
estén cubiertos por dichas especificaciones técnicas o partes de ellas.
3. En caso de que no se hayan publicado las referencias de las normas
armonizadas a que se refiere el apartado 1, se presumirá que el contenido de los sitios
web que cumpla los requisitos pertinentes de la norma EN 301 549 V1.1.2 (2015-04) o
partes de estos, es conforme a los requisitos de accesibilidad establecidos en el
artículo 5 que estén cubiertos por dichos requisitos o partes de ellos.
En caso de que no se hayan publicado las referencias de las normas armonizadas a
que se refiere el apartado 1, y en ausencia de las especificaciones técnicas a que se
refiere el apartado 2, se presumirá que el contenido de aplicaciones para dispositivos
móviles que cumpla los requisitos pertinentes de la norma EN 301 549 V1.1.2 (2015-04)
o partes de estos, es conforme a los requisitos de accesibilidad establecidos en el
artículo 5 que estén cubiertos por dichos requisitos o partes de ellos.
4. Se aplicarán directamente las actualizaciones de referencias a la norma EN 301
549 V1.1.2 (2015-04) que la Comisión adopte mediante actos delegados para hacer
referencia a una versión más reciente de dicha norma o a una norma europea que la
sustituya.
5. El órgano encargado de realizar el seguimiento y presentación de informes ante
la Comisión Europea mantendrá disponible en su sitio web la referencia concreta a las
normas armonizadas, normas y especificaciones técnicas que sean de aplicación en
cada momento.
La disposición final quinta indica cuándo entrará en vigor:
Disposición final quinta. Entrada en vigor.
El presente real decreto entrará en vigor el día siguiente al de su publicación en el
«Boletín Oficial del Estado» con las siguientes excepciones:
Para los sitios web, las disposiciones previstas en los artículos 10.2.b), 12 y 13 serán
de aplicación al año de la entrada en vigor de este real decreto, y a los dos años para los
sitios web ya publicados.
Todas las disposiciones relativas a aplicaciones para dispositivos móviles serán de
aplicación desde el 23 de junio de 2021.
Este Real Decreto surge a partir de 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 tiene como objetivo (artículo 1):
La presente Directiva tiene por objeto aproximar las disposiciones legales, reglamentarias y administrativas de los Estados miembros relativas a los requisitos de accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público, permitiendo así que dichos sitios y aplicaciones sean más accesibles para los usuarios, en particular para las personas con discapacidad.
El artículo 2 indica a quién se aplica:
Artículo 2. Ámbito subjetivo.
1. Este real decreto se aplica al sector público que comprende:
a) La Administración General del Estado.
b) Las Administraciones de las comunidades autónomas.
c) Las entidades que integran la Administración Local.
d) El sector público institucional, en los términos establecidos en el artículo 2.2 de
la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las
Administraciones públicas
e) Las asociaciones constituidas por las Administraciones, entes, organismos y
entidades que integran el sector público.
2. Lo dispuesto en este real decreto también será de aplicación a la Administración
de Justicia.
El artículo 3 indica a qué se aplica:
Artículo 3. Ámbito objetivo de aplicación.
1. Este real decreto se aplica tanto a los sitios web, independientemente del
dispositivo empleado para acceder a ellos, como a las aplicaciones para dispositivos
móviles de los organismos del sector público y otros obligados incluidos en el ámbito de
aplicación del artículo 2.
2. El contenido accesible de los sitios web y de las aplicaciones para dispositivos
móviles incluye la información tanto textual como no textual, los documentos y formularios
que se pueden descargar, los contenidos multimedia pregrabados de base temporal, las
formas de interacción bidireccional, el tratamiento de formularios digitales y la
cumplimentación de los procesos de identificación, autenticación, firma y pago con
independencia de la plataforma tecnológica que se use para su puesta a disposición del
público.
3. Están excluidos de este real decreto y se regularán por su normativa específica
los contenidos multimedia en directo y pregrabado de base temporal de los sitios web y
aplicaciones para dispositivos móviles de prestadores del servicio público de
radiodifusión y sus filiales, así como los de otros organismos o sus filiales que cumplan
un mandato de servicio público de radiodifusión.
4. Asimismo, quedan excluidos del ámbito de aplicación del presente real decreto
los siguientes contenidos:
a) Formatos de archivo de ofimática publicados antes de la entrada en vigor de este
real decreto, salvo que los mismos sean necesarios para tareas administrativas activas
relativas a las funciones realizadas por los sujetos obligados por este real decreto.
b) Contenido multimedia pregrabado de base temporal publicado antes de la
entrada en vigor de este real decreto.
c) Contenido multimedia en directo de base temporal salvo lo dispuesto en otra
legislación específica que obligue al respecto.
d) Servicios de mapas y cartografía en línea, siempre y cuando la información
esencial se proporcione de manera accesible digitalmente en el caso de mapas
destinados a fines de navegación.
e) Contenidos de terceros que no estén financiados ni desarrollados por el sujeto
obligado ni estén bajo su control.
f) Reproducciones de bienes de colecciones del patrimonio que no puedan hacerse
plenamente accesibles por alguna de las siguientes causas:
1.° Incompatibilidad de los requisitos de accesibilidad con la conservación del bien
de que se trate o con la autenticidad de la reproducción.
2.° Indisponibilidad de soluciones automatizadas y rentables que permitan extraer
el texto de manuscritos u otros bienes de colecciones del patrimonio y transformarlos en
contenidos compatibles con los requisitos de accesibilidad.
g) Contenidos de extranet e intranet entendidos como sitios web accesibles
únicamente para un grupo restringido de personas y no para el público en general,
publicados antes del 23 de septiembre de 2019, hasta que dichos sitios web sean objeto
de una revisión sustancial.
h) Contenidos de sitios web y aplicaciones para dispositivos móviles que tengan la
condición de archivos o herramientas de archivo por contener únicamente contenidos no
necesarios para el desarrollo de cualesquiera tareas administrativas activas, siempre que
no hayan sido actualizados ni editados con posterioridad a la entrada en vigor de este
real decreto.
El artículo 6 indica los requisitos que se deben cumplir:
Artículo 6. Presunción de conformidad con los requisitos de accesibilidad.
1. Se presumirá que el contenido de los sitios web y aplicaciones para dispositivos
móviles que cumpla las normas armonizadas o partes de éstas cuyas referencias hayan
sido publicadas en el «Diario Oficial de la Unión Europea» es conforme a los requisitos
de accesibilidad establecidos en el artículo 5 que estén cubiertos por dichas normas o
partes de ellas.
2. En caso de que no se hayan publicado las referencias de las normas
armonizadas a que se refiere el apartado 1, se presumirá que el contenido de las
aplicaciones para dispositivos móviles que cumpla las especificaciones técnicas o partes
de éstas, que la Comisión haya adoptado mediante los correspondientes actos de
ejecución, es conforme a los requisitos de accesibilidad establecidos en el artículo 5 que
estén cubiertos por dichas especificaciones técnicas o partes de ellas.
3. En caso de que no se hayan publicado las referencias de las normas
armonizadas a que se refiere el apartado 1, se presumirá que el contenido de los sitios
web que cumpla los requisitos pertinentes de la norma EN 301 549 V1.1.2 (2015-04) o
partes de estos, es conforme a los requisitos de accesibilidad establecidos en el
artículo 5 que estén cubiertos por dichos requisitos o partes de ellos.
En caso de que no se hayan publicado las referencias de las normas armonizadas a
que se refiere el apartado 1, y en ausencia de las especificaciones técnicas a que se
refiere el apartado 2, se presumirá que el contenido de aplicaciones para dispositivos
móviles que cumpla los requisitos pertinentes de la norma EN 301 549 V1.1.2 (2015-04)
o partes de estos, es conforme a los requisitos de accesibilidad establecidos en el
artículo 5 que estén cubiertos por dichos requisitos o partes de ellos.
4. Se aplicarán directamente las actualizaciones de referencias a la norma EN 301
549 V1.1.2 (2015-04) que la Comisión adopte mediante actos delegados para hacer
referencia a una versión más reciente de dicha norma o a una norma europea que la
sustituya.
5. El órgano encargado de realizar el seguimiento y presentación de informes ante
la Comisión Europea mantendrá disponible en su sitio web la referencia concreta a las
normas armonizadas, normas y especificaciones técnicas que sean de aplicación en
cada momento.
La disposición final quinta indica cuándo entrará en vigor:
Disposición final quinta. Entrada en vigor.
El presente real decreto entrará en vigor el día siguiente al de su publicación en el
«Boletín Oficial del Estado» con las siguientes excepciones:
Para los sitios web, las disposiciones previstas en los artículos 10.2.b), 12 y 13 serán
de aplicación al año de la entrada en vigor de este real decreto, y a los dos años para los
sitios web ya publicados.
Todas las disposiciones relativas a aplicaciones para dispositivos móviles serán de
aplicación desde el 23 de junio de 2021.
miércoles, 19 de septiembre de 2018
lunes, 17 de septiembre de 2018
miércoles, 12 de septiembre de 2018
¿Nueva página del Congreso de los Diputados?
El pasado viernes 7 de septiembre se publicó en el Boletín Oficial del Estado el Anuncio del Congreso de los Diputados de formalización del contrato de servicios para el desarrollo de una página web y la infraestructura que la debe soportar para el Congreso de los Diputados.
El anuncio dice:
Objeto del contrato:
a) Tipo: Servicios.
b) Descripción: Servicios para el desarrollo de una página web y la
infraestructura que la debe soportar.
g) Medio de publicación del anuncio de licitación: DOUE, BOCG, BOE y Perfil
del Contratante.
h) Fecha de publicación del anuncio de licitación: 28/11/2017
5. Presupuesto base de licitación. Importe total: 1.846.218,79 euros.
6. Formalización del contrato:
a) Fecha de adjudicación: 25/07/2018.
b) Fecha de formalización del contrato: 29/08/2018.
c) Contratista: Grupo Corporativo GFI Informática, S.A.
d) Importe o canon de adjudicación: Importe total: 1.597.051,36 euros.
Un millón y medio de euros para el desarrollo de una página web, ¿una página web? Un poco cara, ¿no?
Habrá que investigar más este contrato, ¿estará la accesibilidad web en la lista de requisitos a cumplir? ¿Se les habrá olvidado?
lunes, 10 de septiembre de 2018
Real Decreto para mejorar la accesibilidad a los sitios web y aplicaciones para dispositivos móviles del sector público
El pasado viernes 7 de septiembre, el Consejo de Ministros aprobó un Real Decreto para mejorar la accesibilidad a los sitios web y aplicaciones para dispositivos móviles del sector público. Este Real Decreto "garantiza la igualdad y no discriminación de acceso a toda la ciudadanía, en particular a las personas con discapacidad y a las personas mayores".
Este Real Decreto "traspone 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".
Al gobierno español "le ha pillado el toro" una vez más, porque el plan establecía julio 2018 para que los países de la Unión Europea trasladasen la directiva europea al marco legislativo de cada país.
Más información en Luz verde al real decreto sobre accesibilidad de las web y apps para dispositivos móviles del sector público.
Este Real Decreto "traspone 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".
Al gobierno español "le ha pillado el toro" una vez más, porque el plan establecía julio 2018 para que los países de la Unión Europea trasladasen la directiva europea al marco legislativo de cada país.
Más información en Luz verde al real decreto sobre accesibilidad de las web y apps para dispositivos móviles del sector público.
viernes, 7 de septiembre de 2018
2acces
Según el sitio web de 2acces:
2ACCES es una herramienta creada para la integración de las personas sordas. Este software facilita la accesibilidad para poder estar en igualdad de condiciones con el resto de los usuarios de cualquier sala.
Funciona mediante un software que transcribe en tiempo real todo lo que una persona comunica oralmente.
Este no es el primer sistema que conozco con esta funcionalidad, otros dos gratuitos son Web Captioner y Voice Dictation.
2ACCES es una herramienta creada para la integración de las personas sordas. Este software facilita la accesibilidad para poder estar en igualdad de condiciones con el resto de los usuarios de cualquier sala.
Funciona mediante un software que transcribe en tiempo real todo lo que una persona comunica oralmente.
Este no es el primer sistema que conozco con esta funcionalidad, otros dos gratuitos son Web Captioner y Voice Dictation.
miércoles, 5 de septiembre de 2018
Segunda encuesta del WebAIM dirigida a usuarios con baja visión
El WebAIM ha lanzado la encuesta Survey of Users with Low Vision #2. Esta encuesta está destinada a los usuarios con baja visión y estará abierta hasta el 30 de septiembre de 2018.
La primera encuesta se celebró en el año 2013 y los resultados no fueron concluyentes.
La primera encuesta se celebró en el año 2013 y los resultados no fueron concluyentes.
lunes, 3 de septiembre de 2018
Curso gratuito "Web Accessibility for Developers"
El 24 de septiembre comienza el curso Web Accessibility for Developers:
- Understanding WAI-ARIA (What is does and does not do)
- WCAG 2 and WAI-ARIA
- WAI-ARIA relation to HTML 5
- Static vs dynamic WAI-ARIA
- Cross browser support for WAI-ARIA
- Screen reader compatibility (JAWS, NVDA, ChromeVox)
- Screen reader testing for WAI-ARIA
- WAI-ARIA validation tools
- WAI-ARIA roles, states, and properties
- Navigation with WAI-ARIA landmarks
- Live regions, alerts, and message dialogs
- WAI-ARIA libraries
- WAI-ARIA application and presentation roles
- Keyboard interaction for WAI-ARIA enabled widgets and applications
- WAI-ARIA for toggle buttons, progress bars, suggestion forms, and tooltips
- WAI-ARIA for sliders, accordions, tab panels, and carousels
- WAI-ARIA for menu bars, tree menus, and sortable drag and drop lists
viernes, 31 de agosto de 2018
Mauve
Mauve es una herramienta de revisión de la accesibilidad web de origen italiano.
He analizado con ella la accesibilidad de mi sitio web y me saca un error muy raro:
La técnica H50 no la conozco y no la encuentro en Techniques for WCAG 2.0. ¡Esa técnica no existe!
Existía en versiones anteriores: H50: Using map to group links. Pero eso de usar map para agrupar enlaces como un elemento de navegación nunca lo había visto. Así que, esta herramienta de evaluación automática de la accesibilidad web no sé si es de fiar.
He analizado con ella la accesibilidad de mi sitio web y me saca un error muy raro:
La técnica H50 no la conozco y no la encuentro en Techniques for WCAG 2.0. ¡Esa técnica no existe!
Existía en versiones anteriores: H50: Using map to group links. Pero eso de usar map para agrupar enlaces como un elemento de navegación nunca lo había visto. Así que, esta herramienta de evaluación automática de la accesibilidad web no sé si es de fiar.
martes, 28 de agosto de 2018
Denuncia por falta de accesibilidad contra Apple
En Apple sued over claims website is inaccessible to visually impaired users, se explica que Apple ha sido denunciada en Estados Unidos porque su sitio web no es accesible para las personas ciegas o con baja visión:
Filed in the U.S. District Court of the Southern District of New York on Sunday, the complaint from the plaintiff Himelda Mendez is said to be filed on behalf of other users in a similar accessibility situation. Apple is the sole defendant in the lawsuit.
According to the filing, Mendez is described as a "visually impaired and legally blind person" who uses screen-reading software to access the internet. The software is able to either read out information seen on the screen or outputs it to a refreshable Braille display, and typically relies on the website being constructed in ways that it can read the contents.
In the case of a website that isn't produced in this way, such as one that doesn't follow the Web Content Accessibility Guidelines from the World Wide Web Consortium, the readers may be unable to read content that could be useful for the user, or read it in an unintentional way that would be difficult to parse.
Mendez, said to be a proficient user of the Jobs Access With Speech (JAWS) screen reading program, visited the Apple website earlier this month but encountered "multiple access barriers" that denied "full and equal access to the facilities, goods, and services offered to the public," such as being able to browse and purchase products, make service appointments, or learn of the facilities available in Apple Stores in New York, the city where Mendez is resident.
The filing provides a long list of issues with the website that it believes needs fixing, in order to comply with the ADA, in relation to screen readers. The list includes the lack of alternative text for graphics, empty links containing no text, redundant links, and linked images missing alternative text.
It is asserted these issues caused a denial of "full and equal access" to the plaintiff, deterring future use of the site in the process. If it were fully accessible, the filing believes those using screen-reading software would be able to independently navigate the site and perform the same transactions as those with sight.
It is also alleged the lack of compliance with WCAG 2.0 guidelines means Apple has "engaged in acts of intentional discrimination," under the belief the site was not produced with visually-impaired individuals in mind, nor has it been corrected.
The suit demands a permanent injunction requiring Apple to retain a qualified consultant to help the company comply with WCAG 2.0 guidelines for the site, including training its web developers on accessibility compliance, regularly checking the site's compliance, regular testing by blind and visually-impaired users, and the development of an accessibility policy posted on all of its websites. Also sought are "compensatory damages in an amount to be determined by proof, including all applicable statutory and punitive damages and fines," plus legal fees incurred by the filer.
AppleInsider has asked Apple for comment, and will provide an update if there is a response.
Apple prides itself on including accessibility features in its products, highlighting them in marking Global Accessibility Awareness Day each year. The company has also worked with other companies and organizations in producing accessibility aids, including developing a hearing implant sound processor with Cochlear, and participating in the USB Implementers Forum to produce a new interface standard for braille displays.
Filed in the U.S. District Court of the Southern District of New York on Sunday, the complaint from the plaintiff Himelda Mendez is said to be filed on behalf of other users in a similar accessibility situation. Apple is the sole defendant in the lawsuit.
According to the filing, Mendez is described as a "visually impaired and legally blind person" who uses screen-reading software to access the internet. The software is able to either read out information seen on the screen or outputs it to a refreshable Braille display, and typically relies on the website being constructed in ways that it can read the contents.
In the case of a website that isn't produced in this way, such as one that doesn't follow the Web Content Accessibility Guidelines from the World Wide Web Consortium, the readers may be unable to read content that could be useful for the user, or read it in an unintentional way that would be difficult to parse.
Mendez, said to be a proficient user of the Jobs Access With Speech (JAWS) screen reading program, visited the Apple website earlier this month but encountered "multiple access barriers" that denied "full and equal access to the facilities, goods, and services offered to the public," such as being able to browse and purchase products, make service appointments, or learn of the facilities available in Apple Stores in New York, the city where Mendez is resident.
The filing provides a long list of issues with the website that it believes needs fixing, in order to comply with the ADA, in relation to screen readers. The list includes the lack of alternative text for graphics, empty links containing no text, redundant links, and linked images missing alternative text.
It is asserted these issues caused a denial of "full and equal access" to the plaintiff, deterring future use of the site in the process. If it were fully accessible, the filing believes those using screen-reading software would be able to independently navigate the site and perform the same transactions as those with sight.
It is also alleged the lack of compliance with WCAG 2.0 guidelines means Apple has "engaged in acts of intentional discrimination," under the belief the site was not produced with visually-impaired individuals in mind, nor has it been corrected.
The suit demands a permanent injunction requiring Apple to retain a qualified consultant to help the company comply with WCAG 2.0 guidelines for the site, including training its web developers on accessibility compliance, regularly checking the site's compliance, regular testing by blind and visually-impaired users, and the development of an accessibility policy posted on all of its websites. Also sought are "compensatory damages in an amount to be determined by proof, including all applicable statutory and punitive damages and fines," plus legal fees incurred by the filer.
AppleInsider has asked Apple for comment, and will provide an update if there is a response.
Apple prides itself on including accessibility features in its products, highlighting them in marking Global Accessibility Awareness Day each year. The company has also worked with other companies and organizations in producing accessibility aids, including developing a hearing implant sound processor with Cochlear, and participating in the USB Implementers Forum to produce a new interface standard for braille displays.
lunes, 27 de agosto de 2018
viernes, 24 de agosto de 2018
Un sitio web es accesible cuando es accesible para todas las discapacidades
Un error muy común que muchas veces he notado es pensar centrarse en resolver los problemas de accesibilidad para solo unos tipos de discapacidad.
En el año 2015 escribí la entrada Unas personas con discapacidad que se olvidan del resto de las personas con discapacidad en la que comentaba que el sitio web de la Confederación Estatal de Personas Sordas no era accesible para otras discapacidades.
Tres años después, ¿este sitio web es accesible?
Tres años después este sitio web sigue con los mismos problemas, por ejemplo:
Un captcha en el formulario de contacto:
Imposibilidad de navegar con el teclado porque no se muestra el foco de los elementos de la interfaz, ¿cuál de los siguientes botones tiene el foco?
Enlaces y botones que realmente no lo son, ¿por qué la siguiente botonera son imágenes sin texto alternativo y con el evento onclick?
En el año 2015 escribí la entrada Unas personas con discapacidad que se olvidan del resto de las personas con discapacidad en la que comentaba que el sitio web de la Confederación Estatal de Personas Sordas no era accesible para otras discapacidades.
Tres años después, ¿este sitio web es accesible?
Tres años después este sitio web sigue con los mismos problemas, por ejemplo:
Un captcha en el formulario de contacto:
Imposibilidad de navegar con el teclado porque no se muestra el foco de los elementos de la interfaz, ¿cuál de los siguientes botones tiene el foco?
Enlaces y botones que realmente no lo son, ¿por qué la siguiente botonera son imágenes sin texto alternativo y con el evento onclick?
miércoles, 22 de agosto de 2018
Evaluación semisupervisada de sitios web
Un sitio web puede tener miles o incluso millones de páginas web. ¿Cómo se puede evaluar la accesibilidad de todo un sitio web? Es una tarea desafiante.
En el artículo Using Semi-supervised Group Sparse Regression to Improve Web Accessibility Evaluation se presenta una posible solución:
En el artículo Using Semi-supervised Group Sparse Regression to Improve Web Accessibility Evaluation se presenta una posible solución:
Web accessibility evaluation checks the accessibility of the website to help improve the user experiences for disabled people. Due to the massive number of web pages in a website, manually reviewing all the pages becomes totally impractical. But the complexities of evaluating some checkpoints require certain human involvements. To address this issue, we develop the semi-supervised group sparse regression algorithm which takes advantages of the high precision of a small amount of manual evaluation results along with the global distribution of all the web pages and efficiently gives out the overall evaluation result of the website. Moreover, the proposed method can tell the importance of each feature in evaluating each checkpoint. The experiments on various websites demonstrate the superiority of our proposed algorithm.
lunes, 20 de agosto de 2018
Lo que pasa cuando usas el teclado por un día
En I Used The Web For A Day With Just A Keyboard, una persona explica lo que descubrió cuando estuvo todo el día navegando por la Web solo con el uso del teclado. Su resumen final es:
This experiment has been a mixed bag of great keyboard experiences and poor ones. I have three main takeaways.
KEEP IT STYLISH
By far the most common keyboard accessibility issue I’ve faced today is a lack of focus styling for tabbable elements. Suppressing native focus styles without defining any custom focus styles makes it extremely difficult, even impossible, to figure out where you are on the page. Removing the outline is such a common faux pas that there’s even a site dedicated to it.
Ensuring that native or custom focus styling is visible is the single most impactful thing you can do in the area of keyboard accessibility, and it’s often one of the easiest; a simple case of doubling up selectors on your existing :hover styling. If you only do one thing after reading this article, it should be to search for outline: 0 and outline: none in your CSS.
SEMANTICS ARE KEY
How many times have you tried opening a link in a new tab, only for your current window to get redirected? It happens to me every now and again, and annoying as it is, I’m lucky that it’s one of the only usability issues I tend to face when I use the web. Such issues arise from misusing the platform.
CONTENT IS KEY
You may be required to display cookie notices, subscription forms, adverts or adblock notices.
Do what you can to make these experiences unobtrusive. If you can’t make them unobtrusive, at least make them dismissible.
Users are there to see your content, not your banners, so put these dismissible elements first in your DOM so that they can be quickly dismissed, or fall back to using tabindex="1" if you can’t move them.
Finally, support your users in getting to your content as quickly as they can, by implementing the Holy Grail of ‘skip to main content’ links.
This experiment has been a mixed bag of great keyboard experiences and poor ones. I have three main takeaways.
KEEP IT STYLISH
By far the most common keyboard accessibility issue I’ve faced today is a lack of focus styling for tabbable elements. Suppressing native focus styles without defining any custom focus styles makes it extremely difficult, even impossible, to figure out where you are on the page. Removing the outline is such a common faux pas that there’s even a site dedicated to it.
Ensuring that native or custom focus styling is visible is the single most impactful thing you can do in the area of keyboard accessibility, and it’s often one of the easiest; a simple case of doubling up selectors on your existing :hover styling. If you only do one thing after reading this article, it should be to search for outline: 0 and outline: none in your CSS.
SEMANTICS ARE KEY
How many times have you tried opening a link in a new tab, only for your current window to get redirected? It happens to me every now and again, and annoying as it is, I’m lucky that it’s one of the only usability issues I tend to face when I use the web. Such issues arise from misusing the platform.
CONTENT IS KEY
You may be required to display cookie notices, subscription forms, adverts or adblock notices.
Do what you can to make these experiences unobtrusive. If you can’t make them unobtrusive, at least make them dismissible.
Users are there to see your content, not your banners, so put these dismissible elements first in your DOM so that they can be quickly dismissed, or fall back to using tabindex="1" if you can’t move them.
Finally, support your users in getting to your content as quickly as they can, by implementing the Holy Grail of ‘skip to main content’ links.
viernes, 17 de agosto de 2018
Creación de formularios accesibles
Los formularios en las páginas web suelen tener graves problemas de accesibilidad. ¿Por qué? ¿Será porque es difícil? No, normalmente es porque la gente no sabe hacer bien las cosas.
En Anatomy of Creating Accessible Forms: Practice the best se ofrecen algunos consejos:
En Anatomy of Creating Accessible Forms: Practice the best se ofrecen algunos consejos:
In today’s post we will go through all the ingredients of creating an accessible form that provides the best user experience for all the users. We will go through each aspect of creating an accessible form & understand why a particular step is important & how it affects people with disabilities or users in general.
miércoles, 15 de agosto de 2018
WebAIM's WCAG 2 Checklist
WebAIM ha actualizado su WCAG 2 Checklist para que incluya las novedades de WCAG 2.1. La lista de verificación de WebAIM explica de una forma más sencilla los criterios de WCAG.
lunes, 13 de agosto de 2018
Herramientas gratuitas para convertir voz en texto
Hace unos días, el periódico El País publicó Cuatro herramientas gratuitas para convertir voz en texto:
Cada vez es menos habitual usar el teclado del móvil. Basta con echar un vistazo alrededor para comprobar el auge de las notas de voz frente a los mensajes de texto o las nuevas formas de preguntar a Google desde estos dispositivos. En concreto, comsCore vaticina que en 2020 la mitad de las búsquedas en Internet se harán con la voz, algo para lo que contaremos con la ayuda de asistentes personales como Siri, Sherpa, Google Now, Amazon Echo o Cortana.
Bastará con dar una orden con la voz para obtener al instante lo que queremos, sin tener que escribir esa petición. Ahora bien, de momento estos asistentes pueden quedarse cortos si necesitamos dictarles textos para ser más rápidos a la hora de redactar largos emails, preparar discursos o ponencias o incluso transcribir automáticamente mensajes de voz (por ejemplo, la grabación de una charla que queremos tener por escrito). Para este tipo de casos, existen aplicaciones web gratuitas, basadas en tecnología de Google, que es posible utilizar sin tener que instalarlas y que además cumplen con su cometido: transformar voz en texto de forma automática.
Eso sí, conviene repasar el texto final para pulirlo o corregir posibles errores, porque aunque estas herramientas cada vez están más afinadas y también se presentan como “asistentes personales”, al fin y al cabo siguen siendo máquinas. Además, al estar basadas en Google, sólo funcionan correctamente si utilizamos el navegador de esta compañía, es decir, Chrome.Las herramientas son:
viernes, 10 de agosto de 2018
Algunas herramientas de evaluación automática de la accesibilidad web
En Web Accessibility Evaluation Tools List hay un listado actualizado de las herramientas automáticas de evaluación de la accesibilidad web. Algunas herramientas que acabo de descubrir son:
- AccessMonitor
- European Internet Inclusion Initiative del proyecto Tingtun.
- Vamolà
miércoles, 8 de agosto de 2018
Orbit Reader 20, anotador braille de bajo costo
En Orbit Reader 20, ya está disponible el esperado y asequible anotador con teclado estilo Perkins y línea Braille patrocinado por la TBG se explica:
Os presentamos un revolucionario, asequible y portátil anotador Braille con teclado estilo Perkins y una línea Braille de 20 celdas dinámicas que se ha desarrollado gracias a la unión de la TBG (Transforming Braille Group) y Orbit Research. Un dispositivo que levantó muchas expectativas cuando se presentó hace algo más de dos años, pero que hasta este verano del 2018 no se ha empezado a comercializar a un precio realmente interesante, 449$. En efecto. Habéis leído bien. Orbit Reader 20 se ha desarrollado con el objetivo de conseguir un producto económico, compacto y sencillo, pero con una funcionalidad y conectividad más que satisfactorias que permitan acceder a la educación y a la información a todas aquellas personas que no se pueden permitir el alto coste de las líneas Braille tradicionales.La página oficial del anotador es Orbit Reader 20.
lunes, 6 de agosto de 2018
El tamaño de los controles y los enlaces
En Web Content Accessibility Guidelines (WCAG) 2.1 podemos leer:
Success Criterion 2.5.5 Target Size
(Level AAA)
The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:
Success Criterion 2.5.5 Target Size
(Level AAA)
The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:
- Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
- Inline: The target is in a sentence or block of text;
- User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
- Essential: A particular presentation of the target is essential to the information being conveyed.
Este criterio ayuda a los usuarios con discapacidad motora que carezcan de un buen control, que necesitan un área de interacción con suficiente tamaño en los enlaces y los controles de los formularios.
Un área de interacción de tamaño adecuado también puede ser útil para quienes utilizan pantallas pequeñas o de alta resolución. WCAG 2.1 sugiere que el área sea de un mínimo de 44 x 44 píxeles para los elementos interactivos.
viernes, 3 de agosto de 2018
Principios de diseño inclusivo
Inclusive Design Principles presenta unos principios a tener en cuenta cuando se quiera hacer un diseño inclusivo:
- Provide comparable experience
- Consider situation
- Be consistent
- Give control
- Offer choice
- Prioritise content
- Add value
Todos estos principios se pueden resumir en "poner a las personas lo primero":
These Inclusive Design Principles are about putting people first. It's about designing for the needs of people with permanent, temporary, situational, or changing disabilities — all of us really.
lunes, 30 de julio de 2018
Adiós a las abreviaturas y acrónimos en los sitios web oficiales del Reino Unido
Hace unos días se publicó la noticia Goodbye, etc: why the UK government will stop using Latin abbreviations online:
RIP eg, ie and etc. Henceforth the three abbreviated Latin phrases – which stand for exempli gratia (for the sake of example), id est (that is) and et cetera (and the rest) – will stop being used on Britain’s .gov.uk websites. Eventually they will be replaced in toto by English alternatives such as such as, that is, and so on and so on.En WCAG 2.1, el criterio de éxito 3.1.4 Abbreviations está dedicado a este problema:
(Level AAA)
A mechanism for identifying the expanded form or meaning of abbreviations is available.
viernes, 27 de julio de 2018
inSuit, competencia de Inclusite
A través de la noticia El Ayuntamiento de Alcalá de Henares instala en su web una herramienta de accesibilidad me he enterado de la existencia de inSuit, un producto similar a Inclusite:
La mejora de la navegación con la herramienta Insuit está destinada a personas con disminución o falta de visión, dificultad o falta de movilidad en manos y brazos, incluso cuando están combinadas con dificultades para el habla o discapacidad cognitiva/intelectual. También se ha hecho más sencilla la navegación para personas mayores con dificultades para la lectura o con pocas capacidades digitales.
Para la concejala de Transparencia, Brianda Yáñez, "es una prioridad la accesibilidad universal a los servicios municipales, un condicionante para garantizar los derechos de todas las personas sea cual sea su situación. Las herramientas digitales se están implantando a gran velocidad pero deben ser accesibles para no generar más barreras sino todo lo contrario, debemos lograr que sean facilitadoras".
La puesta en funcionamiento de esta nueva herramienta facilitará además la navegación de todas las personas usuarias de la web, que podrán establecer algunas preferencias a la hora de consultar los contenidos.
El usuario de la página sólo tiene que utilizar el enlace o pestaña habilitada en la página web para la activación de inSuit y tiene acceso instantáneo al conjunto de herramientas para la navegación, con un intuitivo sistema de configuración, una sencilla barra que permite adaptar las ayudas a sus necesidades y preferencias.
[Actualización 29/11/2018]
El Ayuntamiento de Elche también lo tiene instalado:
miércoles, 25 de julio de 2018
Deja de usar PDF en las páginas web
Por fin alguien dice algo que llevaba tiempo queriendo leer: deja de usar PDF en las páginas web.
En los últimos años, el uso y abuso de PDF para publicar contenido en los sitios web es impresionante. Y es un error, porque una cosas es un PDF y otra una página web. Me recuerda a la "epidemia" que se vivió en la primera década del siglo XXI cuando lo "cool" era usar Flash para crear sitios web, o mejor dicho, falsos sitios web.
En Why GOV.UK content should be published in HTML and not PDF se proporcionan varias razones para dejar de usar PDF en los sitios web:
Y si PDF es tan malo ¿por qué se usa tanto? Algunas razones son:
En los últimos años, el uso y abuso de PDF para publicar contenido en los sitios web es impresionante. Y es un error, porque una cosas es un PDF y otra una página web. Me recuerda a la "epidemia" que se vivió en la primera década del siglo XXI cuando lo "cool" era usar Flash para crear sitios web, o mejor dicho, falsos sitios web.
En Why GOV.UK content should be published in HTML and not PDF se proporcionan varias razones para dejar de usar PDF en los sitios web:
- They do not change size to fit the browser
- They’re not designed for reading on screens
- It’s harder to track their use
- They cause difficulties for navigation and orientation
- They can be hard for some users to access
- They’re less likely to be kept up to date
- They’re hard to reuse
Y si PDF es tan malo ¿por qué se usa tanto? Algunas razones son:
- They’re quick and easy to create
- Control over the design
- They’re easy for people to download and print
- They have the feel of a stand-alone product
lunes, 23 de julio de 2018
Curso "Start Building Accessible Web Applications Today"
Start Building Accessible Web Applications Today es un excelente curso sobre accesibilidad web:
- Accessible Icon Buttons
- Accessible Button Events
- Building Forms with Accessibility in Mind
- Headings and semantic structure for accessible web pages
- Focus management using CSS, HTML, and JavaScript
- What is the Accessibility Tree?
- Intro to ARIA
- How Visible vs. Hidden Elements Affect Keyboard/Screen Reader Users
- Using the Voiceover screen reader to test for accessibility
- Testing for Accessibility with the NVDA Screen Reader on Windows
- Creating visual skip links in HTML and CSS
- Accessible modal dialogs
- Using the tabindex attribute for keyboard accessibility
- Basic accessibility testing
- Accessibility testing with axe-cli
miércoles, 18 de julio de 2018
Formulario de acceso con captcha, ¿para qué?
El usuario @begoodness de Twitter me ha avisado del siguiente error.
La página web Te damos la bienvenida al Área Personal del Demandante (el título de la página ya es malo) presenta un formulario de acceso con usuario y contraseña que además añade un captcha:
Esto supone un grave problema de accesibilidad.
¿Para qué el captcha si tienes usuario y contraseña?
Seguramente lo han puesto para evitar ataques masivos. Pero en ese caso hay formas más inteligentes y menos perniciosas para el usuario: controlar la dirección IP, controlar el número de accesos en un período de tiempo, etc.
La página web Te damos la bienvenida al Área Personal del Demandante (el título de la página ya es malo) presenta un formulario de acceso con usuario y contraseña que además añade un captcha:
Esto supone un grave problema de accesibilidad.
¿Para qué el captcha si tienes usuario y contraseña?
Seguramente lo han puesto para evitar ataques masivos. Pero en ese caso hay formas más inteligentes y menos perniciosas para el usuario: controlar la dirección IP, controlar el número de accesos en un período de tiempo, etc.
lunes, 16 de julio de 2018
Ejemplos de textos alternativos de risa en el periódico El País
Estos ejemplos son de risa, si digo que son una mierda seguro que alguien se queja por usar un lenguaje inapropiado.
El primer ejemplo entra dentro de lo esperable, es un error típico: una imagen que es un enlace y tiene como texto alternativo el mismo texto que el enlace textual asociado a la fotografía. Resultado: el lector de pantalla leerá dos veces el mismo texto; molestia, confusión, desorientación para el usuario. Pero además, como no se ha modificado el color del texto, el texto alternativo es muy difícil de leer. Doble error.
El segundo error no entra dentro de lo esperable y nunca había visto algo así: ¿qué es ese texto alternativo en inglés cuando el periódico está en español? Una posible explicación es fácil de entender (el texto alternativo lo han tomado de la descripción de la fotografía que han tomado de un banco de imágenes o de un boletín de una agencia de noticias), pero no es perdonable. Al revés, es completamente condenable.
El primer ejemplo entra dentro de lo esperable, es un error típico: una imagen que es un enlace y tiene como texto alternativo el mismo texto que el enlace textual asociado a la fotografía. Resultado: el lector de pantalla leerá dos veces el mismo texto; molestia, confusión, desorientación para el usuario. Pero además, como no se ha modificado el color del texto, el texto alternativo es muy difícil de leer. Doble error.
El segundo error no entra dentro de lo esperable y nunca había visto algo así: ¿qué es ese texto alternativo en inglés cuando el periódico está en español? Una posible explicación es fácil de entender (el texto alternativo lo han tomado de la descripción de la fotografía que han tomado de un banco de imágenes o de un boletín de una agencia de noticias), pero no es perdonable. Al revés, es completamente condenable.
viernes, 13 de julio de 2018
Cómo joder a la gente con el placeholder
En Don’t Use The Placeholder Attribute el resumen es claro y rotundo:
The placeholder attribute contains a surprising amount of issues that prevent it from delivering on what it promises. Let’s clarify why you need to stop using it.
Pues eso, DEJA DE USAR EL PLACEHOLDER, DEJA DE JODER A LA GENTE, o mejor dicho, DEJA DE USARLO MAL.
Esto ya lo he comentado varias veces en este blog:
* El formulario de registro de Facebook con un abuso de del uso de placeholder:
* Tienes que introducir tu fecha de nacimiento, pero ¿el formato era MM/DD/YY, MM/DD/YYYY, DD/MM/YY o DD/MM/YYYY? ¿No te acuerdas? Pues te jodes, así de sencillo:
* Tiene que introducir una contraseña que debe cumplir una serie de requisitos. ¿Empiezas a escribir la contraseña y no te acuerdas de los requisitos? Pues ya sabes, te jodes una vez más:
* ¿No sabes dónde puedes encontrar el código YAMA? Pues te rejodes:
The placeholder attribute contains a surprising amount of issues that prevent it from delivering on what it promises. Let’s clarify why you need to stop using it.
Pues eso, DEJA DE USAR EL PLACEHOLDER, DEJA DE JODER A LA GENTE, o mejor dicho, DEJA DE USARLO MAL.
Esto ya lo he comentado varias veces en este blog:
- Ejemplo de que usar el placeholder es una mala idea
- Diez razones por las que los placeholders son problemáticos
Y aquí, unos ejemplos que aparecen en el artículo Don’t Use The Placeholder Attribute:
* Tienes que introducir tu fecha de nacimiento, pero ¿el formato era MM/DD/YY, MM/DD/YYYY, DD/MM/YY o DD/MM/YYYY? ¿No te acuerdas? Pues te jodes, así de sencillo:
* Tiene que introducir una contraseña que debe cumplir una serie de requisitos. ¿Empiezas a escribir la contraseña y no te acuerdas de los requisitos? Pues ya sabes, te jodes una vez más:
* ¿No sabes dónde puedes encontrar el código YAMA? Pues te rejodes:
miércoles, 11 de julio de 2018
Problema de accesibilidad para las personas que usan el control por voz
Olga Carreras ha publicado el artículo WCAG 2.1 Comprende el criterio "2.5.3 Etiqueta en el nombre" en el que comenta un nuevo criterio de WCAG 2.1:
En este vídeo explico algunos de los problemas que pretende evitar el nuevo criterio "2.5.3 Etiqueta en el nombre (A)" de las WCAG 2.1, el cual dice así: "Para los componentes de la interfaz de usuario con etiquetas que incluyen texto o imágenes de texto, el nombre accesible contiene el texto que se presenta visualmente".Además ha hecho un vídeo para explicar la importancia de este criterio:
lunes, 9 de julio de 2018
Expediente sancionador contra Endesa
Hace unos días se publicó la noticia Endesa, multada con 30.000 euros por "incumplir" en la web requisitos de accesibilidad para discapacitados:
La Secretaría de Estado de Servicios Sociales, dependiente del Ministerio de Sanidad, Servicios Sociales y Bienestar Social, ha resuelto sancionar con una multa de 30.001 euros a la compañía Endesa por "incumplimiento" de los requisitos mínimos de accesibilidad para personas con discapacidad en su web de atención al cliente.
[...]
Esta resolución es consecuencia de una denuncia formulada en abril de 2017 por el Comité de Representantes de Personas con Discapacidad (CERMI) contra Endesa por "no reunir" en su portal 'www.endesaclientes.com' "los requisitos legales de accesibilidad a los que obliga la Ley de Servicios de la Sociedad de la Información y de Comercio Electrónico".Y ojo a la aclaración que se hace:
Por otro lado, el CERMI también denunciaba deficiencias en la accesibilidad de la web 'www.endesa.com' pero la Secretaría de Estado ha comunicado el archivo de actuaciones ya que, según los informes recabados, al no tratarse esta de una página web destinada a la comercialización del suministro de energía eléctrica, no estaría sometida a las obligaciones de cumplimiento de las condiciones de accesibilidad para las personas con discapacidad.En la web del CERMI podemos leer alguna cosa más en la noticia Sanidad sanciona a Endesa con 30.000 euros de multa por la inaccesibilidad de su página de internet de atención al cliente:
La sanción, contra la que cabe recurso ante la Audiencia Nacional, responde a la comisión de una infracción grave de las establecidas en la Ley General de Derechos de las Personas con Discapacidad y de su Inclusión Social. De esta forma, Sanidad concluye que la web de atención al cliente de Endesa no cumple los requisitos legales de accesibilidad a los que obliga la Ley 34/2002, de 11 de julio, de Servicios de Sociedad de la Información y de Comercio Electrónico, por lo que incurre en una infracción administrativa considerada grave.Hasta donde yo sé, esta es la tercera sanción por falta de accesibilidad web que se impone en España, las otras fueron contra Iberia y Vueling:
[...]
El CERMI recuerda que todas las páginas de internet públicas, así como las de las empresas que según la Ley prestan servicios de especial trascendencia económica, han de ser accesibles para personas con discapacidad y mayores, de acuerdo con los criterios de accesibilidad a la web generalmente admitidos, constituyendo infracción administrativa por discriminación los incumplimientos de este deber.
- Confirmada la primera sanción por falta de accesibilidad web en España (2/8/2015)
- Expediente sancionador contra Vueling (29/7/2016)
¿Cuál será la próxima empresa? Sería bueno que fuese un banco.
viernes, 6 de julio de 2018
Cómo ayuda la tecnología a una persona ciega
En el siguiente vídeo, una persona ciega comenta algunas situaciones en las que la tecnología le es de una gran ayuda en su vida diaria:
Christine Hà - Stories from the Digital Divide from Siteimprove Inc on Vimeo.
Christine Hà - Stories from the Digital Divide from Siteimprove Inc on Vimeo.
miércoles, 4 de julio de 2018
Voice Dictation
Voice Dictation es un sistema que permite mostrar transcripción de lo que se dice, por ejemplo en una conferencia, en tiempo real. El sistema usa el motor de Google Speech Recognition para transcribir más de 100 idiomas.
Este sistema es similar a Web Captioner que comenté hace un par de meses.
Este sistema es similar a Web Captioner que comenté hace un par de meses.
lunes, 2 de julio de 2018
Cómo funciona un lector de pantalla
Muy interesante el artículo A Tale of Two Rooms: Understanding screen reader navigation, que explica mediante analogías el funcionamiento de un lector de pantalla:
One of the best ways to better understand the screen reader user experience is to try it yourself. It is certainly advantageous to try using screen reading software on your own to navigate web page content. In addition though, here is a simple exercise you can do to simulate the scenarios illustrated above. (I don’t recommend finding random conference rooms with people in them and turning out all the lights!)
- Print out a paper copy of a web page. I recommend one that is not too large but contains a variety of elements such as text, links, menus, etc.
- Find a blank sheet of paper and make a small hole in the center of it. The hole should be about the size of 2 or 3 words (around a half inch in diameter is usually sufficient).
It will probably be very difficult and time consuming to understand what is on the page but this gives you a general idea of what it is like for a screen reader user (especially if no page navigation techniques are used).
- Place the paper with the hole in it over the printout of the web page and try making sense of what is there. Slide the paper with the hole in it around in order to read the contents of the web page print out below.
viernes, 29 de junio de 2018
Más sobre WCAG 2.1
A raíz de la reciente publicación de WCAG 2.1, los diferentes expertos sobre accesibilidad web publican su análisis de las nuevas pautas. Algunos de los más interesantes que he encontrado son:
jueves, 28 de junio de 2018
Curso "Creación de ePubs interactivos y accesibles: mini-libros electrónicos modulares"
El curso Creación de ePubs interactivos y accesibles: mini-libros electrónicos modulares organizado por la Fundación UNED se impartirá del 9 al 13 de julio de 2018. Los objetivos del curso:
- Reflexionar sobre la importancia del soporte digital en la docencia.
- Conocer las características de los ePubs interactivos y accesibles.
- Familiarizarse con conceptos básicos de XHTML, CSS y JavaScript.
- Entender la importancia de los mini-libros electrónicos modulares (MEM).
- Construir un MEM en formato ePub interactivo y accesible.
miércoles, 27 de junio de 2018
La accesibilidad de SPA
Las single-page applications (SPA) están de moda desde hace un par de años, y como casi siempre que aparece una moda, el buen uso al abuso hay un pequeño paso. Ahora todo tiene que ser SPA, y si no usas SPA eres un inculto.
Desgraciadamente, SPA presenta numerosos problemas de accesibilidad. En esta página web (se le olvidó poner título al autor) se dan algunos consejos para que SPA sea más accesible:
Desgraciadamente, SPA presenta numerosos problemas de accesibilidad. En esta página web (se le olvidó poner título al autor) se dan algunos consejos para que SPA sea más accesible:
For dynamic screen changes in an SPA, I highly recommend setting focus to the region with new content, preferably to a top-level heading within the new content. An ARIA live region will read new content to a screen reader user but the keyboard focus will remain in a illogical location on the screen, and very often focus will be lost entirely since content is removed. Reading out all the new content may also be overwhelming for the user.
Also, when a screen changes in an SPA, the page title should be updated. A screen reader user will not be notified of this change which is why focusing a new top level heading for new content is important.
lunes, 25 de junio de 2018
Cómo los usuarios utilizan un lector de pantallas
Muy interesante e importante el artículo Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers. Se trata de una versión extendida del artículo Bridging the gap: between accessibility and usability publicado en la revista Interactions en el año 2003. Aunque ya tenga sus años, hay muchas cosas que no han cambiado.
viernes, 22 de junio de 2018
miércoles, 20 de junio de 2018
La primera regla de ARIA
La primera regla de ARIA es bien sencilla: no uses ARIA.
Lo podemos leer en 2.1 First rule of ARIA use:
Lo podemos leer en 2.1 First rule of ARIA use:
If you can use a native HTML element [HTML51] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
lunes, 18 de junio de 2018
Vídeos del W3C
Web Accessibility Perspectives: Explore the Impact and Benefits for Everyone es una página web del W3C con numerosos vídeos sobre discapacidad y accesibilidad.
Algunos ejemplos:
Algunos ejemplos:
viernes, 15 de junio de 2018
En Noruega todos los sitios web deben ser accesibles
Según It’s illegal to have an inaccessible website in Norway — and that’s good news for all of us, todos los sitios web en Noruega deben ser accesibles:
Está explicado en inglés en Universal design of ICT:
The requirements are relevant for private businesses, organisations, and government agencies. They are applicable to websites and self-service machines. The use of social media, such as blogs, Facebook and Twitter, for non-commercial purposes are not covered by the regulations.
The regulations were approved 21 June 2013 and took effect 1 July 2013. This means that new ICT solutions should be universally designed from 1 July 2014. Existing ICT solutions should be universally designed from 2021.
The Web Content Accessibility Guidelines (WCAG) 2.0 level AA is the standard for the universal design of websites. There are some exceptions regarding time-based media: 1.2.3 Audio Description or Media Alternative (Prerecorded content), 1.2.4 Captions (Live content) and 1.2.5 Audio Description (Prerecorded content).
Está explicado en inglés en Universal design of ICT:
The requirements are relevant for private businesses, organisations, and government agencies. They are applicable to websites and self-service machines. The use of social media, such as blogs, Facebook and Twitter, for non-commercial purposes are not covered by the regulations.
The regulations were approved 21 June 2013 and took effect 1 July 2013. This means that new ICT solutions should be universally designed from 1 July 2014. Existing ICT solutions should be universally designed from 2021.
The Web Content Accessibility Guidelines (WCAG) 2.0 level AA is the standard for the universal design of websites. There are some exceptions regarding time-based media: 1.2.3 Audio Description or Media Alternative (Prerecorded content), 1.2.4 Captions (Live content) and 1.2.5 Audio Description (Prerecorded content).
miércoles, 13 de junio de 2018
Lo que dice Orange sobre los captchas
En el sitio web de Orange sobre accesibilidad web, existe la página CAPTCHA Accessibility:
Y propone como alternativas:
CAPTCHAs are often problematic, even for savvy users. It is often necessary to undergo several trials before giving the right answer to a CAPTCHA. For some users a CAPTCHA is a no-go, plain and simple. For example a blind user cannot solve a visual CAPTCHA. Even if some sites provide alternatives, like audio CAPTCHAs in addition to visual CAPTCHAs, it actually seldom works. It’s even the first source of difficulty quoted by visually impaired users according to WebAIM’s latest survey at the end of 2017.La conclusión es que no hay que usar captchas, son un grave problema de accesibilidad.
Y propone como alternativas:
- HoneyPot and Time measuring, two simple techniques to put in place to identify bots.
- Anti-spam and blacklist solutions to remove bot requests.
- A logical or mathematical test, also called textual CAPTCHA.
- An email, SMS or phone verification for reinforced security.
lunes, 11 de junio de 2018
Orange web accessibility guidelines
La compañía Orange tiene el sitio web Orange web accessibility guidelines con información sobre accesibilidad web.
martes, 5 de junio de 2018
Publicado WCAG 2.1
Ha tardado, WCAG 2.0 era de diciembre de 2008, han pasado 10 años, pero ya hay una nueva versión de las pautas de accesibilidad web que se pueden considerar el estándar internacional de accesibilidad web: Web Content Accessibility Guidelines (WCAG) 2.1.
En el blog del W3C tenemos el anuncio de la publicación de WCAG 2.1: WCAG 2.1 IS A W3C RECOMMENDATION.
¿Cuáles son las principales novedades?
¿Qué pasará con WCAG 2.0?
¿Y qué versión deberíamos usar?
¿Y cuál es el futuro a corto plazo de WCAG?
¿Y cuál es el futuro a largo plazo de WCAG?
¿Y qué pasará en España y otros países?
Para eso el W3C no tiene respuesta. El W3C anima a usar la nueva versión, pero las leyes indican que se debe cumplir WCAG 2.0. Incluso, todavía puede quedar algún país con leyes que hagan referencia a WCAG 1.0.
No obstante, como indica el W3C, WCAG 2.1 se ha desarrollado para que sea compatible hacia atrás y se conservan todos los criterios de conformidad de WCAG 2.0. Por tanto, si se desarrolla un sitio web que cumpla WCAG 2.1 también se estará cumpliendo WCAG 2.0.
En el blog del W3C tenemos el anuncio de la publicación de WCAG 2.1: WCAG 2.1 IS A W3C RECOMMENDATION.
Web Content Accessibility Guidelines (WCAG) 2.1 is now a W3C Recommendation. This is an evolution of W3C’s accessibility guidance, including expansion of mobile, low vision, and cognitive and learning provisions. It maintains W3C’s accessibility guidance, while maintaining W3C’s standard of implementable, technology neutral, objectively testable and universally applicable accessibility guidance.
¿Cuáles son las principales novedades?
For users of mobile devices, WCAG 2.1 provides updated guidance including support for user interactions using touch, handling more complex gestures, and for avoiding unintended activation of an interface. For users with low vision, WCAG 2.1 extends contrast requirements to graphics, and introduces new requirements for text and layout customization to support better visual perception of web content and controls. For users with cognitive, language, and learning disabilities, WCAG 2.1 improvements include a requirement to provide information about the specific purpose of input controls, as well as additional requirements to support timeouts due to inactivity. This can help many users better understand web content and how to successfully interact with it.
¿Qué pasará con WCAG 2.0?
WCAG 2.0 remains a W3C Recommendation. It was designed to be a highly stable, technology-agnostic standard, with informative supporting resources. The Working Group has taken care to maintain backwards compatibility of WCAG 2.1 with WCAG 2.0. All the criteria from WCAG 2.0 are included in WCAG 2.1, so web sites that conform to WCAG 2.1 will also conform to WCAG 2.0. As with WCAG 2.0, WCAG 2.1 will be supported by an extensive library of implementation techniques and educational materials, including Understanding WCAG 2.1 and Techniques for WCAG 2.1.
¿Y qué versión deberíamos usar?
W3C encourages organizations and individuals to use WCAG 2.1 in web content and applications, and to consider WCAG 2.1 when updating or developing new policies, in order to better address the needs of more web and mobile users with disabilities.
¿Y cuál es el futuro a corto plazo de WCAG?
WCAG 2.1 provides important and timely guidance but is still only a step—the Working Group expects to develop another dot-release, WCAG 2.2, to expand the new coverage even further. WCAG 2.2 may be developed under a similar timeline and requirements set than WCAG 2.1 was, though we plan to refine the process to address process challenges experienced during the development of WCAG 2.1.
¿Y cuál es el futuro a largo plazo de WCAG?
In addition to a further dot-release of WCAG 2, the Accessibility Guidelines Working Group has been working in parallel on a more major revision to accessibility guidelines, which would not have the same structure as WCAG 2. Beyond web content, these new guidelines are intended to incorporate guidance for user agents and other tools so requirements that depend on tool support are more clear for authors, and address issues of conformance and testability in a different way from WCAG 2. This is a major multi-year project, which is the reason additional updates to WCAG 2 are needed in the meantime.
¿Y qué pasará en España y otros países?
Para eso el W3C no tiene respuesta. El W3C anima a usar la nueva versión, pero las leyes indican que se debe cumplir WCAG 2.0. Incluso, todavía puede quedar algún país con leyes que hagan referencia a WCAG 1.0.
No obstante, como indica el W3C, WCAG 2.1 se ha desarrollado para que sea compatible hacia atrás y se conservan todos los criterios de conformidad de WCAG 2.0. Por tanto, si se desarrolla un sitio web que cumpla WCAG 2.1 también se estará cumpliendo WCAG 2.0.
lunes, 4 de junio de 2018
Consentimiento informado
Según la Wikipedia, el consentimiento informado "es el procedimiento mediante el cual se garantiza que el sujeto ha expresado voluntariamente su intención de participar en la investigación, después de haber comprendido la información que se le ha dado, acerca de los objetivos del estudio, los beneficios, las molestias, los posibles riesgos y las alternativas, sus derechos y responsabilidades".
Cuando se realiza una prueba de usabilidad o accesibilidad con usuarios se debe solicitar a los participantes que firmen un consentimiento informado. Un par de ejemplos de este documento:
Cuando se realiza una prueba de usabilidad o accesibilidad con usuarios se debe solicitar a los participantes que firmen un consentimiento informado. Un par de ejemplos de este documento:
viernes, 1 de junio de 2018
El scroll infinito es malo para la accesibilidad
¿Te gusta esto?
El famoso scroll infinito que se puso de moda hace unos pocos años y que sigue de moda.
¿Útil? A veces.
¿Usable? Pocas veces.
¿Accesible? Casi nunca. En los siguientes artículos te lo explican:
El famoso scroll infinito que se puso de moda hace unos pocos años y que sigue de moda.
¿Útil? A veces.
¿Usable? Pocas veces.
¿Accesible? Casi nunca. En los siguientes artículos te lo explican:
miércoles, 30 de mayo de 2018
Pequeñas cosas que pueden mejorar la accesibilidad de un sitio web
En Small Tweaks That Can Make a Huge Impact on Your Website’s Accessibility explican pequeños cambios que pueden mejorar enormemente la accesibilidad de una página web:
- Document Structure and Semantics
- Get Your Color Contrast Right
- Responsible Text Labels
- Small Typography Tweaks With a Big Impact
- Enhance Keyboard Support
- Don't Rely on Color Alone to Communicate State Changes
- Wrapping Up
lunes, 28 de mayo de 2018
Algunos comentarios sobre el daltonismo
Muy interesante todo lo que se cuenta en What my color-blindness taught me about design:
I can tell the difference between green and red most of the time depending on what light I’m under, but I’m pretty sure it’s not the same green and red other people see. The color blindness is typically inherited. After I was diagnosed, my grandpa and uncle from my mom’s side were also diagnosed color blindness (they always were but they didn’t notice). Also, there is no cure for color blindness. This means that I will have to adapt.
In fact, 8% of all men and 0.5% of all women suffer from color blindness. Although 99% of color blind people suffer from red-green color blindness, they don’t agree on the same colors. For example, I suffer from Deuteranomaly, and it is hard for me to tell violet from blue or yellow from light green; others who suffer from Protanomaly may see red, orange, yellow appear greener.
viernes, 25 de mayo de 2018
miércoles, 23 de mayo de 2018
lunes, 21 de mayo de 2018
jueves, 17 de mayo de 2018
Global Accessibility Awareness Day
Hoy se celebra el Global Accessibility Awareness Day:
El 17 de mayo, le invitamos a participar en el Día Mundial para Promover la Concienciación sobre la Accesibilidad Web, conocido en inglés como Global Accessibility Awareness Day (GAAD). Cuando hablamos de la accesibilidad Web nos referimos a el contenido, la navegación y la interacción. El propósito de este día es para hablar, pensar y aprender sobre la accesibilidad de las tecnologías digitales (web, software, dispositivos móviles, etc.) y los diferente tipos de usuarios, incluyendo las personas con discapacidades. La audiencia que queremos atraer para GAAD son las comunidades de diseño, desarrollo, usabilidad y también los que crean, dan forma, apoyan financieramente e influencian la industria de tecnología y su uso. Aunque una persona este interesada en el tema de hacer la tecnología mas accesible y usable para las personas con discapacidades, la realidad es que muchas veces no saben como y donde comenzar. El conomocimento sobra la accesibilidad Web es el primer paso.
miércoles, 16 de mayo de 2018
Cómo escribir sobre las personas mayores según APA
Publication Manual of the American Psychological Association, Sixth Edition, 2010:
3.16 Age
Age should be reported as part of the description of participants in the Method section. Be specific in providing age ranges; avoid open-ended definitions such as "under 18 years" or "over 65 years." Girl and boy are correct terms for referring to individuals under the age of 12 years. Young man and young woman and female adolescent and male adolescent may be used for individuals aged 13 to 17 years. For persons 18 years and older, use women and men. The terms elderly and senior are not acceptable as nouns; some may consider their use as adjectives pejorative. Generational descriptors such as boomer or baby boomer should not be used unless they are related to a study on this topic. The term older adults is preferred. Age groups may also be described with adjectives. Gerontologists may prefer to use combination terms for older age groups (youngold, old-old, very old, oldest old, and centenarians); provide the specific ages of these groups and use them only as adjectives. Use dementia instead of senility; specify the type of dementia when known (e.g., dementia of the Alzheimer's type). For more references relating to age, see Guidelines for the Evaluation of Dementia and Age-Related Cognitive Decline (APA Presidential Task Force on the Assessment of Age-Consistent Memory Decline and Dementia, 1998) and "Guidelines for Psychological Practice With Older Adults" (APA, 2004; see also www.apastyle.org).
3.16 Age
Age should be reported as part of the description of participants in the Method section. Be specific in providing age ranges; avoid open-ended definitions such as "under 18 years" or "over 65 years." Girl and boy are correct terms for referring to individuals under the age of 12 years. Young man and young woman and female adolescent and male adolescent may be used for individuals aged 13 to 17 years. For persons 18 years and older, use women and men. The terms elderly and senior are not acceptable as nouns; some may consider their use as adjectives pejorative. Generational descriptors such as boomer or baby boomer should not be used unless they are related to a study on this topic. The term older adults is preferred. Age groups may also be described with adjectives. Gerontologists may prefer to use combination terms for older age groups (youngold, old-old, very old, oldest old, and centenarians); provide the specific ages of these groups and use them only as adjectives. Use dementia instead of senility; specify the type of dementia when known (e.g., dementia of the Alzheimer's type). For more references relating to age, see Guidelines for the Evaluation of Dementia and Age-Related Cognitive Decline (APA Presidential Task Force on the Assessment of Age-Consistent Memory Decline and Dementia, 1998) and "Guidelines for Psychological Practice With Older Adults" (APA, 2004; see also www.apastyle.org).
lunes, 14 de mayo de 2018
Como escribir sobre las discapacidades según APA
Publication Manual of the American Psychological Association, Sixth Edition, 2010:
3.15 Disabilities
The overall principle for "nonhandicapping" language is to maintain the integrity (worth) of all individuals as human beings. Avoid language that objectifies a person by her or his condition (e.g., autistic, neurotic), that uses pictorial metaphors (e.g., wheelchair bound or confined to a wheelchair), that uses excessive and negative labels (e.g., AIDS victim, brain damaged), or that can be regarded as a slur (e.g., cripple, invalid). Use people-first language, and do not focus on the individual's disabling or chronic condition (e.g., person with paraplegia, youth with autism). Also use people-first language to describe groups of people with disabilities. For instance, say people with intellectual disabilities in contrast to the retarded (University of Kansas, Research and Training Center on Independent Living, 2008).
Avoid euphemisms that are condescending when describing individuals with disabilities (e.g., special, physically challenged, handi-capable). Some people with disabilities consider these terms patronizing and offensive. When writing about populations with disabilities or participants, emphasize both capabilities and concerns to avoid reducing them to a "bundle of deficiencies" (Rappaport, 1977). Do not refer to individuals with disabilities as patients or cases unless the context is within a hospital or clinical setting.
3.15 Disabilities
The overall principle for "nonhandicapping" language is to maintain the integrity (worth) of all individuals as human beings. Avoid language that objectifies a person by her or his condition (e.g., autistic, neurotic), that uses pictorial metaphors (e.g., wheelchair bound or confined to a wheelchair), that uses excessive and negative labels (e.g., AIDS victim, brain damaged), or that can be regarded as a slur (e.g., cripple, invalid). Use people-first language, and do not focus on the individual's disabling or chronic condition (e.g., person with paraplegia, youth with autism). Also use people-first language to describe groups of people with disabilities. For instance, say people with intellectual disabilities in contrast to the retarded (University of Kansas, Research and Training Center on Independent Living, 2008).
Avoid euphemisms that are condescending when describing individuals with disabilities (e.g., special, physically challenged, handi-capable). Some people with disabilities consider these terms patronizing and offensive. When writing about populations with disabilities or participants, emphasize both capabilities and concerns to avoid reducing them to a "bundle of deficiencies" (Rappaport, 1977). Do not refer to individuals with disabilities as patients or cases unless the context is within a hospital or clinical setting.
viernes, 11 de mayo de 2018
Algunos consejos sobre el uso del atributo title
Muy interesante el artículo The Trials and Tribulations of the Title Attribute.
El primer consejo es "no uses el atributo title". Pero si lo tienes que usar, o lo quieres usar aunque te digan que no lo debes usar, entonces lee este artículo para saber cómo usarlo correctamente.
El primer consejo es "no uses el atributo title". Pero si lo tienes que usar, o lo quieres usar aunque te digan que no lo debes usar, entonces lee este artículo para saber cómo usarlo correctamente.
miércoles, 9 de mayo de 2018
Global Accessibility Awareness Day el 17 de mayo
El próximo 17 de mayo se celebra el Global Accessibility Awareness Day:
El 17 de mayo, le invitamos a participar en el Día Mundial para Promover la Concienciación sobre la Accesibilidad Web, conocido en inglés como Global Accessibility Awareness Day (GAAD). Cuando hablamos de la accesibilidad Web nos referimos a el contenido, la navegación y la interacción. El propósito de este día es para hablar, pensar y aprender sobre la accesibilidad de las tecnologías digitales (web, software, dispositivos móviles, etc.) y los diferente tipos de usuarios, incluyendo las personas con discapacidades. La audiencia que queremos atraer para GAAD son las comunidades de diseño, desarrollo, usabilidad y también los que crean, dan forma, apoyan financieramente e influencian la industria de tecnología y su uso. Aunque una persona este interesada en el tema de hacer la tecnología mas accesible y usable para las personas con discapacidades, la realidad es que muchas veces no saben como y donde comenzar. El conomocimento sobra la accesibilidad Web es el primer paso.
martes, 8 de mayo de 2018
Uso de Twitter con la vista
Muy interesante el siguiente vídeo que muestra cómo se puede utilizar Twitter con la vista, creo que el sistema que emplea es Irisbond:
— Alberto Moreno (@albertopajariyo) 27 de abril de 2018
lunes, 7 de mayo de 2018
Fecha para la próxima normativa sobre accesibilidad de la Unión Europea
En EU Directive on the Accessibility of Public Sector Websites and Mobile Applications podemos leer que la directiva de la Unión Europea que obliga a los estados miembros a asegurar que sus sitios web y sus aplicaciones son accesibles se debe trasponer a la legislación de cada país hasta el 23 se septiembre de 2018:
The European Union (EU) Directive on the Accessibility of Websites and Mobile Applications requires EU member states to make sure their websites and mobile apps meet common accessibility standards. The Directive will be transposed into the laws of each EU member state by September 23 2018.
The Directive uses the four principles of the Web Content Accessibility Guidelines (WCAG) 2.0, requiring that public sector organisations across the EU take steps to make sure their websites are “Perceivable, Operable, Understandable, and Robust”.
The Directive references EN 301 549 as the standard which will enable websites and apps to comply with the law. EN 301 549 is a set of Functional Accessibility requirements broken down into chapters, and chapter 9 on Web Content cites WCAG 2.0 Level AA as the expected standard.
The W3C is close to publishing WCAG 2.1, an update to WCAG 2.0 that introduces many Success Criteria (SC) focused on mobile apps, as well as SC relating to low vision and cognitive disability. The W3C anticipates that WCAG 2.1 will be released in June 2018, and EN 301 549 could be updated to include the new SC introduced in WCAG 2.1.
Once adopted into the laws of each EU member state, the Directive sets a timetable for compliance with the new regulations:
In order to comply with the Directive, public sector organisations will need to monitor the accessibility of their websites and mobile apps, make information from the monitoring available in an accessibility statement, and provide reports to a central authority. These requirements mean that many EU public sector organisations will need to rethink their accessibility strategy in the coming months if they are to be ready when the Directive comes into effect on September 23 2018.
The European Union (EU) Directive on the Accessibility of Websites and Mobile Applications requires EU member states to make sure their websites and mobile apps meet common accessibility standards. The Directive will be transposed into the laws of each EU member state by September 23 2018.
The Directive uses the four principles of the Web Content Accessibility Guidelines (WCAG) 2.0, requiring that public sector organisations across the EU take steps to make sure their websites are “Perceivable, Operable, Understandable, and Robust”.
The Directive references EN 301 549 as the standard which will enable websites and apps to comply with the law. EN 301 549 is a set of Functional Accessibility requirements broken down into chapters, and chapter 9 on Web Content cites WCAG 2.0 Level AA as the expected standard.
The W3C is close to publishing WCAG 2.1, an update to WCAG 2.0 that introduces many Success Criteria (SC) focused on mobile apps, as well as SC relating to low vision and cognitive disability. The W3C anticipates that WCAG 2.1 will be released in June 2018, and EN 301 549 could be updated to include the new SC introduced in WCAG 2.1.
Once adopted into the laws of each EU member state, the Directive sets a timetable for compliance with the new regulations:
- New public sector websites must conform by September 23 2019
- All public sector websites by September 23 2020
- All public sector mobile apps by June 23 2021
In order to comply with the Directive, public sector organisations will need to monitor the accessibility of their websites and mobile apps, make information from the monitoring available in an accessibility statement, and provide reports to a central authority. These requirements mean that many EU public sector organisations will need to rethink their accessibility strategy in the coming months if they are to be ready when the Directive comes into effect on September 23 2018.
viernes, 4 de mayo de 2018
Estadísticas de discapacidad en Estados Unidos
No es reciente, es del año 2012, pero es la información más oficial y actualizada que existe: Nearly 1 in 5 People Have a Disability in the U.S., Census Bureau Reports. Este dato se basa en el censo realizado en EEUU en el año 2010. El censo se realiza cada 10 años, así que habrá que esperar un poco hasta el siguiente.
La nota de prensa dice:
La nota de prensa dice:
About 56.7 million people — 19 percent of the population — had a disability in 2010, according to a broad definition of disability, with more than half of them reporting the disability was severe, according to a comprehensive report on this population released today by the U.S. Census Bureau.
The report, Americans with Disabilities: 2010, presents estimates of disability status and type and is the first such report with analysis since the Census Bureau published statistics in a similar report about the 2005 population of people with disabilities. According to the report, the total number of people with a disability increased by 2.2 million over the period, but the percentage remained statistically unchanged. Both the number and percentage with a severe disability rose, however. Likewise, the number and percentage needing assistance also both increased.
[..]
The report shows that 41 percent of those age 21 to 64 with any disability were employed, compared with 79 percent of those with no disability. Along with the lower likelihood of having a job came the higher likelihood of experiencing persistent poverty; that is, continuous poverty over a 24-month period. Among people age 15 to 64 with severe disabilities, 10.8 percent experienced persistent poverty; the same was true for 4.9 percent of those with a nonsevere disability and 3.8 percent of those with no disability.
miércoles, 2 de mayo de 2018
La accesibilidad según las personas con discapacidad
En Accessibility according to actual people with disabilities se incluyen varias respuestas a la siguiente pregunta:
If you have a disability, what’s the hardest thing about browsing the web?
Las respuestas están agrupadas en:
If you have a disability, what’s the hardest thing about browsing the web?
Las respuestas están agrupadas en:
- Lack of captions.
- Motion, animations and cluttered pages.
- Wall of text.
- Small font size.
- Zooming problems.
- Low contrasts and image of text.
- Bright color schemes.
- Relying only on color.
- Mouse-focused sites.
- Too small touch-targets.
- Captchas.
lunes, 30 de abril de 2018
Accessibility acceptance criteria
Un concepto nuevo, "accessibility acceptance criteria", aunque en realidad es muy similar a otros conceptos como "checklist" o "conformance requirements": Improving accessibility with accessibility acceptance criteria.
What are accessibility acceptance criteria?
They are a list of conditions that a user interface must meet to be considered accessible. They help us raise awareness of access needs and maintain accessibility as we iterate.
Be aware that accessibility acceptance criteria alone won’t make your service accessible – read more guidance on building an accessible service.
viernes, 27 de abril de 2018
Estudio de mercado de los productos de apoyo 2018-2025
He encontrado la página Assistive Technologies for Visual Impairment Market Research on Technology 2018 to 2025 y no sé si es de verdad o es una broma.
La página dice:
“Global Assistive Technologies for Visual Impairment Market Research Report 2018” provides a unique tool for evaluating the market, highlighting opportunities, and supporting strategic and tactical decision-making. This report recognizes that in this rapidly-evolving and competitive environment, up-to-date marketing information is essential to monitor performance and make critical decisions for growth and profitability. It provides information on trends and developments, and focuses on markets and materials, capacities and technologies, and on the changing structure of the Assistive Technologies for Visual Impairment Market.
This report studies the Assistive Technologies for Visual Impairment market status and outlook of global and United States, from angles of players, regions, product types and end industries; this report analyzes the top players in global and United States market, and splits the Assistive Technologies for Visual Impairment market by product type and applications/end industries.
Inquire for sample copy at https://www.marketinsightsreports.com/reports/0130187329/global-assistive-technologies-for-visual-impairment-market-research-report-2018/inquiryPero, los ejemplos que ponen en la página están "ofuscados":
¿O es una broma?
Suscribirse a:
Entradas (Atom)