Traducido del inglés al español - www.onlinedoctranslator.

com

Reconocimiento de pantalla: creación de metadatos de accesibilidad para dispositivos móviles

Aplicaciones de píxeles
Xiaoyi Zhang lilian de greef amanda juramento
Apple Inc. Apple Inc. Apple Inc.
xiaoyiz@apple.com ldegreef@apple.com aswearngin@apple.com

samuel blanco kyle murray Lisa yu

Apple Inc. Apple Inc. Apple Inc.
samuel_white@apple.com kyle_murray@apple.com lixiu_yu@apple.com

Shan Qi Jerey Nichols jason wu

Apple Inc. Apple Inc. Apple Inc.
qshan@apple.com jwnichols@apple.com jason_wu2@apple.com

chris fleizach Aaron Everitt Je�rey P. Bigham

Apple Inc. Apple Inc. Apple Inc.
c� eizach@apple.com aeveritt@apple.com jbigham@apple.com

RESUMEN Everitt y Jerey P. Bigham. 2021. Reconocimiento de pantalla: creación de metadatos de

accesibilidad para aplicaciones móviles a partir de píxeles. EnConferencia de CHI sobre
Muchas funciones de accesibilidad disponibles en las plataformas móviles requieren
factores humanos en sistemas informáticos (CHI'21), del 8 al 13 de mayo de 2021, Yokohama,
aplicaciones (apps) para proporcionar metadatos completos y precisos que describan los
Japón.ACM, Nueva York, NY, EE. UU., 15 páginas. https://doi.org/10.1145/3411764. 3445186
componentes de la interfaz de usuario (UI). Desafortunadamente, muchas aplicaciones no
proporcionan suficientes metadatos para que las funciones de accesibilidad funcionen como
se espera. En este documento, exploramos la inferencia de metadatos de accesibilidad para
aplicaciones móviles a partir de sus píxeles, ya que las interfaces visuales a menudo reflejan
1. INTRODUCCIÓN
mejor la funcionalidad completa de una aplicación. Entrenamos un modelo robusto, rápido y
Muchas funciones de accesibilidad (p. ej., lectores de pantalla [10, 38], control de
con uso eficiente de la memoria en el dispositivo para detectar elementos de la interfaz de
botón [8, 36]) solo funcionan en aplicaciones que brindan una descripción completa y
usuario utilizando un conjunto de datos de 77 637 pantallas (de 4068 aplicaciones de iPhone)
precisa de la semántica de su interfaz de usuario (p. ej., class="TabButton",
que recopilamos y anotamos. Para mejorar aún más las detecciones de la interfaz de usuario
state="Selected ", texto alternativo="Per�l"). A pesar de décadas de trabajo en
y agregar información semántica, introdujimos heurísticas (p. ej., agrupación y orden de la
herramientas para desarrolladores y educación para respaldar la accesibilidad en
interfaz de usuario) y modelos adicionales (p. ej., reconocimiento del contenido de la interfaz
muchas plataformas diferentes [16, 18, 59], las aplicaciones aún no proporcionan
de usuario, estado, interactividad). Creamos Screen Recognition para generar metadatos de
metadatos de accesibilidad universales en ninguna plataforma [42]. Por ejemplo, las
accesibilidad para mejorar iOS VoiceOver. En un estudio con 9 usuarios de lectores de
100 aplicaciones de Android más descargadas tenían problemas básicos de
pantalla, validamos que nuestro enfoque mejora la accesibilidad de las aplicaciones móviles
accesibilidad en un estudio reciente [65]. La falta de metadatos apropiados necesarios
existentes, lo que permite usar incluso aplicaciones que antes eran inaccesibles.
para las características de accesibilidad es un desafío de larga data en accesibilidad.

CONCEPTOS CCS Es posible que las aplicaciones no sean completamente accesibles por una variedad de razones. Es

posible que los desarrolladores desconozcan la accesibilidad, carezcan de la experiencia necesaria en

• ¡Computación centrada en el ser humano! Tecnologías de accesibilidad. accesibilidad para que sus aplicaciones sean accesibles o dejen de priorizar la accesibilidad. Los

desarrolladores a menudo usan kits de herramientas de interfaz de usuario de terceros que pueden
PALABRAS CLAVE funcionar en todas las plataformas, pero tienen un soporte de accesibilidad integrado limitado. Por

accesibilidad móvil, mejora de la accesibilidad, detección de interfaz de usuario ejemplo, para hacer que las aplicaciones de Unity sean accesibles de forma no visual, los

Formato de referencia ACM:
Xiaoyi Zhang, Lilian de Greef, Amanda Swearngin, Samuel White, Kyle
Murray, Lisa Yu, Qi Shan, Je�rey Nichols, Jason Wu, Chris Fleizach, Aaron
desarrolladores deben usar un complemento de Unity pago [34] que replique la experiencia de un
lector de pantalla (captura gestos en una superposición de pantalla completa y anuncie elementos de
IU enfocados) o recrear manualmente un similar experiencia accesible desde cero. Los kits de

herramientas de interfaz de usuario propios (p. ej., UIKit para iOS) facilitan mucho la accesibilidad, pero

los desarrolladores de aplicaciones aún deben proporcionar metadatos de accesibilidad, como texto

alternativo o elementos de accesibilidad para vistas personalizadas [7]. Gran parte de la atención se
Este trabajo tiene una licencia Creative Common Att ibution Inter ational 4.0
centra en la creación de nuevos contenidos y aplicaciones que sean accesibles, aunque la mayoría de
Licen e.
las plataformas tienen un legado sustancial de contenido y aplicaciones inaccesibles que ya no cuentan
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
con soporte activo para desarrolladores. Los innumerables desafíos de lograr la accesibilidad a través
© 2021 Derechos de autor del propietario/autor(es).
de muchas plataformas y conjuntos de herramientas diferentes
ACM ISBN 978-1-4503-8096-6/21/05.
https://doi.org/10.1145/3411764.3445186
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
Figura 1: Descripción general de nuestro enfoque: 1) Diez trabajadores recopilaron capturas de pantalla y árboles de interfaz de usuario en las aplicaciones. 2) Cuarenta
trabajadores anotaron las pantallas para proporcionar metadatos completos. 3) Un modelo en el dispositivo (entrenado con datos anotados) detecta elementos de la interfaz de
usuario a partir de píxeles. 4) La heurística (p. ej., ordenar y agrupar) y los modelos adicionales (p. ej., OCR) aumentan las detecciones de la interfaz de usuario para mejorar la
experiencia del usuario. 5) Los metadatos de accesibilidad generados se ponen a disposición de los lectores de pantalla para su uso en tiempo de ejecución para mejorar la
accesibilidad experimentada de las aplicaciones.
para tantas aplicaciones diferentes nos motivó a crear automáticamente metadatos de
accesibilidad a partir de los píxeles de las interfaces de usuario de la aplicación.
En este documento, presentamos un nuevo método para proporcionar metadatos de
accesibilidad automáticamente desde los píxeles de la interfaz visual de usuario. En la
práctica, las interfaces visuales de las aplicaciones móviles a menudo reciben la mayor
atención de los desarrolladores y representan mejor la funcionalidad prevista de una
aplicación. Para facilitar este método, recopilamos, anotamos y analizamos 77 637 pantallas
(de 4068 aplicaciones de iPhone). Con este conjunto de datos, entrenamos un modelo de
detección de objetos en el dispositivo sólido, rápido y con uso eficiente de la memoria para
extraer elementos de la interfaz de usuario de las capturas de pantalla, lo que logra una
precisión promedio promedio del 71,3 %. Para agregar semántica y mejorar aún más los
resultados de detección de la interfaz de usuario, presentamos heurística para corregir las
detecciones, proporcionar un orden de navegación y agrupar las detecciones relevantes;
también usamos modelos adicionales para reconocer el contenido de la interfaz de usuario,
los estados de selección y la interactividad. Nuestro método crea metadatos útiles para una
amplia variedad de servicios de accesibilidad [8–10, 36, 38] y puede usarse solo o para
mejorar los metadatos de accesibilidad existentes en una aplicación. La figura 1 muestra la
integración con lectores de pantalla como ejemplo.
Para demostrar la utilidad de nuestro enfoque, creamos Screen Recognition que
proporciona estos metadatos a iOS VoiceOver, usando solo píxeles de captura de
pantalla como entrada. En un estudio de usuarios con 9 usuarios de lectores de
pantalla, validamos que los participantes podían usar una amplia variedad de
aplicaciones móviles existentes, incluidas las que antes eran inaccesibles. También
exploramos las limitaciones de nuestro enfoque y discutimos las mejoras futuras, así
como la posible integración con las herramientas de desarrollo. En un nivel alto,
creemos que nuestro enfoque ilustra una nueva forma de comenzar a abordar el
desafío de larga data de las aplicaciones inaccesibles en dispositivos móviles y,
eventualmente, en otras plataformas.
Nuestro trabajo contribuye:
• Un análisis de las características (p. ej., distribución de la interfaz de usuario,
problemas de accesibilidad) de un gran conjunto de datos de 77 637 pantallas (de
4068 aplicaciones de iPhone) que recopilamos y anotamos.
Zhang, de Greef, Swearngin, et al.
• Un modelo de detección de objetos en el dispositivo sólido, rápido y con uso eficiente de la
memoria para extraer elementos de la interfaz de usuario de píxeles sin formato en una
captura de pantalla, que entrenamos y evaluamos.
• Aumento de las detecciones de UI para una mejor experiencia de usuario. Nuestras
heurísticas corrigen las detecciones, proporcionan un orden de navegación y agrupan las
detecciones relevantes; los modelos adicionales reconocen el contenido, el estado y la
interactividad de la interfaz de usuario.
• Un estudio de usuarios con 9 usuarios de lectores de pantalla, que probaron
aplicaciones de su elección con VoiceOver con y sin nuestro enfoque
aplicado. Sus comentarios validan que nuestro enfoque puede mejorar
significativamente la accesibilidad en las aplicaciones existentes.
2 TRABAJO RELACIONADO
Nuestro trabajo se basa en trabajos previos sobre(i)apoyando la accesibilidad móvil,(ii)
detectar elementos de la interfaz de usuario a partir de píxeles, y(iii)comprensión automática
de la semántica de la interfaz de usuario.
2.1 Compatibilidad con la accesibilidad móvil
La mayoría de las plataformas móviles (p. ej., iOS, Android) en estos días
contienen servicios de accesibilidad incorporados como lectores de pantalla
[10, 38]) y soporte para entrada accesible [8, 36], lo que permite a las personas
usar una amplia variedad de habilidades para usarlos. Estas tecnologías
dependen en gran medida de la disponibilidad de metadatos de accesibilidad
proporcionados por los desarrolladores para exponer la semántica subyacente
de las aplicaciones [2, 37]. Cuando se proporcionan estos metadatos, los
servicios de accesibilidad tienen acceso programático a qué elementos de la
interfaz de usuario están disponibles, qué contiene su contenido, en qué
estado se encuentran y qué interacciones se pueden realizar en ellos. Como tal,
estos metadatos son fundamentales para permitir que los servicios de
accesibilidad cambien las modalidades mediante las cuales alguien puede
interactuar con las interfaces de usuario y ayudar a las personas que las usan
de diferentes maneras. Sin embargo, tanto investigaciones previas [65–67],
Reconocimiento de pantalla: creación de metadatos de accesibilidad para aplicaciones móviles a partir de píxeles
Los enfoques anteriores para abordar este problema incluyen alentar a los
desarrolladores a solucionar los problemas de accesibilidad a través de la educación
[16], los estándares [15, 62] y mejores herramientas de prueba [14, 18]. Si bien estos
enfoques son importantes, dado que, en última instancia, los desarrolladores podrán
hacer que sus aplicaciones sean más accesibles, el progreso actual sigue siendo lento
[42], lo que motiva la investigación que intenta resolver el problema sin depender de
la cooperación de los desarrolladores originales. Suplantar o generar
automáticamente metadatos para aplicaciones inaccesibles existentes puede
proporcionar beneficios más inmediatos para los usuarios. Con este fin, Interaction
Proxies permite que los usuarios finales sustituyan los metadatos faltantes al
etiquetar manualmente los elementos de la interfaz de usuario y formar un depósito
compartido de dicha información para la reparación en tiempo de ejecución [80, 81].
Sin embargo, este enfoque requiere voluntarios activos para actualizar y mantener
anotaciones y personalizaciones para una gran cantidad de aplicaciones que se
actualizan con frecuencia. El intento anterior más grande de accesibilidad de “fuente
colectiva”, Social Accessibility for the Web [72], se mostró prometedor desde el
principio, pero finalmente no pudo hacer una gran mella en el problema de la
accesibilidad web.
La investigación previa en la generación automatizada de descripciones de imágenes [35,
39] y la predicción de etiquetas de UI [23] también crea tipos específicos de metadatos de
accesibilidad automáticamente a partir de píxeles. Sin embargo, solo comprende un
subconjunto de la información necesaria para que los servicios de accesibilidad funcionen
como se espera (es decir, estos enfoques no hacen que los elementos de la interfaz de
usuario que faltan estén disponibles). Nuestro enfoque va mucho más allá hacia la
generación completa de metadatos de accesibilidad a partir de píxeles, infiriendo
automáticamente los elementos de la interfaz de usuario que faltan (tamaño, posición, tipo,
contenido y estado), el orden de navegación adecuado y la agrupación.
2.2 Detección de interfaz de usuario de píxeles
Nuestro trabajo consiste en inferir las ubicaciones y la semántica de los elementos de la
interfaz de usuario en una pantalla para proporcionar metadatos para los servicios de
accesibilidad. Algunos trabajos iniciales extrajeron información de la interfaz de usuario para
modificar interfaces de fuentes que no son píxeles, como las API de accesibilidad [17] e
instrumentación [32, 58], o videos tutoriales de software [11]. Sin embargo, requieren acceso
a la API para habilitar la instrumentación o exponer elementos de la interfaz de usuario y, a
menudo, tienen acceso incompleto a los metadatos de la interfaz de usuario. Los enfoques
basados en píxeles, por el contrario, son más independientes del conjunto de herramientas
de la aplicación subyacente y no requieren que las IU se expongan a través de las API.
El uso de píxeles para identificar elementos de la interfaz de usuario se ha utilizado
durante mucho tiempo para hacer que las aplicaciones sean accesibles. Por ejemplo, el lector
de pantalla OutSpoken para Windows 3.1 permitía a los usuarios etiquetar iconos en la
pantalla, que luego reconoce solo por sus píxeles [69]. La inferencia de información de los
píxeles de las interfaces se ha aplicado en diversas aplicaciones, como el aumento y la
reasignación de interfaces [11, 17, 30, 79], las pruebas de GUI [78], el diseño basado en datos
para la búsqueda de GUI [20, 22, 45] o la creación de prototipos. [70], generar código de
interfaz de usuario a partir de aplicaciones existentes para respaldar el desarrollo de
aplicaciones [12, 21, 24, 53, 57] y la seguridad de la interfaz gráfica de usuario [25]. Algunos
trabajos también emplearon métodos basados en píxeles para mejorar la accesibilidad,
como Prefab, que aumenta la interfaz de la aplicación existente con técnicas de señalización
de objetivos que mejoran la interacción de las personas con discapacidad motora [31].
Existen múltiples enfoques para la interpretación de interfaces basada en píxeles.
Un trabajo reciente de Chen et al. [24] clasifica y evalúa dos enfoques principales de
detección de GUI: el uso de métodos tradicionales de procesamiento de imágenes (p.
ej., detección de bordes/contornos [57], detección de plantillas
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
coincidencia [30, 61, 78]) y el uso de modelos de aprendizaje profundo entrenados en
datos GUI a gran escala [21, 24].
Métodos tradicionales de procesamiento de imágenes:Los métodos de detección de
bordes/contornos [57, 70, 73] detectan y fusionan bordes en elementos de la interfaz de
usuario, lo que puede funcionar bien en GUI simples, pero puede fallar en imágenes (p. ej.,
fondo degradado, fotos) o diseños de GUI complejos. Alternativamente, los métodos de
coincidencia de plantillas [30, 78, 79] pueden funcionar mejor en estos casos, ya que hay más
características en elementos de interfaz de usuario complejos. Sin embargo, requieren
ingeniería de funciones y plantillas para reconocer la forma y el tipo de elementos de la
interfaz de usuario, lo que puede limitarlos a detectar interfaces de usuario sin mucha
variación en las funciones visuales.
Modelos de aprendizaje profundo:Pix2Code [12] aplica un modelo de subtítulos de
imágenes neuronales de extremo a extremo para predecir una descripción de lenguaje
específico de dominio del diseño de la interfaz. Chen et al. [21] aplica un modelo CNN-RNN
similar para generar un esqueleto de interfaz de usuario (que consta de tipos de widgets y
diseño) a partir de una captura de pantalla. En ambos trabajos, los diseños generados solo
proporcionan ubicaciones relativas de los elementos de la interfaz de usuario en la jerarquía
de vistas, mientras que la mayoría de los servicios de accesibilidad requieren la ubicación
absoluta de cada elemento de la interfaz de usuario en la pantalla. Los modelos de detección
de objetos también pueden ubicar elementos de IU en una pantalla: GalleryDC [20] detecta IU
con el modelo Faster RCNN [64] para crear automáticamente una galería de componentes de
diseño de GUI, y White et al. [75] aplica el modelo YOLOv2 [63] para identificar widgets de GUI
en capturas de pantalla para mejorar las pruebas de GUI.
Métodos híbridos:Algunos trabajos [24, 26, 53] primero usan métodos
tradicionales de procesamiento de imágenes (p. ej., detección de bordes) para ubicar
elementos de la IU y luego aplican una clasificación basada en CNN para determinar
la semántica de los elementos de la IU (p. ej., tipo de IU).
Muchos de estos enfoques tienen como objetivo facilitar las primeras etapas del diseño
de aplicaciones en lugar de la accesibilidad; por lo tanto, solo se enfocan en un subconjunto
de metadatos (es decir, ubicación y tipo de interfaz de usuario) que necesitan los servicios de
accesibilidad. Por el contrario, nuestro enfoque basado en el aprendizaje profundo está
optimizado para casos de uso de accesibilidad, proporciona metadatos de píxeles más
completos (p. ej., estado de la interfaz de usuario, orden de navegación, agrupación) y
requiere menos recursos para ejecutarse de manera eficiente en teléfonos móviles.
2.3 Comprender la semántica de la interfaz de usuario
Más allá de detectar elementos de la interfaz de usuario de una captura de
pantalla, nuestro trabajo requiere obtener una comprensión más profunda de
la semántica de la interfaz de usuario (por ejemplo, tipo de interfaz de usuario,
estado, orden de navegación, agrupación, descripciones de imágenes e íconos),
lo que puede mejorar aún más los servicios de accesibilidad y la experiencia del
usuario. Más allá de la detección de elementos de la interfaz de usuario, el
trabajo de diseño basado en datos reciente se basa en grandes conjuntos de
datos de diseño de la interfaz de usuario para inferir la semántica de la interfaz
de nivel superior, como los patrones de diseño [56], los flujos [28] y las
etiquetas [19]. Los lectores de pantalla requieren inferir un conjunto diferente
de semánticas, como el orden de navegación y la jerarquía de la interfaz de
usuario (es decir, la agrupación) para una pantalla. Algunos trabajos aplican el
aprendizaje automático en conjuntos de datos de diseño de interfaz de usuario
para inferir el diseño de la interfaz [13, 21, 22, 48]. Otro trabajo extrae la
estructura de la interfaz a través de las API del sistema [52]. A diferencia de,
Además, es importante que los servicios de accesibilidad conozcan el estado y la interactividad de
un elemento (p. ej., posibilidad de hacer clic, estado de selección), para que puedan manejar los
elementos de manera diferente (p. ej., VoiceOver anunciará "Botón" para los elementos de la interfaz
de usuario en los que se puede hacer clic; Cambiar El control puede
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón Zhang, de Greef, Swearngin, et al.

omita los elementos de la interfaz de usuario no interactivos en la navegación para ahorrar tiempo). El Texto 741,285
Icono 327,206
trabajo de Swearngin et al. [71] predice la percepción humana de la capacidad de tocar los elementos
Envase 7,513
dieciséis

