Capacidades y privacidad de WebGL: guía práctica para aplicaciones

WebGL ofrece a las aplicaciones web una superficie gráfica gestionada por el navegador para contenido interactivo en 2D y 3D. Es adecuado cuando una tarea requiere dibujar con frecuencia, interacción espacial o trabajo gráfico que los elementos normales de una página no expresan con claridad. Un uso de WebGL respetuoso con la privacidad empieza con una pregunta más concreta que «¿qué puede revelar este dispositivo?»: qué resultado gráfico pidió la persona, qué nivel de compatibilidad necesita y qué alternativa útil queda si la opción preferida no está disponible.

La compatibilidad no es una simple propiedad de sí o no. En un entorno concreto, un navegador puede ofrecer WebGL 1, WebGL 2, ambos o ninguno. Una función disponible en un dispositivo puede faltar en otro por las políticas del navegador, el software gráfico, las decisiones del sistema operativo o los límites de recursos. La aplicación debe tratar estas diferencias como datos de compatibilidad, no como motivo para recopilar un perfil detallado del dispositivo.

Esta distinción separa la gestión normal de capacidades del seguimiento. Una aplicación gráfica puede necesitar saber si puede presentar una escena solicitada. Rara vez necesita conservar un inventario amplio del dispositivo que motivó esa decisión. Para conocer la técnica de seguimiento y su impacto en la privacidad, consulta la introducción a la huella de WebGL. Para la API gráfica más reciente y su modelo de compatibilidad independiente, consulta la guía de privacidad de WebGPU.

Elige WebGL para una tarea gráfica concreta

Empieza por el resultado que la persona debe ver o controlar. WebGL se usa en mapas interactivos, vistas de productos, visualización científica, juegos, simulaciones y efectos de imagen. Estas tareas pueden implicar muchos objetos, actualizaciones frecuentes o cambios que aprovechan una canalización gráfica específica. La elección se justifica cuando hace posible la tarea de cara al usuario o la mejora de forma significativa.

No todo elemento visual necesita WebGL. Una ilustración estática puede funcionar mejor como imagen. Un gráfico sencillo puede ser más fácil de leer, imprimir y recorrer si usa elementos semánticos de página o un componente accesible. Los controles básicos pertenecen a HTML, donde las etiquetas, el foco, la selección de texto, la traducción y la tecnología de asistencia cuentan con un soporte conocido. Elegir una superficie más sencilla reduce el trabajo y las decisiones de compatibilidad que debe gestionar la aplicación.

La distinción también importa para la privacidad. Si una página usa WebGL solo para un resultado visual concreto, puede limitar las comprobaciones a ese resultado. Una página que inicializa gráficos sin un propósito visible y recopila muchos detalles del entorno establece otra relación con la persona. La API técnica puede ser la misma, pero cambian el propósito de los datos, su conservación y las expectativas del usuario.

Define la experiencia mínima antes de empezar a implementar. Identifica la escena, las interacciones importantes, la calidad visual aceptable y el punto en que una representación más sencilla basta. Una vista de producto puede necesitar rotación y zoom, pero no efectos cinematográficos. Una visualización de datos puede requerir selección clara y etiquetas, pero no animación continua. Estas decisiones ayudan a solicitar únicamente el soporte gráfico realmente utilizado.

Siempre que sea posible, deja las acciones principales fuera de la superficie de dibujo. La navegación, las compras, las acciones de cuenta, las opciones de consentimiento y los enlaces de ayuda deben seguir siendo controles normales de la página. La escena WebGL puede apoyar la tarea sin convertirse en la única forma de recorrerla. Esto también facilita la recuperación si el contexto gráfico deja de estar disponible después de cargar la página.

El movimiento y la densidad visual necesitan límites propios. Una escena animada puede comunicar cambios espaciales, pero el movimiento continuo puede distraer o causar molestias. Respeta la preferencia de movimiento reducido, ofrece controles para pausar cuando el movimiento no sea esencial y no hagas depender las instrucciones de una animación breve. La persona debe poder entender el estado de la experiencia cuando la escena está quieta.

