Study on Web Accessibility to help develop Assistive Technology for Visually Challenged People

Transcription

1 Study on Web Accessibility to help develop Assistive Technology for Visually Challenged People Student Name: Akash Aggarwal Roll Number: BTP report submitted in partial fulfillment of the requirements for the Degree of B.Tech. in Computer Science & Engineering on April 18, 2018 BTP Track: Research BTP Advisor Dr Vikram Goyal Indraprastha Institute of Information Technology New Delhi

2 Student s Declaration I hereby declare that the work presented in the report entitled Study on Web Accessibility to help develop Assistive Technology for Visually Challenged People submitted by me for the partial fulfillment of the requirements for the degree of Bachelor of Technology in Computer Science & Engineering at Indraprastha Institute of Information Technology, Delhi, is an authentic record of my work carried out under guidance of Dr Vikram Goyal. Due acknowledgements have been given in the report to all material used. This work has not been submitted anywhere else for the reward of any other degree.... Place & Date: Delhi, 18 April 2017 Akash Aggarwal Certificate This is to certify that the above statement made by the candidate is correct to the best of my knowledge.... Place & Date:... Dr Vikram Goyal 2

3 Abstract The goal is to study accessibility of web pages, specially those who have visual disabilities and finds it difficult to perceive, navigate and interact with the web. Most websites have some sort of accessibility barrier that makes it difficult for a person with a disability to use their site. Accessibility of web pages continues to remain a major challenge globally for both accessibility based web developers and researchers. Screen Readers do exist that allow blind people to hear what is sighted on a page. Still its of no use, if vast majority of web pages on Internet are inaccessible and if developers continue to build pages without keeping accessibility front in their mind. Effective classification of web pages as assistive and non-assistive pages can help improve the association of web elements with their accessibility guidelines and rules. Further using the syntactic structure used for performing the classification, it might be able to convert inaccessible web pages to better accessible pages. Further using the classification and similarity based model, we can avoid the limitation of the rule based model. A web chrome extension is developed for filling up the forms, only for the web pages which follow accessibility rules. The extension provides fully voice based speech generation and recognition and thus not require us to interact with web pages using mouse or keyboard. Keywords: Web Accessibility, Visual Disability, Web page classification, Assistive Technologies, Chrome Extension, Speech Recognition, Text to Speech

4 Acknowledgments I would like to express my special thanks to Vikram Sir who gave me this opportunity to work on this project and for the faith he has shown in me. I thank him for all the guidance and motivation he has provided me throughout my B.Tech Project. I also thank him for helping me doing lot of research on this project. I am grateful enough to my parents and my brother who have always supported me and provided me with lots of love and encouragement. Work Distribution Chapter 1 and 2: August to mid-october, 2017 Chapter 3.4.1: mid-october to November, 2017 Chapter 3.4.2: January to mid-march, 2018 Chapter 4: mid-march to April, 2018 i

5 Contents 1 Introduction Motivation Web Disability Web Accessibility WAI-ARIA Scope Support Rules and guidelines of WAI-ARIA ARIA Specification Assistive Technologies Working Accessibility Tools JAWS Screen Reader About JAWS JAWS Support for ARIA Roles JAWS Support for ARIA States JAWS Support for Document Region JAWS Support for Live Region Accessible Web Pages Importance of Web Accessibility Web Crawling Classification of Web Pages Making Websites Accessible Rule Based Model Similarity Based Model Results and Conclusion Voice based form filling extension 18 ii

6 5 Future Work 19 iii