de la interfaz de usuario de la aplicación móvil, en función de las anotaciones humanas y los

Elemento de la barra de pestañas 157, 687
signi�cadores comunes de capacidad de clic (por ejemplo, tipo de interfaz de usuario, tamaño). En 130,057

Tipo de elemento de interfaz de usuario

Imagen

nuestro trabajo, creamos e integramos un modelo para predecir la posibilidad de hacer clic en algunos Campo de texto 22,417

elementos de la interfaz de usuario en función de características similares (es decir, tamaño, ubicación, Control segmentado 18,695

Caja 7,861
tipo de icono); sin embargo, nuestro objetivo es predecir la capacidad de clic real de los elementos de
Control de página 6,258
la interfaz de usuario en lugar de la percepción humana; como muestra [71], estos dos a menudo no
Palanca 5,805
coinciden. Más allá del trabajo anterior para detectar elementos de la interfaz de usuario de las
Diálogo 4200
capturas de pantalla [12, 24, 53, 57], también detectamos el estado de selección para los tipos de Deslizador 1,808
elementos de la interfaz de usuario relevantes (p. ej., alternar, casilla de verificación) al inferir clases de 0 200,000 400.000 600.000 800.000
Número de anotaciones
tipos de elementos de la interfaz de usuario adicionales.

Por último, inferimos información semántica de los elementos de la interfaz de usuario