El consumo de recursos también es una decisión de producto. Las escenas detalladas pueden consumir memoria, batería y tiempo de procesamiento. La aplicación debe ajustar su contenido según el desempeño de la tarea y las preferencias explícitas de calidad, no intentar inferir una identidad detallada del dispositivo. Permite elegir menos detalle cuando sea útil y conserva la tarea principal al quitar efectos opcionales.

Un propósito acotado también facilita el mantenimiento. Si una actualización del navegador cambia el comportamiento gráfico, el equipo puede comparar el resultado afectado con un requisito definido. Sin ese requisito, el trabajo de compatibilidad tiende a convertirse en una búsqueda abierta de diferencias del entorno. Asignar claramente la tarea convierte WebGL en un componente de aplicación delimitado, no en una consulta general del entorno.

Trata el soporte de WebGL como un contrato de compatibilidad

Las especificaciones WebGL de Khronos definen el contrato de plataforma de WebGL y WebGL 2. MDN documenta la API desde la perspectiva de una aplicación y describe la relación entre ambas generaciones. WebGL 2 añade capacidades de plataforma respecto de WebGL 1, pero no debe suponerse que está disponible solo porque el navegador sea reciente. El entorno efectivo incluye navegador, sistema operativo, plataforma gráfica, políticas administrativas y estado actual de los recursos.

Por eso, la aplicación necesita un nivel mínimo de soporte explícito. Decide si basta WebGL 1, si se requiere WebGL 2 o si la experiencia tiene distintos niveles de calidad. Vincula la decisión con funciones visibles. Si una función depende realmente del contrato más reciente, explica por qué la ruta anterior no puede ofrecer el mismo resultado. Si la diferencia solo afecta al acabado visual, conserva la interacción principal en la ruta más amplia.

Las comprobaciones de capacidades deben responder a una pregunta concreta de la aplicación. Por ejemplo, si se puede crear el contexto requerido, si la escena se puede representar con la calidad admitida o si se puede usar una entrada multimedia necesaria. Detén las comprobaciones cuando haya información suficiente para elegir una ruta compatible. No hace falta un inventario completo del entorno para elegir entre una escena normal, una reducida y una alternativa sin WebGL.

La creación del contexto puede fallar aunque la visita anterior haya funcionado. Una persona puede cambiar ajustes del navegador, una actualización del sistema puede modificar el soporte gráfico, un administrador puede aplicar una política o el navegador puede rechazar la solicitud en las condiciones actuales. Trata el fallo como una rama normal del producto. No dejes un lienzo en blanco, una carga interminable ni un control desactivado sin explicación.

El soporte también puede cambiar mientras la página está abierta. El navegador puede perder un contexto gráfico si recupera recursos o cambia el entorno de gráficos. Conserva la interfaz circundante, explica lo ocurrido con palabras sencillas y ofrece una acción de recuperación limitada. Si restaurar la escena pudiera descartar trabajo sin guardar, explícalo antes de reintentar y, cuando sea práctico, conserva el estado de la aplicación fuera de la superficie gráfica.

No conviertas cada diferencia del entorno en una variante del producto. Es más fácil probar y explicar unos pocos niveles basados en resultados que muchas ramas específicas por dispositivo. Por ejemplo, un modo normal, otro con efectos reducidos y una alternativa estática son experiencias concretas de las que el equipo puede hacerse cargo. También limitan la información de capacidades que debe procesar la aplicación.

Asigna claramente la responsabilidad del soporte por versión. Registra las familias y versiones de navegadores admitidas, la generación WebGL que necesita cada experiencia y la alternativa fuera de ese intervalo. Este registro pertenece a la política de compatibilidad del producto. No debe prometer que todos los controladores o dispositivos gráficos producirán píxeles idénticos.