7 Chapter 1 Introduction Of the 37 million people across the globe who are blind, over 15 million are from India. What s worse, 75% of these are cases of avoidable blindness. The number of regular computer and web users who are blind is also increasing year by year. Web accessibility involves making web content available to all. Making a website accessible goes well beyond providing access to the most obvious market, which is users with visual disabilities. Even though frameworks exists which provides the guidelines defining accessibility of web pages such as the roles, states and properties which should be present for each widget in html pages but still no one enforces them and still vast majority of pages on the web are inaccessible. Work has been done which describes how the developers and researchers should develop web pages so that assistive technologies could understand them and do their work without any hindrance but little to no research has been done which tells how to make inaccessible pages more accessible, to all. The work done here is new to this domain and exploits the pages on the web using a specially designed web parsing spider which starts crawling the web pages and classifies them. This paper first presents a unique technique to use web accessibility guidelines and rules to classify web pages in the terms of accessibility and using this classification methodology to generate a model which can be used to make web pages more accessible. This paper then presents a similarity based model to avoid the limitations of rule based model by generating features for accessibility nodes and finding a correlation with non-accessibility nodes to classify them as what type of accessible node could be assigned to it. Due to high similarity between the features of different accessibility nodes, it is concluded that accessibility nodes and non-accessibility nodes does not have any correlation. Thus, a web chrome extension is developed for visually challenged people using which they can fill forms using speech and the extension will assist you to follow up the form from top to bottom, thus interaction to web pages using mouse and keyboard would not be required any more. 1

8 1.1 Motivation Web access for users with disabilities is an important goal and challenging problem for web content developers and designers. Blind users require the use of screen reader to browse the internet. Screen readers process the content of the page and are thus able to read the visual content to the users. However, just reading the content of the page is not sufficient. Most of the usage on the web requires dynamic interaction of the users with the content on the web page such as filling out webbased forms, navigating from one region to another or changing states or properties of widgets such as selecting different option in radio button instead of the default. All of these requires that assistive technologies such as screen readers to be able to understand all the relation or association of web elements with each other. Thus despite the importance of web accessibilities, most sites remain partly or totally inaccessible. This need of making such inaccessible web pages more accessible for assistive technologies is the major motivation for this work. Finally, the aim was to built a supportive application which can help blind users interact with web pages easily, especially for filling up the forms and submitting the forms. 2

9 (a) Sight hindrance (b) Limited Hand Motion Figure 1.1: Web Disability 1.2 Web Disability We focused on two types of disabilities in which screen readers can help overcome those problems. Sight Hindrances or Visually Impaired: Site difficulties include mild vision to no vision where person is not able to look the content or text on the screen. They struggle figuring out letters or the words under the cursor and to move or scroll around the web pages. Figure 1.1a. Screen-readers and braille-keyboards are also great tools to help the visually impaired get the most of their web usage. Limited or involuntary hand motions: Web accessibility can be a major issue for those who cannot type. Browsing on web, chatting with friends, writing business s and many other tasks requires the ability to see and type or to point on web elements using mouse. Figure 1.1b. Advanced features like voice to speech recognition and vice-versa and eye-motion tracking are some ways around these troubles.certain popular voice assistant bots are there such as Siri, Cortana, Echo etc which helps in searching and looking for some information but still they can not help in doing majority of tasks which is possible on the web. 3

10 Chapter 2 Web Accessibility 2.1 WAI-ARIA WAI-ARIA is a technical specification that defines how to make web pages accessible, in particular, dynamic content and user interface components developed with Ajax, HTML and JavaScript. It describes how to add semantics and other metadata to HTML content in order to make user interface controls and dynamic content more accessible Scope Web developers increasingly use client-side scripts to create user interface controls that cannot be created with HTML alone. They also use client-side scripts to update sections of a page without requesting a completely new page from a web server. Such techniques on websites are called rich Internet applications. These user interface controls and content updates are often not accessible to users with disabilities, especially screen reader users and users who cannot use a mouse or other pointing device. WAI-ARIA allows web pages (or portions of pages) to declare themselves as applications rather than as static documents, by adding role, property, and state information to dynamic web applications. ARIA is intended for use by developers of web applications, web browsers, assistive technologies, and accessibility evaluation tools Support ARIA is a relatively new specification, but support for it is growing. A wide variety of commonlyused browsers, assistive technologies, JavaScript toolkits, and applications now support ARIA. However, many users may still be using older versions of these technologies. You may want to consider implementing ARIA using progressive enhancement techniquessuch as adding ARIA using JavaScript, not directly to your markupin order to more gracefully support older browsers and assistive technologies. 4