para mejorar la experiencia del lector de pantalla. Para reconocer iconos, el trabajo anterior
[50, 76, 77] entrenó modelos de clasificación de imágenes a partir de conjuntos de datos de
diseño de interfaz de usuario [27]. Para describir el contenido de las imágenes, el trabajo
anterior utilizó modelos de aprendizaje profundo para generar descripciones de imágenes en
lenguaje natural [44, 46], y algunas investigaciones de mejora de la accesibilidad también han
aprovechado el crowdsourcing para generar leyendas de imágenes [35, 39, 40]. Utilizamos un
motor de reconocimiento de iconos y una función de descripciones de imágenes existentes en
iOS [4] para generar texto alternativo para los iconos e imágenes detectados,
respectivamente.
3 CONJUNTO DE DATOS DE PANTALLA DE LA APLICACIÓN iOS
Para entrenar y probar nuestro modelo de detección de interfaz de usuario, primero creamos
un conjunto de datos de 77 637 pantallas de 4068 aplicaciones de iPhone. La creación de
nuestro conjunto de datos requirió dos pasos:(i)recopilar las pantallas, en las que capturamos
capturas de pantalla y extrajimos información de sus árboles de interfaz de usuario y árboles
de accesibilidad, y(ii)anotar manualmente los elementos visuales de la interfaz de usuario en
las pantallas. Ajustamos este proceso, incluido nuestro software personalizado de
recopilación y anotación de datos, a través de varias pruebas piloto. El detalle de los
trabajadores que contratamos en la recopilación y anotación de datos y las instrucciones para
los anotadores se encuentran en el material complementario.
3.1 Colección de pantallas
Recolectamos un total de 80,945 pantallas únicas de 4,239 aplicaciones de iPhone,
descargando e instalando manualmente las 200 aplicaciones gratuitas más descargadas para
cada una de las 23 categorías de aplicaciones (excluyendo juegos y aplicaciones AR)
presentadas en la tienda de aplicaciones de EE. UU. Tenga en cuenta que algunas aplicaciones
están en varias categorías. Omitimos las aplicaciones que requerían información de la tarjeta
de crédito (p. ej., para pagos dentro de la aplicación) o información personal confidencial (p.
ej., inicio de sesión para aplicaciones bancarias, datos personales de salud). Creamos un
conjunto de cuentas de marcador de posición para iniciar sesión en aplicaciones que
requerían esto para acceder a más de sus pantallas. Recopilamos todas las pantallas entre el
09/12/2019 y el 13/02/2020.
Diez trabajadores atravesaron manualmente las pantallas en cada aplicación para recopilar
información de pantalla utilizando el software personalizado que creamos. Para cada pantalla
atravesada, nuestro software recopiló una captura de pantalla y metadatos sobre los elementos de la
interfaz de usuario. Los metadatos incluyen una estructura de árbol de todos los elementos de la
interfaz de usuario expuestos en una pantalla y las propiedades de cada elemento de la interfaz de
usuario (p. ej., clase, cuadro delimitador, rasgo). También extrajimos las propiedades de accesibilidad
de cada elemento de la interfaz de usuario que están expuestos a las API de accesibilidad (por ejemplo,
isAccessibilityElement, sugerencia, valor). Nuestro software de recopilación también asignó un
identificador único a cada elemento de la interfaz de usuario. Los metadatos recopilados tienen las
mismas limitaciones en términos de integridad y
Figura 2: El número de anotaciones para cada tipo de elemento de IU
representado en el conjunto de datos.
corrección que motivó nuestro enfoque. Por lo tanto, establecer una
verdad de campo confiable requiere anotar las pantallas recopiladas.
3.2 Anotación en pantalla
Cuarenta trabajadores anotaron todos los elementos de la interfaz de usuario
visualmente discernibles en las capturas de pantalla. El proceso de anotación tenía
dos componentes:(i) segmentación y(ii)clasi�cación.
En la segmentación, los trabajadores determinaron un cuadro delimitador para cada
elemento de la interfaz de usuario. La herramienta de anotación ayudó a dirigir a los
trabajadores hacia el uso de un cuadro delimitador proporcionado por un elemento de IU
capturado, cuando estaba disponible uno apropiado, para mejorar la coherencia entre los
trabajadores y las anotaciones. Cuando no había ningún cuadro delimitador disponible para
un elemento de la interfaz de usuario, los anotadores dibujaban manualmente un cuadro.
Establecimos pautas para garantizar la consistencia y la calidad, por ejemplo, cómo dibujar
un cuadro delimitador ajustado; cuándo agrupar o separar cuadros delimitadores; qué
elementos ignorar (p. ej., fondo); y cómo manejar casos límite (por ejemplo, elementos
recortados).
Para la clasi�cación, los trabajadores asignaron atributos a los elementos de la IU
identi�cados. Para cada uno, los anotadores asignaron uno de los 12 tipos de interfaz de
usuario comunes según la inspección visual: Casilla de verificación, Contenedor, Diálogo,
Icono, Imagen, Control de página, Control segmentado, Control deslizante, Texto, Campo de
texto, Elemento de la barra de pestañas y Alternar. Los ejemplos visuales de los tipos de
interfaz de usuario están disponibles en nuestro material complementario. Dos autores de
este artículo (un investigador y un ingeniero senior de accesibilidad) eligieron estos tipos de
interfaz de usuario al examinar 500 pantallas de muestra para identificar qué elementos son
importantes para los servicios de accesibilidad. Para los elementos de la interfaz de usuario
que no están en uno de estos tipos de interfaz de usuario, como anuncios y vistas de mapas,
los anotadores los marcaron como Otros (0,5 % de todas las anotaciones). Los anotadores
también etiquetaron información adicional para tipos de interfaz de usuario específicos, como
si cada casilla de verificación o alternar está seleccionada, si se puede hacer clic en un
elemento, y qué parte de un elemento encapsula el cuadro delimitador (por ejemplo, el
contorno de un campo de texto o su texto de marcador de posición). Como los atributos a
veces pueden ser ambiguos, los anotadores también pueden elegir la opción "no estoy
seguro".
Para monitorear la calidad de los datos y corregir iterativamente los errores
operativos, dos investigadores examinaron una selección aleatoria del 6 % de
las pantallas después de anotar cada uno de los 20 lotes. Además, nuestro
equipo de Garantía de calidad (QA) examinó el 20 % de las pantallas que se
anotaron en cada lote y compartió un informe de QA detallado. En base a esto,
trabajamos con los anotadores para reducir los errores comunes. El total
Reconocimiento de pantalla: creación de metadatos de accesibilidad para aplicaciones móviles a partir de píxeles
tasa de error que observamos fue de 2,62% en todos los lotes, que se redujo de 4,49%
(primer lote) a 1,27% (último lote). En promedio, la tasa de error de los cuadros
delimitadores (p. ej., anotación extra o faltante, cuadro demasiado grande o pequeño)
fue del 1,35 %; la tasa de error del tipo de IU fue del 0,54 %; y la tasa de error de los
atributos de la interfaz de usuario (p. ej., clicable/no clicable, seleccionado/no
seleccionado) fue del 0,73 %. Descubrimos que los errores principales eran las
anotaciones faltantes para las imágenes y la confusión entre los elementos en los que
se puede hacer clic y los que no, un desafío conocido [71].
Durante la fase de anotación, descartamos 3308 pantallas que se
capturaron accidentalmente cuando una aplicación estaba en la transición
entre pantallas, mostró accidentalmente un botón AssistiveTouch, tomaría
demasiado tiempo para anotar (por ejemplo, contiene más de 50 elementos de
la interfaz de usuario) o tenía mucho no Texto en inglés. Todas estas pantallas
representan oportunidades para el trabajo futuro, pero las consideramos fuera
del alcance de la primera versión del proyecto. Esto resultó en 77,637 pantallas
anotadas en total.
3.3 Análisis de la composición del conjunto de datos
Para comprender mejor la composición de nuestro conjunto de datos, realizamos dos análisis.
El primer análisis explora los sesgos de nuestro conjunto de datos entre diferentes tipos de
interfaz de usuario, lo que puede afectar el rendimiento de nuestro modelo. Las anotaciones
revelaron un desequilibrio de los tipos de interfaz de usuario en las pantallas de las
aplicaciones, como se muestra en la Fig. 2: el texto tiene la representación más alta (741 285
anotaciones); Los controles deslizantes tienen los más bajos (1808 anotaciones); y los 4 tipos
principales de IU comprenden el 95 % de las anotaciones. Consideramos tales desequilibrios
de datos en el entrenamiento del modelo para mejorar el rendimiento en los tipos de interfaz
de usuario subrepresentados, como se analiza en la Sección 4.1.
Nuestro segundo análisis examinó las discrepancias entre las anotaciones y los
metadatos de los elementos de la interfaz de usuario para cada pantalla para estimar cuántos
elementos de la interfaz de usuario no estaban disponibles para los servicios de accesibilidad.
Tenga en cuenta que existen limitaciones importantes para esta estimación, ya que estas
anotaciones no son un reflejo perfecto de todos los elementos de la interfaz de usuario que
son importantes para el servicio de accesibilidad: los anotadores a veces ignoran los
elementos de la interfaz de usuario; las anotaciones pueden incluir elementos de la interfaz
de usuario creados por motivos estéticos que no son importantes para la accesibilidad; las
anotaciones pueden tener errores adicionales como se menciona en la Sección 3.2. Además,
los metadatos de los elementos de la interfaz de usuario disponibles no tienen en cuenta
todas las formas posibles de hacer que una aplicación sea accesible. Por ejemplo, algunas
aplicaciones utilizan métodos personalizados (p. ej., volver a implementar un lector de
pantalla) cuando sus kits de herramientas de interfaz de usuario no admiten la accesibilidad
nativa. Nuestro análisis se centró en los elementos de la interfaz de usuario expuestos al
lector de pantalla nativo con el entendimiento de que las anotaciones de la observación
humana siguen siendo una aproximación cercana a los elementos de accesibilidad
importantes. En la mayoría de los casos, las diferencias entre las anotaciones y los metadatos
de accesibilidad existentes sugieren posibles problemas de accesibilidad en una pantalla.
Hacer coincidir las anotaciones con los elementos de la interfaz de usuario en la jerarquía
de vistas presenta varios desafíos. Los cuadros delimitadores de anotaciones a veces no se
alinean exactamente con los elementos de la interfaz de usuario subyacentes. A veces,
difieren en la forma en que dividen un componente general de la interfaz de usuario (p. ej., el
tratamiento de líneas o párrafos individuales de texto como elementos individuales en lugar
de una gran parte de texto, o la exposición de elementos separados para el icono, el
contenedor y el texto de un botón en lugar de elementos individuales). simplemente
exponiendo una de estas partes a los servicios de accesibilidad). Algunos de los elementos de
accesibilidad expuestos más grandes también tienen muchos elementos de accesibilidad más
pequeños anidados dentro de ellos, creando más ambigüedad sobre qué elementos
coinciden con qué anotaciones.
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
45%
41%
40%
35%
30%
Proporción de pantallas
25%
20%
17%
15%
15%
10%
7%
5%
5% 4% 3%
2% 2% 2% 2%
1%
0%
0 >0 10 20 30 40 50 60 70 80 90 < 100 100
Proporción de anotaciones que coinciden con un elemento de IU accesible en %
Figura 3: Un histograma del porcentaje de pantallas agrupadas por qué
porcentaje de sus anotaciones coincidieron con un elemento de IU
accesible existente, con barras separadas para mostrar el porcentaje de
pantallas con 0% de coincidencias y 100% de coincidencias.
Para hacer esta comparación, ignoramos anuncios o mapas y examinamos las
anotaciones restantes con el siguiente procedimiento (que describimos con más
detalle en el material complementario de este documento): categorizar las
anotaciones según si algún cuadro delimitadorB desde un elemento de accesibilidad
que no es de pantalla completa contiene o se superpone con el cuadro delimitador de
la anotaciónA,donde definimos "contención" como si al menos el 85% deA'el área se
encuentra dentroB,y "superposición" como si la intersección sobre la unión deAyBes
al menos el 5%. Cuando el cuadro delimitador de un elemento expuesto contiene solo
una anotación, los consideramos como una coincidencia entre sí. Consideramos que
las anotaciones que no se superponen con ningún elemento de accesibilidad
expuesto no coinciden, con algunas excepciones, como los iconos que se alinean
horizontalmente con elementos de texto ya coincidentes en los que no se puede
hacer clic de forma independiente, como suele ser el caso en las celdas o los botones
de una tabla. Para las posibilidades restantes (un elemento expuesto contiene más de
una anotación, o se superpone pero no contiene una anotación), examinamos 150
pantallas de ejemplo con diferentes tipos de elementos de la interfaz de usuario para
desarrollar heurísticas, que probamos en otras 150 pantallas de ejemplo. Estas
heurísticas intentan hacer coincidir cuadros delimitadores incoherentes para
elementos de imágenes y texto, cuadros delimitadores anidados y anotaciones
funcionalmente redundantes. Para mantener un alto recuerdo de las coincidencias,
estas heurísticas tienen tolerancias indulgentes y no requieren anotaciones en las que
se pueda hacer clic para que coincidan con los elementos de la interfaz de usuario en
los que se puede hacer clic. Por lo tanto, es posible que hayamos subestimado el
número de anotaciones no coincidentes.
Como se muestra en la figura 3, el 59 % de las pantallas tienen anotaciones que no
coinciden con ningún elemento de la interfaz de usuario accesible (una media de 5,3 y una
mediana de 2 anotaciones por pantalla). Descubrimos que el 94% de las aplicaciones en
nuestro conjunto de datos tienen al menos una de esas pantallas, en lugar de solo unas pocas
aplicaciones inutilizables que contribuyen a una gran cantidad de estas pantallas. En estas
pantallas, nuestro enfoque de generación de metadatos de accesibilidad tiene el potencial de
exponer elementos de accesibilidad faltantes. Nuestro enfoque podría ser especialmente útil
para proporcionar metadatos de accesibilidad para el 4 % de las pantallas que no exponen
ningún elemento de accesibilidad. Como se muestra en la Fig. 4, la prevalencia de
coincidencias entre anotaciones y elementos de IU accesibles varió según el tipo de IU. De
todas las anotaciones no coincidentes, el 33 % son texto y el 21 % son imágenes. La
discrepancia
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
Palanca
Deslizador
Caja
Control de página
Tipo de elemento de interfaz de usuario
Campo de texto
Control segmentado
Elemento de la barra de pestañas
Envase
Icono
Imagen
Texto
0%
Figura 4: un gráfico de barras que muestra el desglose de las anotaciones no coincidentes
por tipo de elemento de interfaz de usuario.
entre las anotaciones y los metadatos de accesibilidad existentes demuestra la
importancia de la anotación, que proporciona información adicional en comparación
con los conjuntos de datos de recopilación de IU móviles anteriores [27].
4 MODELO DE DETECCIÓN DE IU
Entrenamos un modelo de detección de objetos para extraer elementos de la interfaz de
usuario de los píxeles, que ubica los elementos de la interfaz de usuario en una captura de
pantalla de la aplicación y predice sus tipos de interfaz de usuario. Después de experimentar
con una variedad de arquitecturas y configuraciones de red, elegimos una que equilibra la
precisión y el rendimiento en el dispositivo. Describimos la arquitectura del modelo, los datos
y la evaluación a continuación.
4.1 Arquitectura modelo
Comenzamos experimentando con Faster R-CNN (y su extensión Mask R-CNN) [43,
64], que es uno de los modelos de detección de objetos de mejor rendimiento
evaluados en conjuntos de datos públicos. Como el objetivo es ejecutar este modelo
de detección en el dispositivo (iPhone), el tiempo de inferencia y la huella de memoria
se convirtieron en factores limitantes. Una R-CNN más rápida requiere más de 1
segundo para cada pantalla y más de 120 MB de memoria, lo que no es adecuado
para la inferencia en el dispositivo. Luego experimentamos con los kits de
herramientas de detección de objetos de TuriCreate [6], que son fáciles de usar y
están optimizados para dispositivos iOS. El modelo TuriCreate usa aproximadamente
la mitad de la memoria (60M) y tiene un tiempo de inferencia significativamente más
rápido (alrededor de 20ms). En la búsqueda de un modelo más eficiente con
predicciones de cuadro delimitador más estrictas y un mAP más alto (precisión
promedio promedio), convergimos en un modelo SSD (Single Shot MultiBox Detector)
[51] que cumple con nuestros requisitos. Específicamente, usamos MobileNetV1 (en
lugar de ResNet grande) como columna vertebral para reducir el uso de memoria.
Otro desafío común en las tareas de detección de objetos es detectar objetos
pequeños. Desafortunadamente, los elementos de la interfaz de usuario son
relativamente pequeños en comparación con la mayoría de los objetivos que se ven a
menudo en las tareas de detección de objetos. Utilizamos Feature Pyramid Network
(FPN), que es un extractor de características diseñado con una pirámide jerárquica
para mejorar la precisión y la velocidad al detectar objetos en diferentes escalas. Para
manejar datos de clase desequilibrada, discutidos en la Sección 3.3, realizamos un
aumento de datos en tipos de IU subrepresentados durante el entrenamiento y
aplicamos una función de pérdida de clase equilibrada (más peso para tipos de IU
subrepresentados). Nuestra arquitectura �nal usa solo 20 MB de memoria (modelo
CoreML),
Zhang, de Greef, Swearngin, et al.
0,5% para inferencia (en un iPhone 11 con iOS 14). Para entrenar este modelo,
0,6% usamos 4 GPU Tesla V100 durante 20 horas (557,000 iteraciones).
0,6% Los modelos de detección de objetos a menudo devuelven múltiples cuadros
0,8% delimitadores para un objetivo subyacente dado con diferentes confianzas. Usamos
1,9% dos métodos de procesamiento posterior para filtrar las detecciones duplicadas: (i) La
2.9% supresión no máxima selecciona la detección más confiable de las detecciones
5,2% superpuestas [55]. (ii) Se pueden aplicar diferentes umbrales de confianza en cada
6,4% tipo de interfaz de usuario para eliminar detecciones menos seguras. Elegimos
16,5% umbrales de confianza por tipo de interfaz de usuario que equilibren el recuerdo y la
26,4% precisión para cada uno (Figura 5).
38.1%
5% 10% 15% 20% 25% 30% 35% 40% 4.2 Datos de entrenamiento y prueba
Proporción de anotaciones no coincidentes
Los conjuntos de datos de entrenamiento y prueba incluyen 13 clases (Tabla 1) derivadas de
los tipos de interfaz de usuario en la anotación: Casilla de verificación (seleccionada), Casilla
de verificación (no seleccionada), Contenedor, Diálogo, Icono, Imagen, Control de página,
Control segmentado, Control deslizante, Texto, Campo de texto , Alternar (Seleccionado) y
Alternar (No seleccionado). En base a experimentos iniciales con modelos de detección de UI,
dividimos la casilla de verificación y alternar en subtipos "Seleccionado" y "No seleccionado", y
reasignamos el elemento de la barra de pestañas en icono y texto.
Casilla de verificación y alternar:La apariencia visual de las casillas de verificación
"Seleccionado" y "No seleccionado" es bastante diferente (lo mismo para Alternar), y
dividirlas mejoró la precisión de detección general para cada clase. La detección
directa del estado de selección también significa que no necesitamos un modelo de
clasificación separado para determinar el estado de selección de una casilla de
verificación o alternar detectada, lo que reduce el uso de memoria en el dispositivo y
el tiempo de inferencia.
Elemento de la barra de pestañas:Los experimentos iniciales revelaron que la clase de elemento de
la barra de pestañas independiente tenía un buen recuerdo pero baja precisión. Este resultado se
debió a que nuestro modelo inicial tendía a detectar la mayoría de los elementos de la interfaz de
usuario en la parte inferior de la pantalla como elementos de la barra de pestañas, incluidos los íconos
y el texto en la parte inferior de la pantalla de las aplicaciones que no tenían ninguna barra de
pestañas. Por lo tanto, decidimos dividir las anotaciones de elementos de la barra de pestañas en
clases de texto y/o icono. Más adelante, describiremos las heurísticas que presentamos para agrupar
filas de texto e íconos cerca de la parte inferior de la pantalla en elementos de la barra de pestañas
contenidos dentro de una barra de pestañas.
Con respecto a nuestra división de datos de entrenamiento/prueba, una simple división aleatoria
no puede evaluar la generalización del modelo, ya que las pantallas en la misma aplicación pueden
tener apariencias visuales muy similares. Para evitar este problema de fuga de datos [47], dividimos las
pantallas en el conjunto de datos por aplicación. También nos aseguramos de que la representación de
las categorías de aplicaciones, el recuento de pantallas por aplicación y los tipos de interfaz de usuario
sean similares en los conjuntos de datos de entrenamiento y prueba. Ejecutamos varias divisiones
aleatorias en las aplicaciones y nos detuvimos cuando la división cumplió con estos requisitos. La
división resultante tiene 72 635 pantallas en el conjunto de datos de entrenamiento y 5002 pantallas en
el conjunto de datos de prueba.
4.3 Evaluación
Para cada tipo de interfaz de usuario, evaluamos el rendimiento de nuestro modelo mediante
la precisión promedio (AP), una métrica de evaluación de detección de objetos estándar.
Elegimos un umbral de > 0,5 IoU (intersección sobre unión), comúnmente utilizado en
desafíos de detección de objetos [33], para hacer coincidir una detección con un elemento de
interfaz de usuario de verdad en tierra. En nuestro conjunto de datos de prueba (5002
capturas de pantalla), nuestro modelo de detección de interfaz de usuario logró un AP medio
del 71,3 %. Si ponderamos nuestros resultados por la frecuencia de cada tipo de interfaz de
usuario en el conjunto de datos, el AP medio ponderado es del 82,7 %. La Tabla 1 muestra el
AP individual para cada uno de los 13 tipos de UI. Basado en la recuperación de precisión
Reconocimiento de pantalla: creación de metadatos de accesibilidad para aplicaciones móviles a partir de píxeles CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón

Tabla 1: Precisión promedio (AP) de cada tipo de interfaz de usuario en 5002 pantallas
de prueba.

Tipo de interfaz de usuario AP (>0,5 pagarés) AP (Centro) Contar

Casilla de verificación (no seleccionada) 77,5% 79,1% 471
Casilla de verificación (seleccionada) 27,4% 27,4% 119
Envase 82,1% 83,0% 11528
Diálogo 62,9% 63,3% 264
Icono 79,7% 88,0% 21875
Control de página 65,4% 87,3% 454
Imagen 72,0% 76,9% 9211
Control segmentado 55,1% 57,6% 1036
Deslizador 55,6% 63,0% 110
Texto 87,5% 91,7% 47045
Campo de texto 79,2% 79,5% 1379
Alternar (no seleccionado) 91,7% 91,7% 247
Alternar (seleccionado) 90,5% 92,0% 131
Significar 71,3% 75,4% Figura 6: Matriz de confusión para todos los tipos de interfaz de usuario. Las casillas
Media ponderada 87,5% 83,2% de verificación (seleccionadas) a menudo se confundían con íconos o imágenes. Los
iconos a veces se confundían con imágenes.

Casilla de verificación (seleccionada) Casilla de verificación (no seleccionada) Envase Diálogo Icono

1.0
Precisión

0.5 (Seleccionado) con Icono y, a veces, Imagen. Las casillas de verificación se ven visualmente
similares a los íconos, lo que podría explicar por qué nuestro modelo tiende a clasificarlos
0.0
erróneamente como íconos, que tienen una frecuencia mucho mayor en el conjunto de datos.
Control de página Imagen Control segmentado Deslizador Texto

1.0 La creación de otro modelo de clasi�cación para distinguir las detecciones de casillas de
verificación (seleccionadas) de las de íconos tiene el potencial de duplicar su recuperación.
Precisión

0.5

También evaluamos el rendimiento de detección de nuestro modelo con una

0.0
métrica de evaluación específica para los servicios de accesibilidad: si el centro de una
Campo de texto Alternar (seleccionado) Alternar (no seleccionado)

1.0 detección se encuentra dentro de su elemento de interfaz de usuario de destino. Con

los lectores de pantalla móviles, tocar dos veces una detección pasará un evento de
Precisión

0.5
toque a su centro, lo que activa el objetivo. Esta métrica de evaluación es más
relajada que > 0,5 IoU y aumenta el AP medio del 71,3 % al 75,4 %, como se muestra
0.0
0.0 0.5 1.0 0.0 0.5 1.0 0.0 0.5 1.0 0.0 0.5 1.0 0.0 0.5 1.0
en la columna AP (centro) de la Tabla 1. En algunos casos, es posible que el cuadro
Recuerdo Recuerdo Recuerdo Recuerdo Recuerdo

delimitador de detección no sea lo suficientemente ajustado para incluir todos

información semántica de un elemento de la interfaz de usuario de destino, pero aún
Figura 5: Las curvas de recuperación de precisión de nuestro modelo para detectar
permite a los usuarios manipular el destino. Por lo tanto, esta métrica puede capturar
cada tipo de interfaz de usuario. Examinar el desempeño individual nos permite
mejor si el modelo permite que las personas usen los elementos manipulables de la
asignar un umbral de confianza a cada tipo de interfaz de usuario, equilibrando el
interfaz de usuario.
recuerdo y la precisión (mostrado como puntos naranjas).

5 MEJORA DE LA EXPERIENCIA DEL USUARIO A PARTIR

(curvas PR) para tipos de IU individuales (como se muestra en la Fig. 5), elegimos un DE LOS RESULTADOS DE DETECCIÓN DE LA IU
umbral de confianza diferente para cada tipo de IU. El caso de uso de la accesibilidad Nuestro modelo detecta y clasifica correctamente la mayoría de los elementos de la
del lector de pantalla informó nuestras elecciones. Tenga en cuenta que las opciones interfaz de usuario en cada pantalla; sin embargo, aún puede perder algunos
pueden diferir para otros servicios de accesibilidad (p. ej., los usuarios de Switch- elementos de la interfaz de usuario y generar detecciones adicionales. Incluso cuando
Control pueden preferir una mayor precisión a la recuperación para reducir la las detecciones son perfectas, simplemente presentarlas a los lectores de pantalla no
cantidad de elementos para navegar cuando pueden ver elementos que nuestro proporcionará una experiencia de usuario ideal, ya que el modelo no proporciona
modelo no detecta). metadatos de accesibilidad completos (p. ej., contenido de la interfaz de usuario,
Nuestro modelo logró el AP más bajo para la casilla de verificación (seleccionada). Su baja estado, posibilidad de hacer clic). Trabajamos con 3 ingenieros de control de calidad
frecuencia en el conjunto de datos puede contribuir a un desempeño deficiente del modelo; ciegos y 2 ingenieros de accesibilidad sénior en nuestra empresa para descubrir y
sin embargo, Slider y Toggle también tienen una baja frecuencia similar. Para comprender diseñar iterativamente las siguientes 6 mejoras para brindar una mejor experiencia
mejor cuánto clasifica erróneamente el modelo un tipo de interfaz de usuario como otro, de lectura de pantalla. Durante 5 meses, los ingenieros participantes probaron nuevas
generamos una matriz de confusión [68] como se muestra en la Fig. 6. Descubrimos que el versiones del modelo en las aplicaciones de su elección y proporcionaron comentarios
modelo a menudo confunde Casilla de verificación sobre cuándo funcionó bien y cómo se podría mejorar.
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón Zhang, de Greef, Swearngin, et al.

Figura 8: Ejemplos de cómo se indica visualmente el estado de selección en diferentes

tipos de interfaz de usuario. Las diferencias en el color de tinte son a menudo una
señal de selección para controles segmentados y botones de pestañas. También hay
Figura 7: Los resultados de detección de interfaz de usuario sin procesar de otros indicadores visuales para los estados de selección.
nuestro modelo no siempre darían como resultado la mejor experiencia de
usuario del lector de pantalla. (Izquierda) El modelo no detecta el control
aproveche algunas funciones integradas de iOS para reconocer el contenido en estas
segmentado más a la izquierda. (Centro) El paraguas más a la derecha tiene
detecciones de la interfaz de usuario.Para texto:utilizamos el motor OCR integrado de iOS [5],
dos detecciones; La casilla de verificación y el texto no están agrupados.
que proporciona un cuadro delimitador estrecho y un resultado de texto preciso con una
(Derecha) La detección de contenedor grande en la mitad inferior puede
latencia razonable (< 0,5 s).Para icono:aprovechamos el motor de reconocimiento de iconos
eliminarse. En todos los ejemplos, el ícono y el texto en la barra de pestañas
en iOS 13 (y versiones posteriores) VoiceOver para clasificar 38 tipos de iconos comunes [10].
deben agruparse como botones de pestañas. Las pantallas de ejemplo son de
Para la imagen:aprovechamos la función de descripciones de imágenes en VoiceOver de iOS
Apple Health y Dark Sky.
14 para generar texto alternativo de oración completa [4].

5.1 Búsqueda de elementos de la interfaz de usuario que

5.3 Determinación del estado de selección de la interfaz de usuario
faltan y eliminación de detecciones adicionales
Varios tipos de interfaz de usuario también tienen estados de selección, como Alternar, Casilla de verificación, Control segmentado y Botón de

Nuestro modelo de detección de IU puede pasar por alto algunos elementos de la IU. pestaña. Con estos metadatos, VoiceOver puede anunciar interfaces de usuario con estados de selección (p. ej., "Modo avión, O�", "Alarma,

Como se ve en la Fig. 7 a la izquierda, el modelo a veces solo detecta un subconjunto Pestaña, Seleccionado" en la Fig. 8). Para Toggle y Checkbox, nuestro modelo de detección de IU incluye estados de selección en los tipos de IU

de controles segmentados (SC). En el 99,1 % de las pantallas de nuestro conjunto de detectados. Para el control segmentado y el botón de pestaña, aprovechamos su información visual para determinar los estados de selección. El

datos, cada texto en la misma fila de SC está contenido en un SC. Según este patrón, indicador visual más común es el color del tinte. Como se muestra en la Fig. 8.f, la pestaña seleccionada tiene color de tinte mientras que otras

después de detectar SC en una pantalla, encontramos detecciones de texto en la pestañas no están resaltadas. Dentro de cada pestaña, extraemos el color más frecuente como color de fondo y el segundo color más frecuente

misma fila de SC detectados, pero no contenidas en ningún SC. Nuestras heurísticas como color de matiz. Entre todos los botones de pestañas, encontramos el que tiene un color de tinte atípico [60]. Finalmente, asignamos un

actualizan estos elementos de texto como controles segmentados. Otro elemento "seleccionado" estado a esa detección, y un estado "no seleccionado" a las detecciones restantes. Los controles segmentados también utilizan con

común de la interfaz de usuario que falta es el texto, especialmente cuando es frecuencia el color del matiz como indicador visual. Como se muestra en la Fig. 8, los diseños de interfaz de usuario personalizados pueden

pequeño o tiene un fondo complejo. Para abordar este problema, ejecutamos el mantener el mismo color de tinte y usar otros indicadores visuales (Fig. 8.c); por lo tanto, tratamos de abordar algunos diseños comunes con

motor OCR integrado de iOS [5], que está entrenado específicamente para detectar heurísticas adicionales, como verificar la barra en la parte inferior del control segmentado (Fig. 8.d) o encontrar la única pestaña con texto (Fig. 8.g).

texto y supera a nuestro modelo en esta clase. Incluimos detecciones de texto de OCR Evaluamos nuestras heurísticas de estado de selección en nuestro conjunto de datos de prueba (5002 pantallas). En las 936 pantallas en las que

cuando nuestro modelo las pierde (es decir, el texto de OCR no se superpone con las nuestro enfoque detecta botones de pestañas, asignamos el estado de selección correcto el 90,5 % de las veces. Entre 337 pantallas en las que

detecciones existentes). nuestro enfoque detecta controles segmentados, asignamos el estado de selección correcto en el 73,6 % de las pantallas. estado a las detecciones

Nuestro modelo de detección de IU también puede detectar elementos de IU adicionales. restantes. Los controles segmentados también utilizan con frecuencia el color del matiz como indicador visual. Como se muestra en la Fig. 8, los

Para un elemento de la interfaz de usuario, nuestro modelo a veces genera varios cuadros diseños de interfaz de usuario personalizados pueden mantener el mismo color de tinte y usar otros indicadores visuales (Fig. 8.c); por lo tanto,

delimitadores, cada uno con un tipo de interfaz de usuario diferente pero visualmente similar tratamos de abordar algunos diseños comunes con heurísticas adicionales, como verificar la barra en la parte inferior del control segmentado (Fig.

(es decir, Imagen/Icono, Control segmentado/Campo de texto/Contenedor). Por ejemplo, en 8.d) o encontrar la única pestaña con texto (Fig. 8.g). Evaluamos nuestras heurísticas de estado de selección en nuestro conjunto de datos de

la Fig. 7 (Centro), el "paraguas" más a la derecha tiene un cuadro detectado como Icono y otro prueba (5002 pantallas). En las 936 pantallas en las que nuestro enfoque detecta botones de pestañas, asignamos el estado de selección correcto el

cuadro detectado como Imagen. Por lo tanto, aplicamos un algoritmo de supresión no máx. 90,5 % de las veces. Entre 337 pantallas en las que nuestro enfoque detecta controles segmentados, asignamos el estado de selección correcto en

personalizado para eliminar las detecciones duplicadas dentro de estos tipos de interfaz de el 73,6 % de las pantallas. estado a las detecciones restantes. Los controles segmentados también utilizan con frecuencia el color del matiz como

usuario visualmente similares. También hay elementos adicionales de la interfaz de usuario indicador visual. Como se muestra en la Fig. 8, los diseños de interfaz de usuario personalizados pueden mantener el mismo color de tinte y usar

que no debemos eliminar (p. ej., una imagen grande puede contener un icono pequeño, un otros indicadores visuales (Fig. 8.c); por lo tanto, tratamos de abordar algunos diseños comunes con heurísticas adicionales, como verificar la barra

contenedor puede contener un campo de texto), por lo que nuestro algoritmo solo elimina las en la parte inferior del control segmentado (Fig. 8.d) o encontrar la única pestaña con texto (Fig. 8.g). Evaluamos nuestras heurísticas de estado de

detecciones espacialmente similares cuando IoU > 0.8. selección en nuestro conjunto de datos de prueba (5002 pantallas). En las 936 pantallas en las que nuestro enfoque detecta botones de pestañas, asignamos el estado de selección

5.2 Reconocimiento del contenido de la interfaz de usuario 5.4 Determinación de la interactividad de la interfaz de usuario

Los tipos de IU Texto, Icono e Imagen (que comprenden el 83,3 % de los elementos de la IU Saber si un elemento de la interfaz de usuario es interactivo es importante para los usuarios de

en nuestro conjunto de datos) contienen información valiosa. Por lo tanto, es importante lectores de pantalla. Con los metadatos de accesibilidad correctos, un lector de pantalla puede

reconocer y describir su contenido a los usuarios de lectores de pantalla. Nosotros anunciar acciones compatibles con cada elemento de la interfaz de usuario (p. ej., "Página
Reconocimiento de pantalla: creación de metadatos de accesibilidad para aplicaciones móviles a partir de píxeles CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón

no está disponible cuando el ícono no está en los 38 tipos de 2) determinar si una detección de texto o iconoDestá en la barra de pestañas
íconos admitidos). Para predecir la posibilidad de hacer clic siDestá en el 20% inferior de la pantalla, yB.abajo-D.parte superior está
en los íconos, entrenamos un modelo de árboles de dentro de un umbral (0.08 * altura de la pantalla) para queDno es mucho
regresión potenciados por gradientes [3] con varias más alto queB; 3) agrupar las detecciones de icono y texto que tienen
características (es decir, ubicación, tamaño, resultado del superposición x juntas, y determinar que están en la barra de pestañas,
reconocimiento de íconos). Este modelo está entrenado con como un botón de pestaña.
los kits de herramientas TuriCreate Boosted Trees Classi�er • Agrupación de contenedores(Fig. 9.D): Agrupamos una detección de Contenedor
[3]; la inferencia tarda menos de 10 ms y usa 10 MB de con todas las detecciones dentro como un solo elemento.
memoria (modelo CoreML). Solo marcamos un icono como • Agrupación de subtítulos de imágenes(Fig. 9.D): Agrupamos TextoT1como
seleccionable cuando nuestro modelo es muy seguro, ya que subtítulo descriptivo con ImagenPAGSsi satisfacen: 1) tienen más del 50 % de
los usuarios de lectores de pantalla prefieren una mayor superposición x conPAGS, 2)T1tiene una distancia y aPAGSmenos de un
precisión a la recuperación: si un icono en el que se puede umbral (elegimos 0,03 * altura de la pantalla), y 3)T1está más cerca dePAGS
hacer clic se predice que no se puede hacer clic, el usuario que a cualquier otra detección a continuaciónT1. Además agrupamos una
aún puede intentar activarlo; si se predice que se puede segunda línea de TextoT2abajoT1si cumple las mismas condiciones en
hacer clic en un icono en el que no se puede hacer clic, el relación conT1.
usuario escuchará "Botón" en los anuncios del lector de
pantalla y se confundirá si la activación no hace nada. Por lo
tanto, elegimos un umbral para que nuestro modelo Para evaluar estas heurísticas, ejecutamos nuestras heurísticas de agrupación en un subconjunto de pantallas recopiladas (n=300,

mantenga una precisión del 90,0 %. lo que permite un 73,6% seleccionadas al azar). En general, nuestra heurística de agrupación redujo la cantidad de elementos de la interfaz de usuario para navegar en un

