Verificación de que las páginas web tengan un diseño accesible
Pavel Panchekha Adam T. Geller Michael D. Ernst Zachary Tatlock
pavpan@cs.uw.edu atgeller@uw.edu mernst@cs.uw.edu ztatlock@cs.uw.edu
Escuela de Ingeniería y Ciencias de la Computación Paul G. Allen
Universidad de Washington, Seattle, WA, EE. UU.
Resumen
Las pautas de usabilidad y accesibilidad tienen como objetivo hacer que las interfaces gráficas
de usuario sean accesibles para todos los usuarios, por ejemplo, requiriendo que el texto sea lo
suficientemente grande, que los controles interactivos sean visibles y que el tamaño del
encabezado corresponda a la importancia. Estas pautas deben mantener la infinita cantidad de
representaciones posibles de una página web generada por diferentes tamaños de pantalla,
fuentes y otras preferencias del usuario. Hoy en día, estas pautas se prueban mediante la
inspección manual de algunas representaciones, porque 1) las pautas no están expresadas en
un lenguaje formal, 2) la semántica de la representación del navegador no se comprende bien y
3) no existen herramientas para verificar todas las posibles representaciones de una página
web. VizAssert resuelve estos problemas. Primero, presenta lógica visual
para especificar con precisión las propiedades de accesibilidad. En segundo lugar, formaliza un
gran fragmento de la algoritmo de renderizado del navegador
usando novela reducciones de finitización. En tercer lugar, proporciona una sonido, herramienta
automatizada para verificar afirmaciones en lógica visual.
Codificamos 14 afirmaciones extraídas de las mejores prácticas de
accesibilidad y pautas de usabilidad móvil en lógica visual. VizAssert los verificó
en 62 páginas web diseñadas profesionalmente. Encontró 64 errores distintos en
las páginas web, mientras que reportó solo 13 advertencias falsas positivas.
CCSConceptos · Software y su ingeniería → Idiomas gráficos de la interfaz de usuario;
Herramientas de mantenimiento de software;
Palabras clave accesibilidad, usabilidad, verificación, SMT, diseño, CSS, semántica
Formato de referencia de ACM:
Pavel Panchekha, Adam T. Geller, Michael D. Ernst, Zachary Tatlock y Shoaib Kamil.
2018. Verificación de que las páginas web tengan un diseño accesible. En Actas de la
39ª Conferencia ACM SIGPLAN sobre diseño e implementación de lenguajes de
programación (PLDI'18).
ACM, NuevaYork, NY, EE. UU., 19 páginas. https://doi.org/10.1145/3192366. 3192407
El permiso para hacer copias digitales o impresas de todo o parte de este trabajo para uso personal
o en el aula se otorga sin cargo siempre que las copias no se realicen o distribuyan con fines de
lucro o ventaja comercial y que las copias lleven este aviso y la cita completa en la primera página. .
Se deben respetar los derechos de autor de los componentes de este trabajo que son propiedad de
terceros distintos del autor. Se permite resumir con crédito. Copiar de otra manera, o volver a
publicar, publicar en servidores o redistribuir a listas, requiere un permiso específico previo y / o una
tarifa. Solicite permisos a permissions@acm.org.
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.
© 2018 Copyright del propietario / autor (es). Derechos de publicación autorizados a la Asociación de
Maquinaria de Computación.
ACM ISBN 978-1-4503-5698-5 / 18/06. . . $ 15.00
https://doi.org/10.1145/3192366.3192407
1
Shoaib Kamil
kamil@adobe.com
Laboratorio de inteligencia creativa
Adobe Research, Nueva York, EE. UU.
1. Introducción
La accesibilidad a la página web es imperativa por razones morales y legales. Hay más
de 7,4 millones de adultos con discapacidad visual solo en EE. UU. [ 35 ]. Otros usuarios
tienen discapacidades sensoriomotoras que restringen el uso de dispositivos de
entrada. Estas personas deberían tener la oportunidad de usar las páginas web como
lo hacen otras personas, pero las páginas web inaccesibles las bloquean. Los
diseñadores de GUI se esfuerzan por hacer que sus páginas sean accesibles siguiendo
pautas, como las del Departamento de Justicia [ 50 ] o las Pautas de accesibilidad al
contenido web del W3C [ 53 ]. Para algunas aplicaciones, el cumplimiento de estas
pautas es obligatorio por la Directiva europea de accesibilidad web y móvil [ dieciséis ], la
Ley de Estadounidenses con Discapacidades [ 49 ], o la Ley Básica de Tecnología de la
Información de Japón [ 15 ]; otros países también tienen tales estándares. En 2017, se
entablaron al menos 814 demandas contra propietarios de sitios web por páginas web
inaccesibles [ 52 ].
Las pautas de usabilidad son similares: desde una perspectiva de accesibilidad, un desarrollador
puede querer asegurarse de que los botones sean lo suficientemente grandes para usuarios con
discapacidades sensoriomotoras, mientras que desde una perspectiva de usabilidad, un desarrollador
puede querer asegurarse de que los botones sean lo suficientemente grandes para los usuarios de
un dispositivo móvil.
Las pautas de accesibilidad y usabilidad deben cumplirse en todas las infinitas
combinaciones de parámetros de representación como el tamaño de la pantalla, los
tamaños de fuente predeterminados y las preferencias del usuario. Actualmente, los
desarrolladores prueban el cumplimiento de estas pautas ejecutando la aplicación con
algunos parámetros elegidos y buscando visualmente violaciones de las restricciones de
diseño, o utilizan motores de comparación automatizados píxel por píxel como Selenium,
Sikuli y Raven [ 9 , 13 , 17 ]. Estas técnicas solo consideran un subconjunto particular de
parámetros de representación y no son suficientes para garantizar que las aplicaciones
sean accesibles [ 24 , 29 , 43 , 46 ]. Para verificar la accesibilidad es necesario verificar
todas las combinaciones posibles de parámetros de renderizado.
Presentamos VizAssert, una herramienta para verificar que una afirmación sobre
el diseño visual sea válida para las páginas web. Las páginas web son un tipo ubicuo
de interfaz de usuario para aplicaciones modernas. VizAssert toma como entrada una
página web y una afirmación en un lógica visual, por ejemplo, un tamaño de fuente
mínimo o la visibilidad y el contraste de los widgets. VizAssert certifica firmemente
que la aserción se cumple para todos los parámetros de representación en un
conjunto acotado elegido por el usuario, o proporciona un contraejemplo por el cual
se viola la aserción.
VizAssert razones sobre el diseño de la página web utilizando una formalización del
algoritmo de representación del navegador especificado por el
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU. P. Panchekha, AT Geller, MD Ernst, Z. Tatlock y S. Kamil

Estándar W3C CSS 2.1 [ 54 ]. El estándar CSS describe varias características clave en
Accesibilidad Lógica visual
términos de operaciones en conjuntos de tamaño arbitrario, que son difíciles de Directrices Afirmación fi nitización

§3 HTML + CSS reducción QFLRA

razonar para un solucionador SMT. Esto impidió que los intentos anteriores de Mesa 1
Afirmación (SMT)
§4
formalizar varios aspectos ubicuos de CSS, entre ellos el cálculo de la altura de la Web
Páginas
línea, el colapso de los márgenes y el diseño flotante [ 39 ]. Nuestro trabajo introduce §2 VizAssert
reducciones de sonido novedosas ( reducciones de finitización)

desde los conjuntos de tamaño arbitrario discutidos por el estándar hasta una
representación compacta de tamaño finito que es más susceptible al razonamiento
mecánico. Al reducir los conjuntos de tamaño arbitrario a análogos finitos, VizAssert
codifica su formalización de la representación del navegador en una consulta SMT que se
puede resolver de manera eficiente y utiliza Z3 [ 14 ] para buscar automáticamente
contraejemplos de una afirmación o para certificar que no existen contraejemplos.
Figura 1. VizAssert garantiza que las páginas web cumplan con las pautas de
accesibilidad. VizAssert transforma esas afirmaciones, expresadas en lógica
visual, en propiedades de la fuente HTML y CSS de la página web, luego
codifica esas propiedades en fórmulas en la teoría libre de cuantificadores de
aritmética real lineal.

Tabla 1. Pautas de accesibilidad y usabilidad de mejores prácticas que

1.1 Entrada y salida de VizAssert
formalizamos en lógica visual y evaluamos en páginas web diseñadas
Los desarrolladores web desean asegurarse de que sus páginas web cumplan con las
profesionalmente (Sección 5 ). Apéndice segundo formaliza cada directriz.
pautas de alto nivel en inglés. Los desarrolladores están ansiosos por solucionar los
problemas de accesibilidad, pero descubrirlos es demasiado difícil [ 29 , 46 ]. El
desarrollador proporciona a VizAssert una página web y una guía, expresada como una # Descripción Fuente
afirmación formal en lógica visual. Afirmaciones generales, aplicables a muchas páginas web
1 El texto es al menos 14px alto [ 53 ]
Figura 1 muestra cómo funciona VizAssert. Usando su formalización del algoritmo de 2 Se puede cambiar el tamaño del texto hasta en un 200% Las [ 53 ]
representación del navegador, VizAssert construye un problema de búsqueda equivalente 3 líneas no tienen más de 80 caracteres [ 53 ]

a la verdad de esa afirmación. Una respuesta al problema de búsqueda es un conjunto de 4 Los elementos para los usuarios de lectores de pantalla están fuera de la pantalla [ 34 , 41 ]

parámetros de representación (es decir, un conjunto de preferencias del navegador) de

5 La página no requiere desplazamiento horizontal [ 8 ] Los títulos forman
6 una jerarquía visual [ 38 ]
modo que la representación viola la aserción. VizAssert codifica este problema de
7 El texto no se superpone [2]
búsqueda en una fórmula en la teoría libre de cuantificadores de aritmética real lineal
8 Las líneas están debidamente espaciadas [7]
(QFLRA) e invoca un solucionador SMT para decidir el problema de búsqueda.
Afirmaciones específicas, aplicables a una sola página web
9 El texto tiene suficiente contraste [ 1 , 53 ]
10 El texto no se superpone a la imagen [ 1 , 53 ]
VizAssert genera "verificado" si no se pueden encontrar parámetros de 11 Los menús desplegables están ocultos cuando no se seleccionan [ 56 ] Las columnas están
representación que causen una violación de la aserción. La afirmación es válida para 12 alineadas verticalmente [7]
todos los parámetros de representación considerados. VizAssert genera "violado" si el 13 El texto completo del enlace es visible [2]
problema de búsqueda tiene solución. VizAssert también genera un contraejemplo que 14 El botón principal es lo suficientemente grande [ 48 ]
identifica un conjunto de casillas en la página y valores para los parámetros de
representación (tamaño de la ventana, tamaño de fuente) para los que se viola la
opciones necesarias para convertir las pautas informales y las mejores prácticas en
aserción. El desarrollador puede examinar el contraejemplo en un navegador para
afirmaciones formales. 6 de las afirmaciones son específicas de la página, lo que demuestra
confirmar el error y luego modificar la página para corregirlo.
que los usuarios pueden escribir afirmaciones personalizadas para verificar las propiedades

específicas del dominio de sus páginas web. En total, hay 502 combinaciones de página web

y afirmación. De estos, VizAssert encontró 64 violaciones de afirmaciones y emitió 13

Los errores que detecta VizAssert no son fallas ni excepciones. La falta de notificaciones hace
advertencias de falsos positivos.
que los desarrolladores sean más propensos a pasar por alto las fallas de accesibilidad. Esto hace

que las herramientas de verificación como VizAssert sean especialmente valiosas.

1.3 Contribuciones

1.2 Estudios de caso En resumen, las contribuciones de este trabajo son:

Este documento considera 14 pautas de accesibilidad y mejores prácticas (Tabla 1 ).
Todos representan preocupaciones reales para los diseñadores, pero el conjunto
particular es menos importante que el hecho de que VizAssert es general y extensible.
Formalizamos cada pauta de accesibilidad en lógica visual y las
verificamos en una colección de 62 páginas web diseñadas
profesionalmente. Sección 3 analiza las adaptaciones y
• Lógica visual, un lenguaje para expresar propiedades de diseño visual
(Sección 3 ), incluidas las 14 pautas de accesibilidad y usabilidad de la
Tabla 1 .
• Una formalización eficiente de muchos componentes cruciales del algoritmo
de renderizado del navegador. Por razones de espacio, este documento
destaca tres de ellos: altura de línea (Sección 4.1 ), colapso de márgenes
(sección 4.2 ), y flotando

2
Verificación de que las páginas web tengan un diseño accesible PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.

diseño (Sección 4.3 ) Ðque utilizan una táctica de implementación clave

Estilos cascada Selectores
(reducciones de finitización).
• Una implementación de código abierto, VizAssert ( https: //
Tipos de caja Modo de diseño Vertical Despeje
cassius.uwplse.org/ ), que verifica automáticamente una aserción visual
para una página web, o produce una configuración de usuario
Fluir Flotante
contraejemplo para la cual se viola la aserción. Horizontal Altura
Anchura Diseño
§ 4.3
En Cassius
• Una evaluación de VizAssert en 62 páginas web diseñadas
Línea Margen
Reducir para ajustar
profesionalmente, identificando 64 errores con solo 13 falsos positivos Altura Colapso

(Sección 5 ). § 4.1 § 4.2

2. Fondo Figura 2. Los principales subsistemas de la formalización del diseño de páginas web de
VizAssert. Cada componente se describe brevemente en la Sección 2 . Muchos detalles,
Esta sección describe el algoritmo de renderizado del navegador W3C [ 54 ], que
como el manejo de color de VizAssert, las consultas de medios y los límites de ancho y
convierte HTML y CSS en un árbol de cuadros anotados con colores, tamaños y
alto, están ocultos en esta imagen, que muestra solo los componentes de más alto nivel.
posiciones. La formalización de VizAssert de un subconjunto de este algoritmo
Los componentes fuera del área sombreada se formalizan nuevamente en este trabajo.
de renderizado se basa y amplía significativamente el de Cassius [ 39 ]. Las
extensiones más destacadas se describen en la Sección 4 .

HTML HTML define elementos y texto. Cada elemento tiene un nombre de

etiqueta, y el texto se coloca dentro y entre elementos. Por ejemplo, el siguiente
HTML representa 4 elementos (con etiquetas html, cuerpo, b, y botón) y cuatro
fragmentos de texto: • En cascada determina qué valor de la regla se utilizará cuando se apliquen
varias reglas a un elemento.
<html> <body> Este es texto <b> formateado </b> y un
<button>button</button></body> </html> • Estilos se calculan para cada elemento, resolviendo referencias y valores
relativos en los valores CSS especificados.
Algunos elementos HTML, como el botón elemento, son interpretados especialmente por el
• Tipos de caja se determinan para cada casilla utilizando el valor calculado de la monitor
navegador y representados con métodos específicos del navegador o del sistema operativo. La
propiedad.
mayoría de los demás elementos no tienen un comportamiento especial: los navegadores
• Modos de diseño se seleccionan para cada casilla utilizando los valores
proporcionan un archivo CSS predeterminado para garantizar que, por ejemplo, el texto dentro de un segundo-
calculados de la mostrar, flotar, y posición propiedades, más el tipo de caja.
El elemento etiquetado está en negrita. Es este archivo CSS predeterminado, no algo intrínseco al segundo

etiqueta, que hace que el texto se muestre en negrita.

• Horizontal los anchos y las posiciones se calculan para las cajas. Este cálculo
es diferente para diferentes modos de diseño.
CSS Un archivo CSS define una secuencia de reglas. Cada regla selecciona • Anchos de flujo se utilizan para la mayoría de las cajas, calculadas a partir de su

ciertos elementos y luego establece los valores de varios propiedades anchura valor y el ancho de su caja contenedor.
en esos elementos. El siguiente archivo CSS contiene dos reglas: • Reducir para ajustar los anchos se utilizan en su lugar para cajas cuyo

anchura el valor es auto y que utilizan determinados modos de diseño.

cuerpo {margen: .5em; }
b {font-weight: bold; } • Vertical las posiciones se calculan para las cajas basándose en las posiciones de las cajas

anteriores y, en algunos casos, las posiciones de los flotadores.

La primera regla selecciona elementos con la cuerpo etiqueta y establece su margen propiedad.
La segunda regla selecciona elementos con la segundo etiqueta y establece su peso de la
• Alturas se calculan para la mayoría de las cajas en función de las posiciones y
fuente propiedad. CSS también permite seleccionar elementos por su relación con otros
tamaños de su contenido.
elementos o por atributos adjuntos a esos elementos. Si dos reglas aplicables entran en
• Alturas de línea, para líneas de texto, se calculan por separado, utilizando información
conflicto, se utiliza la regla con el selector más específico.
sobre el tamaño de las fuentes y los detalles del diseño del texto descritos en la
Sección 4.1 .

Representación El navegador combina HTML y CSS para producir una representación: una árbol • Márgenes a veces colapso, permitiendo que los márgenes verticales adyacentes de las cajas

de caja que contiene todos los elementos visuales de la página. El navegador utiliza el parámetros se superpongan, siguiendo las reglas discutidas en la Sección 4.2 .

de representación,

incluyendo la altura y el ancho de la ventana del navegador y el tamaño de fuente • Despeje se determina para elementos cuya claro la propiedad está establecida.
preferido del usuario, como entradas para este proceso de renderizado. Numerosos El espacio libre mueve esos elementos para que no tengan una caja flotante
subsistemas del navegador interactúan para representar HTML y CSS (Figura 2 ): junto a ellos.
• Diseño flotante permite que los elementos se muevan a la derecha o la

• Selectores se hacen coincidir con los elementos para encontrar los valores especificados para
izquierda de su padre y que el texto los envuelva Sección 4.3 describe este

cada propiedad CSS para cada elemento.

subsistema.

3
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.
• afirmación • :: = ∀ segundo 1,. . . ∈ B: • cond •
• cond • :: = • cond • ∧ • cond • | ¬ • cond • | • cond • ∨ • cond •
| • real • = • real • | • real • <• real • | • real •> • real •
| • caja • = • caja • | • caja •. tipo = • tipo • | • caja •. espacio en blanco
• real • :: = R | • real • + • real • | • real • - • real • | R × • real •
| • caja •.• dir • | • color •. r | • color •. g | • color •. segundo
• color • :: = transparente | rgb • real •, • real •, • real •)
| • caja •. fg | • caja •. bg | γ ( • caja •. fg) | γ ( • caja •. bg)
• caja • :: = segundo yo | raíz | nulo | • caja •. antepasado( • cond * •)
| • caja •. padre | • caja •. primer hijo | • caja •. último niño
| • caja •. siguiente | • caja •. anterior
• tipo • :: = ventana | en línea | línea | texto | bloquear
• dir • :: = arriba | derecha | abajo | izquierda
Figura 3. Lógica visual, un lenguaje para describir formalmente propiedades de diseño visual. Todos
los cuantificadores están por encima del conjunto segundo de cajas en un renderizado.
Una vez que se conoce el tamaño y la posición de cada cuadro (así como los
colores y otras propiedades diversas), la página web se puede dibujar en la
pantalla.
3 Lógica visual
La lógica visual expresa aseveraciones de accesibilidad y usabilidad en términos
formales e inequívocos. Esta es la entrada a VizAssert.
3.1 Lógica visual básica
La lógica visual expresa las propiedades de un diseño visual. La lógica visual
permite fórmulas cuantificadas en un lenguaje de expresión simple con valores
condicionales, números reales, cuadros y colores (Figura 3 ). Estas fórmulas
describen las propiedades de un árbol de cajas rectangulares.
La mayoría de las construcciones de lógica visual son sencillas (y se describen con más
detalle en el Apéndice UNA ). Algunas construcciones específicas de dominio incluyen:
• Las afirmaciones se cuantifican universalmente en casillas ł segundo yo ž.
• ł • caja •. tipo = • tipo • ž marca el tipo de caja, que
define el tipo de contenido que contiene la caja.
• ł • caja •. espacio en blanco § determina si un cuadro de texto contiene solo
espacios en blanco o también contiene otro texto.
• El l • caja •.• dir • ž constructo expresa la posición de los bordes de la caja (y
por lo tanto la posición y el tamaño de la caja).
• los γ La función corrige los colores RGB.
• Los hermanos, hijos y padres de una caja son accesibles
a través de su anterior, siguiente, padre, primer hijo, y último-
niño campos, que pueden tener un nulo valor.
La lógica visual toma varias decisiones de diseño para permitir un razonamiento
eficiente con un solucionador SMT. No encontramos ninguno
4
P. Panchekha, AT Geller, MD Ernst, Z. Tatlock y S. Kamil
afirmaciones que no pudimos formalizar debido a estas limitaciones. (1) Dado que los
solucionadores SMT solo pueden razonar de manera eficiente lineal aritmética real, las
multiplicaciones deben involucrar una constante. (2) La lógica visual permite solo consultas
cuantificadas universalmente, ya que corresponden a consultas sin cuantificadores para el
solucionador SMT. (3) Los solucionadores de SMT no pueden razonar sobre propiedades
recursivas, por lo que la lógica visual proporciona la antepasado función, que representa el
antepasado más cercano de una caja que satisface una expresión condicional en una
variable (escrito ł? ž). Si ningún antepasado satisface el antepasado condición, la casilla
nula se
convertido. Por ejemplo, ł segundo. ancestro (?. bg, transparente) .bg ž
se refiere al color de fondo del antepasado más cercano de segundo
cuyo fondo no es transparente. Formalmente,
nulo.ancestro C) = nulo
segundo. antepasado( C) = segundo Si C[?/ segundo] más segundo. padre.ancestro C)
Evaluar una afirmación de lógica visual en una representación concreta de una
GUI es sencillo. Buscar en el conjunto infinito de todas las representaciones
posibles un contraejemplo de la aserción es más desafiante (ver Sección 4 ).
3.2 Lógica visual para la Web
La lógica visual formaliza las propiedades de los diseños visuales para cualquier
plataforma que estructura interfaces gráficas como un árbol, como HTML y CSS, Swing
[ 19 ], Cacao [ 3 ] o Android [ 42 ]. Adaptar la lógica visual a una de estas plataformas
implica agregar construcciones específicas de la plataforma a la lógica visual. Dado
que este documento se centra en la accesibilidad de las páginas web, se especializa
en la lógica visual para la plataforma web agregando soporte para selectores y el
modelo de caja CSS.
Selectores La lógica visual para la web contiene una expresión condicional para
determinar si un cuadro es generado por un elemento que coincide con un selector
de CSS dado [ 54 ]:
• cond • :: = · · · | • caja • ∈ $ (• selector •)
Por ejemplo, ł segundo ∈ $ ( h1, h2) ž se evalúa como verdadero si segundo es la casilla de un
título de primer o segundo nivel. Las adaptaciones de la lógica visual a otras plataformas
podrían agregar conceptos análogos, como el acceso a los nombres de los componentes de
Swing, Cocoa viewID s, o
android: id s en Android.
Modelo de caja La lógica visual para la web admite referencias a la posición del
contenido, el relleno, el borde y los bordes de los márgenes de un cuadro, con el borde
del borde como predeterminado.
• real • :: = · · · | • caja •.• dir • [• borde •]
• borde • :: = margen | frontera | acolchado | contenido
Por ejemplo, la expresión condicional ł segundo 1. superior [margen] =
segundo 2. margen superior] ž se evalúa como verdadero si segundo 1 y segundo 2 Los bordes de los
márgenes están alineados en la parte superior.
Verificación de que las páginas web tengan un diseño accesible
3.3 Formalización de afirmaciones
Se deben superar dos grandes desafíos para traducir las pautas informales en
inglés a afirmaciones en lógica visual: identificar con precisión los elementos de
la página discutidos por la guía y traducir conceptos de diseño de alto nivel en
propiedades visuales concretas. Para ilustrar cada uno, usamos una afirmación
representativa de la lista en la Tabla 1 . Apéndice segundo presenta las
formalizaciones de las 14 afirmaciones.
Identificación de elementos relevantes Usuarios que son parcial o
Totalmente ciego a menudo navega por la web utilizando un lector de pantalla. El contenido
destinado exclusivamente a dichos usuarios a menudo se coloca fuera de la pantalla, donde los
usuarios videntes no lo verán. La afirmación # 4, "los elementos para los usuarios de lectores de
pantalla están fuera de la pantalla" requiere que estos elementos permanezcan fuera de la pantalla.
∀ segundo ∈ B: for_screenreader ( b) = ⇒ ¬ en la pantalla( segundo)
La pantalla está representada por el cuadro raíz:
en la pantalla( b): = b. Correcto ≥ root.left ∧ segundo. fondo ≥ root.top
La mayoría (38) de las 62 páginas de evaluación incluían botones para compartir en redes
sociales 1 implementado configurando esos botones '
imagen de fondo propiedad a los logotipos de esas redes sociales. Dado que las imágenes
de fondo no son accesibles para los usuarios ciegos, estas páginas también incluían texto
para nombrar el servicio, pero colocaban este texto fuera de la pantalla.
for_screenreader ( b): =
segundo. tipo = texto ∧ es_descendiente ( b, #S)
dónde S nombra un servicio social. los is_descendant La función es una variante de antepasado: muchos avances para respaldar páginas web realistas (consulte la Sección 7.1 ). Esta
es_descendiente ( b, S): = b. antepasado(? ∈ $ ( S)), nulo
Concretar conceptos de diseño Los diseñadores web utilizan visual
detalles, como el tamaño o el espaciado, para sugerir a los usuarios videntes qué contenido de
la página es más o menos importante. Los usuarios que navegan por la web con un lector de
pantalla en su lugar leen las etiquetas de encabezado jerárquico h1 ś h6, donde números más
pequeños describen contenido más importante. Sin embargo, los desarrolladores de páginas
web pueden cambiar la apariencia de estas etiquetas, haciendo que los usuarios de lectores de
pantalla y los usuarios videntes perciban una jerarquía diferente de importancia en el contenido
de la página. La afirmación # 6, “Los títulos deben formar una jerarquía visual”, verifica que no
ocurra tal uso indebido.
∀ segundo 1, segundo 2 ∈ B: in_header ( segundo 1) in_header
∧ ( segundo 2) ∧
header_level ( segundo 1) < header_level ( segundo 2) = ⇒
importancia_visual ( segundo 1)> importancia_visual ( segundo 2)
1 Los botones de Twitter, Facebook, YouTube, Vimeo, Flickr, LinkedIn, Pinterest, Google+ y RSS estaban
presentes en nuestro conjunto de evaluación.
5
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.
½ líder
fg fg
Línea
altura
Ascenso Base
Descendencia
½ líder
Figura 4. La altura de la línea se calcula alineando todo el texto de la línea con una línea
de base común y encontrando los ascensos máximos por encima y por debajo de la línea
de base, incluido el espacio en blanco por encima y por debajo del texto llamado inicial.
Usamos la altura del texto para establecer la importancia visual en el
páginas de evaluación: importancia_visual ( b): = b. altura. Seleccione-
Los encabezados se hacen usando es_descendiente:
in_header ( b): = b. tipo = texto ∧ ¬ segundo. espacio en blanco ∧
( es_descendiente ( segundo, h1) ∨ descendiente( segundo, h2) ∨ · · ·)
Una vez que se selecciona un encabezado, su nivel se puede calcular a partir de su nombre de
etiqueta: 2
header_level ( b): = Si es_descendiente ( segundo, h1) entonces 1 más . .
Aunque identificar elementos relevantes y concretar conceptos de diseño
puede ser un desafío en algunos casos (ver Apéndice segundo ), la lógica visual
proporciona un lenguaje expresivo para formalizar las pautas de accesibilidad y
usabilidad.
4 Formalización de la representación del navegador
VizAssert utiliza una formalización del algoritmo de representación del navegador W3C
para determinar todas las representaciones posibles de una página web, dado su código
fuente (CSS y HTML). Esta formalización se basa en trabajos anteriores y contiene
sección describe un aspecto central de estos avances: una nueva aplicación de reducciones
de finitización. Una reducción de finitización reduce el razonamiento sobre un conjunto
de tamaño arbitrario a un razonamiento equivalente sobre una estructura de datos finita.
VizAssert utiliza reducciones de finitización para formalizar el cálculo de la altura de la
línea, el colapso de márgenes y el diseño flotante.
4.1 Alturas de línea
En el texto en inglés, las letras están alineadas verticalmente a base.
En la web, una línea de texto puede mezclar texto de diferentes fuentes y tamaños, y
también imágenes y bloque en línea cajas. Los diseñadores web también pueden
controlar el tamaño del espacio entre líneas sucesivas de texto con el altura de la línea Propiedad
CSS. 3
El estándar CSS requiere que el algoritmo de renderizado del navegador
minimice la altura de la línea mientras alinea todos
2 La lógica visual se expande Si declaraciones y otras abreviaturas estándar de los operadores primitivos
de Figure 3 ; ver el Apéndice UNA .
3 A pesar de su nombre, el altura de la línea la propiedad no establece directamente la altura del cuadro de línea; en
cambio, establece el liderazgo. Cuando una línea contiene imágenes,
bloque en línea cajas o cajas en línea con un diferente altura de la línea, Puede tener una altura de línea
diferente a su altura de la línea.
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU. P. Panchekha, AT Geller, MD Ernst, Z. Tatlock y S. Kamil

texto e imágenes en esa línea a una línea de base común y dejando un espacio en
blanco, llamado líder, arriba y abajo del texto (Figura 4 ). 4 La descripción anterior de la
altura de la línea no es susceptible de razonamiento mecánico. Primero, introduce
cuantificadores anidados al razonar sobre el espacio de posibles alturas de línea. En
segundo lugar, describe el conjunto de todos los objetos en una línea, un conjunto
demasiado complejo para un razonamiento mecánico eficiente. VizAssert utiliza una
descripción más eficaz de las alturas de las líneas.

Dado que cada objeto de la línea debe estar alineado con la línea de base, la altura de la línea
Figura 5. Los márgenes verticales adyacentes colapsan y esta figura visualiza dos
debe ser la más alta que un objeto se eleve por encima de la línea de base más lo más profundo
posibilidades. Cada posibilidad muestra varios recuadros y sus márgenes. Los
que un objeto caiga por debajo de ella (más el interlineado). VizAssert calcula lo más alto que un
cuadros de altura cero están representados por líneas horizontales. Cada flecha
objeto se eleva por encima de la línea de base con un máximo de ejecución (y de manera similar,
representa un margen (todo positivo) y tiene el mismo color que el cuadro que lo
para lo más profundo que un objeto cae por debajo de la línea de base):
genera. Cuando un margen determina la ubicación de un cuadro, se dibuja un
círculo a su alrededor. La figura de la izquierda muestra cómo los cuadros de

above_b • aseline b): = altura cero afectan el colapso de los márgenes; tenga en cuenta que el margen