Las declaraciones de compatibilidad deben describir resultados, no detalles internos. «Se puede rotar de forma interactiva» resulta útil. Una lista larga de detalles gráficos subyacentes es más difícil de interpretar y puede exponer información innecesaria para la decisión. El lenguaje centrado en resultados también permanece estable cuando el navegador cambia su implementación pero conserva el comportamiento visible.

Revisa el contrato cuando el producto incorpore una técnica visual, aumente la complejidad de la escena, cambie las entradas multimedia o exija WebGL 2. Una nueva versión del navegador no obliga por sí sola a reescribir la política. Cambia el contrato cuando cambien los requisitos del usuario o las pruebas verificadas de compatibilidad.

Crea mejora progresiva y alternativas útiles

La mejora progresiva mantiene la página útil antes de confirmar la ruta gráfica preferida. Primero presenta con HTML normal el contenido, los controles, las etiquetas y el estado que rodean la escena. Añade WebGL cuando el navegador pueda realizar la tarea requerida. Así, la persona recibe algo comprensible aunque los scripts tarden en cargar, falle el inicio gráfico o una política impida crear el contexto.

Las alternativas deben conservar el propósito, no imitar cada detalle visual. Una vista tridimensional de un producto puede recurrir a una galería de imágenes seleccionadas. Un mapa interactivo puede ofrecer una lista consultable, un resumen de ruta o un mapa estático adecuado a la tarea. Una visualización científica puede incluir una tabla, los hallazgos principales y un formato descargable. Si un juego no tiene una interacción equivalente, puede mostrar un mensaje claro de incompatibilidad, pero las acciones de cuenta y compra deben seguir funcionando.

La alternativa debe reflejar el mismo estado de los datos. Si los filtros cambian la visualización WebGL, la tabla o el resumen deben reflejar esos filtros. Si una opción de producto cambia el modelo representado, también deben cambiar la galería de imágenes y el texto descriptivo. Dos representaciones que no coinciden crean un problema de accesibilidad y otro de corrección del producto.

No presentes una menor calidad visual como un error si todavía permite completar la tarea. Una escena con menos efectos puede ser un modo admitido, no una versión dañada de la opción preferida. Explica las diferencias que afecten a la interacción o al significado, sin cargar al usuario con detalles de implementación. Un control sencillo de calidad ofrece una elección predecible sin exigir que la persona conozca su entorno gráfico.

La carga también necesita una alternativa definida. Las escenas y texturas grandes pueden tardar incluso cuando WebGL está disponible. Muestra avances que correspondan al trabajo real de la aplicación, mantén disponible la cancelación y evita iniciar descargas pesadas antes de que la persona acceda a la función. Si falla un recurso opcional, conserva las partes de la escena que todavía permiten cumplir la tarea en lugar de descartar toda la experiencia.

La red puede afectar a una experiencia WebGL independientemente del soporte gráfico. El navegador puede crear el contexto correctamente y, aun así, no tener disponible un modelo, una imagen o un archivo de datos. Informa de estas condiciones por separado. Decir que WebGL no es compatible cuando falta un recurso conduce a decisiones de soporte incorrectas y a recopilar capacidades innecesarias.

Conserva las entradas del usuario durante los cambios de ruta. Si alguien configura un producto, selecciona una ubicación o cambia un intervalo de datos antes de que falle el inicio gráfico, conserva esas opciones en la alternativa. No obligues a repetir el trabajo porque haya cambiado la capa de presentación. Mantener el estado de la aplicación fuera de la escena facilita esa continuidad.

Cuando se agota el intento acotado de recuperación, deja de reintentarlo y muestra la alternativa HTML equivalente con los mismos datos de tarea y controles esenciales. Conserva el estado de la aplicación que ya estuviera fuera del lienzo; no afirmes que puede recuperarse un estado que solo existía dentro del contexto perdido. Este es un límite del flujo del producto: el fixture actual solo observó una restauración correcta y no verificó la rama de restauración fallida.

