3,730 research outputs found

    Automated Repair of Layout Cross Browser Issues Using Search-Based Techniques

    Get PDF
    A consistent cross-browser user experience is crucial for the success of a website. Layout Cross Browser Issues (XBIs) can severely undermine a website’s success by causing web pages to render incorrectly in certain browsers, thereby negatively impacting users’ impression of the quality and services that the web page delivers. Existing Cross Browser Testing (XBT) techniques can only detect XBIs in websites. Repairing them is, hitherto, a manual task that is labor intensive and requires significant expertise. Addressing this concern, our paper proposes a technique for automatically repairing layout XBIs in websites using guided search-based techniques. Our empirical evaluation showed that our approach was able to successfully fix 86% of layout XBIs reported for 15 different web pages studied, thereby improving their cross-browser consistency

    XFix: An Automated Tool for the Repair of Layout Cross Browser Issues

    Get PDF
    Differences in the rendering of a website across different browsers can cause inconsistencies in its appearance and usability, resulting in Layout Cross Browser Issues (XBIs). Such XBIs can negatively impact the functionality of a website as well as users’ impressions of its trustworthiness and reliability. Existing techniques can only detect XBIs, and therefore require developers to manually perform the labor intensive task of repair. In this demo paper we introduce our tool, XFix, that automatically repairs layout XBIs in web applications. To the best of our knowledge, XFix is the first automated technique for generating XBI repairs

    R2WEB: repairing and evaluating rich web applications accessibility

    Get PDF
    Tese de mestrado em Engenharia Informática (Sistemas de Informação), apresentada à Universidade de Lisboa, através da Faculdade de Ciências, 2013QualWeb is an existing tool that evaluates Web pages’ compliance with WCAG 2.0 HTML techniques. We wanted to enhance this tool’s functions by adding a CSS module. For this we intend to create a CSS module, to extend the evaluation process, so that it evaluates HTML and stylesheets, but also to present the user solutions for every evaluation problem. In this report we present the different development stages that our CSS evaluation and repair module went through. We describe how we interpreted the WCAG 2.0 techniques and how we turned them into code; how we processed every CSS rule in a .html document and how we established the connection between the different HTML elements and their CSS rule; how we build the repair process itself and how we managed to present it in an online user interface. One of this stages includes an experimental study where we presented to a set of twenty Web developers, with different levels of HTML knowledge, our developments in order to obtain some feedback on how we were doing. In the corresponding chapter we describe our study and show how presenting repair suggestions for accessibility problems, helps users feel less lost and more self-assured when using our tool. These findings will build ground for a future complete repair module for QualWeb and open way for further enhancements of this Web Accessibility evaluation tool.A Web é hoje em dia a plataforma mais utilizadas para partilha de conhecimento e divulgação de serviços. A sua crescente importância nota-se aos mais diferentes níveis da nossa sociedade. Universidades, governos, empresas e outras entidades todas aproveitam da facilidade de chegar ao destinatário através da Web. No entanto, o problema surge dado o facto de que nem todos aqueles, a quem este conhecimento e estes serviços se destinam, têm as mesmas capacidades, cognitivas ou físicas. Grupos sociais de indivíduos com dificuldades cognitivas e físicas acabam por ficar à margem destas potencialidades da Web. Apesar de existirem já inúmeras tecnologias de ajuda para estas pessoas, como leitores de ecrã, etc., para que estas funcionem corretamente, é necessário que a informação seja disponibilizada adequadamente formatada. De forma a colmatar estas e outras situações existe a necessidade de normas cujo objectivo seja estandardizar conteúdos desenvolvidos para a Web. A acessibilidade Web é uma preocupação da qual surgem os princípios de inclusão social. E graças à qual, inúmera documentação e tecnologias, têm surgido de forma a colmatar este problema. Entre elas, tecnologias automáticas de avaliação e até de reparação de Acessibilidade Web. Contudo, muitas dessas tecnologias ainda não conseguem colmatar dificuldades que surgem do desenvolvimentos tecnológico da Web. Novas tecnologias, como Javascript, tornam os conteúdos Web em mais do que simples apresentações de texto. Conteúdos Web passam a ser dinâmicos, graças à execução ao de chamadas aos servidores, paralelas à apresentação das páginas Web. Estas interações com o servidor permitem a alteração dos conteúdo nas páginas Web. A avaliação da acessibilidade destes novos conteúdos dinâmicos, não pode ser verificada utilizando os mesmos padrões usados até agora. Caso isto aconteça estes avaliadores de conteúdos estáticos, podem levar a conclusões incompletas que podem mesmo ser incorretas. A ferramenta QualWeb é uma ferramenta de avaliação de Acessibilidade Web. No entanto, ao contrário das mencionadas anteriormente, recorrendo a tecnologias recentes, esta ferramenta permite avaliar aplicações Web dinâmicas. Avaliações de acessibilidade realizadas por esta ferramenta seguem normas internacionais WCAG 2.0 graças à implementação de um modulo de técnicas HTML. No entanto existe ainda espaço para expandir o âmbito desta ferramenta. As normas WCAG 2.0 englobam não apenas o HTML mas também um conjunto de outras tecnologias de entre as quais o CSS. Sendo que, com o crescimento da Web e da quantidade de conteúdos disponíveis online, maior atenção tem sido atribuída à utilização de estilos que possibilitam aos developers desenvolver conteúdos mais apelativos. Por este motivo a sua utilização tem aumentado e os CSS são hoje em dia, considerados como uma das tecnologias mais importantes para a Web. Data esta importância, este trabalho pretende expandir o funcionamento de ferramenta QualWeb, introduzindo lhe novas capacidades anívels dos CSS. Para isso incluímos um módulo de avaliação e reparação de CSS. Esta avaliação, tal como a já existente avaliação de HTML, segue as t´técnicas CSS WCAG 2.0. Não só nos preocupámos em manter a modularidade da ferramenta, mas também nos preocupámos em torna-la ainda mais flexível. As avaliações de HTML seguiam uma determinada forma de execução¸ ao de comprometia a flexibilidade da apresentação de resultados ao developer. Foi por este motivo que decidimos também alterar a perspectiva de apresentação dos resultados,. Esperamos assim melhorar o workflow do developer bem como, a sua experiencia com a nossa ferramenta. Considerando que a complexidade das páginaWeb tem vindo a aumentar, o tempo que um developer poderá eventualmente despender, analisando os seus conteúdos, segundo padrões de acessibilidade, pode ser considerável. De forma a mantermos os developers interessados nestes temas, sem que considerem estas verificações cansativas, é importante tornar a sua experiencia tao simples quando possível. é com este objectivo que surgem ferramentas de reparação de acessibilidade. No entanto, se já as avaliações de acessibilidade podem ser algo ambíguas, esta situação agrava-se na reparação. Reparar uma página Web requer um conhecimento relativamente da página bem como uma visão geral que muitas vezes as ferramentas automáticas não possuem. Por este motivo o que propomos neste trabalho são sugestões de reparação, apresentadas ao developer, de forma a que a ferramenta de forneça toda a informação necessária para reparar a acessibilidade dos seus conteúdos. Neste trabalho procedemos ao desenvolvimento de um módulo de reparação para as técnicas CSS desenvolvidas. O objectivo é acima de tudo, mostrar ao developer que pode tornar as suas páginas mais acessíveis, educando-o sobre como o fazer e despoletando o seu interesse explicando também porque o deve fazer. De forma a que toda esta informação possa ser divulgada, é necessário melhorar a interface da ferramenta QualWeb, desenvolvida paralelamente a este projecto. Desenvolveuse paralelamente a este trabalho uma interface para esta ferramenta, no entanto esta interface tem como objectivo apresentar uma versão anterior do QualWeb. De forma a conseguir disponibilizar todos os conteúdos desenvolvidos foi necessário melhorar essa interface introduzindo lhe novas funcionalidades. Todas estas componentes desenvolvidos, foram verificadas através de um corpus de teste. Para a avaliação desenvolvemos testes individuais, por técnica, e globais que simulavam a complexidade de uma páginaWeb real. Para a reparação, procedemos a reparação de algumas das mais utilizadas páginas Web, o que nos permitiu fazer uma analise critica às nossas implementações. Por fim, de forma a validar a interface e as reparações, procedemos a testes com utilizadores. Estes testes foram cruciais para o refinamento da nossa ferramenta, bem como para obtermos algumas conclusões interessantes no nosso trabalho. No final, conseguimos, como pretendíamos, melhorar a ferramenta QualWeb, tornando a ainda mais competitiva nesta área. Conseguimos também validar toda a implementação realizada dos diferentes componentes e tirámos conclusões bastante interessantes. Nomeadamente que o conhecimento de ferramentas deste género, a nível de estudantes de universidade não é muito elevado e que estas ferramentas podem desempenhar um papel interessante para alterar esta situação. Este trabalho ajudou também a pavimentar caminho para novas melhorias desta ferramenta de avaliação de Acessibilidade Web

    Automated repair of internationalization presentation failures in web pages using style similarity clustering and search-based techniques

    Get PDF
    Internationalization enables companies to reach a global audience by adapting their websites to locale specific language and content. However, such translations can often introduce Internationalization Presentation Failures (IPFs) - distortions in the intended appearance of a website. It is challenging for developers to design websites that can inherently adapt to varying lengths of text from different languages. Debugging and repairing IPFs is complicated by the large number of HTML elements and CSS properties that define a web page's appearance. Tool support is also limited as existing techniques can only detect IPFs, with the repair remaining a labor intensive manual task. To address this problem, we propose a search-based technique for automatically repairing IPFs in web applications. Our empirical evaluation showed that our approach was able to successfully resolve 98% of the reported IPFs for 23 real-world web pages. In a user study, participants rated the visual quality of our fixes significantly higher than the unfixed versions

    Automated repair of mobile friendly problems in web pages

    Get PDF
    Mobile devices have become a primary means of accessing the Internet. Unfortunately, many websites are not designed to be mobile friendly. This results in problems such as unreadable text, cluttered navigation, and content overflowing a device's viewport; all of which can lead to a frustrating and poor user experience. Existing techniques are limited in helping developers repair these mobile friendly problems. To address this limitation of prior work, we designed a novel automated approach for repairing mobile friendly problems in web pages. Our empirical evaluation showed that our approach was able to successfully resolve mobile friendly problems in 95% of the evaluation subjects. In a user study, participants preferred our repaired versions of the subjects and also considered the repaired pages to be more readable than the originals

    Automated and Context-Aware Repair of Color-Related Accessibility Issues for Android Apps

    Full text link
    Approximately 15% of the world's population is suffering from various disabilities or impairments. However, many mobile UX designers and developers disregard the significance of accessibility for those with disabilities when developing apps. A large number of studies and some effective tools for detecting accessibility issues have been conducted and proposed to mitigate such a severe problem. However, compared with detection, the repair work is obviously falling behind. Especially for the color-related accessibility issues, which is one of the top issues in apps with a greatly negative impact on vision and user experience. Apps with such issues are difficult to use for people with low vision and the elderly. Unfortunately, such an issue type cannot be directly fixed by existing repair techniques. To this end, we propose Iris, an automated and context-aware repair method to fix the color-related accessibility issues (i.e., the text contrast issues and the image contrast issues) for apps. By leveraging a novel context-aware technique that resolves the optimal colors and a vital phase of attribute-to-repair localization, Iris not only repairs the color contrast issues but also guarantees the consistency of the design style between the original UI page and repaired UI page. Our experiments unveiled that Iris can achieve a 91.38% repair success rate with high effectiveness and efficiency. The usefulness of Iris has also been evaluated by a user study with a high satisfaction rate as well as developers' positive feedback. 9 of 40 submitted pull requests on GitHub repositories have been accepted and merged into the projects by app developers, and another 4 developers are actively discussing with us for further repair. Iris is publicly available to facilitate this new research direction.Comment: 11 pages plus 2 additional pages for reference

    EWA - Evaluating web accessibility

    Get PDF
    Tese de mestrado em Engenharia Informática (Sistemas de Informação), apresentada à Universidade de Lisboa, através da Faculdade de Ciências, 2011A Web, como uma plataforma aberta para a produção e consumo de informação, é usada por vários tipos de pessoas, algumas com determinadas incapacidades. Os sítios Web devem ser desenvolvidos tendo em conta que a informação deve ser compreendida por todos, isto é, deve ser acessível. Para analisar se uma determinada páginaWeb é acessível, é necessário inspeccionar as suas tecnologias de front-end (por exemplo: HTML, CSS, Javascript) esta inspecção pode ser feita de acordo com regras específicas. Um processo de avaliação interessante diz respeito à utilização de ferramentas de acessibilidade que automaticamente inspeccionam uma página Web. A avaliação automática de acessibilidade pode ocorrer em vários ambientes de execução e pode ser realizada em HTML original ou transformado. O HTML original é o documento HTML inicial derivado do pedido HTTP. O HTML transformado resulta da aplicação das tecnologias de front-end no HTML original, como realizado pelo CSS e pelo Javascript/Ajax. Isto pode alterar substancialmente a estrutura do conteúdo, apresentação e capacidade de interacção propiciada por uma determinada página Web. Esta distinção entre as versões do HTML original e transformado de uma página Web é fundamental, porque é o HTML transformado que é apresentado e com que os utilizadores interagem no Web browser. Os processos existentes de avaliação automática, como os apresentados em [35, 34,37], normalmente ocorrem no HTML original. Desta forma, as conclusões sobre a qualidade da acessibilidade de uma página Web podem estar erradas ou incompletas. Neste trabalho realizou-se uma framework de avaliação de acessibilidade Web em diferentes ambientes, com o objectivo de compreender as suas semelhanças e diferenças a nível de acessibilidade. A arquitectura da framework de avaliação consiste em quatro principais componentes: Execution Environments, QualWeb evaluator, Techniques e Formatters. O QualWeb evaluator é responsável por realizar a avaliação da acessibilidade na páginaWeb usando os recursos fornecidos pelo componente das Techniques, que usa o componente Formatters para adequar os resultados em formatos de serialização específicos, tais como relatórios de erros. O QualWeb evaluator pode também ser usado independentemente dos vários em diferentes ambientes de execução (Execution Environments) Os Execution Environments são responsáveis pela transformação do documento HTML de uma página Web na sua representação equivalente numa árvore HTML DOM. O componente Techniques contém as técnicas de avaliação do front-end, optando-se por usar W3C WCAG 2.0 [17], porque é um dos mais importantes padrões de acessibilidade. A arquitectura foi pensada de forma a permitir a serialização dos resultados da avaliação em qualquer formato. Assim, as bibliotecas de formatação estão contidas dentro do componente Formatters. Foi utilizada a serialização EARL [9], porque é um formato padrão para relatórios de acessibilidade. Os resultados obtidos podem ser interpretados por qualquer ferramenta que use este formato, permitindo comparar os resultados desta ferramenta com os de outras. A qualquer altura pode ser adicionado outro tipo de formatação nos Formatters (por exemplo, relatórios em PDF). O componente Execution Environments representa os vários ambientes de execução e foram usados dois tipos: o Command Line e o Browser. O Command Line é o equivalente ao ambiente de execução normalmente utilizado para realização de testes automáticos, ou seja, o ambiente que fornece o HTML original. O Browser é o ambiente de exevuçao onde o HTML usado é o transformado. A arquitectura foi desenvolvida de forma a ser flexível e modular, sendo possível a qualquer momento a adição um novo módulo dentro dos componentes principais. Por exemplo: adição de um novo ambiente de execução, ou outro tipo de técnicas. Para se conseguir avaliar da mesma forma os ambientes de execução, a implementação foi realizada na linguagem de programação Javascript, porque é facilmente suportada nos dois ambientes. Esta implementação permite o estudo comparativo das diferenças da avaliação da acessibilidade Web em ambos. Foi também desenvolvida uma bateria de testes para se validar de forma sistemática as técnicas implementadas nos dois ambientes. Desta forma, os resultados obtidos para cada técnica foram validados, antes de o avaliador ser utilizado para testes mais complexos. Garantindo que os resultados obtidos posteriormente estariam correctos. Finalmente, foi realizado um estudo para se perceber se era realmente mais vantajosa a realização de avaliações de acessibilidade sobre o documento HTML transformado, em vez de no original. Foi avaliado um conjunto de páginas Web nos dos ambientes implementados. Com a comparação dos resultados obtidos nos dois ambientes conclui-se: que são detectados muito mais elementos no Browser e com isso conseguem-se obter mais resultados de acessibilidade neste ambiente; e que há uma diferença muito significativa na estrutura do HTML transformado e original. Pode assim afirmar-se, que há uma maisvalia significativa na realização deste tipo de avaliação de acessibilidade no Browser. No entanto, é importante considerar que as páginas Web são frequentemente compostas por templates. Os templates são adoptados para manter a uniformidade de distribuição, para tentar melhorar a navegação dos sítios Web e para manter objectivos das marcas. Hoje em dia, o desenvolvimento da Web é muito centrado na utilização de templates para facilitar a coerência, a implementação e a manutenção de recursos de um sítio Web. Foi determinado que 40-50% do conteúdo daWeb são templates [23]. Apesar desta ampla utilização de templates, as avaliações de acessibilidade avaliam as páginas como um todo, não procurando similaridades que se verificam devido à utilização dos templates. Esta forma de avaliação das páginas com um todo, faz com que os verdadeiros resultados de acessibilidade fiquem diluídos no meio de um grande número de resultados repetidos. Contudo, os templates podem ser uma mais-valia para que faz um sítioWeb, não sendo necessário corrigir o mesmo erro várias vezes, basta corrigi-lo uma vez que o próprio template propaga essa correcção por todo o sítio Web. Realizou-se por isso um algoritmo de detecção de templates, utilizando como base um algoritmo de detecção de matching já existente [14]. Este algoritmo detecta similaridades entre duas árvores HTML DOM. Para se perceber concretamente as semelhanças nos elementos HTML entre as páginas Web, efectuou-se um estudo para detecção dos templates em vários sítios Web. O processo utilizado consistiu nos seguintes passos: 1) detectar os templates entre várias páginas do mesmo sítio Web; 2) proceder à avaliação das páginas usando o nosso avaliador definido no inicio do trabalho; e finalmente, 3) separar os ficheiros EARL obtidos em dois ficheiros, um que continha a parte comum entre duas páginas e outro que continha a parte especifica, template set e specific set, respectivamente. Desta forma, determinou-se que aproximadamente 39% dos resultados de acessibilidade foram verificados nos templates. É uma percentagem bastante elevada de erros que pode ser corrigida de uma só vez. Com este trabalho foi então realizado: uma análise comparativa dos dois ambientes de execução; um algoritmo de detecção de templates que permitiu a criação de uma nova métrica de acessibilidade, que quantifica o trabalho necessário para reparar problemas de acessibilidade e que pode até ser utilizada como auxiliar de outras métricas; a arquitectura de um sistema de avaliação que pode ser executado em vários ambientes; um avaliador de acessibilidade Web baseado em WCAG 2.0, genérico o suficiente para permitir a utilização de quaisquer técnicas, formatadores ou ambientes de execução que se pretenda; e uma bateria de testes que permite a verificação dos resultados de acessibilidade da avaliação, de acordo com as técnicas escolhidas.The purpose of this work was to improve the automated Web accessibility evaluation, considering that: evaluation should target what the end users perceive and interact with; evaluation results should address accessibility problems in a focused, uncluttered, way; and results should reflect the quality adequately to the stakeholders. These considerations had the following goals: analyse the limitations of accessibility evaluation in two different execution environments; provide additional guidance to the developer in order to correct accessibility errors, that considers the use of templates in page development and avoid cluttering the relevant evaluation results; and define evaluation metrics that reflect more adequately the difficulty to repair Web sites’ problems. An accessibility evaluator, QualWeb, was implemented and it performs W3C WCAG 2.0 evaluations. Unlike most existing automatic evaluators, this approach performs evaluations on the HTML documents already processed, accessing content as presented to the user. The evaluator also allows the evaluation on unprocessed HTML documents, as traditionally done. The framework was designed to be flexible and modular, allowing easy addition of new components. The serialization chosen was EARL that can be interpreted by any tool understanding this standard format. To verify the correctness of the WCAG techniques implementation, a control test-bed of HTML documents was implemented, representing the most significant problems that should be detected. Results of the first experimental study confirmed that there are deep differences between the HTML DOM trees in the two types of evaluation. This shows that traditional evaluations do not present results coherent with what is presented to the users. It was also implemented a template detection algorithm allowing the adequate detailed and metric-based reporting of an accessibility evaluation. This form of reporting can be used by existing tools, which can become more helpful in producing accessibleWeb sites. Results from the second experimental study show that template-awareness may simplify assessment reporting, and approximately 39% of the results are reported at least twice, of which approximately 38% are errors that can be corrected once

    Web accessibility diagnosis, improvement and maintenance

    Get PDF
    Context: This thesis examines how organisations create and maintain their web pages with particular focus on ensuring pages are accessible. It also investigates the potential for using a Tree-Map based tool to support such web maintenance and process improvement. Novel process improvement recommendations are given and an adaptation of a class web publishing model is presented. Methods: To supplement a review of current literature, 20 accessibility specialists and 79 large organisations were surveyed. This identified web accessibility best practices and whether these practices were implemented in the reality. A subsequent assessment of the accessibility of each organisation's web site tested if certain activities could be linked with better accessibility. Finally, a controlled experiment tested the accuracy and efficiency of a Tree-map based tool for web maintenance. Results: The survey results suggested a wide variety of web accessibility awareness amongst web developers and accessibility specialists. Best practice appeared to be implemented by many organisations with the exception of training provision. It was found that when the best practices aimed specifically at web accessibility were implemented there was a significant improvement in web accessibility. The Tree-Map based tool was proved to be more efficient than and as accurate as report based tool for web maintenance activities. Conclusions of the study: Web accessibility awareness is now reasonably high amongst web developers but the extent to which it is addressed varies. Organisations which take a systematic and mature approach to accessibility have more accessible web sites. As such, accessibility should be integrated into web publishing. Better tools are also required to facilitate this systematic integratio

    Automatically identifying potential regressions in the layout of responsive web pages

    Get PDF
    Providing a good user experience on the ever-increasing number and variety of devices being used to browse the web is a difficult, yet critical, task. With Responsive Web Design (RWD), front-end web developers design web pages so that they dynamically resize and rearrange content to best fit the dimensions of a device’s screen. However, when making code modifications to a responsive page, developers can easily introduce regressions from the correct layout that have detrimental effects at unpredictable screen sizes. For instance, the source code change that a developer makes to improve the layout at one screen size may obscure a page’s content at other sizes. Current approaches to testing are often insufficient because they rely on limited tools and error-prone manual inspections of a web page. As such, many unintended regressions in web page layout often go undetected and ultimately manifest in production web sites. To address the challenge of detecting regressions in responsive web pages, this paper presents an automated approach that extracts the responsive layout of two versions of a page and compares them, alerting developers to the differences in layout that they may wish to investigate further. We implemented the approach and empirically evaluated it on 15 real-world responsive web pages. Leveraging code mutations that a tool automatically injected into the pages as a systematic simulation of developer changes, the experiments show that the approach was highly effective. When compared with manual and automated baseline testing techniques, it detected 12.5% and 18.75% more injected changes, respectively. Along with identifying the best parameters for the method that extracts the responsive layout, the experiments show that the approach surpasses the baselines across changes that vary in their impact, but works particularly well for subtle, hard-to-detect mutants, showing the benefits of automatically identifying regressions in web page layout
    corecore