1 inferior azul no se mide desde la parte inferior de ese cuadro porque ese margen
• se colapsa con el margen superior del cuadro. La figura de la derecha muestra el
• above_baseline
max • ascenso( b) + 2 líder( segundo)anterior) Si segundo. prev, null
( segundo.
margen de un cuadro secundario (en negro) colapsando con el margen de su
• above_baseline ( segundo. último) Si segundo. último, nulo
• padre (naranja) a pesar de ser el segundo hermano del padre (el primer hermano,
El primer argumento tomax es el tamaño del cuadro actual (por encima de la línea de en azul, tiene una altura cero; se ha agregado espacio a su alrededor para mayor
base); los otros pasan el above_baseline valor de izquierda a derecha a lo largo de la línea claridad).
y de los niños a los padres, incorporando así todos los recuadros de la línea. Por lo tanto,

VizAssert reduce el razonamiento de la altura de la línea a solo dos valores: above_baseline

el simétrico below_baseline.
Márgenes positivos y negativos El navegador que representa al-
4.2 Colapso del margen goritmo considera los márgenes positivos y negativos por separado, por lo que VizAssert divide

el margen superior monte en una componente positiva

En CSS, cada cuadro tiene un margen: un área fuera de la caja en la que otras cajas no pueden
nent mt + y un componente negativo monte -. Para rastrear márgenes
entrometerse. 5 Para la mayoría de las cajas, se permite que los márgenes verticales se
mientras colapsan juntos, mt + es, para cualquier cuadro, el máximo del margen
superpongan si son adyacentes; Figura 5
superior mt si es positivo), cualquier margen positivo de su
demuestra dos situaciones de colapso de márgenes. Tenga en cuenta que el margen de