Prueba las alternativas de forma intencional. Comprueba la experiencia sin WebGL, sin WebGL 2, con recursos opcionales bloqueados, con carga lenta de recursos y con pérdida del contexto durante la interacción. Estas pruebas ejercitan rutas del producto, no identifican dispositivos. El resultado esperado es un estado utilizable con acciones claras, no un catálogo de las diferencias de cada entorno.

Vincula la ayuda de soporte con síntomas observables. Las instrucciones pueden explicar cómo reintentar, cambiar a una vista sencilla, conservar el trabajo o contactar con soporte mediante una referencia de error normal. No pidas por defecto un informe gráfico amplio. Si un caso requiere datos de diagnóstico, solicita solo lo pertinente, explica el propósito y fija un plazo de conservación.

Mantén accesible la experiencia fuera del mapa de bits

Un lienzo WebGL presenta píxeles. Los objetos dibujados dentro no se convierten automáticamente en encabezados, botones, campos de formulario u orden de lectura significativo para la tecnología de asistencia. La accesibilidad depende de la interfaz alrededor del lienzo y de la información equivalente que ofrezca la página.

Asigna al contenido visual un nombre y una descripción accesibles que expliquen su propósito. «Vista interactiva del producto» es más útil que «lienzo WebGL». Si la escena representa datos, ofrece los valores, relaciones o conclusiones importantes en texto o contenido estructurado. Si permite realizar acciones, proporciona controles que puedan alcanzarse y entenderse sin depender de la posición del puntero dentro de la imagen.

El acceso mediante teclado requiere un modelo de interacción real. La persona debe poder llegar a la función, conocer las acciones disponibles, mover el foco de forma predecible y salir sin quedar atrapada. Los botones normales para ampliar, restablecer, pausar, cambiar de vista y realizar otras acciones principales son más fáciles de identificar y usar que las zonas invisibles de un dibujo. Mantén visible el indicador de foco tanto sobre la página como sobre la escena.

No expreses el significado solo mediante color, profundidad, movimiento o detalles visuales finos. Los gráficos necesitan etiquetas y patrones distinguibles. Los mapas necesitan información textual de ubicación. Los cambios de estado requieren un mensaje fuera del efecto visual. Una advertencia que solo aparece como un destello rojo breve puede pasar inadvertida y quizá no se perciba como se esperaba.

El texto dentro de una escena gráfica tiene límites prácticos. Puede no responder al tamaño de texto del navegador, la traducción, la selección, las preferencias de contraste o las herramientas de lectura del mismo modo que el texto HTML. Usa texto de página para instrucciones, etiquetas, avisos legales, precios y demás información que deba leerse con precisión. Reserva el texto dibujado para los casos en que forme parte de la imagen y ofrece el mismo significado en otro lugar.

Respeta las preferencias de movimiento antes de iniciar animaciones. Cuando la persona haya solicitado menos movimiento, reduce o elimina desplazamientos de cámara, efectos de partículas y transiciones automáticas que no sean esenciales. El control de pausa debe detener el movimiento continuo significativo, no limitarse a ocultar un efecto mientras la escena sigue cambiando. El estado quieto debe mostrar la tarea y el resultado actual.

La interacción táctil, con puntero y con teclado debe permitir los mismos resultados importantes. Un gesto puede hacer agradable el uso de una escena, pero no debe ser la única forma de elegir un producto, consultar un dato o continuar un flujo de trabajo. Proporciona controles e instrucciones para las formas de entrada admitidas y no deduzcas cómo interactuará la persona a partir del tamaño de la pantalla.