11 2.1.3 Rules and guidelines of WAI-ARIA Accessible Rich Internet Applications (WAI-ARIA) Version 1.0 This is primarily aimed at developers of Web browsers, assistive technologies, and other user agents, in addition to developers of other technical specifications, and developers of accessibility evaluation tools. The WAI-ARIA has been marked as completed on 20 March 2014 and is therefore a W3C recommendation WAI-ARIA Primer This is a technical introduction to WAI-ARIA. It describes the problems WAI-ARIA tries to address, the underlying concepts, the technical approach and business reasons for adopting WAI-ARIA. WAI-ARIA Best Practices This document describes best practices for delivering rich Internet applications with WAI- ARIA: it discusses subjects such as general steps for building accessible widgets, keyboard navigation, relationships, form properties, drag-and-drop support, alert and dialog boxes, reusable component libraries, and testing ARIA Specification ARIA consists of three different types of attributes: roles, states, and properties. Roles describe widgets that aren t otherwise available in HTML 4, such as sliders, menu bars, tabs, and dialogs. Properties describe characteristics of these widgets, such as if they are draggable, have a required element, or have a popup associated with them. States describe the current interaction state of an element, informing the assistive technology if it is busy, disabled, selected, or hidden. ARIA also provides features for dynamic presentational changes include using CSS to change the appearance of content (such as a red border around invalid data, or changing the background colour of a checked checkbox), as well as showing or hiding content. 5

12 Figure 2.1: Assistive Technology Model src: Assistive Technologies Working Assistive technologies use an API built into each operating system specifically designed to describe the roles, states, and structure of an application s user interface. Refer Figure 2.1. For example, a screen reader uses this API to read the user interface with a text-to-speech engine, a magnifier uses it to highlight important or active areas of the screen, and an onscreen keyboard might use it to provide the most efficient keyboard layout for a given context or UI control. Assitive technologies often access a page s DOM as well through this API in order to understand the semantics and attributes of the page. ARIA provides a bridge between the world of the DOM and the desktop. Browsers expose ARIAenabled elements to the assistive technology API as if they were native widgets. As a result, the user potentially gets a more consistent user experience, where dynamic JavaScript-driven widgets on the web are comparable to their equivalents on the desktop. 6

13 2.2.2 Accessibility Tools Assistive technologies are increasingly adopting ARIA. Some of them include: Assistive Technology Minimum Version for basic ARIA Minimum version for live region and alert support NVDA Not supported Orca TBD TBD VoiceOver OSX 10.5, ios 4 OS X 10.7 ios 5 JAWS 8 10 Window-Eyes 7 Not supported ZoomText TBD Not supported 2.3 JAWS Screen Reader About JAWS We chose JAWS, Job Access With Speech, which is the world s most popular screen reader, developed for computer users whose vision loss prevents them from seeing screen content or navigating with a mouse, for testing accessibility of the web pages. JAWS gathers information from the ARIA markup and the browsers API and presents it in a meaningful way to screen reader users JAWS Support for ARIA Roles JAWS support almost all ARIA Roles such as img, checkbox, alertdialog, button, combobox, grid, menu, menubar, menuitem, list, listbox, listitem, radio, radiogroup, tab, tablist and so on. The following is a list of recent addition of roles which JAWS recognizes: 7

14 Role alert dialog document group heading Note Scrollbar toolbar tooltip Comments Its contents are spoken by JAWS when an alert is made visible. This role will be announced only when a child of the dialog gets focus, and will not appear in the virtual buffer. It indicates that the area it occupies is meant to be read as a Web page. JAWS announce its name and description when entering the group. The aria-level gives the heading level JAWS inserts start and end strings into the virtual buffer to indicate notes. Uses the aria-orientation to determine the type of scroll bar This role is indicated in the virtual buffer by start and end messages like those that exist for HTML lists. its contents are spoken when it becomes visible JAWS Support for ARIA States The following is a list of states which JAWS recognizes: States aria-activedescendant aria-busy aria-disabled aria-expanded aria-haspopup aria-invalid aria-invalid aria-pressed Comments JAWS uses this state to locate the focused items in tree views, list boxes, and other such controls that manage multiple, focusable children. An element marked as aria-busy is omitted from the accessibility tree for the page. JAWS announces this state for form controls. JAWS announces this state when in Forms Mode in tree controls. JAWS announces this state for any control except buttons and combo boxes which pops up a menu. JAWS announces this state for form controls. JAWS announces this state for form controls. JAWS announces the pressed state of a toggle button. Other important ARIA states that JAWS can control are aria-checked, aria-describedby, ariahidden, aria-level, aria-multiline, aria-orientation, aria-readonly, aria-selected and more. 8