de recuerdo. Además, hay más interactividades de la interfaz 48,5 % (sin agrupación: media: 21,83, estándar: 12,8, con agrupación: media: 12,1, estándar: 7,6). Dos investigadores (autores de este artículo)

de usuario que vale la pena investigar en trabajos futuros, tabularon manualmente los errores de agrupación en estas pantallas utilizando una rúbrica que contiene 4 categorías heurísticas de agrupación

como detectar el estado habilitado/inhabilitado de los (es decir, agrupación de texto, contenedor, subtítulo de imagen, pestaña) y "Otros" para errores adicionales. Los errores de agrupación se clasifican

elementos de la interfaz de usuario. como "Debería haber agrupado" si dos o más elementos deberían haberse agrupado, o "Incorrectamente agrupados" si se agruparon dos o más

elementos no relacionados. Como puede haber múltiples agrupaciones para algunos elementos, no contamos un agrupamiento o un

agrupamiento perdido como un error si era ambiguo. Reconocemos que la observación humana no es perfecta y que puede haber sesgo al realizar

la evaluación por parte de los autores. Para mitigar estas preocupaciones, los investigadores primero evaluaron de forma independiente el 10% de

las pantallas y luego discutieron los errores encontrados hasta alcanzar un nivel de acuerdo suficiente. Después de llegar a un consenso, cada

investigador examinó la mitad de las pantallas y encontró cantidades muy similares de errores de agrupación en conjuntos de pantallas

5.5 Agrupación de Elementos para una Navegación E�ciente independientes. Entre 1568 grupos realizados, 88 (5,6%) estaban "agrupados incorrectamente". Además, encontramos 99 errores "Debería haber

agrupado". Hubo 0,62 errores por pantalla (Min=0, Max=8, Std=1,1). y podría haber sesgo al hacer la evaluación por parte de los autores. Para
La agrupación de elementos de interfaz de usuario relacionados hace que la
mitigar estas preocupaciones, los investigadores primero evaluaron de forma independiente el 10% de las pantallas y luego discutieron los errores
navegación sea más eficiente para los lectores de pantalla y otros servicios de
encontrados hasta alcanzar un nivel de acuerdo suficiente. Después de llegar a un consenso, cada investigador examinó la mitad de las pantallas y
accesibilidad [8, 36]. La figura 9 muestra las detecciones originales de nuestro modelo
encontró cantidades muy similares de errores de agrupación en conjuntos de pantallas independientes. Entre 1568 grupos realizados, 88 (5,6%)
de detección de elementos de la interfaz de usuario; navegar a través de una gran
estaban "agrupados incorrectamente". Además, encontramos 99 errores "Debería haber agrupado". Hubo 0,62 errores por pantalla (Min=0, Max=8,
cantidad de detecciones llevaría mucho tiempo a los usuarios de lectores de pantalla
Std=1,1). y podría haber sesgo al hacer la evaluación por parte de los autores. Para mitigar estas preocupaciones, los investigadores primero
para comprender el contenido de la pantalla. Para reducir la cantidad de elementos
evaluaron de forma independiente el 10% de las pantallas y luego discutieron los errores encontrados hasta alcanzar un nivel de acuerdo
de la interfaz de usuario en la navegación, agrupamos los elementos relacionados.
suficiente. Después de llegar a un consenso, cada investigador examinó la mitad de las pantallas y encontró cantidades muy similares de errores
Para los elementos de la interfaz de usuario agrupados, brindamos acceso a
de agrupación en conjuntos de pantallas independientes. Entre 1568 grupos realizados, 88 (5,6%) estaban "agrupados incorrectamente". Además,
subelementos en los que se puede hacer clic a través de acciones personalizadas
encontramos 99 errores "Debería haber agrupado". Hubo 0,62 errores por pantalla (Min=0, Max=8, Std=1,1). y encontró números muy similares de
(compatibles con lectores de pantalla móviles). El usuario también puede leer cada
errores de agrupación en conjuntos independientes de pantallas. Entre 1568 grupos realizados, 88 (5,6%) estaban "agrupados incorrectamente". Además, encontramos 99 errores
subelemento en el que no se puede hacer clic ajustando la granularidad del habla en
El conjunto más grande de errores de agrupación fueron de nuestroagrupación
el rotor [1]. Este enfoque todavía tiene limitaciones: cuando nuestro modelo comete
de texto heurístico (25,7%), seguido desubtítulo de imagen(dieciséis%),botón de
errores al inferir la posibilidad de hacer clic, los usuarios pueden perder el acceso a
pestaña(8,6%) yenvase(7,5%). El 42 % de los errores de agrupación no caían en una de
algunos subelementos en los que se puede hacer clic. Sin embargo,
nuestras categorías heurísticas: la mayoría de los errores (48 errores) consistían en
texto de agrupación faltante con iconos contenidos, texto restante detectado por OCR
Desarrollamos varias heurísticas que agrupan las detecciones de IU en función de
dentro de iconos y agrupación de texto no relacionado. Al evaluar los errores de
sus tipos de IU, tamaños y relaciones espaciales en la pantalla. La figura 9 muestra los
agrupación, también encontramos oportunidades para mejorar aún más la
resultados de nuestra heurística de agrupación en pantallas de ejemplo.
experiencia del usuario (p. ej., agrupar el texto y el campo de texto debajo), lo que
Proporcionamos el texto concatenado de subelementos como texto alternativo para
puede dar lugar a nuevas heurísticas.
cada elemento agrupado.
Si bien nuestras heurísticas en general funcionaron bien, observamos que es probable
• Agrupación de texto(Fig. 9.B): Agrupamos un TextoT1con un texto que estas heurísticas tengan más éxito cuando se aplican a las pantallas de aplicaciones de
debajo T2si cumplen: 1) tienen superposición x, y 2) la distancia y entre iOS debido a la influencia de los widgets de interfaz de usuario nativos y las pautas de diseño
los dos textos debe ser menor que un umbral: elegimosmin(T1.altura,T (es decir, Pautas de interfaz humana). Por ejemplo, nuestra heurística de Agrupación de
2.altura). Hacemos esto repetidamente para agrupar texto de varias pestañas probablemente funcione bien porque iOS proporciona un widget estándar, que usa
líneas. una cantidad significativa de aplicaciones, para mostrar pestañas en la parte inferior de la
• Agrupación de pestañas(Fig. 9.B): Agrupamos las detecciones de íconos y pantalla de una aplicación (es decir, UITabBarController). Como tal, nuestra heurística puede
texto en botones de pestañas 1) encontrando la detección más inferiorB; necesitar ser adaptada para otras plataformas.
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón Zhang, de Greef, Swearngin, et al.

Figura 9: Pantallas de ejemplo para demostrar nuestras heurísticas de agrupación y ordenación:(A, C)Detecciones de UI de nuestro modelo en pantallas de
aplicaciones Apple Clock y Apple Watch,(B)la salida que muestra la agrupación de botones de tabulación y texto, y(D)la salida que demuestra la agrupación de
imágenes/subtítulos y contenedores. Nuestras heurísticas de ordenación infieren el orden de navegación (que se muestra en la parte superior izquierda de cada
cuadro), que divide recursivamente la pantalla en regiones verticales y horizontales (ejemplos visualizados con línea discontinua).

(p. ej., Android) si los diseños de widgets de la plataforma son bastante diferentes de "Agregar", "Reloj mundial" y "Hoy, más 0 HRS, Cupertino" para los primeros
los diseños de iOS. cuatro elementos.
Para evaluar nuestras heurísticas de ordenación, las ejecutamos en un

5.6 Inferir orden de navegación subconjunto de pantallas recopiladas (n=380, seleccionadas al azar). Diez expertos en
accesibilidad de nuestra empresa anotaron el orden de navegación real en tierra.
Los lectores de pantalla móviles permiten deslizar para navegar por todos los elementos de la interfaz de usuario
Para cada pantalla, comparamos nuestra salida heurística y el orden de navegación
en una pantalla en un orden lógico. Por lo tanto, debemos proporcionar los elementos de la interfaz de usuario
de la verdad básica con una métrica que se ve a menudo en la clasificación de listas:
detectados a los lectores de pantalla en un orden de navegación razonable. Después de aplicar nuestra heurística
los pasos mínimos de inserción para que nuestra salida sea igual a la verdad básica
de agrupación, determinamos el orden de navegación con un algoritmo de segmentación de página de corte XY
(en un paso, un elemento se puede insertar en cualquier otro). posición en la lista).
OCR ampliamente utilizado [41, 54], que ordena los bloques de texto/imagen de un documento en orden de
Nuestra salida heurística coincidió perfectamente con la verdad del terreno para 280
lectura humana. Aplicamos el algoritmo a nuestro problema, como se muestra en la Fig. 9.D: (i) Construimos
pantallas (73,7 %), mientras que 345 pantallas (90,8 %) tuvieron menos de 1 error (es
segmentos verticales determinando las coordenadas Y donde podemos dibujar una línea horizontal a través de la
decir, 1 paso de inserción) por cada 10 elementos. En promedio, había 18,7 elementos
pantalla sin superponer ningún elemento. (ii) Dentro de cada segmento vertical, construimos segmentos
por pantalla (min=1, max=92, std=13,8); nuestra heurística produjo una media de 0,67
horizontales al ubicar las coordenadas X donde podemos dibujar una línea vertical hacia abajo del segmento sin
errores por pantalla (min=0, max=17, std=1,79).
superponer ningún elemento. (iii) Llamamos recursivamente a este algoritmo en todos los segmentos horizontales

para crear más segmentos verticales y así sucesivamente. Cuando ya no podemos subdividir un segmento,
Para comprender dónde se podrían mejorar nuestras heurísticas de
ordenamos los elementos del interior de arriba a abajo. Si hay empate, los ordenamos de izquierda a derecha.
ordenación, examinamos 35 pantallas con más de 1 error por cada 10
Dentro de los elementos agrupados, también aplicamos el algoritmo de corte XY para ordenar los subelementos.
elementos. En 12 pantallas, encontramos que el orden era ambiguo (es decir,
La figura 9 muestra un número en la parte superior izquierda de cada elemento para indicar el orden de
había varios pedidos razonables). Para las pantallas restantes, 19 de ellas
navegación que proporcionamos a los lectores de pantalla. En la Fig. 9.B, un usuario de lector de pantalla
tendrían un mejor orden de navegación al mejorar nuestras heurísticas de
escucharía "Editar", 9 muestra un número en la parte superior izquierda de cada elemento para indicar el orden de
agrupación: (i) nuestras heurísticas agruparon algún texto con imágenes
navegación que proporcionamos a los lectores de pantalla. En la Fig. 9.B, un usuario de lector de pantalla
incorrectamente, o nuestrasubtítulo de imagenla heurística de agrupación no
escucharía "Editar", 9 muestra un número en la parte superior izquierda de cada elemento para indicar el orden de
agrupó algún texto como subtítulo, lo que provocó errores de ordenación
navegación que proporcionamos a los lectores de pantalla. En la Fig. 9.B, un usuario de lector de pantalla