un niño puede colapsar con el de su padre y que los márgenes superior e inferior de los
niños que colapsan con él, y cualquier margen positivo de sus hermanos anteriores

cuadros de altura cero colapsan. Debido especialmente a estas formas complejas de

que colapsan con él. Se utilizan acumulaciones similares para los márgenes

colapso de márgenes, el conjunto de márgenes que colapsan juntos puede ser bastante
superior e inferior positivos y negativos.

grande.
Primeros hijos de altura cero Cuando el margen superior de un padre
El estándar CSS 2.1 describe el colapso de los márgenes al describir las
colapsa con su primer hijo, y el primer hijo tiene altura cero, sus márgenes
condiciones bajo las cuales colapsan un par de márgenes. Cualquier “componente
colapsan con el margen superior de su siguiente hermano. Esto requiere
conectado” de los márgenes se colapsa, y el tamaño total del margen se calcula
propagar información de ese próximo hermano a ese primer hijo. Esto
sumando los márgenes más positivos y negativos de ese grupo. Razonar sobre un
requiere adicional monte ↑ y +
gran conjunto de márgenes, y mucho menos un conjunto definido por un criterio de
monte
- ↑ valores: monte ↑ es
+ igual a monte para cajas+ con una altura distinta de cero, y es igual
accesibilidad de gráficos, estaría más allá de las capacidades de un solucionador SMT
a la del siguiente hermano monte ↑ para cajas con altura cero. +
moderno. Por lo tanto, VizAssert utiliza una reducción de finitización que reemplaza el
conjunto de márgenes colapsados por una descripción finita. VizAssert rastrea, en
lugar del conjunto de márgenes contraídos, un máximo acumulado de márgenes Despeje Algunas cajas cuyo claro propiedad está configurada y que tienen una caja