15 2.3.4 JAWS Support for Document Region JAWS announces the type and text of document regions, and provides navigation to the next and previous document region on the page using the SEMICOLON and SHIFT+SEMICOLON Navigation Quick Keys. This includes all the ARIA landmark regions along with several other region types roles such as application, article, banner, contentinfo, document, form, navigation and region JAWS Support for Live Region JAWS supports use of the aria-live attribute and any of its acceptable values: polite, assertive, or off which helps in defining dynamic properties inside the web pages. JAWS also supports the ARIA drag-and-drop properties aria-grabbed and aria-dropeffect. When a Web page author applies these properties to objects on a Web page, JAWS will identify such objects as grabbable, grabbed, or droppable. 9

16 Chapter 3 Accessible Web Pages 3.1 Importance of Web Accessibility Examples of screen readers using web page components that do and do not make use of WAI- ARIA can be a good resource for why ARIA is important to accessibility. Thus example demos were developed where web pages were created which does different functionalities both using ARIA properties and without using ARIA properties. JAWS Screen reader was used to compare and test how it was able to access ARIA web pages more efficiently as compared to inaccessible pages. Examples for demonstrating behaviour of screen readers on below ARIA elements were created: aria form dialog datepicker aria footer aria top menu bubble dialog carousel close dynamic controls live region menu tab panel tooltip alert collapsibls dropdowns radio buttons After testing with JAWS for inaccessible pages, it was observed that JAWS did not notice the HTML elements as expected. They all behaved like those elements were simple DIV and just read the web page accordingly from top to bottom. Comparing this to its counterpart that is accessible pages, ARIA enabled web pages were much better and it showed that ARIA is doing wonders as JAWS was able to speak all the landmarks and was able to make the browser navigate actively over the web pages. It was also able to notify the user about the changes that were appearing on the web pages dynamically if live regions were enabled for that section. 10

17 Figure 3.1: Web Crawling and Classification based on Accessibility 3.2 Web Crawling We used Scrapy, a Python framework for large scale web scraping, to crawl the web pages and extract the HTML content and process that content to classify it as either an accessible web page or non-accessible web page. The whole point of using scrapy was to use its spider to detect and traverse links to other pages and grab data from those pages too. We started from some URLs which we manually selected as accessible pages and then used finding and following technique of scrapy spider to generate a data-set of 24,613 web pages. 3.3 Classification of Web Pages To classify the data-set of web pages into two categories: accessible and non-accessible, we defined rules based on the conformance of the website to the accessibility guidelines as mentioned in the Section We parse the content of each web page to search for the presence of ARIA and accessible elements which if resulted as true, is then classified as an accessible web page. Figure 3.1. Our classification result reported 8915 partially accessible web pages and rest as inaccessible web pages with not even a single rule which resulted positive on the whole web page. 11

18 Figure 3.2: Making Websites Accessible 3.4 Making Websites Accessible Rule Based Model To test whether inaccessible pages can be converted to pages with better accessibility, we partitioned the set of accessible pages which was generated in the previous step further into two sets: 70% of the pages as training set and remaining 30% of the web pages for testing. In the traing phase, XPath was used to generate vector set for each ARIA attribute where a vector describes the feature set for that ARIA attribute. Feature set is the set all the the syntactic structure of all the training web page under which condition that particular attribute was present. In the testing phase, all those attributes were removed from each web page in testing set, for which vector set has been generated in the training phase. Since our aim is to make web pages accessible, so in the validation phase, using the vector set generated in the training phase, we automatically filled all the places in modified test web pages with an ARIA attribute, if the syntactic structure at any region of the web page content matches with any syntactic structure of that particular ARIA attribute. Figure

