09 de marzo de 2010
Seraccesible
Seminario Iberoamericano sobre Accesibilidad Universal y ayudas técnicas para todos
Hoy día 8 y hasta el día 11 de Marzo, ha comenzado el "Seminario Iberoamericano sobre Accesibilidad Universal y ayudas técnicas para todos" organizado por el Centro de Formación de la Cooperación Española en Montevideo.
por Lucia Navarro, el 09/03/2010 14:48 CET
El sistema automático de subtÃtulos en Youtube
Dos vídeos sobre el nuevo sistema de Youtube de subtítulos automáticos:
- Google Announces Automatic Captions on Youtube: vídeo de la presentación del nuevo sistema.
- Automatic Captions in Youtube Demo: un vídeo demostración del sistema.
por Lucia Navarro, el 09/03/2010 14:47 CET
La Administración investiga la web de tres grandes empresas por falta de accesibilidad
El Ministerio de Sanidad y Política Social ha abierto actuaciones contra las páginas web de El Corte Inglés, Aguas de Barcelona y Transportes Metropolitanos de Barcelona, para comprobar el cumplimiento de la ley de accesibilidad web.
Según informó el Comité Español de Representantes de Personas con Discapacidad (Cermi), la actuación ministerial obedece a una solicitud de esta entidad, que presentó denuncia por infracción de la obligación de accesibilidad que tienen los sitios de Internet de las consideradas grandes empresas.
La no accesibilidad de una página de Internet obligada por la normativa vigente a ser accesible constituye una infracción sancionable en sede administrativa, de acuerdo con la ley que establece el régimen de infracciones y sanciones en materia de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad
recuerda el Cermi.
Vía: Solidaridad Digital
por Lucia Navarro, el 09/03/2010 14:41 CET
Accesibilidadweb.com
La Administración Central investiga la Accesibilidad Web de tres grandes empresas por posibles errores
El Ministerio de Sanidad y PolÃtica Social ha abierto actuaciones previas, paso anterior a la apertura en su caso de procedimiento sancionador, contra las páginas corporativas de Internet de El Corte Inglés, Aguas de Barcelona (Agbar) y Transportes Metropolitanos de Barcelona, para comprobar si cumplen la normativa vigente en materia de accesibilidad para personas con discapacidad.
La administración investiga la web de tres grandes empresas por falta de accesibilidad
Esta investigación es fruto del informe elaborado el año pasado sobre los sitios webs de grandes empresas españolas. Dicho informe fue puesto en conocimiento de las empresas analizadas para que realizaran las modificaciones necesarias.
Lo que más llama la atención por desgracia es lo siguiente:
Aunque muchas de estas empresas adoptaron medidas para mejorar su accesibilidad y cumplir con la normativa, otras, sin embargo, como las denunciadas, no contestaron al requerimiento “ni consta que hayan avanzado en accesibilidad de sus sitios de Internet”.
¿Cómo puede haber ocurrir ésto? Es decir, ¿llega un informe de Accesibilidad Web sobre tu página y tras leerlo no se hace absolutamente nada?
Si finalmente se produce una sanción (la multa puede oscilar entre los 30.000 y los 90.000 euros), podrÃa ser un punto de partida para que exista una mayor concienciación sobre la Accesibilidad de la información en nuestras páginas.
Hasta el dÃa de hoy y que se haya hecho público, se han hecho denuncias ante el Ministerio de las siguientes páginas:
- Metro de Madrid
- Universidad Autónoma de Madrid
- El Corte Inglés
- Transportes Metropolitanos de Barcelona
- Aguas de Barcelona
por Félix Zapata, el 09/03/2010 08:05 CET
05 de marzo de 2010
Adobe Accessibility
Accessible Flash Presentation How-to
Since Thea Eaton from DoodleDoo created the online tutorial on authoring accessible Flash we've heard a lot of positive comments and many questions about the techniques she used.
Thea wrote up an article on the techniques she used for the Adobe Developer Connection Flash site. Please check it out.
04 de marzo de 2010
Seraccesible
Fundación Vodafone y Caja Canarias enseñan a utilizar el móvil a personas mayores
La Fundación Vodafone España y La Caja Insular de Canarias han suscrito un acuerdo para desarrollar el “Programa de formación en el uso de la telefonía móvil por las personas mayores” en las islas de Gran Canaria, Lanzarote y Fuerteventura.
El acuerdo establece la formación de 600 mayores en 30 cursos, cuyo objetivo es fomentar la accesibilidad por parte de este colectivo al teléfono móvil y que pueda hacer un uso óptimo del mismo. Las sesiones de formación se llevarán a cabo por personal voluntario de Cruz Roja en los centros de mayores donde La Caja desarrolla su proyecto "La Caja Activa".
Vía: adslnet.es
por Lucia Navarro, el 04/03/2010 20:35 CET
WebAIM
WebAIMâs 2010 CSUN Lineup
The folks here at WebAIM are pleased to be attending The 25th Annual International Technology & Persons with Disabilities Conference, more commonly known as the CSUN conference. This conference is one of the highlights of our year. We love interacting with and being educated and invigorated by so many people that are passionate about accessibility.
We’ll be presenting the following sessions:
- Accessibility of Rich Internet Applications (pre-conference workshop)
- Insights Into Cognitive Web Accessibility
- The Myth of the Typical Screen Reader User
- Institutional Self-Study of Web Accessibility: Continuous Improvement for Our Nation’s Campuses
- A Beginner’s Introduction to WAVE
- Web Accessibility Preferences are for Sissies… and Other Universal Web Accessibility Concepts
- WAVE as Part of a Group-Wide Web Accessibility Plan
If you’re interested in attending, be sure to reserve your seat now.
WebAIM, in conjunction with several other fine organizations, is also sponsoring a CSUN Tweetup. We hope to see you there.
And for those attending SXSW Interactive, I’ll be presenting on Monday a session titled Web Accessibility Gone Wild.
por Jared Smith, el 04/03/2010 19:30 CET
02 de marzo de 2010
WebAIM
Web Accessibility Preferences Are For Sissies?
Several years ago I read an article by Garrett Dimon titled “User preferences are for sissies” (available at archive.org, also see this 37signals article). The general idea is that when you present preferences to the end user it typically indicates that you screwed up or are a sissy – either you are forcing the user to account for a poor design or usability decision, or you are too indecisive to make the decision to begin with and thus place the burden to decide upon the user.
In general, I believe that web accessibility preferences are no different.
Important Clarification
I’ve found that some have misinterpreted the message of this post to suggest that those who implement web accessibility preferences, or even web accessibility at all, are literally sissies. This is not at all what I am suggesting – I would not have devoted my life’s work to this effort if I viewed implementers of web accessibility this way. Such preferences obviously have their place, particularly on sites that target people with disabilities (see the comments below). However, implementing them as a method of avoiding native accessibility in content is not acceptable and certainly a cop-out approach to accessibility. My primary goal is that developers will consider the impact on ALL users when implementing such widgets and preferences for a particular group of users.
The term “sissies” comes from the original article that inspired this. We do not intend offense by reusing it here, no more so than “Dummies” books literally mean that someone who reads them is a “dummy”. I have rephrased the article title as a question, to perhaps clarify that this is not a literal, blanket statement, but an invitation to question the motivations and the overall impact of implementing such preferences. I apologize to any who took offense at the general theme of this post. This post has also generated a good deal of respectful and interesting dialog which I hope will continue.
There may be places where accessibility preferences, widgets, or controls are justified. My point is that they always come at a very steep cost – and that developers should balance the possible advantages of web accessibility preferences with the significant disadvantages.
Consider font resizing widgets – the stack of letter A’s that allow one to increase or decrease the font size for a particular web page or site. First, if your font size is too small, why not simply make it adequately sized rather than forcing the user to make it bigger? But assuming that your page’s font sizing is already adequate, who would benefit from a font resizing widget? Users with poor vision, right? But users with more extreme low vision will already be using a screen enlarger or some other mechanism for zooming the page or increasing the font size, so your widget does them little good. Many users who prefer or need larger text will be using the zoom function that is available in all major browsers to provide the larger text on all web pages they encounter. The more accurate response to the question is users who have low vision or who might prefer larger text, but who are not already using technology or browser functionality to provide it. This is a rather small body of users.
Now, who gains no benefit from or could be potentially disadvantaged by a font resizing widget? The short answer is EVERYBODY ELSE!
As noted above, many users with low vision will already have larger text. Users who are blind generally don’t care how big the text is, yet they must listen to and navigate through the widget controls on every page. Users with motor disabilities who use only the keyboard must also ‘tab’ through these controls while gaining no benefit from them. Users with auditory disabilities gain no benefit. Users with cognitive disabilities must handle the additional cognitive load of these controls (what does a stack of increasingly sized A’s mean anyway?). And most notably, users with adequate vision gain no utility from the widget (again, assuming your default font size is adequate), yet are still presented with the control on each and every page.
So, while the font resizing widget has potential to provide some benefit for a small number of users, it serves no benefit and can only make the experience less accessible for everybody else.
The same can be said for nearly every other type of accessibility preference. A preference to enable a high contrast view is provided to either account for poor default contrast or to provide accessibility to a small group of users at the cost of burdening all other users with the contrast control. Text-only versions are typically provided to account for poor accessibility of a main page and may benefit some users (though our surveys indicate they are rarely accessed by these users anyway), but they increase the complexity of the page to everybody else. Even something as seemingly innocuous as an accessibility statement link or badges stating your compliance with standards come at a cost while providing negligible benefit to end users. The cost and benefit of each of these should be considered.
There may be exceptions to the “web accessibility preferences are for sissies” rule, but they are few. “Skip” links are one possible exception, but their days are numbered. They remain necessary only because most browsers have yet to provide meaningful methods of keyboard navigation within pages. Sites that target people with disabilities may find such preferences to be acceptable.
Universal design, like most aspects of web accessibility (consider alternative text for images), is about making solid decisions that are enforced upon users to ensure a highly effective user experience. These decisions must be informed and are often difficult to make. The idea that using accessibility preferences, widgets, or controls to account for poor accessibility or design decisions is a dangerous one that rarely results in overall improvements to accessibility.
por Jared Smith, el 02/03/2010 21:06 CET
Adobe Accessibility
Adobe at CSUN 2010
The California State University at Northridge's Conference on Disability (commonly referred to as CSUN) is coming later this month, and we do feel that it is beneficial to attend this important accessibility event. We enjoy the opportunity to share important information and news, and to have many conversations with users of Adobe technologies.
This CSUN will be a very busy one for Adobe, with several sessions and events that I want to provide a heads-up for. Here's our schedule of events:
Tuesday, March 23 - Preconference Session
Accessible Websites and PDF Documents with Adobe Dreamweaver and Adobe Acrobat (Wednesday at 1:30-3:30 pm Madeline AB-PC Lab)
Wednesday, March 24
Accessibility Support for Designers in Adobe Creative Suite (8:00-9:00am Gregory AB-Adobe)
Access to PDF: Developments in Support of Assistive Technology with Adobe Acrobat (9:20-10:20am Emma AB)
Accessible eBooks, ePub, DAISY, and Adobe (10:40-11:40am Gregory AB-Adobe)
Accessible Web Conferencing Update (1:50-2:50pm Gregory AB-Adobe)
Thursday, March 25
Adobe Flex and Adobe AIR for Accessible Rich Internet Applications (8:00-9:00am Gregory AB-Adobe)
Adobe Open Forum (10:40-11:40am Gregory AB-Adobe)
[To clarify this session, this is chance to ask questions, raise concerns, and discuss topics with the Adobe accessibility team in an open setting]
Assistive Technology Access to Adobe Flash and PDF (1:50-2:50pm Gregory AB-Adobe)
Understanding the End User Role in PDF Accessibility (with AFB Consulting) (3:10-4:10pm Betsy AB)
Friday, March 26
PDF Accessibility - Best Practices for Authoring (8:00-9:00am Gregory AB-Adobe)
PDF Troubleshooting for Blind and Low Vision Users (with AFB Consulting) (10:40-11:40am Gregory AB-Adobe)
[This session is providing a chance to talk with Adobe staff from the Acrobat and Accessibility teams about specific issues accessing PDF files or to try to learn new techniques to access PDF files.]
Video Accessibility for Deaf and Hard of Hearing Users in Adobe Flash (1:50-2:50pm Gregory AB-Adobe)
Other Events
In addition, we are sponsoring the CSUN Tweetup on Wednesday night from 6-8pm in the Elizabeth Ballroom.
Adobe will also have a booth (San Diego 315), so please come by and say hello and ask questions or share your thoughts.
01 de marzo de 2010
Accesibilidadweb.com
Problemas de accesibilidad en el sitio de Vancouver 2010
Roger Johansson menciona en su blog la breve revisión que ha hecho Joe Clark sobre el sitio Web de los Juegos OlÃmpicos de Invierno de Vancouver 2010 y de la página http://www.ctvolympics.ca/.
Joe menciona en su artÃculo la promesa que se hizo en 2004 por parte del Comité Organizador de hacer accesibles los sitios webs relacionados con los Juegos OlÃmpicos de Invierno de este año.
Dicha promesa ha debido caer en saco roto.
El análisis realizado fundamentalmente sobre la página principal presenta los siguientes problemas:
- Falta de textos alternativos en imágenes. No sólo en imágenes decorativas o de espaciado (sorprende el uso aún de este tipo de imágenes) sino también en imágenes de agencias de noticias.
- Tal vez lo más importante. Ausencia de alternativas textuales y/o transcripciones de videos. Por el hecho que cada vez la web sea más multimedia, no podemos olvidarnos del aspecto de proporcionar subtÃtulos, versiones textuales o alternativas equivalentes para la interpretación de la información en caso de no poder reproducir el video, no poder escucharlo, no poder verlo, etc.
- Problemas de navegación mediante el uso del teclado. En especial, los desplegables (pone como ejemplo el medallero o los submenús).
- El uso de Microsoft Silverlight para la reproducción de algunos videos. Siendo una tecnologÃa propietaria podrÃa ocasionar problemas de reproducción en entornos que no sean Windows.
Finaliza su artÃculo haciendo una reflexión sobre la legislación canadiense. La ley no requiere que ninguna web sea accesible. Eso sÃ, los sitios corporativos están sujetos a las leyes de derechos humanos las cuáles prohÃben cualquier discriminación o tratamiento de desigualdad asociados a discapacidades de la persona. Algunas quejas de accesibilidad web se han presentado pero ninguna ha alcanzado una resolución pública.
Bueno, en España la ley lo exige; se han presentado denuncias y…. ¿ha pasado algo? Al igual que en Canadá, desgraciadamente ninguna ha alcanzado una resolución pública.
También realiza una profunda crÃtica al desarrollo online que se suele hacer en Canadá:
First of all, quite obviously nobody really cared enough to make these two Web sites accessible. The fact that some items were well handled (like tables and alternate text for some images) shows that developers had an awareness of Web accessibility. They just didnât go all the way.
Why? Because thatâs not what we do in Canada. Online, we do things really half-assed. We donât have an expert class of Web developers the way other countries, like the U.K., Australia, and Sweden, do. Inaccessible, and just plain incorrect, Web-development practices are reinforced at every level. Not-very-good developers hire other not-very-good developers, which charge a fortune to clients who donât know the difference.
En el último párrafo es bastante explÃcito:
¿Por qué? Porque no es lo que hacemos en Canadá. En Internet, hacemos cosas algo vulgares. No disponemos de una clase de expertos desarrolladores web como en otros paÃses tales como Reunido Unido, Australia y Suecia. Las prácticas de sitios inaccesibles en el desarrollo web se dan en cualquier nivel. Desarrolladores deficientes contratan a otros similares lo que repercute en el presupuesto final a clientes que no saben la diferencia que existe.
¿Habrá alguna consecuencia por estos fallos?. Probablemente ninguna. Empezarán los Juegos ParalÃmpicos y las cosas seguirán igual. Pasará algún tiempo y ya nadie se acordará de nada desgraciadamente.
Si volviésemos a celebrar algún evento de este tipo en España, ¿lo harÃamos mejor?, ¿peor?, ¿se nos llenarÃa la boca de palabrerÃa? ¿O por las prisas (o porque sÃ) publicarÃamos versiones provisionales?
Concienciación, concienciación, concienciación…
Fuentes:
- Accessibility issues on Vancouver Olympics websites
- Vancouver Olympics Web sites are inaccessible to disabled people
- Inaccessible content at Vancouver2010.com and CTVOlympics.ca
por Félix Zapata, el 01/03/2010 20:45 CET
25 de febrero de 2010
Usable y accesible
Sobre el uso de lectores de pantalla
Estudios destacados:
1. Empty Links and Screen Readers
Realizado por yuiblog.com y publicado en enero de 2008.
Los casos que cubre este estudio son:
- Normal links with proper link text
- Links with no link text or title attribute
- Links with a title, but no link text
- Links containing just whitespace for text
Each type of link was styled in the following ways:
- Displayed in a default manner
- Positioned off-screen
- Visibility of hidden
- Display set to none
Sus conclusiones son:
- Always have proper link text for a link, and assure that the link text makes sense in context. At that point the link can then be hidden by positioning it offscreen. If the link is styled with display set to none, ensure that the content makes sense with and without the link text in place.
- Never have an anchor with just an href attribute. The screen reader fallback is to read out the entire URL or try to extrapolate something readable from it, or a combination of both. This can lead to unpredictable results. How a browser or screen reader translates a URL into text that is read out requires more extensive testing.
- Never use visibility: hidden to hide an empty link from view. This leads to the title attribute being ignored in both JAWS/IE6 set-ups, and the absolute URL of the link being read out with Firefox. It also introduces a dependency on CSS to prevent an accessibility barrier.
- Never use just white space as the link text, the choice of link text between the setups tested differ significantly, with all combinations creating an accessibility barrier - either of reading an entire absolute URL, or guessing the link text based on URL extrapolation, or as in Window Eyes announcing a link, but with no link text read out.
- Never use display: none as a means of hiding this link. This creates a dependency on CSS, since the rendering of the page in screen readers is degraded.
- Never rely on the title attribute as the sole means of providing a form of link text since it's inconclusive whether title attributes are enabled for all screen reader users.
2. Prueba de comportamiento de lectores de pantalla frente a abreviaturas y acrónimos
Realizado por SIDAR. Complementa al artÃculo "Abreviaturas vs. Acrónimos"
Las pruebas indican que ninguna versión de los diversos lectores de pantalla analizados (JAWS hasta la versión 8) responde al atributo "title" de la etiqueta de abreviatura o de acrónimo.
Por ello es muy importante que, al menos la primera vez que se usan en el texto, se expandanda su significado en el propio texto. SerÃa también muy útil que los autores ofrecieran una relación de las abreviaturas y acrónimos que se utilizan en la página.
3. Survey of Preferences of Screen Readers Users
Realizado por WebAIM (enero 2009)
El resultado de la encuesta lo comentó uninstallme en "Preferencias y modos de uso de lectores de pantalla" (01.02.2009)
Esta primera encuesta nos recuerda la importancia de:
- Que los enlaces sean significativos, pues el 35% navega por el listado de enlaces de la página.
- Incluir un enlace "Saltar al contenido", pues 38% lo utiliza siempre que puede o a menudo y un 28% algunas veces.
- Incluir teclas de acceso rápido ("accesskey") pues un 35% las usa siempre que puede o a menudo y un 24% algunas veces.
- Que los encabezados deben utilizarse para reflejar la estructura del contenido, pues el 76% navega por los encabezados siempre que puede o a menudo y un 14% algunas veces.
- Que el buscador sea fácil de encontrar y usar. El 61% lo buscan dirigiéndose al primer FORM o campo de edición de texto de la página, por tanto debe ser el primero que encuentren.
- No abusar de los pop-ups, pues los usuarios con menos experiencia en el uso de lectores de pantallas tienen bastantes dificultades con ellos.
- Flash mejor no, el 71% consideran este contenido muy difÃcil o bastante difÃcil.
4. Screen Reader User Survey Results
Realizado por WebAIM (noviembre 2009)
La han comentado:
- "Resultados de la encuesta a usuarios de lectores de pantalla", de accesibilidadweb.com (02.11.2009)
- "Encuestas sobre uso de lectores de pantalla", de Accesibilidad en la web, (17.02.10)
Los elementos más problemáticos que se resaltan son:
- CAPTCHA - imágenes que presentan texto para verificar que un formulario lo está rellenando un ser humano.
- La presencia de contenido Flash inaccesible.
- Enlaces o botones sin sentido.
- Imágenes sin texto alternativo o descripciones no adecuadas.
- Formularios complejos o difÃciles.
- Falta de accesibilidad mediante el teclado.
- Pantallas o partes de la pantallas que cambian de forma inesperada.
- Encabezados ausentes o no adecuados.
- Demasiados enlaces o elementos de navegación.
- Tablas de datos complejas.
- Falta de enlaces "saltar al contenido principal" o "saltar navegación".
- Funcionalidad de búsqueda inaccesible o ausente.
5. Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers1
Realizado por el United States National Cancer Institute. Aunque es antiguo (2002-2003) resulta muy recomendable.
El objetivo del estudio es:
- understand the relationship between accessibility and usability
- understand how blind and low-vision users work with Web sites
- develop research-based guidelines for accessibility and usability
- assess the usability of specific Web sites for blind and low-vision users
Estable 32 pautas a seguir:
Guideline 1. Write for the web. Write in short, clear, straightforward sentences. Use bulleted lists. Put the main point at the beginning of a paragraph. Write links that start with keywords.
Guideline 2. Use empty ALT text, ALT="" or use a space as ALT-text, ALT=" " for decorative elements on a page so that users do not have to listen to "decorative bullet image" or "decorative line." Using empty ALT text for decorative elements complies with 508 guidelines. When links are bulleted, there is no need to identify the bullet, just the link name.
Guideline 3. For developers of screen-reading software: Make the commands mnemonic and intuitive.
Guideline 4. For designers and developers of Web sites: Make the site structure clear and obvious. The more obvious the structure of the site, the easier it will be for screen-reader users (as well as for sighted users) to understand and use the site.
Guideline 5. For developers of the screen-reading software: Consider providing training to help users get the most value from the screen-reading software that they use. Consider building easy-to-use demos and tutorials on new features.
Guideline 6. Write "home page" as two words.
Guideline 7. Do not make up unusual names for products, services, or elements of a Web site. Do not combine two or more words into one name. (Of course, these names often predate the Web site, and designers and developers cannot change them. Just do not add to the problem â and alert others to the problem as well.)
Guideline 8. To make screen readers read an acronym or abbreviation as letters rather than attempting to read it as a word, use the ACRONYM and ABBR tags as explained at http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr.
Guideline 9. For most Web sites, spend the available time and effort making one version that is accessible to all rather than creating and having to later maintain two separate versions.
Guideline 10. Include a "skip" link at the top of every Web page. Name it "Skip to main content." JAWS reads that correctly as the noun "content" with the accent on the first syllable. That wording was much more meaningful to participants than "skip navigation."
Guideline 11. Make links descriptive. Be sure that the link will be useful by itself, with no surrounding text. Do not use "click here," "more," "answer," or other repetitive words or phrases as links. Look at www.aarp.org for a site that consistently expands what used to be "more" into meaningful links, such as "more travel articles," "more of today's news," and so on.
Guideline 12. Start links with relevant keywords.
Guideline 13. Try not to have many links that start with the same word or phrase. In some ways, these guidelines are obvious and easy to implement. We know that even for sighted users, links should be descriptions of what they go to rather than "click here" or the URL
Guideline 14. Start question headings with a keyword followed by the question.
Guideline 15. Pay attention to the wording on pages and be sure that keywords that users would look up are actually on the page. (This is useful for sighted users, too.)
Guideline 16. Make sure that the keywords are not in images.
Guideline 17. For makers of screen-reading software: Make Find cycle through the entire page.
Guideline 18. Do not create subtle differences between the text on the page and the ALT text that can trip users up when they search for words on the page.
Guideline 19. Use a search engine that provides help with spelling, such as the one at www.google.com.
Guideline 20. Use anchor links when a page has several topics.
Guideline 21. Keep pages from refreshing when users select an anchor link. Do not include a time and date stamp on a page with anchor links.
Guideline 22. Encourage authors to use many headings in their content and to be sure that those headings are clear, meaningful, and parallel. This guideline is critical for both sighted users and screen-reader users.
Guideline 23. Be sure that the headings are coded properly in HTML, for example, as H1, H2, etc. JAWS looks for the heading tag.
Guideline 24. Put the keyword at the beginning of the heading. If many headings are about the same thing, differentiate them in meaningful ways.
Guideline 25. Do not put a lot of text on the same page as a form.
Guideline 26. Do not put a form far down on the page or far to the right.
Guideline 27. Make sure that all fields are coded so that users do not have to switch to and from Edit mode. Use the HTML [label] element. To add more information than is in the label, use the Title attribute.
Guideline 28. In addition to checking your site with an automated tool like Bobby or LIFT, listen to it with a screen reader.
Guideline 29. Do not put information between fields on a form.
Guideline 30. If the user has an option of filling out either of two fields, and they are mutually exclusive, inform the user with the label of the first field.
Guideline 31. Do not exclude labels from fields.
Guideline 32. Avoid making pages refresh.
6. "What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users" (PDF)
Realizado por Towson University en 2007.
Es destacable el apartado Motivos de frustación. Consultar la tabla resumen de los principales motivos de frustación.
Enlaces recomendados sobre el tema
- "Navegando una página Web con Jaws: consideraciones de accesibilidad para desarrolladores", deinterfaz.com (14.10.08)
- "Using JAWS to Evaluate Web Accessibility", WebAIM
- Mi lista de producción en YouTube "Sobre lectores de pantalla"
- "WEB 2.0: Blind to an Accessible New World" (PDF)
- "How People with Disabilities Use the Web", del W3C. Existe una traducción al castellano de Alan Chuter, aunque es de un borrador menos reciente que el de inglés "Cómo utilizan la Web las personas con discapacidad"
- Sobre JAWS: "Assistive Technology Quick Reference", "Keyboard Shortcuts for JAWS", JAWS Keystrokes y Jaws Quick Start Guide (PDF)
por Olga Carreras (carreras.olga@gmail.com), el 25/02/2010 14:12 CET
Programar a ciegas
Syrinx, un cliente de Twitter accesible para MacOS X
Twitter está presente en multitud de plataformas y sistemas operativos. En MacOS X hay multitud de clientes gratuitos, de pago, compatibles con Adobe Air, Dash board, incrustados en el finder, etc. El problema es que no todos resultan cómodos o accesibles con voiceOver.
Syrinx es un completo cliente de Twitter para MacOS X Leopard y Snow leopard. Permite leer tu timeline tweet, menciones y mensajes privados en conjunto o filtrado, gestionar tus followers y se integra perfectamente con Growl.
Es muy sencillo de utilizar y muy accesible. El problema es que su interfaz aún no está en español.
Puedes obtener el programa y más información en la web de Syrinx en inglés
24 de febrero de 2010
Seraccesible
Seminario Iberoamericano sobre Accesibilidad Universal y Ayudas Técnicas
Tendrá lugar entre los días 8 y 10 de Marzo en Montevideo (Uruguay), como objetivos, dar a conocer la panorámica general de las Ayudas Técnicas y de las Nuevas Tecnologías de la información y la comunicación aplicadas a las personas con discapacidad, promover un foro de intercambio y debate sobre los programas, intervenciones y proyectos que se están desarrollando en los diversos países participantes del encuentro, posibilitar el conocimiento y discusión de programas en desarrollo o ya desarrollados y analizar las posibilidades de la cooperación técnica internacional en materia de accesibilidad.
Un encuentro dirigido a expertos en accesibilidad, arquitectos, ingenieros, estudiantes de arquitectura, formadores y responsables municipales y de áreas gubernamentales en las cuales la accesibilidad sea una prioridad.
Vía: el-observatorio
por Lucia Navarro, el 24/02/2010 21:36 CET
Accesibilidadweb.com
Australia adopta las WCAG 2.0
Oficiales ya desde Diciembre de 2008, la segunda versión de las Pautas de Accesibilidad al Contenido Web (WCAG 2.0) han sido incorporadas en la legislación australiana.
Las agencias gubernamentales australianas adoptarán dichas pautas a lo largo de un perÃodo de cuatro años, alcanzando el nivel A de accesibilidad en dos años y el nivel doble A (AA) en los dos años restantes.
Cabe destacar, que en Australia se obliga a publicar siempre una alternativa a un documento PDF (Portable Document Format) preferentemente en HTML (HyperText Markup Language) o en RTF (Rich Text Format)
Australia es un paÃs bastante concienciado con la Accesibilidad Web. En especial a raÃz de una demanda presentada por Bruce Maguire, persona ciega residente en Australia la cual obligó al comité olÃmpico internacional y al comité olÃmpico australiano a modificar sus páginas para hacerlas accesibles. En Agosto de 2000, la Comisión de los Derechos Humanos e Igualdad de Oportunidades australiana dictó sentencia a favor de Bruce y multó al comité organizador de los Juegos OlÃmpicos de Sydney. Más información sobre este caso en Readerâs guide to Sydney Olympics accessibility complaint (en inglés).
¿Y en España que sucederá con las WCAG 2.0? Teniendo en cuenta el poco grado de concienciación existente aún en aspectos relacionados con la Accesibilidad Web, bastante con que las páginas cumplan la legislación actual que tenemos y que efectivamente no posean errores graves o muy graves de accesibilidad al contenido presentado.
Fuente: Finally, WCAG 2.0 for Australia!
por Félix Zapata, el 24/02/2010 20:18 CET
Accessites
Web Perfectionist
The Web Perfectionist site was designed by Irina Ponomareva to be clean, elegant, easy to use and accessible to all.
We found it to be a very solid, well coded, accessible site.
por Phil Smears, el 24/02/2010 19:15 CET
Programar a ciegas
Instalación de programas en MacOS X
La mayorÃa de usuarios están acostumbrados a seguir un método de instalación utilizando un asistente, cosa común en los sistemas operativos de la familia Ms Windows. Pero este sistema de asistentes de instalación no se considera una forma estandar de instalación por lo que en otros sistemas operativos siguen otros métodos.
En este artÃculo se muestran las diversas formas de instalar un programa en Apple MacOS X.
Obteniendo el programa
La mayorÃa de las veces descargaremos de la web un fichero comprimido con el programa que queremos instalar. El archivo puede ser ofrecido en uno de los formatos de compresión conocidos, como ZIP o RAR, o en un formato de fichero de imagen común para las máquinas de apple, el formato DMG.
Los ficheros con extensión DMG son equivalentes a un fichero comprimido por lo que para poder instalar un programa contenido en un fichero DMG lo primero que debemos hacer es abrirlo. Al hacer esta operación se nos abrirá en el escritorio de nuestro MacOS X un volumen de unidad nuevo que equivale al contenido comprimido dentro del fichero DMG. Dentro de este volumen encontraremos el programa a instalar.
Si el programa viene en un archivo ZIP o RAR deberemos utilizar el compresor del sistema. MacOS X incluye un compresor compatible con el formato ZIP.
Programa con instalador
Una de las formas posibles de instalación es que el programa se distribuya como paquete de instalador. Son ficheros con extensión MPKG. Finder, el explorador de archivos de MacOS X, identificará este tipo de ficheros con un mensaje parecido a "Paquete de instalador". Lo que debemos hacer es ejecutar el paquete de instalación y seguir las instrucciones donde se nos preguntará si estamos de acuerdo con la licencia, el volumen donde instalar el programa y nos pedirá la contraseña de administrador del equipo.
Estos programas suelen incluir también un paquete de desinstalación o similar.
Instalación de programas sin paquete de instalación
Puede que al descomprimir el fichero ZIP o montar el volumen del fichero DMG no encontremos ningún paquete de instalación, esto es porque la aplicación se instala mediante la operación de arrastrar y soltar. En algunos casos, dentro del fichero DMG, al entrar en su contenido, podemos encontrar, incluso, un acceso directo o alias a la carpeta de aplicaciones para poder instalar el programa desde esa misma ventana.
el proceso de instalación para este tipo de programas pasa por copiar el programa, colocando el foco de voiceOver sobre él y pulsando la combinación de teclas comando+c, ir a la carpeta de aplicaciones del sistema, la combinación de teclado es comando+mayúsculas+a, y pegar el programa en la carpeta de aplicaciones pulsando la combinación comando+v.
Para desinstalar este tipo de programas simplemente borraremos el programa de la carpeta de aplicaciones del sistema.
23 de febrero de 2010
Programar a ciegas
Lectores de pantalla
Un lector o revisor de pantallas es una herramienta de asistencia para discapacitados visuales grabes o totales cuya principal función es transmitir al usuario la información que se visualiza por pantalla.
Dentro de los interfaces de texto (como serÃan la consola de Windows, MSDOS o el Bash de Linux) las funciones del lector de pantalla son simples. Sólo tiene que poder leer cada una de las diversas lÃneas de texto que aparecen en la consola y transmitirlas al usuario. Otras funciones asociadas para este tipo de lectores son las posibilidades de revisar lÃnea a lÃnea la pantalla, verbalizar los cambios sufridos en la pantalla o crear cuadros de detección para prestar mayor atención a zonas especÃficas de la pantalla.
El tener un interfaz visual basado en texto y con una estructura de distribución de la información simple, como es el caso de las consolas de texto, simplifica mucho la tarea del lector de pantallas. El problema aparece cuando el interfaz consiste en elementos visuales como iconos, cuadros de texto, ventanas, barras de desplazamiento y demás controles visuales utilizados por la mayorÃa de interfaces gráficos de usuario comunes en Windows, GNome, KDE y MacOS X.
En este caso el lector de pantallas tiene que realizar una interpretación previa de lo que existe y se ve en la pantalla para transmitirlo al usuario.
Esta interpretación del contenido visual se hace siguiendo un protocolo y conjunto de reglas denominado off screen model.
Dependiendo del tipo de Off screen model el lector de pantallas permitirá una exploración focal (siguiendo al foco del tabulador), exploración lÃnea a lÃnea (como el cursor de JAWS o un lector de pantallas para consola), exploración posicional (como hace voiceOver), o exploración gerarquica utilizando el árbol de objetos (como hace NVDA y tiflowin).
También influirá a la hora de transmitir cierta información como la fuente y color del texto de un control visual, el tamaño del control, el estado del control (activo, visible, oculto, etc) o las caracteristicas de accesibilidad o información alternativa del control (tooltips, globos de texto, etiquetas descriptivas, etc).
Hay que prestar atención en la diferencia que hay entre "lo que existe en la pantalla" y "lo que se ve en la pantalla" ya que el uso de ventanas solapables en los interfaces gráficos puede provocar que el usuario sin discapacidad visual no vea lo que hay detrás de una ventana aunque siga existiendo en el interfaz. El lector de pantallas debe detectar si el control o elemento del interfaz está visible para notificarle el estado al usuario ciego. El lector de pantallas puede controlar la información visual consultando al sistema operativo sobre el árbol de objetos visuales o parasitando el controlador de video, siendo la primera opción la menos intrusiva ya que no se requiere de la instalación de ningún driver o parche de control de video.
El árbol de objetos visuales es una representación abstracta de lo que hay en un interfaz gráfico de usuario. Es utilizado por el sistema operativo para estructurar los diversos elementos de un interfaz gráfico y actualizar el estado y gestionar los eventos. En el árbol de objetos podemos tener la rama inicial en el escritorio y de ella nacen varias ramas hijas representando a las ventanas de las aplicaciones abiertas que tengamos en ese momento, de una de esas ramas pueden colgar subramas para representar subventanas, botones, barras de menú, etc presentando una vista gerarquizada de los elementos del interfaz.
El lector de pantallas también debe estar pendiente del dispositivo de entrada, sea este un teclado, una pantalla táctil o una botonera. El usuario ciego deberá utilizar el dispositivo de entrada para explorar el interfaz gráfico e interactuar con él. Por esta razón el lector de pantallas deberá modificar el comportamiento del dispositivo de entrada para incluir ciertas combinaciones de teclas, gestos o movimientos determinados para realizar las funciones de exploración en el interfaz(leer una ventana o cuadro de texto, moverse al elemento anterior o siguiente del interfaz, activar un elemento del interfaz, etc).
El lector de pantallas debe transmitir el resultado de la interpretación del interfaz al usuario con discapacidad visual utiizando un canal accesible para él, como puede ser voz sintética, eventos de sonido o salida por un dispositivo de lectura braille.
En resumen, un lector de pantallas se compone de los siguientes elementos:
- Módulo de control del interfaz gráfico
- Módulo de control del dispositivo de entrada
- Módulo de salida de información
- Off screen model
Dentro del catálogo de operaciones que un usuario puede pedir a un lector de pantallas están: Leer caracter, palabra, lÃnea anterior, actual o siguiente; consultar tipo, tamaño y color de fuente, leer tÃtulo y última lÃnea de la ventana, repetir lo último verbalizado, etc.
Algunos ejemplos de lectores de pantalla son: NVDA, Window eyes, JAWS, Dolphin HAL, Thunder, voiceOver, Orca, Mobile speak, Talks, out spoken, virgo, tiflowin, lector98, habla, parla, etc.
BeepBeep, juego musical para iPhone
Para Apple iPhone existen multitud de juegos en la appStore, entre ellos existen juegos musicales que consisten en repetir una nota o melodÃa evitando fallar en la nota indicada. Este es el caso de BeepBeep, un juego donde tendremos que recordar la melodÃa que se va generando y repetirla utilizando unas teclas de colores.
El juego resulta muy accesible con voiceOver, el lector de pantallas para iPhone, aunque el problema está al principio de jugar donde no se puede asociar un tono con cada una de las teclas por lo que el usuario ciego comenzará la primera partida perdiendo intentando probar los tonos de cada una de las 4 teclas.
El juego es muy divertido y permite guardar nuestra puntuación.
Puedes instalarlo en tu iPhone utilizando el enlace de BeepBeep en la appStore.
El juego está en inglés aunque su modo de juego es tan sencillo que no es problema alguno que no esté en castellano.
22 de febrero de 2010
Seraccesible
Las nuevas tecnologÃas ayudan a ciegos a consumir más información a través de Internet
La mayoría de organismos públicos y empresas se han sensibilizado y han incorporado sistemas y equipos para que la red sea más accesible.
Indra y la Universidad de Castilla la Mancha han desarrollado un asistente virtual que traduce el texto escrito y el contenido audiovisual en lengua de signos, para que las personas sordas puedan acceder a este tipo de contenidos en la red, salas de cine, programas de televisión o informarse en lugares públicos como estaciones de tren o aeropuertos.
Alumnos de la Universidad Politécnica de Valencia han diseñado un teclado virtual basado en un pulsador para personas que mueven con dificultad o no pueden utilizar sus manos, utilizando un sistema parecido al que utilizan los teléfonos móviles para enviar mensajes de texto.
Zac Browser es un navegador específico para niños autistas con una sola pantalla que funciona solo con imágenes, una herramienta que está ayudando a más de 750.000 niños en todo el mundo.
Artículo completo con ejemplos reales en nuestra sociedad.
Infosord.
por Lucia Navarro, el 22/02/2010 21:02 CET
21 de febrero de 2010
Programar a ciegas
Frotz para Apple iPhone
Muchos usuarios conocen las aventuras conversacionales. Son aquellos juegos donde la acción se centra en información escrita, el jugador escribe qué quiere hacer (coge la espada, abre el cofre del tesoro, mata al dragón, abre la puerta del coche, etc) y donde los resultados de las acciones se leen en la pantalla (coges la fantástica espada, abres el cofre del tesoro descubriendo que está vacÃo, intentas matar al enorme dragón y él te come de un solo mordisco, intentas abrir la puerta del coche y descubres que está cerrada con llave, etc).
Para jugar a estas aventuras conversacionales hay que utilizar un cliente o interprete. Para la máquina Z, uno de los formatos más famosos de aventuras conversacionales, tenemos un cliente portado a multitud de plataformas, el conocido Frotz. Este interprete de MáquinaZ está disponible para MS DOS, MsWidnows, MacOS X, GNU Linux, Windows mobile y, por fin, para Apple iPhone OS.
Frotz para iPhone es gratuito y lo podremos encontrar en la appStore. Puedes utilizar este enlace de Frotz en la appstore.
Una vez instalado podemos jugar a las aventuras que vienen instaladas de serie, aunque están en inglés, o subir más aventuras en castellano utilizando el servicio FTP incorporado en Frotz a través de conexión Wifi.
El interfaz de Frotz para iPhone está en inglés aunque es sencillo de comprender.
Posee propiedades de configuración para el color y tamaño de letras y es muy accesible con voiceOver para iPhone.
19 de febrero de 2010
mindforks
Accessibility Diagnostic Jetpack
I put together a little jetpack that tells you if Firefox's accessibility service is actually running in your browser. It is basically David Baron's "about:accessibilityenabled" extension but as a jetpack. If you want to give it a whirl, strap it on.
You'll need to grab Jetpack if you don't have it already. Alternatively you can just use David Baron's handy about:accessibilityenabled extension.
Aside: we've noticed the gecko accessibility service is being used in some unusual places, for example, by some desktop anti-spyware; leading to unnecessary performance degradation. If you discover that our accessibility service is unexpectedly running in your Firefox session, please consider contacting me so we can figure out why...
Thanks for reading.
por David Bolter (noreply@blogger.com), el 19/02/2010 22:03 CET
Programar a ciegas
Tweetero, un cliente de Twitter para iPhone
El servicio de Twitter es uno de los recursos de la Web 2.0 más utilizados en la actualidad. La gente se conecta desde su equipo de sobremesa, el de la oficina, su teléfono o, incluso, desde su consola de videojuegos.
Para la plataforma Apple iPhone existen multitud de clientes para Twitter, el problema es encontrar uno que sea accesible con voiceOver, el lector de pantallas para Apple iPhone.
Tweetero es un cliente de Twitter para iPhone gratuito y es muy accesible con voiceOver.
Tweetero permite leer los tweets de la gente que seguimos (timeline tweet) hacer retweets, enviar fotografÃas y mensajes privados y algunas opciones más.
Es muy accesible aunque posee algunos botones sin etiquetar a la hora de escribir un tweet.
Puedes descargarlo en tu iPhone con el enlace de Tweetero en la appStore.
Puedes saber más de Tweetero en su página Tweetero home page .
18 de febrero de 2010
Seraccesible
Nuevas tecnologÃas al alcance de todos
El Mobile World Congress, celebrado en Barcelona ha presentado nuevos móviles, aplicaciones y tecnologías para reducir la brecha digital entre los colectivos de ancianos y discapacitados.
Destaca la iniciativa del instituto tecnológico Barcelona Digital, que pretende transformar el teléfono móvil en un “mando universal”. De esta forma, las personas discapacitadas y mayores podrán utilizar cualquier dispositivo electrónico urbano o doméstico no adaptado.
En el caso de los teléfonos móviles destinados a personas mayores, se han mostrado nuevos terminales que cuentan teclas de mayor tamaño y un funcionamiento sencillo, para que sea fácil de consultar y mostrar los números más importantes.
Esta iniciativa se enmarca en el proyecto Cenit Inredis, que nació en 2007 bajo la iniciativa Ingenio 2010 del Gobierno español.
Vía: Solidaridad Digital
por Lucia Navarro, el 18/02/2010 20:52 CET
16 de febrero de 2010
Seraccesible
Portal web para localizar espacios adaptados y denunciar barreras
BJ Adaptaciones ha patrocinado la creación del portal libredebarreras.es, cuyo objetivo es facilitar la movilidad de las personas con discapacidad en los entronos urbanos.
Además, pretende sensibilizar a la sociedad, a las instituciones públicas y al sector privado de los beneficios de construir espacios accesibles.
Funciona sobre un mapa virtual donde se localiza y señala la posición exacta tanto de barreras arquitectónicas como de aparcamientos reservados y empresas y comercios adaptados.
Es una herramienta participativa en la que cualquier usuario puede registrarse para señalar obstáculos y barreras que, en muchos casos, pueden llegar a impedir realizar una actividad cotidiana.
Actualmente, pueden consultarse los espacios accesibles y las barreras arquitectónicas de la ciudad de Granada. Sin embargo, el proyecto ha empezado a extenderse a otros municipios españoles. A día de hoy, ya existen peticiones de las Comunidades Autónomas de Euskadi, Cataluña y Extremadura.
Vía: Solidaridad Digital
por Lucia Navarro, el 16/02/2010 19:12 CET
15 de febrero de 2010
Programar a ciegas
Construyendo una aplicación Cocoa sin InterfaceBuilder gracias a zButton
Uno de los principales problemas de accesibilidad que se encuentra un desarrollador ciego a la hora de trabajar con las herramientas de desarrollo de Apple es que hay alguna de estas herramientas que, en las versiones actuales, resultan bastante inaccesibles.
Es el caso de Interface builder, la herramienta para el diseño de ventanas y formularios para Macintosh e iPhone.
Aunque algunas operaciones si resultan accesibles en Interface builder, no todas las posibles operaciones que nos brinda esta herramienta resultan accesibles para usuarios de lector de pantalla.
La solución pasa por diseñar nuestra aplicación sin utilizar Interface builder.
Gracias a la gente del blog zButton podremos empezar a desarrollar nuestra primera aplicación cocoa ya que han publicado un pequeño y sencillo tutorial donde se explica cómo desarrollar una aplicación cocoa sin interface builder .
11 de febrero de 2010
WebAIM
Target.com Accessibility
We’ve reported over the last several years about the target.com lawsuit and eventual settlement. The $6,000,000 settlement required that Target would implement accessibility for users with visual disabilities, among other things. We’re happy to report that the target.com web site is now quite accessible. Sporting a new design and accessibility features, the site can be considered a wonderful model of an accessible corporate e-commerce site. The National Federation of the Blind considers the site equally accessible to blind and sighted users. While you may not agree with the lawsuit or may have concerns about the impact it has ultimately had on people with disabilities, it’s clear that this site is more accessible now than it likely would have been otherwise.
While we will likely never know the cost of implementing accessibility on this site (and indeed we shouldn’t treat the price of accessibility as something separate from site design and development anyway), I suspect it cost them much less to implement the current levels of accessibility than it did for them to fight and settle the original lawsuit. The new site maintains a clean and stylistic design with nearly all accessibility happening naturally through the structure and presentation of the site pages. Their implementation of “skip” links is fantastic – try tabbing through the page. There is certainly room for some improvement, particularly in other areas of accessibility not addressed by the NFB settlement, but the point is that the site is functional, looks good, and is quite accessible.
Target, along with Amazon.com and a few other innovators in the e-commerce arena, is showing that accessibility of large, complex sites is not only possible, but beneficial to all potential customers and to the corporations themselves.
por Jared Smith, el 11/02/2010 23:21 CET
09 de febrero de 2010
Seraccesible
Mouse para el pie
Información de la mano de Antonio Sacco, esta vez nos muestra un mouse para el pie que se construye a partir de la adaptación de un simple mouse óptico.
El vídeo y la documentación se distribuyen libremente bajo licencia Creative Commons.
Vía: Capacitech
por Lucia Navarro, el 09/02/2010 12:41 CET
08 de febrero de 2010
Programar a ciegas
El rotor de voiceOver para iPhone
El teléfono Apple iPhone 3G s lleva incluido un lector de pantallas para usuarios ciegos. Es el conocido voiceOver.
Este lector de pantalla permite el acceso a la información que aparece en el teléfono a través de gestos. El problema aparece a la hora de inventar tantos gestos como funciones tenga el lector de pantalla. A semejanza con los lectores de pantalla de sistemas operativos de escritorio, como Jaws o NVDA, donde tenemos más de 60 combinaciones de teclas asociadas al lector de pantallas. Esto hace que la curva de aprendizaje del usuario ciego sea lenta.
La gente de Apple ha solucionado el problema de la curva de aprendizaje simplificando el manejo de su lector de pantallas. En otros artÃculos de este blog hemos visto cómo explorar la pantalla y los elementos que aparecen en ella. Pero aún no sabemos cómo leer palabra a palabra, letra a letra, seleccionar texto o saltar entre los encabezados o controles de formulario de una página web.
En un lector de pantallas que utilizase el teclado tendrÃamos 2 combinaciones de teclas por cada una de esas funciones. Con voiceOver para iPhone con 3 gestos podemos hacer todas esas funciones y más. Todo esto se consigue gracias al rotor de voiceOver.
El rotor
El rotor consiste en un gesto giratorio que nos permite seleccionar un elemento entre un grupo de elementos de una lista dispuestos de forma circular a semejanza del movimiento que hacemos en el dial de una radio o la rueda de control de un iPod classic o iPod nano para seleccionar una frecuencia o un nivel de volumen determinado.
Para conseguir este gesto debemos colocar dos dedos sobre la pantalla y, mientras uno de los dedos lo dejamos quieto el otro debe arrastrarse por la pantalla haciendo un cÃrculo rodeando al dedo que se encuentra quieto.
El gesto del rotor nos permite seleccionar un tipo de elemento que utilizaremos para avanzar o retroceder. Por ejemplo, en el escritorio del iPhone, si hacemos el gesto del rotor podremos seleccionar uno de los siguientes elementos: palabra, caracter. Una vez seleccionado uno de los elementos podremos leer palabra a palabra o caracter a caracter. Para conseguir esto simplemente tenemos que hacer un flick (caricia corta) hacia arriba para leer la palabra o el caracter anterior, dependiendo de lo que hayamos elegido en el rotor; o caracter atrás o caracter adelante con el gesto de flick arriba o flick abajo.
Seleccionar, copiar y pegar
Con el rotor, cuando estamos editando un texto, junto a las opciones de palabra y caracter nos sale una nueva opción llamada editar. Esta opción nos permite realizar operaciones de selección y copia. Para ello, mientras estamos editando un texto, utilizaremos el gesto del rotor para elegir la opción de editar. Cuando hagamos el gesto de flick arriba o flick abajo oiremos varias opciones:seleccionar, seleccionar todo. Si elegimos la opción "seleccionar todo y hacemos un doble tab(pulsar dos veces la pantalla con un dedo) seleccionaremos todo el texto. Si volvemos a hacer el gesto de flick arriba o flick abajo, junto con las opciones de seleccionar y seleccionar todo habrá aparecido dos opciones nuevas (copiar y cortar) seleccionando una de ellas y haciendo doble tab copiaremos o cortaremos el texto. Con información en el portapapeles, al hacer el gesto de flick arriba o flick abajo, junto con las opciones de selecionar, seleccionar todo, cortar y copiar; aparecerá la opción de pegar.
El rotor y la navegación web
Safary mobile es el navegador web que viene con el iPhone. Los lectores de pantalla suelen permitir navegar entre encabezados de una página web, controles de formulario, enlaces, párrafos, etc. VoiceOver para iPhone también lo permite, para poder seleccionar qué elemento utilizaremos como criterio de salto deberemos utilizar el gesto del rotor. Dentro de una página web en Safary al hacer el gesto del rotor, entre muchas otras opciones, podremos elegir entre: palabra, caracter, enlaces, controles de forma, encabezados, etc. Una vez elegido uno de los elementos del rotor, al hacer flick arriba, buscará el elemento hacia atrás desde donde nos encontremos, si hacemos el gesto de flick abajo, lo buscará hacia adelante.
03 de febrero de 2010
Seraccesible
Cursos de idiomas online para personas ciegas o discapacidad visual
Se trata del proyecto Eurochance II, cursos de inglés, alemán, español e italiano para personas con ceguera o discapacidad visual.
Su objetivo, la inclusión en el mercado laboral de este colectivo mediante la adquisición de destrezas lingüísticas relacionadas con el trabajo.
Se tratan de cursos virtuales que pueden ser realizados desde un ordenador en cualquier punto del planeta. Los requisitos técnicos son mínimos y los resultados muy alentadores.
Vía: Capacitech
por Lucia Navarro, el 03/02/2010 21:52 CET
Inteco premiado por su descodificador de TDT accesible
La Fundación Dintel ha premiado al Instituto Nacional de Tecnologías de la Comunicación por el software desarrollado para hacer accesibles los decodificadores de TDT, tanto a personas mayores como a personas discapacitadas.
Inteco ha desarrollado el sistema operativo denominado IDTVOS, que es compatible con varios receptores de TDT del mercado, una herramienta que incorpora funcionalidades de accesibilidad como los tamaños de fuente, la ayuda a la navegación por voz, tonalidades de alto contraste o velocidad de la voz personalizable.
Vía: Solidaridad Digital
por Lucia Navarro, el 03/02/2010 21:51 CET
02 de febrero de 2010
Seraccesible
Taller Digital de la Universidad de Alicante
El Taller Digital de la Universidad de Alicante ofrece servicios de consultoría, desarrollo y formación en Accesibilidad Web.
Esta es la definición de accesibilidad web en el sitio:
La expresión "accesibilidad web" hace referencia a la preparación de un sitio web para permitir el acceso y facilitar el uso de sus servicios y contenidos a todo tipo de usuarios, independientemente de las limitaciones que puedan tener en relación con el hardware y el software que utilicen, la infraestructura de red, su idioma, cultura o localización geográfica, o sus propias capacidades personales.
por Lucia Navarro, el 02/02/2010 16:37 CET
01 de febrero de 2010
Programar a ciegas
¿La muerte del teclado será la muerte de los lectores de pantalla actuales?
Actualmente estamos viviendo en el mundo de la tecnologÃa una continua evolución en los interfaces hombre-máquina donde el teclado fÃsico está dejando espacio a las pantallas táctiles.
La pantalla táctil es un candidato ideal para sustituir al teclado, aunque actualmente no exista un feedBack satisfactorio que emule a la sensación de pulsar algo. La posibilidad de que en una zona de la pantalla se pueda pulsar un botón, en un momento determinado, o que en esa misma zona de pantalla, en otro momento, aparezca un teclado permite optimizar y reducir los tamaños de los dispositivos.
Muchos perfiles de discapacidad se benefician de tener todo en una misma superficie, por ejemplo, los usuarios con motricidad reducida que utilizan un apuntador sostenido por la boca tienen pantalla, ratón(pulsando la pantalla) y teclado todo en la misma superficie.
El problema aparece para aquellos usuarios con discapacidad cuyo producto de apoyo utiliza el teclado para crear la comunicación hombre-máquina. Este es el caso de los lectores de pantalla.
Un lector de pantalla es un software que hace de interprete entre el usuario con discapacidad visual y el interfaz gráfico que se muestra en la pantalla.
Las incorporaciones de funcionalidades táctiles en las últimas versiones de MsWindows, MacOS X y algunas distribuciones de GNU-linux nos hacen pensar que los fabricantes piensan que el futuro está en la pantalla táctil. El problema está en saber si los fabricantes de lectores de pantallas, como Jaws o Window eyes, han pensado en lo que piensan los fabricantes de sistemas operativos.
Pongamos el caso hipotético siguiente: Un usuario ciego adquiere un Tablet con Windows 7. Esta versión del sistema operativo de Microsoft incorpora multitud de funciones para ser utilizadas con una pantalla táctil. El usuario ciego sabe que el sistema operativo, Windows 7, es el apropiado para instalar Jaws o Window eyes. Pasa el instalador al disco duro del Tablet (con ayuda de alguien ya que todavÃa no tiene accesibilidad instalada en su nuevo equipo), ejecuta el instalador de Jaws y el Tablet comienza a hablar y le pide que pulse el botón "siguiente". Aparece el primer y gran problema. Un usuario de Jaws utiliza el teclado para explorar la pantalla y activar los distintos elementos pero recordemos que el Tablet carece de teclado. Algunos pensarán que se puede conectar un teclado externo, cierto, pero entonces para qué queremos un Tablet en lugar de un portatil común? La principal decisión para adquirir un equipo sin teclado es porque son más ligeros y más portátiles. ¿Debemos condenar al usuario ciego a tener que ir a todas partes con su Tablet, un teclado externo, el cargador, recambio de pilas para el teclado si es inalámbrico, un ratón si el usuario puede usar magnificación, etc?
La solución pasa por la concienciación y aceptación del nuevo modelo de interactividad hombre-máquina con pantallas táctiles por parte de los fabricantes de lectores de pantalla y la adopción del modelo de gestión del lector de pantalas mediante gestos.
Este modelo de control, haciendo dibujos en la pantalla táctil o pulsando zonas determinadas de ellas, es el modelo adoptado por los 2 lectores de pantalla para dispositivos móviles con pantalla táctil que existen en el mercado: Mobile speak 4 y voiceOver for iPhoneOS.
Esperemos que la gente de Jaws, Window eyes, GNome-orca, NVDA, Thunder y otros lectores de pantalla para sistemas operativos de escritorio estén estudiando el problema y aporten soluciones. De no ser asà los usuarios ciegos nos veremos obligados a descolgarnos del tren tecnológico y seguir utilizando un interfaz anticuado con respecto al resto de usuarios.
29 de enero de 2010
Seraccesible
La web del SID sin actualizar en espera desde el 1 de Enero
El Servicio de Información sobre Discapacidad (SID) no actualiza la información de su portal en Internet desde el 1 de enero de 2010 y tiene en paro a siete trabajadores por
"incidencias en el establecimiento de la colaboración entre el Ministerio de Sanidad y Política Social y la Universidad de Salamanca"
Así lo asegura la propia web en su pantalla de inicio. Según indicó a Servimedia el director del SID, Miguel Ángel Verdugo, el Ministerio está trabajando para "subsanarlas a la mayor brevedad", pero cabe la posibilidad de que la situación se prolongue durante meses.
Según informó, los problemas en la renovación del convenio entre Sanidad y la Universidad que han dado lugar a esta situación le fueron comunicados a finales de diciembre.
Vía: Solidaridad Digital
por Lucia Navarro, el 29/01/2010 11:15 CET
El BoletÃn Oficial de Madrid se digitaliza
El Boletín Oficial de la Comunidad de Madrid va a abandonar su tradicional soporte en papel para adaptarse a los nuevos requerimientos de la sociedad de la información con su lanzamiento como edición electrónica, más accesible a los ciudadanos, mediante el decreto que el Consejo de Gobierno ha acordado tras recibir el dictamen favorable del Consejo Consultivo de la Comunidad.
Con esta iniciativa se facilita y simplifica la consulta de este servicio público, que avanza en el proceso de implantación de la sociedad de la información y fomenta la preservación y el respeto del medio ambiente.
El futuro decreto es que el Organismo Autónomo Boletín Oficial se responsabilizará de garantizar la autenticidad, integridad e inalterabilidad de su contenido a través de la firma electrónica avanzada. Su edición se realizará conforme a los principios de accesibilidad, usabilidad, utilización de estándares abiertos y una adaptación al progreso tecnológico.
Vía: Solidaridad Digital
por Lucia Navarro, el 29/01/2010 11:14 CET
El CESyA edita una guÃa sobre el uso del subtitulado en la TDT
El Centro Español de Subtitulado y Audiodescripción ha publicado una guía informativa sobre el subtitulado en la TDT donde explica el uso de esta herramienta y los sintetizadores que permiten el uso de ella.
Los subtítulos en la TDT están pensados sobre todo para personas con discapacidad auditiva, mayores y quienes están aprendiendo un idioma.
El subtitulado en la TDT, denominado técnicamente subtítulo DVB (Digital Video Broadcast), es más avanzado que el de teletexto, ya que permite utilizar más colores, tipografías y formatos de texto.
La guía, llamada "Los subtítulos en la TDT ¿Qué debe saber?", es fruto de una investigación del CESyA en colaboración con la confederación de familias de personas sordas FIAPAS.
Vía: Solidaridad Digital
por Lucia Navarro, el 29/01/2010 11:01 CET
28 de enero de 2010
Programar a ciegas
Apple iPad, el cuaderno accesible
Apple presentó ayer, en su primera Keynote del año, su nuevo dispositivo, el iPad.
Este dispositivo es una delgada pantalla táctil de 9,7 pulgadas y un peso de 680g. Incorpora micrófono, altavoz, brújula digital, acelerómetro, conectividad inalámbrica y capacidad multitáctil en su pantalla.
El dispositivo estará a la venta denta en Marzo, en su versión Wifi, y en Abril en su versión Wifi/3G. Por esta razón aún faltan caracterÃsticas por conocer.
La red está llena de caracterÃsticas y comentarios sobre el hardware del iPad. Por esta razón nos centraremos en este artÃculo en su accesibilidad.
Un iPod touch de grandes dimensiones
El iPad utiliza una versión de iPhone OS, el sistema operativo para iPhone y iPod touch. Esto hace que su aprendizaje resulte muy sencillo y enfocado a utilizar el dispositivo con una mano. Además, iPad incorpora todos los mecanismos de accesibilidad que ya hemos visto en iPhone 3G S e iPod touch 3g.
Lector de pantallas
El iPad lleva la última versión de voiceOver, el lector de pantallas para iPhone OS. Este lector de pantallas permite acceder a todas las funciones del dispositivo mediante gestos y explorar la pantalla con un dedo.
VoiceOver utiliza la sÃntesis de voz incorporada en el dispositivo. El iPad incluye soporte para 21 idiomas.
La duda es si esta versión de voiceOver incorporará gestos especiales para iPad.
Zoom
El iPad, al igual que el iPhone, incorpora un magnificador de pantallas. Esto unido al gran tamaño de la pantalla y su gran resolución hacen que el magnificador resulte muy apropiado para personas con discapacidad visual.
Contraste de color
El iPad incorpora un sistema de ato contraste denominado blanco&negro que ayudará a as personas que requieran de un interfaz de alto contraste para apreciar los elementos de la pantalla.
Control del canal sonoro
El iPad permite controlar los canales de audio para aquellas personas con hipoacúsia localizada en un oÃdo.
Lo nuevo frente a lo conocido
El iPad, como mucha gente ha criticado, es una especie de iPod touch de grandes dimensiones. La gente que ya tiene un iPhone o un iPod touch pueden pensar que no necesitan un iPad y puede que tengan razón, sobre todo en el caso de personas ciegas, a las cuales no nos importa el tamaño de la pantalla. Pero junto con iPad ha aparecido unas cuantas nuevas aplicaciones donde una pantalla grande es algo muy importante.
Lectura de libros electrónicos
Junto con la presentación de iPad Steve Jobs presentó también eBooks. Esta nueva aplicación de la appStore, la tienda de aplicaciones de Apple para sus dispositivos móviles, permite el acceso a la nueva tienda eBookStore, donde comprar libros en formato ePub, y poder leerlos en una cómoda pantalla del tamaño de un clásico cuaderno escolar.
La aplicación eBooks permite controlar el tipo y tamaño de fuente de letra por lo que podemos deducir que la aplicación será accesible con el lector de pantallas.
Apple ha establecido contratos con importantes editoriales para distribuir libros en formato electrónico para su iPad. Estas editoriales, principalmente, son de caracter educativo y es aquà donde Apple ha marcado la diferencia con los lectores de libros electrónicos en el mercado.
Mientras que un lector de libros electrónicos como el Kindle o el Sony PRS eBook reader mantienen una página escrita y con gráficos en 16 tonos de grises el iPad puede presentar una página en color y donde en lugar de utilizar un dibujo para explicar un experimento de ciencias naturales se muestre un vÃdeo con el desarrollo del experimento. Con el iPad parece que comienza la evolución del libro de estudio.
Unido esto a que el iPad es accesible según la ley 508 de EEUU hace que este dispositivo de Apple sea el candidato principal para ser adquirido por bibliotecas, universidades y escuelas en EEUU ya que ni Kindle ni otros lectores de libros electrónicos han incorporado soporte para productos de apoyo para usuarios discapacitados.
Mayor superficie de visión y de control
Los usuarios con discapacidad visual parcial que utilicen magnificación de pantalla estarán de enhorabuena. El iPhone resultaba algo engorroso para ciertas tareas, como la lectura de correo electrónico, navegación por la Web o la lectura de documentos. Con la ampliación del tamaño de la pantalla y el zoom integrado todos estos problemas desaparecen.Los usuarios con problemas de motricidad que utilizaban el iPhone con un apuntador sujeto por la boca se quejaban de que la pantalla de 3,5 pulgadas del iPhone era demasiado pequeña como para una selección precisa de un elemento. Con una pantalla de 9,7 pulgadas este problema desaparece y como se ha utilizado la misma tecnologÃa de pantalla que para iPhone el apuntador es compatible con ambos dispositivos.
Ofimática
Por muy intuitivo que resulte el manejo de un iPhone hay tareas que resultan muy engorrosas con este dispositivo. Por ejemplo, a nadie se le ocurre escribir y editar un artÃculo, informe o redacción con un iPhone. La posibilidad de hacerlo está pero de hacerlo cómodo no la tiene. En cambio iPad proporciona un teclado virtual que ocupa toda la pantalla, permite escribir con 2 manos y, además, Apple presentó ayer un teclado externo compatible con iPad.
El problema es que las aplicaciones ofimáticas que hay para iPhone no están preparadas, todavÃa, para iPad por esta razón Steve Jobs presentó también iWork para iPad.
iWork es el paquete ofimático de Apple. Los usuarios de MacOS X conocemos ya a este paquete ofimático en el que se incluye un editor de textos, Pages, una hoja de cálculo, Numbers, y un gestor/visualizador de presentaciones, Keynote.
La versión para iPad está optimizada para ser utilizada con un dedo y de forma más intuitiva que la versión para MacOS X. Lo interesante es que podremos comprar cada aplicación por separado a un precio de $9.99 cada aplicacion por lo que tener Pages, Numbers y Keynote en nuestro iPad nos costarÃa menos de $30.
Además, gracias a la existencia del teclado externo, editar un documento de forma rápida es posible.
Un duro competidor en el ocio electrónico
El iPad es compatible con las 140000 aplicaciones que existen en la appStore para iPhone y iPod touch. De estas 140000 aplicaciones hay más de 30000 juegos. Con su pantalla táctil de gran tamaño el iPad se convierte en un tablero de juego interactivo muy atractivo que puede cambiar el concepto de videoconsola portatil gracias a su gran pantalla y sus caracterÃsticas hardware.
El ideal compañero del estudiante
Con todo lo que se ha expuesto en este artÃculo se puede deducir que el iPad es el ideal compañero del estudiante. Con acceso a la Web mediante Safary mobile, el navegador web de iPhone e iPad, para consultar la prensa electrónica, Wikipedia o el aula virtual de la escuela o la facultad; eBooks para leer los libros de cada asignatura; iWork para hacer los deberes y trabajos y los juegos para los momentos de ocio el estudiante puede tener todas sus herramientas en un sólo dispositivo de menos de 700g de peso y, además, accesible.
Multitud de posibilidades
El iPad amplia las posibilidades que tenÃamos los usuarios de iPhone al incorporar una pantalla más grande ya que hay actividades donde el tamaño si importa.
Mobile speak 4 ya está aquÃ
La empresa Codefactory publicó ayer la nueva versión de su lector de pantallas para dispositivos móviles.
Esta nueva versión del lector de pantallas permite mover la licencia del usuario entre varios teléfonos por lo que podremos utilizar nuestro teléfono Symbian y nuestro SmartPhone con Windows mobile.
Mobile speak 4 permite el acceso a dispositivos móviles táctiles con Symbian y Windows mobile por lo que es compatible con los últimos teléfonos con pantalla táctil que han salido al mercado con sistemas operativos Symbian y Windows mobile 6.5. Para conseguir esto la gente de Codefactory ha incorporado a Mobile speak la capacidad de detectar gestos en la pantalla por lo que se podrán controlar las diversas funciones del lector de pantallas mediante movimientos sobre la pantalla del teléfono.
Las voces disponibles son las conocidas de Acapela y Loquendo por lo que podremos disfrutar de voces de calidad.
27 de enero de 2010
Accesibilidadweb.com
Una alternativa al JavaScript no basta para que sea accesible
En muchas ocasiones se tiene la idea errónea que basta con proponer y desarrollar una alternativa a una función que realicemos en JavaScript para haber solventado un problema de Accesibilidad Web ya que los usuarios que usen alguna herramienta de ayuda no disponen de dicha tecnologÃa.
Pero las encuestas nos dicen lo contrario, que existe una mayorÃa muy amplia de usuarios que utilizan herramientas de ayuda y que ejecutan JavaScript asà que aparte debemos comprobar que nuestra funcionalidad es igualmente accesible con dicha tecnologÃa.
Roger Johansson habla brevemente sobre ello y expone como ejemplos el uso, en ocasiones abuso, de los efectos ligthbox (las ampliaciones que nos aparecen en grande oscureciendo el resto de la pantalla), calendarios, controles de formulario personalizados, etc…. todos ellos funcionales sin tecnologÃa JavaScript pero con carencias de acceso por teclado o mediante un lector de pantalla ejecutando código JavaScript.
Fuente: Unobtrusive JavaScript is not necessarily accessible JavaScript
por Félix Zapata, el 27/01/2010 22:00 CET
Imágenes de fondo y modos de alto contraste
Una de las cosas en las que a veces podemos no darnos cuenta en un desarrollo es la visualización de imágenes de fondo aplicadas mediante hojas de estilo (CSS) en un sistema operativo configurado con alto contraste.
En el blog de The Paciello Group hablan de ello y ponen dos ejemplos con el editor de entradas de Wordpress:
Editor de entradas de Wordpress en modo normal
Editor de entradas de Wordpress en alto contraste
Parece ser que algunos modos de alto contraste pueden llegar a ocultar las imágenes utilizadas como fondo.
En el artÃculo proponen alguna solución mediante hojas de estilo para usar alguna alternativa.
Otra opción siempre puede ser evaluar si merece la pena o no que usemos la imagen como fondo. Obviamente esto dependerá mucho de la página en cuestión ya que hay veces que el uso de fondos está muy claro mientras que en otras ocasiones se puede optar de este modo por simple optimización de recursos y/o por facilitar un efecto de cambio al pasar el usuario por encima de un enlace por ejemplo.
Fuente: High Contrast Proof CSS Sprites
por Félix Zapata, el 27/01/2010 21:44 CET
Seraccesible
La Universidad de Valencia implanta un software de ayudas técnicas a la discapacidad
La Universidad de Valencia ha implantado un sistema centralizado de aulas informáticas que actúa como control remoto para la propagación de un programa a centenares de equipos en cualquier entorno del centro, con lo que se convierte en pionera del software de ayudas técnicas a la discapacidad.
El sistema contempla intervenciones a las aulas informáticas de acceso libre, a las bibliotecas y en algunas aulas convencionales de la Universidad de Valencia, así como acciones específicas para mejorar la accesibilidad de los servicios y aplicaciones web.
Estas medidas tienen como objetivo hacer que los estudiantes disponen de servicios de alto nivel tecnológico y, a su vez, que los estudiantes con discapacidad tengan las mismas oportunidades que los otras estudiantes.
Vía: Solidaridad Digital