vistos hasta ahora e información adicional sobre esos márgenes. Sin embargo, flotante cercana tienen despeje. Una peculiaridad de las reglas de colapso de

hacerlo para los márgenes que colapsan es más complejo que la reducción de márgenes declara que si un cuadro sin altura tiene espacio libre, sus márgenes, y

finitización análoga para la altura de la línea, porque debe enfrentar tres problemas cualquier otro con el que colapse, no colapsarán con el margen inferior de su padre.

clave. Un campo booleano adicional ¿megabyte? en cada cuadro describe si

sus mb + y megabyte - incluir márgenes de dichos cuadros, que el padre

utiliza para evitar colapsar en esos casos.
4 Apéndice C.1 reproduce la especificación estándar de alturas de línea.

5 Esta descripción elides muchos detalles; en algunos casos, otras casillas pueden entrometerse en el margen de En total, la reducción de finitización por colapso de márgenes reduce el conjunto de

una casilla. Apéndice C.2 reproduce la especificación del estándar de colapso de márgenes. márgenes que colapsan a seis valores reales ( mt +,
monte -, mb +, mb -, monte ↑, monte
+↑ -) y el booleano ¿megabyte?.

6
Verificación de que las páginas web tengan un diseño accesible
4.3 Diseño flotante
Una caja flotante "se desplaza hacia la izquierda o hacia la derecha hasta que toque el
borde de la caja que la contiene u otro elemento flotante" [ 33 ]. El diseño flotante se usa
comúnmente para implementar barras laterales, figuras y menús. El diseño flotante es
particularmente desafiante y, como resultado, la formalización de VizAssert es
particularmente novedosa. Para formalizar el diseño flotante, VizAssert reduce el conjunto
de todos los cuadros flotantes anteriores a una estructura de datos llamada
Zona de exclusión. Estas zonas de exclusión tienen un mínimo formas canónicas cuyo
tamaño compacto los convierte en una opción atractiva para representar diseños
flotantes. VizAssert limita el tamaño de las formas canónicas, lo que permite que un
solucionador SMT las use para calcular las posiciones de las cajas flotantes. Limitar el
tamaño de las formas canónicas es correcto: siempre que VizAssert se agrega a una
forma canónica, prueba si se acierta el límite; si es así, VizAssert vuelve a ejecutar la
verificación con un límite mayor. Limitar el tamaño de los formularios canónicos también
es completo, ya que ningún formulario canónico puede ser mayor que el número de
cuadros flotantes en una página.
4.3.1 Semántica de diseño flotante
En casos simples, un cuadro flotante se mueve hacia el borde izquierdo o derecho de su
cuadro contenedor y el texto se ajusta a su alrededor. Sin embargo, las reglas para colocar
múltiples cajas flotantes son bastante complejas. El diseño flotante se utiliza para cualquier
caja cuyo flotador
se establece la propiedad, a menos que su posición la propiedad está establecida en absoluto
o fijo, en cuyo caso, la caja utiliza un diseño posicionado. Apéndice C.3 reproduce para algunos y ∈ Y, ℓ ∈ L, y r ∈ R,
la especificación estándar de diseño flotante.
El estándar CSS describe las posiciones de los cuadros flotantes con nueve reglas:
siete propiedades que la posición debe satisfacer y dos criterios de optimización que
seleccionan entre múltiples opciones. Para el razonamiento automatizado, estas reglas
deben traducirse en fórmulas lógicas sobre las que un solucionador SMT pueda razonar de
manera eficiente. El desafío es doble: primero, las reglas describen las relaciones que
deben cumplirse para todos los pares de cajas flotantes, lo que genera demasiadas
limitaciones para resolverlas de manera eficiente; y en segundo lugar, la codificación de
los criterios de optimización introduce cuantificadores, lo que mueve las restricciones más
allá de las capacidades de los solucionadores SMT actuales. Debido a estos problemas, el
trabajo anterior [ 39 ] solo permitía usos restringidos del diseño flotante. Por el contrario,
VizAssert admite la semántica completa del diseño flotante utilizando una formalización
novedosa de diseño flotante basada en la estructura de datos de la zona de exclusión.
4.3.2 Zonas de exclusión
Diseñar una caja flotante requiere conocimientos sobre las cajas flotantes
anteriores. Un Zona de exclusión resume esta información:
• Bordes superior e inferior de cajas flotantes anteriores;
• Bordes derechos de los cuadros flotantes a la izquierda anteriores; y
• Bordes izquierdos de los cuadros flotantes a la derecha anteriores.
7
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.
y1 y2
UNA UNA
C1 C2
y3
UNA segundo
C3
Figura 6. Un cuadro flotante a la izquierda se coloca en la posición más alta, más a la
izquierda fuera de un Zona de exclusión. Aquí, los cuadros azules etiquetados como łAž son
elementos secundarios flotantes a la izquierda de su padre, cuyos bordes izquierdo y derecho
se muestran. La zona de exclusión resultante son todos los puntos arriba (ya la izquierda de)
la línea punteada verde, que se utiliza para determinar la ubicación del cuadro naranja
etiquetado como łBž. Formalmente, la zona de exclusión sería un triple
({ y 1, y 2, y 3}, { C 1, C 2, C 3}, ∅) o equivalente, ({ y 3}, { C 3}, ∅).
Este resumen forma un triple ( Y, L, R), dónde Y es el conjunto de y posiciones de los bordes
superiores de los márgenes de las cajas flotantes anteriores, L es el conjunto de las
coordenadas de las esquinas del margen inferior derecho de los flotantes izquierdos anteriores,
y R es el conjunto de las coordenadas de las esquinas del margen inferior izquierdo de los
flotantes derechos anteriores. En conjunto, esta información describe una región de la pantalla
donde no se puede colocar un cuadro flotante: un cuadro pag está excluido de ( Y, L, R) cuando,
pag. y < y ∨ ( pag. x < ℓ. X ∧ pag. y < ℓ. y) ∨ ( pag. x> r. X ∧ pag. y < r. y)
Figura 6 muestra la zona de exclusión utilizada para diseñar un cuadro flotante en una página
web.
Dada la zona de exclusión, es posible calcular la posición de una caja flotante
usando el ancho de la caja w su bloque contenedor pag, y la posición y ∗ la caja
tendría si estuviera diseñada con un diseño de flujo de bloque. Dada esta
información, la caja se coloca de manera que el borde superior del margen esté en o
por debajo y ∗, sus esquinas superiores no están en la zona de exclusión y sus
esquinas superiores están dentro del bloque contenedor (con excepciones para cajas
más anchas que su bloque contenedor o de ancho negativo). Esto conduce a una
codificación SMT eficiente. Por ejemplo, la siguiente fórmula restringe y para
garantizar que ambas esquinas superiores no estén en la zona de exclusión cuando
la caja tiene un ancho positivo pero no es más ancho que el bloque que lo contiene.
0 ≤ w ≤ pag. ancho [contenido] = ⇒ w ≤ r - ℓ
r = min { X r | ( X r, y r) ∈ R ∧ y <y r}
ℓ = max ({ X l | ( X yo y l) ∈ L ∧ y <y l} ∪ { pag. izquierda [contenido]})
Fórmulas similares manejan los otros dos casos y el X posición.
La fórmula anterior es una propiedad que y posición debe tener. Para
determinar el hormigón y posición, VizAssert utiliza el hecho de que el y puesto
debe ser miembro de Y ∪ { y ∗} y
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.
simplemente los prueba en orden creciente, para satisfacer las reglas de CSS 2.1 que son
criterios de optimización. Del mismo modo, el X posición
debe (para un flotador izquierdo) ser miembro de { X l | ( X yo y l) ∈ L} ∪
{ pag. izquierda [contenido]}.
4.3.3 Formas canónicas
Dos zonas de exclusión pueden ser equivalente Ð pueden excluir el mismo conjunto
de puntos. Por ejemplo,
e = ({ 0}, {(0, 1), (1, 1)}, {}) y mi ′ = ({ 0}, {(1, 1)}, {})
difieren en su L componente pero excluye el mismo conjunto de puntos:
( x, y) ∈ mi ⇔ ( x, y) ∈ mi ′ ⇔ y < 0 ∨ x < 1 ∧ y < 1
Se puede calcular una forma canónica compacta:
Teorema 4.1. Cada zona de exclusión ( Y, L, R) tiene un forma canónica ( Y ∗, L ∗, R ∗),
tal que:
• ( Y ∗, L ∗, R ∗) es equivalente a ( Y, L, R);
• las zonas de exclusión equivalentes tienen formas canónicas idénticas;
• entre zonas de exclusión ( Y ′, L ′, R ′) equivalente a ( Y, L, R),
la forma canónica minimiza | Y ′ | + | L ′ | + | R ′ |.
Prueba. Construimos la forma canónica de manera explícita. Y ∗ está vacío si Y está vacío y
de lo contrario es el conjunto singleton
Y ∗ = { max ( Y ∪ Y ′)}
Y ′ = { min { y yo y r} | ( X yo y l) ∈ L ∧ ( X r, y r) ∈ R ∧ X l> X r}
L ∗ es el máximo su ∧ bset de L tal que
( x, y) ∈ L ∗ =⇒ ( x, y) = (x ′, y ′) ∨ x> x ′ ∨ y> y ′
( X ′, y ′) ∈ L
R ∗ es análogo. La verificación de las tres propiedades dadas para las formas
canónicas es mecánica.
Ejemplo 4.1. Los cuadros flotantes se utilizan con frecuencia para diseñar elementos alineados
verticalmente en barras de herramientas y menús. Suponga que el ancho de la página es w> ℓ, y
considere un diseño que contenga
ℓ cajas flotantes a la izquierda, todas de tamaño 1 × 1. La zona de exclusión es
({ 0}, {(1, 1), (2, 1),. . . ( ℓ, 1)}, ∅). Esta zona de exclusión es equivalente a la zona
de exclusión canónica ({ 0}, {( ℓ, 1)}, ∅).
Debido a que las zonas de exclusión tienen formas canónicas compactas, VizAssert puede
establecer un límite k en su tamaño; | L |, | R | ≤ 5 es suficiente para la mayoría de las páginas
web. Limitando zonas de exclusión a k
elementos plantea el desafío de elegir un tamaño suficientemente grande
k. VizAssert evita este problema afirmando, en cada adición de una casilla a
una zona de exclusión, que el límite elegido es suficiente para representar la
zona de exclusión combinada. Si esta aserción falla para cualquier adición a
una zona de exclusión, la consulta se reintenta con más registros. Dado que es
suficiente utilizar tantos registros como haya cuadros flotantes en la página,
este proceso siempre terminará.
P. Panchekha, AT Geller, MD Ernst, Z. Tatlock y S. Kamil
4.3.4 Implementación mediante triples
VizAssert requiere una codificación SMT eficiente de zonas de exclusión, incluidas
operaciones eficientes para encontrar la posición correcta de una caja flotante y
agregar una caja flotante a una zona de exclusión.
Para calcular la posición de un flotador dada una zona de exclusión
( Y, L, R), es importante encontrar primero el flotador y posición, que es la
mínima y posición donde encajará el flotador. Esto requiere iterar a través L y R juntos
y en orden creciente y. Para evitar codificar una operación de clasificación y
combinación en una fórmula SMT, L y R se almacenan juntos. Para hacerlo
L y R se almacenan como un tamaño k conjunto de triples y, ℓ, r), donde cada
triple representa ( ℓ, y) ∈ L y ( r, y) ∈ R. Estos triples se almacenan en orden
creciente y valor, y ℓ ( o r) puede faltar si L no contiene puntos con y- posición
mayor que y. Esta codificación permite iterar fácilmente a través L y
R en orden creciente y. Además, en ( y, ℓ, r), el espacio horizontal disponible para
una caja flotante es simplemente r - ℓ, facilitando la elección de la posición vertical
correcta para un nuevo flotador.
Además de los triples ( y, ℓ, r), el conjunto Y también debe estar codificado. Dado que
VizAssert usa zonas de exclusión canónicas, Y es un conjunto singleton que se puede
almacenar directamente. Cuando se agrega un nuevo flotador a una zona de exclusión, Y se
actualiza al máximo del elemento actual de Y y el borde superior del nuevo flotador. Valores
en L y R cuyo y La posición es menor que el borde superior del nuevo flotador también debe
eliminarse. Esto es fácil ya que L y R se almacenan en orden clasificado como triples ( y, ℓ, r).
La codificación de base triple reduce significativamente el tamaño de las fórmulas
SMT que definen las operaciones de la zona de exclusión y evita la codificación de
operaciones ineficientes como la clasificación y la combinación. Como una modificación
adicional a esta codificación, VizAssert permite "triples redundantes", que son dos triples
cuyas y
los valores difieren y cuyo ( ℓ, r) Son identicos. Estos triples redundantes reducen el
tamaño de la fórmula SMT para agregar un flotador a una zona de exclusión, a costa de
□ posiblemente requerir más registros. Hemos encontrado que, en general, los triples
redundantes dan como resultado fórmulas más pequeñas.
4.3.5 Validación de la implementación
La codificación de las zonas de exclusión es compleja. Cada vez que se ejecuta
VizAssert, demuestra que su implementación satisface las reglas del estándar
para el diseño flotante, para el k. Si la prueba falla, VizAssert conserva la solidez
al terminar.
Para cada una de las nueve reglas requeridas para el diseño flotante, la prueba
considera la ubicación de una caja flotante arbitraria dada una zona de exclusión
arbitraria. Cada regla está probada por inducción sobre la construcción de la zona de
exclusión: está probada para una zona de exclusión vacía y se prueba que se conserva
cuando se agrega una caja flotante a una zona de exclusión. Cada caso de la prueba
se lleva a cabo automáticamente por el solucionador de SMT, ya que la implementación
del diseño flotante de VizAssert es una colección de fórmulas SMT.
8
Verificación de que las páginas web tengan un diseño accesible PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.