Las pruebas de accesibilidad deben cubrir los mismos estados del producto que las pruebas visuales. Como recomendación de aceptación, comprueba la ruta WebGL preferida, la reducida, la alternativa, la carga, los mensajes de fallo y la recuperación del contexto. Verifica nombres, orden del foco, operación mediante teclado, avisos de lectores de pantalla, zoom, contraste y movimiento reducido con herramientas adecuadas al público. El fixture de runtime actual solo comprobó el nombre del lienzo y el texto visible de la alternativa; no verificó estos comportamientos, por lo que esto sigue siendo una recomendación y no un resultado del fixture. Una escena que solo supera una revisión visual no está completa.

Si no es viable ofrecer una interacción no visual totalmente equivalente, explica la limitación con honestidad y ofrece la ruta práctica más cercana al mismo resultado. Puede ser una vista estructurada de datos, un proceso con ayuda de soporte o un formulario alternativo. La limitación debe ser una decisión de producto con responsable, no la suposición de que todas las personas pueden operar la imagen.

Limita los datos de privacidad a la decisión del producto

La extensión WEBGL_debug_renderer_info expone las cadenas del fabricante y el renderizador del controlador gráfico. MDN indica que, por lo general, estos datos solo deben usarse en casos puntuales para optimizar contenido WebGL o depurar problemas de GPU, y que la configuración de privacidad del navegador puede restringir la extensión. Para las comprobaciones normales de compatibilidad, basta con determinar si puede ejecutarse la ruta necesaria.

Usa la decisión mínima que permita seleccionar una ruta admitida. Si la aplicación solo necesita saber si puede iniciar su escena normal, no recopiles un informe detallado del entorno. Si debe elegir entre dos niveles de calidad propios, guarda el nivel seleccionado en vez de todas las entradas que llevaron a esa opción. La minimización facilita documentar, probar y retirar el comportamiento.

Mantén la información de compatibilidad en la sesión cuando no sea necesario conservarla a largo plazo. La página puede elegir una ruta gráfica para la visita actual sin convertir esa elección en un identificador persistente. Si resulta útil recordar una preferencia de calidad elegida por la persona, guárdala como una opción que pueda entender y cambiar. No presentes un perfil técnico inferido como si lo hubiera elegido el usuario.

No combines la información gráfica con datos de cuenta, red u otros datos del navegador sin una necesidad clara y comunicada del producto. La combinación cambia el impacto para la privacidad aunque cada valor aislado parezca corriente. La guía de privacidad de superficies del navegador explica por qué varias superficies pueden revelar más información que cada una por separado.

Los diagnósticos requieren un tratamiento separado de la compatibilidad durante el uso. Los registros operativos deben guardar el resultado del producto, como un fallo al iniciar la escena o al cargar recursos, sin incluir por defecto un inventario gráfico amplio. Si una investigación de soporte necesita más detalles, solicítalos en el contexto del caso, explica qué se recopilará, limita el acceso y elimínalos según un plazo definido.

No uses las diferencias de capacidades para hacer suposiciones sensibles sobre una persona. El soporte gráfico no establece de forma fiable la identidad, los ingresos, la discapacidad, la ubicación ni la intención. Las decisiones del producto deben limitarse a si puede ejecutarse la visualización solicitada. Las inferencias amplias añaden riesgo para la privacidad sin mejorar la tarea gráfica.

Las bibliotecas gráficas y de analítica de terceros pueden ampliar el flujo de datos. Revisa qué recopila una biblioteca, qué servicios reciben los datos, si la recopilación es necesaria para mostrar el contenido y cuánto tiempo se conserva la información. Cargar un componente por comodidad visual no elimina la responsabilidad de la aplicación sobre los datos que envía.

Si un uso de datos independiente es opcional, el texto de consentimiento debe nombrar el propósito real. Una declaración genérica sobre mejorar el rendimiento no basta cuando se conservarán o compartirán diagnósticos detallados. Ofrece una elección significativa cuando el uso sea opcional y, cuando resulte práctico, mantén la experiencia principal disponible por la ruta admitida menos invasiva.