19 3.4.2 Similarity Based Model Figure 3.3: Feature Dataset Generation From accessibility guidelines rules, we observed that each accessibility role is associated with the same set of states and properties. For example, aria-checked property can only be used with role option. Every ARIA properties and states can be used with supported roles only. Thus if we can determine the type of role of an HTML node, it will be possible to insert the corresponding states and properties in it. We used scrapy to expand our data-set further to contain CSS and Java content for all the HTML pages in our previous data-set. Thus, the data-set now consists of HTML, CSS and JAVA files for each web link crawled. We generated a feature data-set containing N-grams, for N = 1 to 3, for each ARIA role. Figure 3.3. That is for each role, we find all the nodes containing that role in HTML, CSS and JAVA files of accessible web pages as a string. A valid ARIA node in the HTML is the node which contains the data starting from the tag which contains the role as an attribute within it and all the enclosing data within that tag. A valid ARIA node in the CSS is the node which consists of the smallest enclosing string between } and { and containing the role as the sub-string in that string. A valid ARIA node in the JAVA is the node which contains all the data of the function as a string where the string has that role as a sub-string. For each string representing a valid node, all non-html, non-css and non-java elements are removed, that is any non-programmatical textual data is removed. Then the string is split into words at every non-alphabetical positions. The set of N-grams, for N = 1 to 3, is saved as a feature data-set for that role. The feature data-set contains features for 49 roles which are - button, checkbox, dialog, link, log, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, slider, status, tab, tabpanel, textbox, timer, tooltip, switch, combobox, grid, listbox, menu, menubar, tablist, tree, article, definition, directory, document, group, heading, img, list, listitem, math, note, presentation, region, separator, toolbar, application, banner, contentinfo, form, main, navigation and search. 13

20 Figure 3.4: Similarity Based Model As shown in Figure 3.4, for each Accessible page, we retrieved all the nodes which either contains a role as its tag or contain type, class or name field as its attribute and assigned the best suitable role to it. Thus a true label data-set is generated which is in a form of dictionary with key as the role and value as the tuple (i, j) where i is the web page id and j is the node which is assigned that role, that is the tuple here represents the web page and the position of the node which should have that role as a field. Cosine similarity is used to measure the similarity between the feature vector of a node in the page with the features of its role to which it was assigned. Here features of the role are the features which were generated from accessible pages. Here, cosine similarity measures the angle between two non zero vectors or the inner product space. We maintain the minimum cosine similarity till then for each role which will act as a threshold for cosine similarity for that role while comparing nodes later. 14

21 Also from Figure 3.4, for each Non-Accessible page, we associated an ARIA role for every candidate node in the page. A candidate node is the node which either contains a role as its tag or contain type, class or name field as its attribute. For each possible candidate node, its feature vector is generated that is a set of N-grams, for N = 1 to 3, is formed for the node, similarly in the way it was formed for generating the feature data-set. Again cosine similarity is used to measure the similarity between the feature vector of a node in the page with the features of each role and then the node is assigned to the role for which it got the maximum cosine similarity. Also the maximum cosine similarity should be greater the minimum cosine similarity threshold for that role to which it is being assigned otherwise it is assigned to none, that is no role to assign. Thus a predicted label data-set is also generated which is in a form of dictionary with key as the role and value as the tuple (i, j) where i is the web page id and j is the node which is assigned that role. Recall, precision and false positive rate is determined using the true label data-set and predicted label data-set. 15

22 3.5 Results and Conclusion Validation phase of our methodology resulted in huge fall-out that is false positive rate is high along with high recall that is sensitivity is also high. That is our technique was successfully able to place correct ARIA attribute at 87.23% of the actual position of the web pages from where these attributes were removed during testing phase. It was not able to place the ARIA attributes back to the remaining 12.77% of the positions from where they were removed in testing phase. Though the recall is high, but the trained model also placed ARIA attributes to an estimated 100x new positions for each html web page, where these attributes were not initially present before the testing phase. Thus the above results concludes that: Rule based model is not sufficient as it results in high false positive rate as well as high recall and thus a better context or hierarchical based model is required which takes into consideration the HTML DOM structure also and keeps tracks of the the widget/element from which the current widget/element is derived and the widget/element which lies within its structure. Quantitative measure of the amount of accessibility on a web page is also a big factor that must be considered while training accessibility model. That is even though we have classified web pages with some trace of accessibility while parsing as accessible page, still they are just partially accessible and accessibility has not been exploited properly on the whole page. High false negative rate suggest that the false positions where our model placed the ARIA attributes could actually suggest lack of accessibility at that position and that these false results could actually help developers to exploit more accessibility features at that position. Similarity model is used because it was observed from the data-set that wherever an aria role was present, the same node consists of fixed aria attributes and states, which concluded that ARIA states and properties can be associated with fixed roles. So if we could determine the role of a HTML node, corresponding ARIA attributes could be inserted to that node automatically. Any property which is not associated with a role but still present as an attribute is not functional. Table 3.1 represents dependency between some ARIA roles and states and properties which implicitly supports them. Using the similarity based model, we were successful in lowering the false positive rate to an average of 13.13% but our model also resulted in very low recall and precision that is we brought down the false positive rate at the cost of decreased F1-Score using the similarity based model. From Figure 3.5, low recall and precision in similarity based model shows that there is no correlation between the features of accessibility nodes and non-accessibility nodes. This is because of the high similarity between inter-features of each role, that is the training features in themselves 16

23 were having very high cosine similarity, which makes classification of non-accessibility nodes to ARIA roles, a mere random assignment. Role checkbox menuitemcheckbox radio tab gridcell button grid listbox menu tablist row combobox textbox option menuitemradio treeitem States and Properties ARIA-CHECKED ARIA-CHECKED ARIA-CHECKED ARIA-SELECTED ARIA-REQUIRED, ARIA-SELECTED, ARIA-READONLY ARIA-PRESSED, ARIA-EXPANDED ARIA-MULTISELECTABLE, ARIA-ACTIVEDESCENDANT, ARIA-READONLY ARIA-REQUIRED, ARIA-MULTISELECTABLE, ARIA-ACTIVEDESCENDANT ARIA-ACTIVEDESCENDANT ARIA-MULTISELECTABLE, ARIA-ACTIVEDESCENDANT ARIA-ACTIVEDESCENDANT, ARIA-SELECTED ARIA-REQUIRED, ARIA-ACTIVEDESCENDANT, ARIA-AUTOCOMPLETE ARIA-REQUIRED, ARIA-MULTILINE, ARIA-AUTOCOMPLETE, ARIA-READONLY ARIA-SELECTED, ARIA-CHECKED ARIA-SELECTED, ARIA-CHECKED ARIA-SELECTED, ARIA-CHECKED Table 3.1: Dependency Matrix Figure 3.5: Comparing results when model trained for ARIA nodes vs HTML nodes 17

24 Chapter 4 Voice based form filling extension We interact with web forms a lot in our day to day life, beginning from registering and logging in to Facebook page, Gmail page and many other websites, for filling out online application forms, online bookings as well as for exchanging information. Building conversational forms could be the next big revolution as people who do have some inabilities could also process forms simply by engaging in conversation. We developed a web chrome extension for form conversation using Scrapy and JavaScript. It is an interactive application which first ask user if a form on the page should be filled or not. If the response is Yes, it forms a collection of all text fields, fields, password fields, radio fields. For each text fields, fields and password fields, it speaks the aria-label attribute of the field if aria-attribute label is present, else it speaks the name attribute. Next, it expects a speech from the user which it recognizes and then it sets the text recognized as the value for the corresponding fields. The extension also supports speaking the word character by character for better accuracy of the final word. For each radio fields, first the script extracts all unique names of the radio field, so as to find what all radio groups are present. Then for each radio groups, all radio fields corresponding to that group is spoken one by one, and the application expects Yes to be spoken against the correct option, else No. Once user has spoken Yes, all remaining options are skipped, and the application moves to the next radio group. The radio fields must be in the label-for-input construct format. The script when once finish filling up the form element, ask the user if the form is to be submitted. If the response is Yes, the form is submitted else the script moves to filling up the next form on the page. 18

25 Chapter 5 Future Work For expanding this work, we hope to improve and modify the training model so as to improve recall but also a decline in fall-out rate. Research has to be carried out for appropriate evaluation techniques for further improving our testing techniques. We would also be interested in taking review from visually disabled people for better comparative analysis and review of rate of accessibility efficiency after applying accessibility enhancement model as compared to actual inaccessible pages. Improving voice based form filling application to better recognize the speech, handling synchronization problems and expanding support for more html form elements. 19

26 Bibliography aria examples/ gravano/papers/2002/deb02.pdf and properties 20