Tabla 2. Resultados de la verificación de las afirmaciones de accesibilidad para 62 páginas

web. T + y F + son verdaderos y falsos positivos. La tasa general de falsos positivos fue

baja: 2.6% de todas las pruebas y 17% de los contraejemplos.

# Aserción Verificado T+ F+ Se acabó el tiempo

1 tamano del texto 38 18 3 3

2 pantalla_interactiva 59 1 1 1
3 grosor de línea 39 18 3 2
6 36
4 accesible_en pantalla
. . . equipo organizador corre o [...] para. . . un gran ajuste para cualquier salud personal cualquier equipo que
organice deportes. . . 5 no_hscroll 60 1 1
orientado a la pequeña empresa. . .
6 header_size 39 21 2
7 superposición_texto 53 2 5 2
Figura 7. Dos páginas web, corriendo y rehabilitación-yoga,
8 Espaciado entre líneas 59 3
de la suite FWT y los usos sugeridos por los organizadores de FWT para las
9 contraste 1
plantillas.
10 no_text_on_bg_image 1

20 11 dropdown_offscreen 1
12 columnas_alineadas 1
10 15
13 texto_visible 1
14 button_large 1
10

5 Total 388 65 13 11
5

0 0
50 100150200250300350 100 200 300 400 500
páginas web que encajan dentro del subconjunto de CSS admitido por VizAssert
Cajas Reglas
(consulte la Sección 6 ). Cuando las plantillas contenían varias páginas (por ejemplo, una
página principal, una página de información y una página de producto), usábamos solo la
Figura 8. Histograma del número de casillas y reglas CSS para las 62
página principal. En conjunto, las 62 páginas web tienen un promedio de 78 elementos
páginas web.
(rango intercuartil 56ś93), 176 casillas (119ś222 IQR) y 128 reglas (89ś145 IQR). Ver
figura 8 para histogramas de estas estadísticas.
Realizamos una prueba en papel de que la prueba automatizada siempre tiene
éxito.
5.2 Resultados
5 Evaluación Ejecutamos VizAssert con un tiempo de espera de 30 minutos, utilizando una máquina con
VizAssert puede verificar que las páginas web realistas satisfagan las pautas de una CPU i7-4790K, 32 GB de memoria y Z3 versión 4.5.1. VizAssert verificó cada
accesibilidad y usabilidad. Para 62 páginas web, VizAssert determinó si satisface las 8 afirmación para todos los anchos de pantalla posibles de 1024 a 1920 píxeles, alturas de
afirmaciones de propósito general descritas en la Sección 3 . También ejecutamos pantalla de 800 a 1080 píxeles y tamaños de fuente predeterminados de 16 a 32 píxeles.
VizAssert en las 6 afirmaciones específicas de la página y sus páginas web En total, hubo 414 verificaciones exitosas, 64 verdaderos positivos, 13 falsos positivos y 11
correspondientes. tiempos de espera (consulte la Tabla 2 ).

5.1 Páginas web temáticas

Recopilamos 62 páginas web de una comunidad en línea de profesionales del diseño
web que nomina, selecciona y publica páginas web de alta calidad:
FreeWebsiteTemplates (FWT) [ 20 ]. Las páginas web publicadas están escritas por
diferentes desarrolladores, por lo que cubren una sección transversal de técnicas
comunes de diseño web. Ver figura 7 por ejemplo. Los desarrolladores web novatos
utilizan estas plantillas simplemente cambiando el texto de relleno a su propio contenido,
mientras que los desarrolladores con más conocimientos modifican la plantilla publicada
o extraen y reutilizan componentes en sus propias páginas web. No se espera que todas
las páginas web aprueben todas las afirmaciones, pero las fallas representan
desviaciones de las mejores prácticas de diseño web.
VizAssert genera parámetros de representación que ilustran una violación de las
pautas de diseño, por lo que la mayoría de los informes son fáciles de diagnosticar y
corregir. Por ejemplo, el header_size
se viola la afirmación en la página carrera de coches para un 1856 × 800 navegador con 16px texto
(ver figura 9 ). La afirmación requiere que los encabezados más importantes sean más grandes,
pero en la barra lateral de la página, los títulos de las secciones (en segundo nivel h2 encabezados)
se representan en 14px tipo, mientras que los enlaces de la barra lateral (en tercer nivel h3 encabezados)
se representan en un mayor 16px fuente. Un cambio de una sola línea en el archivo CSS soluciona
este problema aumentando el tamaño de h2
encabezados.

6 Verificado en las 62 páginas, pero 13 verificaciones son vacías porque no se identificaron elementos del

Seleccionamos las páginas web descargando las 100 páginas web de FWT lector de pantalla.

publicadas más recientemente y conservando las 62

9
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU. P. Panchekha, AT Geller, MD Ernst, Z. Tatlock y S. Kamil

Tamaño de instancia (términos) Tamaño de prueba (restricciones)

100% 100%

75% 75%

50% 50%

25% 25%

Figura 9. A la izquierda, un verdadero positivo descubierto por VizAssert: el título 0% 0%

488 k 770 k 1052 k 8k 17 k 27 k
de la sección, "Vínculo misceláneo", está escrito en letras más pequeñas que los
Tiempo de verificación
subtítulos. A la derecha, un falso positivo: VizAssert cree que łSALEž puede 100%

superponerse con la fecha, porque no razona sobre la falta de descendientes en

las letras de łSALEž.
75%

50%
Como ejemplo de un falso positivo, VizAssert informa que el
superposición_texto la afirmación se viola en el artículos deportivos
página web para un 1872 × 800 navegador con 16px texto. El texto no se
25%
superpone (ver Figura 9 ), pero los cuadros de texto lo hacen porque reservan Aserción #
espacio para posibles descendientes. Si el texto fuera "Liquidación" en lugar de 1234

"VENTA", el texto se superpondría. VizAssert detectó así una falla en la 5678

0%
afirmación formal, pero no una falla en la pauta de accesibilidad que formalizó la 10 s 30 s 100 s 300 s 1000 s

afirmación. VizAssert necesitaría razonar sobre la forma de las letras Tiempo (s; escala logarítmica)

individuales para evitar este falso positivo.