escucharía "Editar",
Reconocimiento de pantalla: creación de metadatos de accesibilidad para aplicaciones móviles a partir de píxeles
(13 pantallas); (ii) nuestroagrupación de textola heurística agrupó algún texto
incorrectamente o debería haber agrupado algún texto que causó errores de
ordenación (9 pantallas); (iii) nuestra heurística detectó algunos íconos dentro de los
bloques de texto pero no los agrupó con el texto, por lo que los íconos se ordenaron
después del texto (6 pantallas).
6 ESTUDIOS DE USUARIOS
Para comprender cómo nuestro enfoque afecta la experiencia del usuario de
los lectores de pantalla, realizamos un estudio de usuarios con 9 personas con
discapacidad visual (3 mujeres, 6 hombres). Todos son usuarios habituales de
iOS VoiceOver con un promedio de 8,9 años (mín. = 6, máx. = 11) de experiencia
en VoiceOver. La edad promedio de los participantes fue de 44,2 años (mín. =
28, máx. = 65). En los estudios, les pedimos a los participantes que usaran
aplicaciones con VoiceOver y Screen Recognition regulares (nuestro enfoque) y
compararan sus experiencias. Había dos tipos de estudios:
(i)Estudios de entrevista: a través de videoconferencia con 4 usuarios de lectores de pantalla
(1F, 3M) que son ingenieros de control de calidad de accesibilidad en nuestra empresa, y(ii)
Estudios de correo electrónico: un estudio de usabilidad remoto no supervisado a través de
correos electrónicos con 5 usuarios de lectores de pantalla (2F, 3M) que se ofrecieron a
participar, lo que brinda más flexibilidad de tiempo que las entrevistas. Para reducir el sesgo,
excluimos de nuestros estudios a los ingenieros de control de calidad que proporcionaron
sugerencias en la Sección 5.
6.1 Procedimiento
Ambos estudios utilizaron las mismas instrucciones y preguntas. Pedimos a los
participantes que seleccionaran 3 aplicaciones de iOS que les resultaran
difíciles o imposibles de usar con VoiceOver. Si los participantes no podían
pensar en tales aplicaciones, ofrecimos una lista de sugerencias. Pedimos a los
participantes que pasaran 10 minutos usando cada aplicación, primero con
VoiceOver normal y luego con Reconocimiento de pantalla. Durante el estudio,
los participantes siempre estaban al tanto de la condición actual que estaban
probando. No equilibramos el orden de las condiciones, ya que todos los
participantes eran usuarios experimentados de VoiceOver y la mayoría de las
aplicaciones en el estudio fueron sugeridas por los participantes (ya probaron
estas aplicaciones con VoiceOver normal antes). Recopilamos comentarios de
los participantes sobre las diferencias que experimentaron entre VoiceOver
normal y el Reconocimiento de pantalla, los beneficios del Reconocimiento de
pantalla,
Debido a la pandemia de COVID-19, realizamos todos los estudios de usuarios de forma
remota. En los estudios de entrevista, enviamos la preparación del estudio por correo
electrónico con anticipación y los comentarios se recopilaron a través de una conferencia
telefónica. En los estudios por correo electrónico, enviamos y recopilamos todas las
instrucciones y comentarios del estudio por correo electrónico.
6.2 Resultados
Cada participante eligió aplicaciones para usar durante el estudio que previamente
les habían resultado difíciles de usar con VoiceOver. Los participantes usaron 22
aplicaciones diferentes, de las cuales solo 2 provenían de nuestra lista sugerida.
Varios participantes exploraron solo 2 aplicaciones: una de nuestra lista sugerida
(elegida por 4 participantes) y otra que no está en la lista (elegida por 2 participantes).
Tenga en cuenta que no compartimos nombres de aplicaciones específicos porque
queremos ser respetuosos y no destacar a los desarrolladores individuales. Los
participantes eligieron una combinación de aplicaciones con diferentes niveles de
usabilidad para VoiceOver y las calificaron de 1 (nada usable) a 5 (totalmente usable).
La mayoría de los participantes eligieron 3 aplicaciones que ya sabían que eran
inaccesibles, pero 3 participantes también decidieron
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
Narración Reconocimiento de pantalla
8
15
6
10
Contar
Contar
4
5
2
0 0
1 2 3 4 5 -1 0 1 2 3
Clasificación Diferencia de calificación
Figura 10: (Izquierda) Un histograma de calificaciones de usabilidad para
aplicaciones que usan VoiceOver y Reconocimiento de pantalla regulares.
(Derecha) Un histograma de las diferencias de calificación dentro de las
aplicaciones individuales entre los dos sistemas, como la calificación de
Reconocimiento de pantalla menos la calificación de VoiceOver normal.
para incluir una aplicación que sabían que era accesible y que proporcionaba información
útil. Todas las aplicaciones que eligieron los participantes estaban disponibles en la App Store
de iOS a partir de agosto de 2020. Algunas aplicaciones fueron creadas por las principales
empresas tecnológicas, pero la mayoría fueron creadas por desarrolladores más pequeños o
empresas no tecnológicas, como las empresas de medios.
En general, las calificaciones de usabilidad de las aplicaciones que usan VoiceOver
regular promediaron 2.08 (SD 1.20), mientras que las calificaciones de las aplicaciones
que usan Screen Recognition promediaron 3.73 (SD 0.78). Esta diferencia es
significativa según una prueba de rangos con signo de Wilcoxon (p < 0,00004). La
figura 10 muestra un histograma de calificaciones de usabilidad y un histograma de
diferencias de calificación dentro de aplicaciones individuales entre los dos sistemas.
Para los participantes estaba claro que los investigadores crearon el Reconocimiento
de pantalla, por lo que estos resultados pueden reflejar algún sesgo [29, 74], pero aun
así muestran una diferencia bastante significativa entre los dos sistemas,
especialmente en las aplicaciones inaccesibles que eligieron los participantes. En 4
casos, los participantes otorgaron a Screen Recognition una calificación de usabilidad
idéntica o peor que VoiceOver normal. Dos de estos casos fueron para aplicaciones
que el participante calificó como muy útiles (5) con VoiceOver normal, y luego calificó
el reconocimiento de pantalla como usable con un 4 o un 5. En los otros dos casos,
ambas experiencias recibieron la misma calificación baja (2 y 3 respectivamente).
Según los comentarios de los participantes y nuestro propio uso, creemos que estas
últimas calificaciones reflejan que estas aplicaciones son difíciles de usar en general,
incluso para las personas videntes.
Para las aplicaciones que los participantes calificaron como inutilizables con
VoiceOver regular, todos notaron que estas aplicaciones exhibían elementos de la
interfaz de usuario sin etiquetas, y que era frustrante saber que existía un control
pero no sabían su propósito. Al explorar las mismas aplicaciones con el
reconocimiento de pantalla, todos los participantes comentaron que se dieron cuenta
de los elementos de la interfaz de usuario que no sabían que existían porque no
estaban expuestos en la interfaz de VoiceOver normal. Un participante señaló que en
una aplicación se puso a disposición un control deslizante, lo que les sorprendió
porque estos elementos a menudo no están disponibles o no se pueden utilizar. En
otro caso, un participante dijo:
QA2:“Estoy tan emocionada que NECESITO compartir. Anoche descargué
[nombre de la aplicación eliminado]... que no tiene elementos AX y es
completamente inutilizable. Así que decidí habilitar [Reconocimiento de
pantalla]. ¿Adivina quién tiene una nueva puntuación más alta? ¡Estoy
impresionado! Esto es increíble. es el primero
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
juego convencional que he podido jugar en iOS
además de Trivia Crack”.
Tres participantes eligieron probar aplicaciones que sabían que eran accesibles. En
estos casos, los participantes aún compararon el Reconocimiento de pantalla
favorablemente con VoiceOver normal, y señalaron que el Reconocimiento de
pantalla expuso ciertas funciones de una manera diferente y potencialmente útil. Por
ejemplo, un participante notó que el diseño de la pantalla se les reveló de una manera
que a menudo se les pasó por alto, diciendo:
P1:“Fue divertido descubrir el contenido de las imágenes de perfil
que se muestran junto al nombre de la persona y comprender el
diseño de la aplicación. Obviamente, al hacer que la aplicación sea
accesible, a menudo perdemos la comprensión del diseño de la
pantalla. Con [Reconocimiento de pantalla] ahora tenemos la
capacidad de comprender la aplicación espacialmente además de
contextualmente”.
La única experiencia de reconocimiento de pantalla calificada como menos
utilizable que la experiencia de VoiceOver normal ocurrió con una aplicación de
redes sociales. El participante que presentó esta aplicación señaló que era muy
accesible y le otorgó una puntuación de usabilidad de 5 con VoiceOver normal,
mientras que le dio a Screen Recognition una puntuación de usabilidad de 4. La
razón principal de esta diferencia fueron las opciones de agrupación de los
desarrolladores de aplicaciones. , que hizo que la navegación a través de
muchos tweets fuera rápida y se centrara solo en el contenido esencial. El
participante notó que navegar por esta interfaz con el reconocimiento de
pantalla era mucho más lento, lo que incluye una variedad de contenido de
baja prioridad (por ejemplo, cantidad de me gusta, cantidad de retweets,
etiquetas hash, etc.) que la interfaz de la aplicación con VoiceOver normal
omitió. Sin embargo, este participante notó que vieron valor en la interfaz de
reconocimiento de pantalla en ciertas situaciones porque, aunque lento,
permitía el acceso a cierto contenido que de otro modo no estaría disponible.
Poder cambiar entre los dos modos permitió a este participante profundizar en
el contenido de la interfaz cuando fue necesario, mientras disfrutaba de una
experiencia optimizada el resto del tiempo.
Este ejemplo ilustra un resultado importante: incluso con el reconocimiento de pantalla,
las experiencias más accesibles aún las crean los desarrolladores de aplicaciones que
entienden cómo se puede transmitir mejor el contenido para satisfacer las necesidades de
los usuarios. Es posible que nuestro sistema no tenga la comprensión de alto nivel de las
interfaces de las aplicaciones para darse cuenta de que la lista de tweets debe optimizarse,
mientras que los desarrolladores de aplicaciones pueden comprender mejor el diseño e
implementar la experiencia de accesibilidad para los usuarios.
El reconocimiento de pantalla tiene margen de mejora. Dos participantes notaron
que, si bien muchos controles se hicieron evidentes con el reconocimiento de
pantalla, las etiquetas de estos controles a veces requerían interpretación. Por
ejemplo, un ícono etiquetado como "flecha hacia abajo" podría hacer que un
elemento se moviera hacia abajo en una lista, pero no expuso esta semántica de nivel
superior. En estos casos, los participantes comentaron que pudieron descifrar la
interfaz de usuario con algo de experimentación. Otra limitación del reconocimiento
de pantalla es que no puede exponer funciones que no tengan un rendimiento visual
claro. Por ejemplo, un participante descubrió que con Screen Recognition, era
imposible pasar las páginas en una aplicación de lectura de libros, a pesar de que
Screen Recognition puso a disposición el texto del libro que antes era ilegible. En esta
aplicación, el cambio de página se activaba deslizando el dedo desde el borde de la
pantalla, que no tenía un acuerdo visual para que el reconocimiento de pantalla lo
reconociera. Un problema desafiante para el trabajo futuro podría ser mejorar
Zhang, de Greef, Swearngin, et al.
comprender la semántica de la interfaz visual. Finalmente, un participante notó que
ocasionalmente experimentaba retrasos con el Reconocimiento de pantalla en
pantallas especialmente complejas, lo que ayuda a justificar nuestras intenciones de
explorar más adelante optimizaciones para nuestro sistema.
7 DISCUSIÓN Y TRABAJO FUTURO
A pesar del esfuerzo persistente en herramientas, educación y políticas para
desarrolladores, la accesibilidad sigue siendo un desafío en todas las plataformas
porque muchas aplicaciones no se crean con metadatos semánticos suficientes para
permitir que los servicios de accesibilidad funcionen como se esperaba. En este
documento, presentamos un enfoque que, en cambio, genera metadatos de
accesibilidad a partir de los píxeles de las interfaces visuales, lo que abre una serie de
oportunidades para el trabajo futuro.
Una serie de próximos pasos se derivan directamente del enfoque y los
resultados presentados en este documento. Un próximo paso claro es seguir
mejorando nuestro modelo y nuestras heurísticas para hacerlos más precisos.
Nuestro enfoque actual genera metadatos desde cero una y otra vez; el trabajo
futuro puede explorar cómo permitir que estos metadatos persistan a través
de las invocaciones de una aplicación o incluso entre dispositivos. Otro
siguiente paso es aplicar nuestro enfoque a otras plataformas móviles (p. ej.,
Android) y también más allá del contexto móvil, como para escritorio o
interfaces web, que son igualmente inaccesibles debido a la falta de semántica
adecuada proporcionada por los desarrolladores. Aplicar nuestro enfoque al
escritorio o la Web presentaría nuevos desafíos, ya que nuestro método actual
aprovecha las limitaciones de tamaño y complejidad de las aplicaciones
móviles.
En el trabajo presentado aquí, usamos solo información de píxeles para crear los
metadatos semánticos necesarios para los servicios de accesibilidad. No
aprovechamos los datos semánticos dentro de la jerarquía de vista de la aplicación,
que utilizan los servicios de accesibilidad [10, 38]. Si bien la combinación de
información de nuestro enfoque y la jerarquía de vistas podría reconstruir un
conjunto más completo de metadatos de accesibilidad, descubrimos que implementar
esta idea presenta desafíos de ingeniería para extraer y fusionar de manera efectiva
las dos representaciones en el momento. Actualmente, los usuarios deben ingresar a
un modo separado para acceder a los metadatos automáticos; a medida que
exploramos los modos combinados, sospechamos que tendremos que considerar aún
más cuidadosamente cómo transmitir los metadatos inferidos a los usuarios. Además,
quedan preguntas sobre cómo resolver las diferencias incompatibles entre las
representaciones, especialmente en lo que se refiere a conceptos de nivel superior,
como el agrupamiento y el ordenamiento. En lugar de una fusión post hoc, una
oportunidad interesante para el trabajo futuro podría ser construir un modelo que
aproveche la información estructurada en la jerarquía de vistas además de los píxeles.
Nuestro modelo y heurística tienen muchos otros casos de uso para explorar.
Demostramos cómo podemos aplicarlos para mejorar la accesibilidad en los dispositivos de
los usuarios en tiempo real. Otra oportunidad es incorporar el modelo en las herramientas de
desarrollo para ayudar a los desarrolladores a crear aplicaciones más accesibles desde el
principio. Las herramientas de evaluación de accesibilidad actuales dependen principalmente
de los metadatos (potencialmente incompletos) que los desarrolladores ya proporcionan, lo
que limita el acceso de las herramientas a la información para informar sus sugerencias de
accesibilidad. Nuestro enfoque para comprender las interfaces de usuario a partir de píxeles
podría permitir que las herramientas para desarrolladores identifiquen más problemas de
accesibilidad y sugieran soluciones automáticamente. Finalmente, si bien nos hemos
centrado en los casos de uso de accesibilidad, las API de accesibilidad también forman la base
de la mayoría de la automatización en el dispositivo [49], por lo que esperamos que nuestro
enfoque encuentre utilidad en muchos otros casos de uso.
Reconocimiento de pantalla: creación de metadatos de accesibilidad para aplicaciones móviles a partir de píxeles
La longevidad de nuestro modelo es incierta. Los diseños de aplicaciones visuales
cambian con el tiempo, tanto en términos de cualidades estéticas como en relación
con los dispositivos de destino. Si bien las personas generalmente pueden adaptarse
a tales cambios visuales, es posible que nuestro modelo deba volver a entrenarse.
Sería ideal crear un modelo más universal que sea resistente a tales cambios o que
incluso pueda actualizarse mientras visita nuevas aplicaciones. Si bien la
incertidumbre permanece, nuestro conjunto de datos, a medida que lo actualicemos
con el tiempo, proporcionará una ventana sobre cómo ocurren estos cambios
visuales y cómo afectan los métodos automáticos que operan en ellos.
Finalmente, nuestro enfoque podría verse como una reacción a la forma en que la
mayoría de los desarrollos de aplicaciones actualmente priorizan el diseño visual, en
lugar de abordar el problema desde la perspectiva de la accesibilidad. Esperamos
que, al automatizar algunos aspectos de la generación de metadatos de accesibilidad,
especialmente a través de futuras mejoras en las herramientas para desarrolladores,
nuestro enfoque pueda ayudar a escalar la accesibilidad básica, liberando a los
investigadores, desarrolladores y profesionales de la accesibilidad de ponerse al día
y, en su lugar, permitirles trabajar hacia soluciones más innovadoras y experiencias
integrales accesibles para todos.
8 CONCLUSIÓN
Hemos presentado un enfoque para crear automáticamente metadatos de
accesibilidad para aplicaciones móviles a partir de sus píxeles. Nuestra evaluación
técnica y la evaluación de los usuarios demuestran que este enfoque es prometedor y,
a menudo, puede hacer que las aplicaciones inaccesibles sean más accesibles.
Nuestro trabajo ilustra un nuevo enfoque para resolver un problema de accesibilidad
de larga data, que tiene implicaciones en varias plataformas y servicios diferentes. En
el futuro, nos gustaría usar los metadatos de accesibilidad generados
automáticamente no solo para impactar directamente en las funciones de
accesibilidad, sino también para ayudar a los desarrolladores a hacer que sus
aplicaciones sean más accesibles desde el principio.
EXPRESIONES DE GRATITUD
Agradecemos a nuestros colegas de Apple, en particular: Cynthia L.
Ben- red, Shantanu Chhabra, Dominik Moritz,Muriel Nahmani y Jay
Pillai por sus contribuciones.
REFERENCIAS
[1] Manzana. 2020. Acerca del rotor de VoiceOver en iPhone, iPad y iPod touch. https: //
support.apple.com/en-us/HT204783/
[2] Manzana. 2020. Accesibilidad por Desarrolladores.
https://developer.apple.com/accessibility/.
[3] Manzana. 2020. Clasificador de Árboles Impulsados. https://apple.github.io/turicreate/
docs/userguide/supervised-learning/boosted_trees_classi�er.html
[4] Manzana. 2020. Vista previa de iOS 14 - Características. https://www.apple.com/ios/
ios-14-preview/features/.
[5] Manzana. 2020. Reconocimiento de texto en imágenes. https://developer.apple.com/
documentación/visión/reconociendo_texto_en_imágenes/
[6] Manzana. 2020. Turi Crear. https://github.com/apple/turicreate/
[7] Manzana. 2020. UIAccesibilidad. https://developer.apple.com/documentation/
objetivec/vision/nsobject/uiaccessibility/
[8] Manzana. 2020. Usa el control por botón para navegar por tu iPhone, iPad o iPod touch.
https://support.apple.com/en-us/HT201370.
[9] Manzana. 2020. Usa Voice Control en tu iPhone, iPad o iPod touch. https://
support.apple.com/en-us/HT210417.
[10] Manzana. 2020. Accesibilidad de visión - iPhone. https://www.apple.com/accessibility/
iphone/vision/
[11] Nikola Banovic, Tovi Grossman, Justin Matejka y George Fitzmaurice. 2012. Waken:
información de uso de ingeniería inversa y estructura de interfaz de videos de software.
EnActas del 25º Simposio Anual de ACM sobre Software y Tecnología de Interfaz de
Usuario (UIST '12). ACM, Nueva York, NY, EE. UU., 83–92.
[12] Tony Beltramelli. 2018. Pix2Code: generación de código a partir de una captura de pantalla de la
interfaz gráfica de usuario. EnActas del Simposio de Ingeniería ACM SIGCHI
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
Sistemas informáticos interactivos(París, Francia)(EICS'18). ACM, Nueva York, NY, EE.
UU., Artículo 3, 6 páginas.
[13] Pavol Bielik, Marc Fischer y Martin Vechev. 2018. Síntesis robusta de diseño
relacional a partir de ejemplos para Android.Actas de la ACM sobre lenguajes de
programación2, OOPSLA (2018), 1–29.
[14] Giorgio Brajnik. 2008. Una prueba comparativa de métodos de evaluación de
accesibilidad web. EnActas de la 10ª conferencia internacional ACM SIGACCESS sobre
Informática y accesibilidad. 113–120.
[15] Ben Caldwell, Michael Cooper, Loretta Guarino Reid, Gregg Vanderheiden, Wendy
Chisholm, John Slatin y Jason White. 2008. Directrices de accesibilidad al
contenido web (WCAG) 2.0.Consorcio WWW (W3C)(2008).
[16] Jim A. Carter y David W. Fourney. 2007. Técnicas para ayudar en el desarrollo de
ingenieros de accesibilidad. EnActas de la IX Conferencia Internacional ACM SIGACCESS
sobre Informática y accesibilidad. 123–130.
[17] Tsung-Hsiang Chang, Tom Yeh y Rob Miller. 2011. Asociación de la representación visual
de las interfaces de usuario con sus estructuras internas y metadatos.
EnActas del 24º Simposio Anual de ACM sobre Software y Tecnología de Interfaz de Usuario
(UIST '11). ACM, Nueva York, Nueva York, Estados Unidos.
[18] Comprobador de accesibilidad web. 2011. Comprobador de accesibilidad web de IDI:
Comprobador de accesibilidad web.En línea. Disponible: http://achecker.ca/checker/index. php.
[Último acceso: 28 10 2014](2011).
[19] Chunyang Chen, Sidong Feng, Zhengyang Liu, Zhenchang Xing y Shengdong Zhao. 2020. De
perdido a encontrado: descubra la semántica de diseño de interfaz de usuario faltante a través
de la recuperación de etiquetas faltantes.Actas de la ACM sobre interacción humano-
computadora CSCW (2020).
[20] Chunyang Chen, Sidong Feng, Zhenchang Xing, Linda Liu, Shengdong Zhao y Jinshui Wang. 2019.
Galería DC: Búsqueda de diseño y descubrimiento de conocimiento a través de la galería de
componentes GUI creada automáticamente.Actas de la ACM sobre interacción humano-
computadora3, CSCW (noviembre de 2019).
[21] Chunyang Chen, Ting Su, Guozhu Meng, Zhenchang Xing y Yang Liu. 2018. De la imagen de diseño de la
interfaz de usuario al esqueleto de la interfaz gráfica de usuario: un traductor automático neuronal a la
implementación de la interfaz gráfica de usuario móvil de Bootstrap. EnActas de la 40ª Conferencia
Internacional sobre Ingeniería de Software (ICSE '18). ACM, Nueva York, NY, EE. UU., 665–676.
[22] Jieshan Chen, Chunyang Chen, Zhenchang Xing, Xin Xia, Liming Zhu, John Grundy y Jinshui Wang.
2020. Búsqueda de diseño de interfaz de usuario basada en estructura alámbrica a través del
codificador automático de imágenes.ACM Trans. suave Ing. Método.29, 3, artículo 19 (junio
2020), 31 págs. https://doi.org/10.1145/3391613
[23] Jieshan Chen, Chunyang Chen, Zhenchang Xing, Xiwei Xu, Liming Zhu, Guoqiang Li y Jinshui Wang.
2020. Desenmascara tus aplicaciones: predicción de etiquetas en lenguaje natural para
componentes de GUI móviles mediante aprendizaje profundo.2020 IEEE/ACM 42.a Conferencia
internacional sobre ingeniería de software (ICSE)(2020).
[24] Jieshan Chen, Mulong Xie, Zhenchang Xing, Chunyang Chen, Xiwei Xu y Liming Zhu. 2020.
Detección de objetos para la interfaz gráfica de usuario: ¿aprendizaje antiguo o
profundo o una combinación?2020 IEEE/ACM 42.a Conferencia internacional sobre
ingeniería de software (ICSE)(2020).
[25] Sen Chen, Lingling Fan, Chunyang Chen, Minhui Xue, Yang Liu y Lihua Xu. 2019. Ataque
de GUI-Squatting: generación automatizada de aplicaciones de phishing de Android.
Transacciones IEEE en computación confiable y segura(2019).
[26] Sen Chen, Lingling Fan, Ting Su, Lei Ma, Yang Liu y Lihua Xu. 2019. Generación automatizada de
código GUI multiplataforma para aplicaciones móviles. En2019 IEEE 1er Taller Internacional
sobre Inteligencia Arti�cial para Móviles (AI4Mobile). IEEE, 13–16.
[27] Biplab Deka, Zifeng Huang, Chad Franzen, Joshua Hibschman, Daniel Afergan, Yang Li,
Jerey Nichols y Ranjitha Kumar. 2017. Rico: un conjunto de datos de aplicaciones
móviles para crear aplicaciones de diseño basadas en datos. EnActas del 30.º Simposio
anual de ACM sobre software y tecnología de interfaz de usuario.
[28] Biplab Deka, Zifeng Huang y Ranjitha Kumar. 2016. ERICA: Aplicaciones móviles de
minería de interacción. EnActas del 29º Simposio Anual sobre Software y Tecnología de
Interfaz de Usuario(Tokio, Japón)(UIST'16). Association for Computing Machinery, Nueva
York, NY, EE. UU., 767–776. https://doi.org/10.1145/2984511.2984581
[29] Nicola Dell, Vidya Vaidyanathan, Indrani Medhi, Edward Cutrell y William Thies. 2012. "¡El
tuyo es mejor!" Sesgo de respuesta del participante en HCI. EnActas de la Conferencia
SIGCHI sobre factores humanos en sistemas informáticos. 1321-1330.
[30] Morgan Dixon y James Fogarty. 2010. Prefab: Implementación de comportamientos avanzados
mediante ingeniería inversa basada en píxeles de la estructura de la interfaz. EnActas de la
Conferencia SIGCHI sobre factores humanos en sistemas informáticos(Atlanta, Georgia, EE. UU.)(
CHI '10). Asociación de Maquinaria de Computación, Nueva York, NY, EE. UU., 1525–1534. https://
doi.org/10.1145/1753326.1753554
[31] Morgan Dixon, James Fogarty y Jacob Wobbrock. 2012. Una mejora de apuntamiento
consciente de objetivos de uso general mediante el análisis de interfaces gráficas a
nivel de píxel. EnActas de la Conferencia SIGCHI sobre factores humanos en sistemas
informáticos(Austin, Texas, EE. UU.)(CH '12). Association for Computing Machinery,
Nueva York, NY, EE. UU., 3167–3176. https://doi.org/10.1145/2207676.2208734
[32] James R. Eagan, Michel Beaudouin-Lafon y Wendy E. Mackay. 2011. Cracking the Cocoa
Nut: programación de interfaz de usuario en tiempo de ejecución. EnActas del 24º
Simposio Anual de ACM sobre Software y Tecnología de Interfaz de Usuario (UIST '11).
ACM, Nueva York, NY, Estados Unidos.
[33] Mark Everingham, Luc Van Gool, Christopher KI Williams, John Winn y Andrew
Zisserman. 2010. El desafío de las clases de objetos visuales (voc) de Pascal.
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
Revista internacional de visión por computadora88, 2 (2010), 303–338.
[34] Juegos de MetalPop. 2020. Complemento de accesibilidad de la interfaz de usuario (UAP): Herramientas de interfaz gráfica
de usuario: Unity Asset Store. https://assetstore.unity.com/packages/tools/gui/ui-accessibility-pluginuap-87935
[35] Cole Gleason, Amy Pavel, Emma McCamey, Christina Low, Patrick Carrington, Kris M
Kitani y Je�rey P Bigham. 2020. Twitter A11y: una extensión del navegador para hacer
que las imágenes de Twitter sean accesibles. EnActas de la Conferencia CHI 2020 sobre
factores humanos en sistemas informáticos. 1–12.
[36] Google. 2020. Ayuda de accesibilidad de Android: Accesibilidad mediante interruptores.
https://support.google.com/accessibility/android/topic/6151780.
[37] Google. 2020. Construir más accesible aplicaciones
https://developer.android.com/guide/topics/ui/accessibility/.
[38] Google. 2020. Comience a usar Android con TalkBack - Ayuda de accesibilidad de
Android. https://support.google.com/accessibility/android/answer/6283677?hl=en
[39] Darren Guinness, Edward Cutrell y Meredith Ringel Morris. 2018. Rastreador de subtítulos:
habilitación de descripciones de texto alternativo reutilizables mediante la búsqueda inversa de
imágenes. EnActas de la Conferencia CHI 2018 sobre factores humanos en sistemas
informáticos. 1–11.
[40] Danna Gurari, Yinan Zhao, Meng Zhang y Nilavra Bhattacharya. 2020. Subtitulado
de imágenes tomadas por personas ciegas. (2020). arXiv:2002.08565
[41] Jaekyu Ha, Robert M Haralick e Ihsin T Phillips. 1995. Corte XY recursivo utilizando
cuadros delimitadores de componentes conectados. EnActas de la 3ra Conferencia
Internacional sobre Análisis y Reconocimiento de Documentos (ICDAR '95, Vol. 2). IEEE,
952–955.
[42] Vicki L Hanson y John T Richards. 2013. ¿Progreso en la accesibilidad del sitio web?
Transacciones de ACM en la Web (TWEB)7, 1 (2013), 1–30.
[43] K He, G Gkioxari, P Dollar y R Girshick. 2017. Máscara R-CNN. EnConferencia
internacional IEEE 2017 sobre visión por computadora (ICCV). 2980–2988.
[44] MD Zakir Hossain, Ferdous Sohel, Mohd Fairuz Shiratuddin y Hamid Laga. 2019. Una
encuesta exhaustiva de aprendizaje profundo para subtítulos de imágenes.Encuestas
de computación ACM (CSUR)51, 6 (2019), 1–36.
[45] Forrest Huang, John F Canny y Jerey Nichols. 2019. Swire: recuperación de la interfaz de usuario
basada en bocetos. EnActas de la Conferencia CHI 2019 sobre factores humanos en sistemas
informáticos. 1–10.
[46] Andrej Karpathy y Li Fei-Fei. 2015. Profundas alineaciones visual-semánticas para
generar descripciones de imágenes. EnActas de la conferencia IEEE sobre visión
artificial y reconocimiento de patrones. 3128–3137.
[47] Shachar Kaufman, Saharon Rosset, Claudia Perlich y Ori Stitelman. 2012. Fugas en
minería de datos: Formulación, detección y evitación.Transacciones de ACM sobre
descubrimiento de conocimiento a partir de datos (TKDD)6, 4 (2012), 1–21.
[48] Ranjitha Kumar, Jerry O Talton, Salman Ahmad y Scott R Klemmer. 2011. Bricolage:
retargeting basado en ejemplos para diseño web. EnActas de la Conferencia SIGCHI
sobre factores humanos en sistemas informáticos. 2197–2206.
[49] Toby Jia-Jun Li, Amos Azaria y Brad A. Myers. 2017. SUGILITE: Creando Automatización de
Smartphone Multimodal por Demostración. EnActas de la Conferencia CHI 2017 sobre
factores humanos en sistemas informáticos(Denver, Colorado, Estados Unidos)(CH '17).
Association for Computing Machinery, Nueva York, NY, EE. UU., 6038–6049. https://
doi.org/10.1145/3025453.3025483
[50] Thomas F. Liu, Mark Craft, Jason Situ, Ersin Yumer, Radomir Mech y Ranjitha Kumar.
2018. Aprendizaje de semántica de diseño para aplicaciones móviles. EnActas del 31.º
Simposio anual de ACM sobre software y tecnología de interfaz de usuario(Berlín,
Alemania)(UIST'18). Association for Computing Machinery, Nueva York, NY, EE. UU.,
569–579. https://doi.org/10.1145/3242587.3242650
[51] Wei Liu, Dragomir Anguelov, Dumitru Erhan, Christian Szegedy, Scott Reed, Cheng-Yang
Fu y Alexander C Berg. 2016. SSD: detector multibox de disparo único.
EnConferencia europea sobre visión artificial. Springer, 21–37.
[52] Atif Memon, Ishan Banerjee y Adithya Nagarajan. 2003. Extracción de GUI: ingeniería
inversa de interfaces gráficas de usuario para pruebas. EnActas de la 10.ª Conferencia
de trabajo sobre ingeniería inversa (WCRE '03). Citaseer, 260–269.
[53] Kevin Patrick Moran, Carlos Bernal-Cárdenas, Michael Curcio, Richard Bonett y Denys Poshyvanyk.
2018. Creación de prototipos basados en aprendizaje automático de interfaces gráficas de
usuario para aplicaciones móviles.Transacciones IEEE sobre ingeniería de software (2018).
[54] George Nagy y Sharad C. Seth. 1984. Representación jerárquica de documentos
escaneados ópticamente.Actas de la 7ª Conferencia Internacional sobre
Reconocimiento de Patrones(1984), 347–349. https://ci.nii.ac.jp/naid/10006753131/en/
[55] Alexander Neubeck y Luc Van Gool. 2006. Supresión no máxima eficiente. En18ª
Conferencia Internacional sobre Reconocimiento de Patrones (ICPR'06), vol. 3.IEEE, 850–
855.
[56] T. Nguyen, P. Vu, H. Pham y T. Nguyen. 2018. Patrones de diseño de interfaz de usuario de
aprendizaje profundo de aplicaciones móviles. En2018 IEEE/ACM 40.a Conferencia internacional
sobre ingeniería de software: nuevas ideas y resultados de tecnologías emergentes (ICSE-NIER).
65–68.
[57] Tuan Anh Nguyen y Christoph Csallner. 2015. Interfaces de usuario de aplicaciones
móviles de ingeniería inversa con REMAUI (T). EnConferencia internacional IEEE/ACM
sobre ingeniería de software automatizada (ASE '15). IEEE, 248–259.
[58] Dan R. Olsen, Scott E. Hudson, Thom Verratti, Jeremy M. Heiner y Matt Phelps. 1999.
Implementación de adjuntos de interfaz basados en representaciones de superficie. En
Zhang, de Greef, Swearngin, et al.
Actas de la Conferencia SIGCHI sobre factores humanos en sistemas informáticos (CHI '99).
ACM, Nueva York, Nueva York, Estados Unidos.
[59] Elaine Pearson, Christopher Bailey y Steve Green. 2011. Una herramienta para apoyar el proceso
de evaluación de accesibilidad web para principiantes. EnActas de la 16.ª conferencia conjunta
anual sobre innovación y tecnología en la enseñanza de las ciencias de la computación. 28–32.
[60] Pixelología. 2020. ColorCube. https://github.com/pixelogik/ColorCube
[61] Suporn Pongnumkul, Mira Dontcheva, Wilmot Li, Jue Wang, Lubomir Bourdev, Shai
Avidan y Michael F Cohen. 2011. Pausar y reproducir: vinculación automática de videos
tutoriales de screencast con aplicaciones. EnActas del 24º simposio anual de ACM sobre
software y tecnología de interfaz de usuario. 135–144.
[62] Christopher Power, André Freire, Helen Petrie y David Swallow. 2012. Las directrices son solo la
mitad de la historia: los problemas de accesibilidad que encuentran los usuarios ciegos en la
web. EnActas de la conferencia SIGCHI sobre factores humanos en sistemas informáticos. 433–
442.
[63] Joseph Redmon, Santosh Divvala, Ross Girshick y Ali Farhadi. 2016. Solo miras una vez:
Detección unificada de objetos en tiempo real. EnActas de la conferencia IEEE sobre
visión artificial y reconocimiento de patrones. 779–788.
[64] Shaoqing Ren, Kaiming He, Ross Girshick y Jian Sun. 2015. Faster r-cnn: Hacia la detección de
objetos en tiempo real con redes de propuestas regionales. EnAvances en los sistemas de
procesamiento de información neuronal. 91–99.
[65] Anne Spencer Ross, Xiaoyi Zhang, James Fogarty y Jacob O. Wobbrock. 2017. La
epidemiología como marco para la evaluación de la accesibilidad de aplicaciones
móviles a gran escala. EnActas del XIX Congreso Internacional ACM SIGAC-CESS
sobre Informática y Accesibilidad(Baltimore, Maryland, Estados Unidos)
(ACTIVOS '17). Association for Computing Machinery, Nueva York, NY, EE. UU., 2–
11. https://doi.org/10.1145/3132525.3132547
[66] Anne Spencer Ross, Xiaoyi Zhang, James Fogarty y Jacob O. Wobbrock. 2018. Examen del
etiquetado de botones basado en imágenes para la accesibilidad en aplicaciones de
Android a través de análisis a gran escala. EnActas de la 20ª Conferencia Internacional
ACM SIGACCESS sobre Informática y Accesibilidad(Galway, Irlanda)(CONJUNTOS DE
ACTIVOS '18). Association for Computing Machinery, Nueva York, NY, EE. UU., 119–130.
https://doi.org/10.1145/3234695.3236364
[67] Anne Spencer Ross, Xiaoyi Zhang, James Fogarty y Jacob O. Wobbrock. 2020. Un análisis a gran
escala inspirado en la epidemiología de la accesibilidad de las aplicaciones de Android. ACM
Trans. Acceso. computar13, 1, artículo 4 (abril de 2020), 36 páginas. https://doi. org/
10.1145/3348797
[68] Santiago. 2018. Matriz de confusión en la detección de objetos con Tensor-Flow.
https://towardsdatascience.com/confusion-matrix-in-object-detectionwith-
tensor�ow-b9640a927285
[69] Richard S. Schwerdtfeger. 1991. ftp:// Haciendo que la GUI hable.
service.boulder.ibm.com/sns/sr-os2/sr2doc/guitalk.txt.
[70] Amanda Swearngin, Mira Dontcheva, Wilmot Li, Joel Brandt, Morgan Dixon y Amy J. Ko.
2018. Rewire: asistencia en el diseño de interfaz a partir de ejemplos. En Actas de la
Conferencia SIGCHI sobre factores humanos en sistemas informáticos (CHI '18). ACM,
Nueva York, NY, EE. UU., 504:1–504:12.
[71] Amanda Swearngin y Yang Li. 2019. Modelado de la capacidad de toque de la interfaz
móvil mediante colaboración abierta y aprendizaje profundo. EnActas de la Conferencia
CHI 2019 sobre factores humanos en sistemas informáticos(Glasgow, Escocia Reino
Unido) (CHI '19). Association for Computing Machinery, Nueva York, NY, EE. UU., 1–11.
https://doi.org/10.1145/3290605.3300305
[72] Hironobu Takagi, Shinya Kawanaka, Masatomo Kobayashi, Takashi Itoh y Chieko
Asakawa. 2008. Accesibilidad social: lograr la accesibilidad a través de la
creación colaborativa de metadatos. EnActas de la 10ª conferencia internacional
ACM SIGACCESS sobre Informática y accesibilidad.
[73] Tecnología de Alibaba. 2019. UI2code: Cómo ajustar el análisis de fondo y primer plano.
https://medium.com/hackernoon/ui2code-how-to-�ne-tune-backgroundand-
foreground-analysis-fb269edcd12c
[74] Shari Trewin, Diogo Marques y Tiago Guerreiro. 2015. Uso de escalas subjetivas en la
investigación sobre accesibilidad(ACTIVOS '15). Association for Computing Machinery,
Nueva York, NY, EE. UU., 59–67. https://doi.org/10.1145/2700648.2809867
[75] Thomas D White, Gordon Fraser y Guy J Brown. 2019. Mejora de las pruebas de GUI
aleatorias con detección de widgets basada en imágenes. EnActas del 28º Simposio
Internacional ACM SIGSOFT sobre Pruebas y Análisis de Software. 307–317.
[76] Shengqu Xi, Shao Yang, Xusheng Xiao, Yuan Yao, Yayuan Xiong, Fengyuan Xu, Haoyu
Wang, Peng Gao, Zhuotao Liu, Feng Xu y Jian Lu. 2019. DeepIntent: Aprendizaje
profundo de comportamiento de íconos para detectar discrepancias de
comportamiento e intención en aplicaciones móviles. EnActas de la Conferencia ACM
SIGSAC 2019 sobre seguridad informática y de las comunicaciones(Londres, Reino
Unido)(CCS '19). Association for Computing Machinery, Nueva York, NY, EE. UU., 2421–
2436. https://doi.org/10. 1145/3319535.3363193
[77] Xusheng Xiao, Xiaoyin Wang, Zhihao Cao, Hanlin Wang y Peng Gao. 2019. Iconintent:
identi�cación automática de widgets de interfaz de usuario confidenciales basados en la
clasificación de iconos para aplicaciones de Android. En2019 IEEE/ACM 41.ª Conferencia
internacional sobre ingeniería de software (ICSE). IEEE, 257–268.
[78] Tom Yeh, Tsung-Hsiang Chang y Robert C. Miller. 2009. Sikuli: uso de capturas de
pantalla de GUI para búsqueda y automatización. EnActas del 22.º Simposio anual de
ACM sobre software y tecnología de interfaz de usuario(Victoria, BC, Canadá)
Reconocimiento de pantalla: creación de metadatos de accesibilidad para aplicaciones móviles a partir de píxeles
(UIT '09). Association for Computing Machinery, Nueva York, NY, EE. UU., 183–192.
https://doi.org/10.1145/1622176.1622213
[79] Luke S. Zettlemoyer y Robert St. Amant. 1999. Un medio visual para el control
programático de aplicaciones interactivas. EnActas de la Conferencia SIGCHI sobre
factores humanos en sistemas informáticos (CHI '99). ACM, Nueva York, Nueva York, EE.
UU., 199–206.
[80] Xiaoyi Zhang, Anne Spencer Ross, Anat Caspi, James Fogarty y Jacob O Wobbrock. 2017.
Proxies de interacción para la reparación y mejora del tiempo de ejecución de
CHI '21, del 8 al 13 de mayo de 2021, Yokohama, Japón
accesibilidad de aplicaciones móviles. EnActas de la conferencia CHI 2017 sobre
factores humanos en sistemas informáticos. 6024–6037.
[81] Xiaoyi Zhang, Anne Spencer Ross y James Fogarty. 2018. Anotación robusta de
interfaces de aplicaciones móviles en métodos para reparar y mejorar la
accesibilidad. EnActas del 31.º Simposio anual de ACM sobre software y
tecnología de interfaz de usuario. 609–621.