La revisión de privacidad también debe cubrir los fallos. Una página alternativa puede cargar accidentalmente otro paquete de analítica, pedir un informe de diagnóstico más amplio o mostrar detalles internos del error. Aplica las mismas reglas de minimización y conservación a los estados preferido, reducido y fallido. Que los gráficos no hayan arrancado no justifica recopilar más información sin un propósito claro.

Para esa revisión, captura las solicitudes de red y los registros de soporte u operativos durante el inicio normal, la falta de WebGL 2, la pérdida de contexto y la alternativa HTML. Comprueba que por defecto no se emita un inventario de renderizador o controlador, que los campos de soporte tengan un propósito limitado y que existan fechas definidas de conservación y eliminación. Son comprobaciones de observabilidad recomendadas, no conclusiones de runtime: los fixtures actuales no inspeccionaron tráfico de red, cargas de analítica, campos de registro, controles de acceso ni conservación.

Asigna una persona responsable a cada dato de compatibilidad conservado. Registra quién lo usa, qué decisión depende de él, cuándo caduca y qué ocurre al retirar la función gráfica. Elimina los campos que ya no tengan una decisión vigente a su cargo. Así, mantener la privacidad forma parte del trabajo normal del producto, no de una revisión ocasional de datos sin explicación.

Relaciona las fuentes con las afirmaciones y la evidencia de compatibilidad

Usa especificaciones públicas y documentación de API para relacionar cada afirmación de compatibilidad con un resultado observable de la aplicación:

• Disponibilidad de WebGL y WebGL 2: La especificación WebGL 1.0 de Khronos y la especificación WebGL 2.0, junto con la referencia de la API WebGL en MDN, describen las dos generaciones de contexto y sus capacidades. El resultado de la aplicación se puede verificar: solicita el contexto que necesita la función y elige la escena estándar, la reducida o la alternativa sin WebGL cuando no está disponible. Esta comprobación no requiere un perfil del dispositivo.
• Pérdida y recuperación del contexto: MDN documenta los eventos webglcontextlost y webglcontextrestored. El resultado se puede verificar: conserva el estado fuera del lienzo, anuncia la pérdida, intenta una recuperación limitada y ofrece la alternativa si no se recupera.
• Límite de privacidad de WEBGL_debug_renderer_info: La referencia de la extensión en MDN explica que las cadenas de fabricante y renderizador son opcionales, pueden estar restringidas por la configuración de privacidad y están pensadas para casos extremos de optimización o depuración de GPU. El resultado se puede verificar: la selección normal de compatibilidad funciona sin esta extensión; un diagnóstico de soporte, si hace falta, tiene un propósito explícito y una conservación limitada, en lugar de convertirse en un perfil persistente.

Estos enlaces respaldan afirmaciones sobre el comportamiento de la plataforma; las pruebas del producto deben comprobar los resultados visibles anteriores, sin comparar píxeles, crear perfiles de dispositivos ni intentar identificar un navegador.

Matriz de aceptación para capacidad, alternativa y pérdida de contexto

Usa esta matriz breve como orientación de aceptación de la aplicación. Cada fila incluye una fuente pública, un resultado comprobable y un límite de privacidad; no es una garantía de compatibilidad entre navegadores ni de producción:

Caso	Condición respaldada por la fuente	Resultado observable de la aplicación	Límite de privacidad
Comprobación de capacidad	Creación de contexto según WebGL 1.0 y WebGL 2.0.	Se solicita el contexto necesario; se inicia la escena estándar o reducida, o se elige una representación útil sin WebGL.	Limita el resultado a la decisión de ruta de la sesión. No recopiles datos del renderizador, controlador o versión del navegador solo para elegirla.
Alternativa	Las mismas referencias de API definen cuándo no está disponible el contexto solicitado; la referencia de la API WebGL en MDN describe la superficie de aplicación.	La alternativa conserva el mismo estado de datos, controles esenciales y resultado de la tarea, con un mensaje claro en lugar de un lienzo vacío.	Registra solo el resultado (por ejemplo, context-unavailable); no conviertas esta rama en una solicitud de diagnósticos más amplia.
Pérdida y recuperación del contexto	MDN documenta los eventos webglcontextlost y webglcontextrestored.	La interfaz y el estado permanecen disponibles, se intenta una recuperación limitada y la persona puede elegir la alternativa si falla.	No conserves un inventario gráfico por defecto. Un diagnóstico de soporte debe ser independiente, tener un propósito concreto y conservarse por tiempo limitado.

La aceptación significa que el resultado visible pasa en cada fila; no significa que la aplicación pueda identificar el dispositivo o reproducir píxeles idénticos.

Comprobaciones reproducibles de aceptación de la aplicación

Ejecuta estas comprobaciones con un único accesorio de aplicación y los mismos datos de la tarea. Registra la versión del navegador, la revisión de la aplicación y la rama que se muestra a la persona usuaria. La prueba trata de un resultado propio del producto, no de recopilar una descripción del dispositivo.

Comprobación	Preparación reproducible	Resultado observable	No es un objetivo de privacidad
Creación del lienzo y del contexto	Carga el accesorio, crea el lienzo y solicita el contexto que requiere la función según las especificaciones WebGL de Khronos.	El lienzo informa de un contexto utilizable y la escena estándar llega al estado listo; si la creación devuelve null, la página muestra la alternativa sin WebGL con los mismos datos de tarea.	No leas datos del renderizador, controlador o versión del navegador para explicar un éxito o un fallo.
Función requerida no disponible	Mantén habilitada la creación del contexto y haz que falte la función o extensión WebGL 2 necesaria; usa getExtension() en MDN como referencia.	La aplicación detecta el requisito ausente, elige la ruta reducida o alternativa propia, conserva controles y estado y muestra un mensaje de estado limitado.	No enumeres todas las extensiones disponibles ni infieras una clase de dispositivo a partir de la función ausente.
Pérdida del contexto	Durante la escena lista, activa la ruta de pérdida documentada y observa webglcontextlost.	Los controles fuera del lienzo siguen utilizables, se anuncia la pérdida y la aplicación no entra en un bucle de reinicialización ilimitado.	No conviertas el evento en un inventario gráfico ni en un identificador persistente.
Contexto restaurado o recuperación fallida	Permite webglcontextrestored, o haz que falle el intento limitado de recuperación.	La escena vuelve al estado listo con los datos de tarea conservados, o la persona puede elegir la alternativa con un mensaje claro de recuperación.	No compares píxeles ni conserves campos de diagnóstico fuera del caso de soporte aprobado y limitado en el tiempo.

La aceptación es el estado visible y la tarea completada en cada fila. La identificación del dispositivo, la clasificación del renderizador, la coincidencia de píxeles y afirmar que WebGL demuestra identidad quedan fuera de esta prueba.

Cómo interpretar el resultado de un único accesorio

El registro runtime-20261005 es una muestra de recuperación correcta de la aplicación. El registro complementario webgl-api-capabilities-and-recovery-failure-runtime-20261001 es un modelo determinista del estado de la interfaz: verifica un intento de recuperación limitado, conserva la selección de la persona, mueve el foco, muestra una alternativa HTML equivalente y no genera solicitudes de diagnóstico desde ese accesorio. El modelo no crea un contexto WebGL ni demuestra que un evento webglcontextlost real llegue a un renderizador de producción. Ambos registros son observaciones locales de Chromium, no afirmaciones de compatibilidad entre navegadores ni de producción; repita las comprobaciones reales en cada entorno del que el producto se haga cargo explícitamente.

Valida la compatibilidad sin crear un perfil del dispositivo