Figura 10. CDF de la instancia SMT y el núcleo insaturado para cada afirmación, y el
VizAssert verifica las afirmaciones transformándolas en instancias SMT decidibles en la tiempo necesario para verificar la satisfacibilidad de las instancias SMT.
teoría de la aritmética real lineal sin cuantificadores. Las instancias SMT son bastante

grandes, como se muestra en la Figura 10 , debido a la complejidad del algoritmo de

renderizado del navegador. El tamaño de la instancia es en gran medida independiente de

la aserción que se verifica, en lugar de eso depende principalmente del tamaño de la página pruebas, seguimos a Cassius [ 39 ] al evaluar la semántica de VizAssert con estas
que se verifica, ya que las aserciones son pequeñas en relación con la formalización de la pruebas comparando la representación de VizAssert con la de Mozilla Firefox. 7

representación del navegador de VizAssert. Las pruebas de diferentes aserciones difieren

en tamaño, ya que diferentes aserciones pueden requerir un razonamiento más o menos
global.
A pesar de las grandes instancias, VizAssert decidió la mayoría de las
afirmaciones rápidamente: solo 11 ejecuciones de 502 (2,2%) caducaron en 30
Para garantizar la exactitud de la implementación de VizAssert de altura de
línea, colapso de margen y diseño flotante, usamos todas las pruebas de
conformidad W3C para las subsecciones 10.8 y
10.8.1 (altura de línea), 8.3 y 8.3.1 (colapso de margen), y
9.5, 9.5.1 y 9.5.2 (diseño flotante). Mesa 3 muestra resultados para VizAssert y Cassius.

minutos. Figura 10 traza el tiempo para decidir cada afirmación de propósito VizAssert pasa todas las pruebas excepto 91; las 91 pruebas fallidas utilizan

general. los grosor de línea la afirmación lleva mucho más tiempo que las demás. características no compatibles, principalmente alineación vertical, texto de derecha a

Creemos que esto se debe al hecho de que requiere razonar sobre la relación izquierda y SVG, por lo que están fuera del alcance de la semántica de VizAssert. Entre

entre tres recuadros diferentes: una línea de texto, su primer hijo y su último hijo.
5.3 Pruebas de conformidad del W3C
las pruebas aprobadas hay 5 para las que la representación de VizAssert es diferente
de la de Mozilla Firefox. Para verificar la exactitud de VizAssert en estos cuatro casos,
confirmamos manualmente que la representación de VizAssert coincide con la
representación de referencia; Se sabe que la representación de Firefox de estos casos
es incorrecta [ 59 ].

VizAssert formaliza nuevos subsistemas de CSS, incluidos los tres discutidos en la

Sección 4 : altura de línea, colapso de márgenes y diseño flotante. Una semántica
Para determinar si las reducciones de finitización eran importantes para

incorrecta llevaría a que VizAssert produjera falsos negativos. Afortunadamente, el

lograr una semántica precisa, comparamos

W3C ofrece amplios conjuntos de pruebas de conformidad para que los

desarrolladores de navegadores se aseguren de que su navegador implementa CSS
correctamente. Estas pruebas se proporcionan como páginas web que contienen
instrucciones en inglés; para mostrar que VizAssert pasa estos
7 Los pequeños errores de redondeo a veces hacen que la representación de Firefox de las pruebas
de conformidad difiera de la exigida por el estándar en una fracción de píxel [ 39 ]. Compensamos esto
en esta evaluación comparando la semántica de VizAssert con la representación de Firefox con una
precisión de un sexto de píxel.

10
Verificación de que las páginas web tengan un diseño accesible PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.

Tabla 3. Pruebas de conformidad para las siete secciones del estándar CSS 2.1 7 Trabajo relacionado
relevantes para la altura de línea, colapso de márgenes y diseño flotante, todas
VizAssert se basa en esfuerzos anteriores para estudiar formalmente visualizaciones e
formalizadas en VizAssert usando reducciones de finitización. Ninguna herramienta falló
interfaces gráficas. Se suma al conjunto de herramientas disponibles para los
en ninguna prueba, pero Cassius dejó a la abrumadora mayoría sin soporte porque su
desarrolladores web para validar y mejorar sus páginas web.
falta de reducciones de finitización hizo que el soporte para estas características fuera
imposible.

7.1 Formalización de la representación del navegador

Sección Título VizAssert Cassius Pruebas La formalización de VizAssert del algoritmo de representación del navegador es
8.3 .0 Márgenes 318 218 343 significativamente más detallada y conforme que la del trabajo anterior, Cassius [ 39 ],
8.3.1 Márgenes colapsados 128 13 133 sobre el que se basa. (De los 13 subsistemas principales de la formalización de
9.5 .0 Flotadores 184 0 205 VizAssert en la Figura 2 , siete no están presentes en Cassius). Los avances de
9.5.1 Colocación de flotadores 24 0 27 VizAssert en este trabajo anterior incluyen no solo las reducciones de finitización
9.5.2 Despeje 60 0 69 utilizadas para formalizar la altura de la línea, el colapso de márgenes y el diseño
10,8 .0 Altura de la línea 7 1 10 flotante, sino también varias propiedades CSS adicionales no admitidas por Cassius y
10.8.1 Líder 194 39 219 un soporte de selector CSS más rico.
Total 915 271 1006
Ninguna de las páginas web realistas utilizadas para evaluar VizAssert encaja dentro
del pequeño subconjunto de CSS implementado por Cassius. Además de los subsistemas
VizAssert a una semántica sin reducciones de finitización: Cassius [ 39 ]. Debido a discutidos en la Sección 4 , estas páginas también hacen un uso frecuente del diseño
su falta de reducciones de finitización, Cassius no pudo manejar correctamente la posicionado (que permite colocar un cuadro en una posición fija de píxeles en la pantalla)
mayoría de las pruebas de conformidad. y espacio libre (que permite mover un cuadro verticalmente en respuesta

a flotadores). Soporte para el guion de texto y posición-estilo-lista

6 Limitaciones de VizAssert Las propiedades también se agregan en VizAssert.

CSS es grande: decenas de estándares que suman miles de páginas impresas,
VizAssert admite funciones para permitir la verificación de una fracción sustancial de
páginas web, pero omite muchas funciones menos utilizadas. Algunas funciones, como
la alineación vertical y el texto de derecha a izquierda, solo requerirían tiempo de
ingeniería para implementarlas. Otras características, como la formalización de diseños
tabulares, presentan importantes desafíos de investigación para comprender las
implementaciones del navegador, desarrollar reducciones de finitización y manejar
varios casos extremos.
VizAssert actualmente maneja solo HTML y CSS. Sería un desafío interesante
analizar el código JavaScript que modifica las páginas web (probando la accesibilidad
sobre todas las posibles modificaciones a la página) o el código del lado del servidor que
genera las páginas (probando la accesibilidad sobre todos los posibles contenidos de la
página). Se podrían agregar operadores temporales a la lógica visual para expresar las
propiedades de accesibilidad para el código dinámico [ 21 ]. VizAssert podría combinarse
con otras herramientas para lograrlo. Por ejemplo, para verificar el efecto de JavaScript
en una página web, se podría combinar una herramienta de análisis estático de
JavaScript con VizAssert, utilizando el análisis de JavaScript para calcular el conjunto de
posibles DOM de páginas web producidos y luego usar VizAssert para verificar sus
propiedades de diseño.
VizAssert trata solo el algoritmo de renderizado del navegador para CSS. Se
podrían aplicar técnicas similares a otros algoritmos de diseño, y se podrían usar
reducciones de finitización similares a las utilizadas en VizAssert para formalizar
esos algoritmos. Por ejemplo, las zonas de exclusión pueden ser útiles para
formalizar la
comportamiento de los flotantes en TEX, y la reducción de la altura de la línea podría aplicarse al
Cassius estaba destinado a ser utilizado para sintetizar CSS a partir de ejemplos y,
por lo tanto, no puede asumir un archivo CSS concreto conocido. Sin embargo, al
verificar páginas web, se conoce el archivo CSS; esto permite que VizAssert calcule la
coincidencia de selectores y la conexión en cascada fuera del solucionador SMT, lo que
hace posible admitir selectores descendientes, secundarios y de pseudoclase que
Cassius, que hizo la selección y coincidencia en el solucionador SMT, no pudo admitir.
La suposición de un archivo CSS conocido también permite que VizAssert maneje bien
el em y ex unidades, que se escalan con el tamaño de fuente y, por lo tanto, son
esenciales para escribir páginas web accesibles.
Otro trabajo ha formalizado subconjuntos de CSS utilizando gramáticas de atributos [ 32
]. Debido a las limitaciones de las gramáticas de atributos, estos esfuerzos cubren un
subconjunto más pequeño de CSS que VizAssert, aunque más grande que Cassius.
Además, estas formalizaciones no están destinadas a la verificación, solo a la
interpretación y, por lo tanto, no pueden usarse para el razonamiento mecánico.
7.2 Razonamiento visual formalizado
El trabajo anterior ha abordado la idea del razonamiento mecánico sobre el diseño
visual desde muchas direcciones. Algunos autores han investigado la síntesis de
programas a partir de manipulaciones visuales [ 12 , 23 ]. Otros han desarrollado
lenguajes específicos de dominio para el diseño visual, como la gramática de gráficos
[ 62 ] usado por ggplot2 [ 61 ]. ConstraintSS [ 4 ] y trabajos similares sobre el diseño
basado en restricciones [ 6 , 22 , 47 , 51 , 64 ] permiten especificar diseños mediante un
conjunto de restricciones, sintetizando el diseño a partir de las restricciones. Si bien
todo este trabajo implica algunos

diseño de texto en aplicaciones iOS o Android.

11
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU. P. Panchekha, AT Geller, MD Ernst, Z. Tatlock y S. Kamil

razonamiento formal sobre el diseño, ninguno de ellos proporciona una forma de afirmar o Remaui [ 36 ] utiliza heurística para sintetizar diseños de Android a partir de maquetas. Estas

verificar las propiedades de accesibilidad o usabilidad. herramientas tienen como objetivo simplificar la tarea de escribir o editar interfaces gráficas;

Otro trabajo ha explorado disciplinas de prueba para interfaces gráficas. Prueba de VizAssert se enfoca en verificar la accesibilidad y usabilidad de estas interfaces. Algunos

Sikuli [ 10 ] proporciona un lenguaje de secuencia de comandos simple para describir autores han desarrollado heurísticas para detectar diseños problemáticos [ 5 , 28 , 57 , 58 ].

secuencias de entradas de usuario y para comparar la interfaz píxel por píxel con una Otras herramientas intentan detectar diferencias entre navegadores web para las páginas

imagen fija. Otros autores [ 26 , 30 , 37 ] proporcionan técnicas para capturar dichos web, a menudo utilizando heurísticas para construir un modelo de alto nivel del

scripts a partir de las interacciones del usuario. Este trabajo ha demostrado la comportamiento de la página [ 11 , 31 , 44 ] Estas herramientas son útiles, pero cada una es

