Una función de accesibilidad no vive al margen de la versión del juego. Puede estar presente en PC y faltar en consola, cambiar de ruta tras un parche o comportarse de otra manera según el idioma. Por eso, una lista genérica de opciones envejece mal: mezcla observaciones hechas en entornos distintos y no permite saber qué dato sigue vigente.
Un registro de accesibilidad por versión resuelve ese problema al vincular cada hallazgo con una plataforma, una edición, una build, una fecha y un recorrido de prueba. La plantilla que sigue sirve para conservar esa trazabilidad. No puntúa al juego, no sustituye una prueba con personas usuarias y no certifica cumplimiento legal; documenta evidencia y deja visibles sus límites.
Para qué sirve un registro de accesibilidad por versión
El registro permite comparar revisiones sin presentar sus diferencias como contradicciones. Si un parche añade escalado de texto, la observación anterior no era necesariamente errónea: correspondía a otra build. Mantener ambas entradas muestra qué cambió y evita que una mejora reciente se atribuya también a ediciones que no la recibieron.
Antes de abrir el registro conviene decidir qué mirar al elegir un videojuego accesible. Esa guía ayuda a formular las preguntas; el registro se ocupa de asociar cada respuesta con su entorno, su procedencia y la parte del juego realmente recorrida.
También obliga a evitar conclusiones demasiado amplias como «es accesible». Una función puede ayudar a unas personas y no a otras, depender de un periférico o quedar fuera de un modo. Microsoft, por ejemplo, indica que una etiqueta de función sólo debe asignarse cuando se cumplen todos sus criterios aplicables, no por la mera presencia nominal de una opción. Es una regla de su sistema, no una certificación universal (documentación de Accessibility Feature Tags de Xbox).
Datos previos: plataforma, edición y build
Crea una cabecera nueva para cada combinación comprobada. Incluye título, desarrollador o editor, edición, plataforma y modelo de hardware cuando sea relevante. Anota el número de build o parche y la fecha de la observación. Si el juego no muestra una compilación clara, registra la versión que presenta el sistema o la fecha de la última actualización instalada y señala esa limitación.
No copies un resultado de una plataforma a otra sin evidencia. El menú narrado, el remapeo o la ruta para llegar a los ajustes pueden variar aunque el contenido principal parezca idéntico. Una remasterización, una edición completa y un servicio en la nube también necesitan entradas propias cuando no se ha demostrado que compartan comportamiento.
Idioma, región y dispositivos usados
Registra la región y los idiomas de texto, voces y subtítulos. La localización puede afectar a la legibilidad, la identificación de hablantes o la documentación disponible. Añade los dispositivos empleados —mando, teclado, ratón, pantalla táctil o tecnología de apoyo— y cualquier condición que pueda influir en el resultado.
La Xbox Accessibility Guideline 121 recomienda que la documentación de cada juego sea localizable, explique funciones, guías y soporte, y esté disponible en los idiomas pertinentes (XAG 121 sobre documentación accesible). Esa recomendación ayuda a revisar la calidad de la información, pero no demuestra por sí sola que una función esté implementada.
Recorrido de prueba y secciones no comprobadas
Enumera las áreas recorridas: primer arranque, configuración inicial, menús, tutorial, partida, pausa, guardado, multijugador o comunicación. Una comprobación parcial puede ser útil si se describe como tal. «Los subtítulos se observaron durante el tutorial y el primer capítulo» informa mejor que «el juego tiene subtítulos completos» cuando no se revisó el contenido posterior.
Anota también lo que quedó fuera. No encontrar una opción durante un recorrido limitado debe constar como «no comprobado» hasta agotar una ruta de verificación suficiente. Esa expresión describe el estado de la evidencia; no afirma que la función no exista.
Registro de accesibilidad por versión: plantilla
Copia esta tabla dentro de la entrada correspondiente y dedica una fila a cada función o barrera. No agrupes ajustes con comportamientos diferentes: tamaño del texto, contraste y dependencia del color necesitan observaciones separadas. Si un campo no aplica, explica por qué; si falta evidencia, conserva «no comprobado».
| Área | Función o barrera | Estado de evidencia | Plataforma y build | ¿Activa por defecto? | Ruta de configuración | Qué permite | Excepciones y límites | Fuente y fecha |
|---|---|---|---|---|---|---|---|---|
| Indica la categoría funcional. | Nombra una función o barrera concreta. | Usa uno de los cuatro estados definidos más abajo. | Anota sistema, edición y versión exacta. | Responde sí, no o no comprobado. | Describe los pasos desde el arranque. | Explica el efecto observable sin prometer resultados universales. | Delimita modos, idiomas, escenas o dependencias. | Enlaza la evidencia y fecha la consulta o prueba. |
Campos visuales, auditivos y de entrada
En el área visual, separa tamaño y legibilidad del texto, contraste, uso del color, escala del HUD, campo de visión, movimiento de cámara y efectos intensos. En la auditiva, registra subtítulos, identificación de hablante, descripción de sonidos relevantes, señales visuales y controles independientes de volumen. Indica si cada ajuste cubre cinemáticas, conversaciones ambientales y contenido generado durante la partida.
Para entrada y movilidad, documenta remapeo, alternativas a mantener o pulsar repetidamente, sensibilidad, zonas muertas, uso con un solo stick y cambio entre dispositivos. La ruta para alcanzar el ajuste importa: una opción presente pero inaccesible antes de un tramo obligatorio todavía puede crear una barrera.
Cognición, navegación, dificultad y comunicación
Describe por separado ayudas de navegación, repetición de instrucciones, tutoriales, diario de objetivos, control de velocidad, pausa y ajustes de dificultad. Señala si el cambio afecta a logros, recompensas o modos concretos. «Dificultad baja» no equivale automáticamente a accesibilidad cognitiva: la carga de memoria, la claridad del lenguaje y el tiempo de respuesta son dimensiones distintas.
En juegos conectados, añade chat de texto, voz a texto, texto a voz, indicadores no sonoros, silenciamiento, moderación y alternativas a la comunicación simultánea. Cuando intervenga un servicio de terceros, identifica esa dependencia y no atribuyas su funcionamiento al juego.
Cómo separar pruebas, declaraciones e informes
Asigna a cada fila uno de estos estados. Mantenerlos separados permite corregir o ampliar el registro sin borrar la procedencia del dato:
- Verificado en prueba editorial: observado de forma reproducible en el entorno y recorrido registrados. Incluye la ruta y cualquier excepción.
- Declarado por el editor o la plataforma: procede de una página oficial fechada, pero no se comprobó de manera independiente.
- Informe externo: atribuye el hallazgo al medio, especialista o persona que lo publicó y enlaza el análisis original.
- No comprobado: no hay evidencia suficiente o la función quedó fuera del recorrido. No significa que la función no exista.
Accessible Games Initiative explica que sus etiquetas buscan comunicar con claridad las funciones disponibles y publica criterios técnicos abiertos (criterios de Accessible Games Initiative). Esas etiquetas ayudan a localizar información, pero su presencia no reemplaza los detalles sobre build, activación, cobertura y límites. Una página comercial sigue siendo una declaración mientras no exista una comprobación editorial reproducible.
Barreras, dependencias y excepciones
Añade un bloque para lo que la tabla puede ocultar: conexión obligatoria, cuenta externa, suscripción, periférico, cooperación o ayuda de otra persona. Registra las secciones no recorridas y posibles bloqueos de progreso. Una opción puede funcionar en la campaña y faltar en multijugador, o estar disponible en un idioma y no en otro.
Da prioridad a formulaciones observables. «El tamaño del texto no cambia en el inventario de esta build» aporta más que «el texto tiene fallos». Para ordenar la comprobación puede usarse Game Accessibility Guidelines, que agrupa recomendaciones por categorías y niveles de implementación. Esos niveles sirven para organizar preguntas; no son una nota de calidad del juego.
Actualizar el registro de accesibilidad por versión
Cierra cada entrada con la fecha de última revisión, la fuente oficial vigente y un historial breve. Tras un parche, una edición nueva, un cambio de idioma o una migración de plataforma, revisa los campos afectados y crea una nueva entrada cuando cambie la combinación registrada. La guía de uso de Accessible Games Initiative también recomienda mantener actualizada la información cuando evolucionan el juego o los criterios (guía de uso de las etiquetas, PDF).
No sobrescribas sin más una barrera corregida. Mueve la observación anterior al historial, conserva su build y fecha, y añade la evidencia nueva. Así puede saberse si la mejora llegó a todas las ediciones o sólo a una rama del juego.
El registro está listo cuando cada afirmación responde quién la sostiene, cuándo se revisó, en qué entorno se aplica y qué quedó fuera. Puede contener varios «no comprobado»: esos huecos muestran dónde termina la evidencia y cuál es la siguiente revisión útil. Esa honestidad hace que el documento pueda crecer con el juego sin arrastrar promesas que nunca estuvieron demostradas.