Las pruebas de compatibilidad deben partir de resultados visibles para el usuario. Confirma que la escena carga, los controles responden, el contenido esencial se lee con claridad, la tarea puede completarse y las rutas alternativas conservan el estado. Estos criterios siguen siendo útiles tras actualizar el navegador o los gráficos porque describen lo que promete la aplicación.

Usa un conjunto documentado de entornos admitidos en vez de intentar representar todos los dispositivos posibles. Incluye las familias de navegadores, sistemas operativos y versiones relevantes para el producto. Dentro de ese conjunto, cubre la ruta preferida, los niveles inferiores de soporte y la alternativa sin WebGL. El objetivo es confiar en experiencias de las que el equipo se hace cargo, no crear una base de diferencias del entorno.

Limita las escenas de prueba a las funciones del producto. Una prueba de mapa debe ejercitar las capas, etiquetas, selección y navegación que realmente usa. Una prueba de vista de producto debe cubrir carga, rotación, zoom, cambios de opciones y recuperación. Una demostración gráfica genérica puede mostrar que WebGL se ejecuta, pero no prueba los recursos, interacciones y alternativas propios del producto.

Comprueba que el objeto, estado, etiqueta o relación de datos solicitados estén presentes y se puedan usar. Registra los fallos según ese resultado del producto. La prueba debe decidir si la experiencia funciona, no caracterizar el dispositivo.

Separa los cambios del navegador de los cambios de recursos y aplicación. Fija las entradas de prueba cuando la reproducibilidad importe, registra la versión de la aplicación y anota qué versión del navegador se usó. Si cambia una escena, esta información ayuda a distinguir entre un recurso nuevo, un cambio de código, una dependencia actualizada o un cambio de comportamiento del navegador. La evidencia apoya el mantenimiento sin crear un perfil persistente de las personas usuarias.

Prueba la pérdida y recuperación del contexto como comportamiento del producto. Conserva los controles externos, el estado de la aplicación y un mensaje de estado claro. Comprueba que los intentos de recuperación tengan un límite y que la persona pueda elegir la alternativa. Un ciclo que reinicia continuamente gráficos pesados puede empeorar la experiencia y consumir recursos sin restaurar la tarea.

Revisa también la privacidad durante las pruebas. Comprueba que el inicio normal no envíe un inventario gráfico innecesario, que la alternativa no active diagnósticos más amplios y que una preferencia de calidad recordada refleje una elección de la persona, no una inferencia opaca. Confirma que los registros de soporte contengan solo los campos de resultados limitados que aprobó el equipo.

La revisión de versiones debe centrarse en los cambios que afecten al contrato. Una versión nueva del navegador puede modificar la disponibilidad, el rendimiento, el uso de recursos o el resultado visual. Una versión de la aplicación puede incorporar una técnica gráfica o aumentar los requisitos de recursos. Repite las rutas afectadas y actualiza la ayuda solo cuando las pruebas cambien un requisito visible para el usuario.

El proceso de validación de versiones del navegador ofrece un marco más amplio para actualizar de forma controlada. En WebGL, mantén el conjunto de regresión lo bastante pequeño para que cada escena tenga un propósito concreto. Una colección reducida de escenas propias resulta más útil que muchas muestras sin relación con el producto.

WebGL funciona mejor como una capa de presentación acotada, con una tarea clara, un nivel mínimo de soporte escrito, alternativas útiles y pruebas centradas en resultados. Consulta solo las capacidades necesarias para elegir una experiencia de la que el equipo se haga cargo. Mantén las acciones y el significado esenciales fuera de la imagen, limita los diagnósticos conservados y revisa los cambios frente al contrato visible para el usuario. Estas prácticas permiten ofrecer gráficos web capaces sin convertir la compatibilidad en un perfil del dispositivo.

Fuentes públicas

• Especificaciones WebGL de Khronos
• MDN: API WebGL
• MDN: WEBGL_debug_renderer_info