importancia de desarrollar las descripciones formales correctas del comportamiento específica de una propiedad de página web; VizAssert permite a los desarrolladores web

correcto de la interfaz gráfica [ 63 ]. VizAssert incorpora esta información al desarrollar escribir y verificar afirmaciones personalizadas.

una lógica expresiva en la que los desarrolladores pueden especificar sus propiedades
de accesibilidad y usabilidad.

8 Conclusión
Una de esas lógicas expresivas la proporciona Cornipickle [ 21 ], que prueba, para
Verificar las propiedades visuales de las interfaces de usuario es importante para garantizar que
parámetros de representación particulares y secuencia de acciones del usuario,
las aplicaciones sean utilizables y accesibles para todos los usuarios. Desarrollamos una lógica
propiedades temporales de páginas web interactivas. La lógica visual está inspirada
visual de afirmaciones y una herramienta automatizada disponible públicamente, VizAssert, que
en Cornipickle, pero está adaptada para permitir el razonamiento automatizado: la
verifica las afirmaciones visuales de las páginas web independientemente de las preferencias del
lógica visual agrega funciones para atravesar el árbol de cajas, agrega el antepasado función
usuario y el tamaño de la pantalla. La construcción de VizAssert contiene formalizaciones
para relacionar cajas distantes y limita la multiplicación a la aritmética lineal. Por otro
novedosas de múltiples aspectos del algoritmo de diseño CSS, incluida la altura de la línea, el
lado, dado que VizAssert no razona sobre JavaScript, omite los operadores
colapso de márgenes y el diseño flotante, implementados mediante reducciones de finitización
temporales de Cornipickle. Cornipickle no ofrece una herramienta de verificación
novedosas. Para un conjunto de páginas web del mundo real, VizAssert verificó las afirmaciones
como VizAssert para su lenguaje de afirmación; simplemente ofrece un método
de las pautas y estándares de usabilidad, encontrando 64 errores con solo 13 falsos positivos.
conveniente para probar afirmaciones en representaciones particulares.

Expresiones de gratitud
7.3 Accesibilidad
Agradecemos a Jen Mankoff y Anat Caspi por sus valiosos comentarios sobre los
Los principales marcos de GUI, incluidos Android, iOS, OS X y los múltiples marcos
primeros borradores. También agradecemos a nuestro pastor Ben Livshits y a los
de Windows, incluyen soporte para información de accesibilidad, que a menudo
revisores anónimos por sus valiosas sugerencias.
implica anotar widgets con roles o describir su contenido. Para la web, este marco es
ARIA [ 55 ], que define el significado de los atributos de accesibilidad, y las WCAG [ 53 ],
Este trabajo fue apoyado por una beca de Adobe y por donaciones de Adobe. Este
que documenta las mejores prácticas para su uso. Herramientas como WAVE [ 60 ],
material se basa en el trabajo respaldado por el Programa de becas de investigación
SOAtest [ 40 ] y 508checker [ 18 ] compruebe que el HTML de la página web cumple
para graduados de la National Science Foundation con el número de subvención
con las mejores prácticas de accesibilidad, como evitar el texto justificado y tener
DGE-1256082. Este material se basa en el trabajo respaldado por la Fuerza Aérea de
leyendas significativas. También se ha realizado trabajo académico sobre este
los Estados Unidos bajo el Contrato No. FA8750-15-C-0010, y en una investigación
problema. Cuervo [ 17 ] aplica "reglas de validación" para garantizar que los objetos
patrocinada por el Laboratorio de Investigación de la Fuerza Aérea y DARPA bajo el
Java que componen una interfaz gráfica contengan correctamente títulos, resúmenes
número de acuerdo FA8750-16-2-0032. El gobierno de los EE. UU. Está autorizado a
y mnemónicos válidos, pruebas importantes para interfaces accesibles. Chang, Yeh y
reproducir y distribuir reimpresiones con fines gubernamentales sin perjuicio de
Miller amplían las herramientas basadas en píxeles, como Sikuli, para acceder a la
cualquier mención de derechos de autor al respecto.
información de accesibilidad, como el contenido y la información de funciones para
los elementos de la interfaz de usuario [ 9 ]. Todas estas herramientas solo prueban el
diseño visual para parámetros de representación particulares, por lo que no brindan
garantías sólidas independientes de los parámetros de representación.
Referencias
[1] Apple. 2017. Pautas de interfaz humana. https://developer.apple.
com / ios / human-interface-Guidelines /
[2] Apple. 2017. Qué hacer y qué no hacer en el diseño de UI. https://developer.apple.com/

diseño / consejos /

[3] Desarrollador de Apple. 2017. Marco UIKit. https://developer.apple.

7.4 Herramientas para desarrolladores de interfaces
Muchos artículos recientes han desarrollado herramientas para diseñadores de
interfaces de usuario. Bricolaje [ 25 ] utiliza heurística para transferir estilos de una
página a otra; VerSS [ 27 ] rastrea los efectos de los cambios de CSS; Revisión [ 45 ]
extrae datos de visualizaciones y sintetiza nuevas presentaciones para esos datos;
com / documentation / uikit
[4] Greg J. Badros, Alan Borning, KimMarriott y Peter J. Stuckey. 1999.
Restricción de hojas de estilo en cascada para la Web. En Actas del 12º Simposio anual de la
ACMS sobre software y tecnología de interfaz de usuario (UIST'15). ACM, 73ś82. https://doi.org/10.1145/320719.322
[5] Jeffrey P. Bigham. 2014. Haciendo que la Web sea más fácil de ver con Oppor-

y Mejora de la accesibilidad tunistic. En Actas de la 27a Anual

12
Verificación de que las páginas web tengan un diseño accesible
Simposio ACM sobre software y tecnología de interfaz de usuario (UIST '14).
ACM, 117ś122. https://doi.org/10.1145/2642918.2647357
[6] Alan Borning, Richard Lin y Kim Marriott. 1997. Restricciones para
La web. En Actas de la Quinta Conferencia Internacional ACM sobre Multimedia
(MULTIMEDIA '97). ACM, 173ś182. https://doi.org/10. 1145 / 266180.266361
[7] Matthew Butterick. 2010. Tipografía práctica. Matthew Butterick
Tipografía, solo en línea.
[8] Lyndon Cerejo. 2011. Un enfoque del diseño web centrado en el usuario
para dispositivos móviles. https://www.smashingmagazine.com/2011/05/ un-enfoque-centrado en
el usuario-al-diseño-web-para-dispositivos-móviles
[9] Tsung-Hsiang Chang, Tom Yeh y Rob Miller. 2011. Asociación de
Representación visual de interfaces de usuario con sus estructuras internas y metadatos.
En Actas del 24º Simposio anual de ACM sobre tecnología y software de interfaz de
usuario (UIST '11). ACM, 245ś256.
https://doi.org/10.1145/2047196.2047228
[10] Tsung-Hsiang Chang, TomYeh y Robert C. Miller. 2010. Pruebas de GUI
Usando visión artificial. En Actas de la Conferencia SIGCHI sobre factores humanos en
sistemas informáticos (CHI '10). ACM, 1535 y 1544. https:
//doi.org/10.1145/1753326.1753555
[11] SR Choudhary, MR Prasad y A. Orso. 2012. CrossCheck: Com-
Combinando rastreo y diferenciación para detectar mejor las incompatibilidades entre
navegadores en aplicaciones web. En 2012 IEEE Quinta Conferencia Internacional sobre Pruebas,
Verificación y Validación de Software. 171ś180.
https://doi.org/10.1109/ICST.2012.97
[12] Ravi Chugh, Brian Hempel, Mitchell Spradlin y Jacob Albers. 2016.
Manipulación programática y directa, por fin juntos. En Actas de la 37ª Conferencia ACM
SIGPLAN sobre diseño e implementación de lenguajes de programación (PLDI '16). ACM,
341ś354. https: //doi.org/10.1145/2908080.2908103
[13] Quema a David. 2012. Herramientas de prueba de Selenium 2: Guía para principiantes. Packt
Publishing, Birmingham, Reino Unido.
[14] Leonardo De Moura y Nikolaj Bjùrner. 2008. Z3: un SMT eficiente
Solucionador. En Actas de la Teoría y Práctica del Software, XIV Congreso Internacional
de Herramientas y Algoritmos para la Construcción y Análisis de Sistemas (TACAS'08 /
ETAPS'08). Springer-Verlag, 337ś340.
http://dl.acm.org/citation.cfm?id=1792734.1792766
[15] Dieta. 2000. Ley básica de formación de una información avanzada
y Sociedad de Redes de Telecomunicaciones. http://japan.kantei.go.jp/ it / it_basiclaw /
it_basiclaw.html
[16] Comisión Europea. 2016. Directiva (UE) 2016/2102 de la Euro-
pean Parlamento y el Consejo de 26 de octubre de 2016 sobre la accesibilidad de los sitios
web y aplicaciones móviles de los organismos del sector público. http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:
OJ.L_.2016.327.01.0001.01.ENG & toc = OJ: L: 2016: 327: TOC
[17] Barry Feigenbaum y Michael Squillace. 2006. Accesibilidad Valida-
ción con RAVEN. En Actas del Taller internacional de 2006 sobre calidad del software
(WoSQ '06). ACM, 27ś32. https://doi.org/10.1145/
1137702.1137709
[18] LLC Formstack. 2014. Verificador de cumplimiento de la Sección 508 gratuito. http:
//www.508checker.com/check
[19] Amy Fowler. 2017. Una descripción general de la arquitectura Swing. http: // www.
oracle.com/technetwork/java/architecture-142923.html
[20] Plantillas de sitios web gratuitas. 2017. Plantillas web gratuitas. https: //
freewebsitetemplates.com
[21] Sylvain Hallé, Nicolas Bergeron, Francis Guerin y Gabriel Le Bre-
tonelada. 2015. Prueba de aplicaciones web a través de restricciones de diseño. En Pruebas,
verificación y validación de software (ICST), 2015 IEEE 8th International Conference on. IEEE,
IEEE, 1ś8.
[22] Osamu Hashimoto y Brad A. Myers. 1992. Estilos gráficos para
Creación de interfaces mediante demostración. En Actas del 5º Simposio anual de ACM sobre
software y tecnología de interfaz de usuario (UIST '92).
ACM, 117ś124. https://doi.org/10.1145/142621.142635
13
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.
[23] Thibaud Hottelier, Ras Bodik y Kimiko Ryokai. 2014. Programación
por manipulación para el diseño. En Actas del 27º Simposio anual de ACM sobre software
y tecnología de interfaz de usuario (UIST'14). ACM, 231ś241. https://doi.org/10.1145/2642918.2647378
[24] Melody Ivory y Aline Chevalier. 2002. Un estudio de la web automatizada
Herramientas de evaluación del sitio. Reporte técnico. Universidad de Washington, Departamento de Ciencias
de la Computación.
[25] Ranjitha Kumar, Jerry O. Talton, Salman Ahmad y Scott R. Klem-
mer. 2011. Bricolage: Retargeting basado en ejemplos para diseño web. En
Actas de la Conferencia SIGCHI sobre factores humanos en sistemas informáticos (CHI'11).
ACM, 2197ś2206. https://doi.org/10.1145/1978942. 1979262
[26] Maurizio Leotta, Andrea Stocco, Filippo Ricca y Paolo Tonella. 2015.
Generación automatizada de pruebas web visuales a partir de pruebas web basadas en DOM.
En Actas del 30º Simposio Anual ACM sobre Computación Aplicada (SAC '15). ACM, 775ś782.
https://doi.org/10.1145/2695664. 2695847
[27] Hsiang-Sheng Liang, Kuan-Hung Kuo, Po-Wei Lee, Yu-Chien Chan,
Yu-Chin Lin y Mike Y. Chen. 2013. SeeSS: Ver lo que rompí ś Visualización del impacto del
cambio de las hojas de estilo en cascada (CSS). En Actas del 26º Simposio anual de ACM
sobre tecnología y software de interfaz de usuario (UIST '13). ACM, 353ś356. https://doi.org/10.1145/2501988.
2502006
[28] Sonal Mahajan, Abdulmajeed Alameer, Phil McMinn y William GJ
Halfond. 2017. Reparación automatizada de problemas de diseño entre navegadores utilizando
técnicas basadas en búsquedas. En Actas del 26 ° Simposio Internacional ACM SIGSOFT sobre
Análisis y Pruebas de Software (ISSTA 2017).
ACM, 249ś260. https://doi.org/10.1145/3092703.3092726
[29] Jennifer Mankoff, Holly Fait y Tu Tran. 2005. ¿Es su página web?
¿Accesible ?: Un estudio comparativo de métodos para evaluar la accesibilidad de las páginas
web para ciegos. En Actas de la Conferencia SIGCHI sobre factores humanos en sistemas
informáticos (CHI '05). ACM, 41ś50. https: //doi.org/10.1145/1054972.1054979
[30] Atif Memon, Ishan Banerjee y Adithya Nagarajan. 2003. GUI Rip-
ping: Ingeniería inversa de interfaces gráficas de usuario para pruebas. En Actas de la X
Conferencia de Trabajo sobre Ingeniería Inversa (WCRE '03). Sociedad de Informática
IEEE, 260ś. http://dl.acm.org/citation. cfm? id = 950792.951350
[31] A. Mesbah y MR Prasad. 2011. Compuerta automatizada entre navegadores
pruebas de compatibilidad. En 2011 33ª Conferencia Internacional de Ingeniería de Software
(ICSE). 561ś570. https://doi.org/10.1145/1985793.1985870
[32] Leo A. Meyerovich y Rastislav Bodik. 2010. Web rápida y paralela
diseño de página. En Actas de la XIX Conferencia Internacional sobre la World Wide Web
(WWW '10). ACM, 711ś720. https://doi.org/10.1145/
1772690.1772763
[33] Red de desarrolladores de Mozilla. 2017. flotador. https://developer.mozilla.org/
es-US / docs / Web / CSS / float
[34] Red de desarrolladores de Mozilla. 2017. Verificación de accesibilidad móvil
lista. https://developer.mozilla.org/en-US/docs/Web/Accessibility/
Mobile_accessibility_checklist
[35] Federación Nacional de Ciegos. 2016. Estadísticas de ceguera. https:
//nfb.org/blindness-statistics
[36] Tuan A. Nguyen y Christoph Csallner. 2015. Ingeniería inversa-
ing interfaces de usuario de aplicaciones móviles con REMAUI. En Proc. 30ª Conferencia
Internacional IEEE / ACM sobre Ingeniería de Software Automatizada (ASE) (ASE'15). IEEE,
248ś259.
[37] Thomas Ostrand, Aaron Anodide, Herbert Foster y Tarak Goradia.
1998. Un entorno de desarrollo de pruebas visuales para sistemas GUI. En
Actas del Simposio Internacional ACM SIGSOFT de 1998 sobre Análisis y Pruebas de
Software (ISSTA '98). ACM, 82ś92. https://doi.org/
10.1145 / 271771.271793
[38] Jason Pamental. 2014. AMore Modern Scale forWeb Typography. http:
//typecast.com/blog/a-more-modern-scale-for-web-typography
PLDI'18, 18 y 22 de junio de 2018, Filadelfia, PA, EE. UU.
[39] Pavel Panchekha y Emina Torlak. 2016. Razonamiento automatizado
para el diseño de páginas web. En Actas de la Conferencia Internacional ACM SIGPLAN
2016 sobre Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones
(OOPSLA 2016). ACM, 181ś194. https: //doi.org/10.1145/2983990.2984010
[40] Parasoft. 2017. Pruebas de interfaz de usuario web. https://www.parasoft.com/capability/
web-ui-testing /
[41] Pearson. 2017. Haciendo accesible el aprendizaje electrónico. http: //wps.pearsoned.
com / accesibilidad /
[42] Proyecto de código abierto de Android. 2017. Descripción general de la interfaz de usuario. https: // desarrollador.
android.com/guide/topics/ui/overview.html
[43] Murray Rowan, Peter Gregor, David Sloan y Paul Booth. 2000. Evalu
Recursos web para el acceso de discapacitados. En Actas de la Cuarta Conferencia
Internacional ACM sobre Tecnologías de Asistencia (Activos '00).
ACM, 80ś84. https://doi.org/10.1145/354324.354346
[44] Shauvik Roy Choudhary, Husayn Versee y Alessandro Orso. 2010.
WEBDIFF: Identificación automatizada de problemas entre navegadores en aplicaciones web. En Actas
de la Conferencia Internacional IEEE 2010 sobre Mantenimiento de Software (ICSM '10). Sociedad
de Informática IEEE, 1ś10.
https://doi.org/10.1109/ICSM.2010.5609723
[45] Manolis Savva, Nicholas Kong, Arti Chhajta, Li Fei-Fei, Maneesh
Agrawala y Jeffrey Heer. 2011. ReVision: Clasificación, Análisis y Rediseño Automatizados
de Imágenes Gráficas. En Actas del 24º Simposio anual de ACM sobre tecnología y
software de interfaz de usuario (UIST '11). ACM, 393ś402. https://doi.org/10.1145/2047196.2047247
[46] Terry Sullivan y RebeccaMatson. 2000. Barreras de uso: usabilidad y
Accesibilidad al contenido en los sitios más populares de la Web. En Actas de la Conferencia de
2000 sobre usabilidad universal (CUU '00). ACM, 139ś144.
https://doi.org/10.1145/355460.355549
[47] Ivan E. Sutherland. 1964. Cuaderno de bocetos, una empresa gráfica hombre-máquina
Sistema de comunicación. En Actas del Taller de Automatización de Diseño SHARE (DAC
'64). ACM, 6.329ś6.346. https://doi.org/10.1145/800265. 810742
[48] Anthony T. 2012. Diseño amigable para los dedos: toque móvil ideal
tamaños de destino de pantalla. https://www.smashingmagazine.com/2012/02/
tamaño-objetivo-de-pantalla-táctil-móvil-ideal-diseño-amigable para los dedos /
[49] Departamento de Justicia de los Estados Unidos. 2010. Aviso anticipado del Departamento de Justicia de la propuesta
Reglamentación, RIN 1190-AA61. https://www.ada.gov/anprm2010/web%
20anprm_2010.htm
[50] DOJ de EE. UU. 2017. Kit de herramientas de mejores prácticas de la ADA para gobiernos estatales y locales
Ernments. https://www.ada.gov/pcatoolkit/chap5toolkit.htm
[51] Christopher J. van Wyk. 1982. Un lenguaje de alto nivel para especificar
Imágenes. ACM Trans. Grafico. 1, 2 (abril de 1982), 163ś182. https: // doi.
14
P. Panchekha, AT Geller, MD Ernst, Z. Tatlock y S. Kamil
org / 10.1145 / 357299.357303
[52] Minh N. Vu y Susan Ryan. [Dakota del Norte]. 2017 Web-
Site Resumen de la demanda de accesibilidad: Un año difícil para las empresas.
https://www.adatitleiii.com/2018/01/
2017-recapitulación-de-demanda-de-accesibilidad-del-sitio-web-un-año-difícil-para-las-empresas /
[53] W3C. 2008. Pautas de accesibilidad al contenido web 2.0. https: // www.
w3.org/TR/WCAG/
[54] W3C. 2011. Hojas de estilo en cascada Nivel 2 Revisión 1 (CSS 2.1) Especificación
ficación. https://www.w3.org/TR/2011/REC-CSS2-20110607/
[55] W3C. 2016. Descripción general de WAI-ARIA. https://www.w3.org/WAI/intro/aria
[56] W3Schools. 2017. Desplegables CSS. https://www.w3schools.com/css/
css_dropdowns.asp
[57] Thomas A. Walsh, Gregory M. Kapfhammer y Phil McMinn. 2017.
Detección automatizada de fallas de diseño para páginas web receptivas sin un Oracle
explícito. En Actas del 26 ° Simposio Internacional ACM SIGSOFT sobre Análisis y
Pruebas de Software (ISSTA 2017). ACM, 192ś202. https://doi.org/10.1145/3092703.3092712
[58] TA Walsh, P. McMinn y GM Kapfhammer. 2015. Automático
Detección de posibles errores de diseño después de cambios en páginas web receptivas (N).
En 2015 30a Conferencia Internacional IEEE / ACM sobre
Ingeniería de software automatizada (ASE). 709ś714. https://doi.org/10. 1109 / ASE.2015.31
[59] Pruebas de plataforma web. 2017. panel de pruebas de plataforma web,
WPT / css / CSS2 / flotadores. https://wptdashboard.appspot.com/css/
CSS2 / flotadores
[60] WebAIM. 2017. Herramienta de accesibilidad web WAVE. http: //wave.webaim.
org /
[61] Hadley Wickham. 2009. ggplot2: Gráficos elegantes para análisis de datos.
Springer-Verlag Nueva York, Nueva York, Nueva York, Estados Unidos. http: // ggplot2. org
[62] Leland Wilkinson. 2005. La gramática de los gráficos (estadística y
Informática). Springer-Verlag New York, Inc., Secaucus, NJ, EE. UU.
[63] Qing Xie y Atif M. Memon. 2007. Designing and Comparing Au-
oráculos de prueba creados para aplicaciones de software basadas en GUI. ACM Trans. Softw. Ing.
Methodol. 16, 1, artículo 4 (febrero de 2007), 38 páginas.
https://doi.org/10.1145/1189748.1189752
[64] Brad Vander Zanden y Brad A. Myers. 1991. The Lapidary Graphical
Herramienta de diseño de interfaz. En Actas de la Conferencia SIGCHI sobre factores humanos
en sistemas informáticos (CHI '91). ACM, 465ś466. https: //doi.org/10.1145/108844.109005