Main content (Site structure)
Mobile Web accessibility assessment Tool – MobileWaaT
Introduction & Information details for the MobileWaaT Tool
The MobileWaaT (see figure 1 below) is an integrated tool that provides to users the opportunity to evaluate the mobile Web adequacy and accessibility status of a preferable Web site, according to the MobileOk subset of the Mobile Web Best Practices (MWBP) defined by the W3C’s Mobile Web Initiative (MWI) and the Web Content Accessibility Guidelines (WCAG) developed by the Web Accessibility Initiative (MWI). The adopted evaluation framework allows users (developers, designers, testers, etc.) to perform a personalized mobile adequacy and accessibility assessments, though the selection of different accessibility constraints (e.g. different types of impairments and disabilities, different sets of guidelines, personas).
Figure 1: Screenshot of the MobileWaaT Program
As presented in figure 2, the ACCESSIBLE Mobile Web Assessment module consists of the following components:
- a. Mobile Web Accessibility Evaluator (MWA):This is the main component of the Mobile Web Accessibility assessment tool, where software applications can must be evaluated according to the mobile Web accessibility assessment standards (Mobile Web best practices and WCAG 2.0). The interconnection of this module with the Core Web assessment simulation module (which supports the WCAG 2.0 implementations) permits the accessibility evaluation of the Mobile Web applications
- b. Content negotiation/parsingmodule: This component is responsible for HTTP negotiation with Web servers, in order to obtain responses that are tailored to mobile devices, when available. With this outcome, an XML parser must transform the corresponding Web page into a machine-friendly memory structure (e.g., XML tree), for subsequent evaluation
Figure 2: Block diagram of the Mobile Web Assessment Module
Owner/Main Developer (including also key partners contribution)
FFCUL, FORTH (for the UI of the tool)
Intelectual property Rights (IPR issues, Licences)
MIT licence
Nature of the Code
Open source
Published Papers
- R. Bandeira, R. Lopes and L. Carriço.2010. Towards Mobile Web Accessibility Evaluation. Free and Open Source Software for Accessible Mainstream Applications (FOSS-AMA), colocated with ETAPS 2010, Paphos, Cyprus, 27-28 March 2010. 12 pages
- R. Lopes, L. Carriço. 2010. Macroscopic characterisations of Web accessibility. New Review of Hypermedia and Multimedia. Vol. 16, Iss. 3, 221-243.
- L. Carriço, R. Lopes, and R. Bandeira. 2011. Crosschecking the mobile web for people with visual impairments. In Proceedings of the International Cross-Disciplinary Conference on Web Accessibility (W4A '11). ACM, New York, NY, USA, Article 12 , 4 pages.
- N. Fernandes, R. Lopes, L. Carriço. 2012. Evaluating Web accessibility at different processing phases. New Review of Hypermedia and Multimedia. Taylor & Francis. 23 pages. (Available online on Taylor & Francis, Forthcoming in paper format).
Strengths and Weaknesses
| Strengths | Weaknesses |
|---|---|
|
|
Contribution to the state of the art
Mobile phone usage has been exploding all over the world With the decreasing costs on data plans, accessing the Web through these devices is quickly becoming more important to everyone. At the same time, the Web as a medium to convey information and services is being increasingly used by people with disabilities. Therefore it is paramount to understand the accessibility of mobile Web content, either in order to aid developers and designers to correct accessibility issues on mobile Web sites, or simply to provide hints to users if they are worth visiting.
The World WideWeb Consortium (W3C) has devised several guidelines (under the form of checklists) that can be used to assess the quality of Web pages in this context. Particularly relevant are the Web Content Accessibility Guidelines (WCAG) and the Mobile Web Best Practices (MWBP). Ideally, by following MWBP and WCAG, developers and designers should be able to create Web sites that are both usable on mobile phones, and accessible to users with disabilities.
Understanding the accessibility of mobile Web content for specific impairments implies taking into consideration the technological constraints of mobile devices and its use, as well as how these impose constraints on different disabilities. Considering the current recommendation, our goal is to find a coherent subset resulting from the integration of MWBP and WCAG guidelines that applies to a specific disability (for example as defined by ICF).
The ACCESSIBLE Harmonized Methodology (HAM) was primarily proposed as a framework for the integration of the WCAG and ICF, a concrete user disability classification.
Chuter & Yesilada studied the intersection of these two sets of guidelines, addressing its complexity, commonalities and differences and pointing recommendations for their practical application. However, particularly when the evaluation of existing Web sites is at stake – i.e., its worthiness for a user – a third dimension should be considered: the users’ specific impairments.
For example, disabling image loading on the browser precludes at least some MWBP checks. It is diosyncratic to classify a Web page as not adequate to a user’s mobile device because it contains large images, if the device does not load images. On the other hand, it should be a problem if it does not include textual alternatives. In a nutshell then,there must be a thorough scrutiny of the convergence of accessibility,mobile devices, and specific users’ impairments in a Web context.
The Mobile WaaT tool introduces for the first time the evaluation accessibility of Mobile Web content by the coherent merge of state of the art guidelines on Web accessibility and mobile best practices; and the usage of current and prospective practices particularly for people with specific disabilities and preferences.
Technical Testing Results from the developer and beneficiary validation
MobileWaaT tool has been tested in pilot tests with developers and beneficiaries and several important usability issues occurred. In the following table we outline the most important issues that were identified during the testing, and how they were addressed for the improvement of the tool.
| Issue description | Priority | Solved | Solution / Explanation |
|---|---|---|---|
| Accessibility reports are very complex, it's necessary to create a more navigable report. With this report, it is very difficult to know the accessible level of your application. | 1 | YES | The report generation module used by MobileWaaT was addressed by CERTH/ITI, within the scope of Waat. |
| Very difficult to understand pdf report. | 1 | YES | The report generation module used by MobileWaaT was addressed by CERTH/ITI, within the scope of Waat. |
| A slightly malformed URL and URI should be autocorrected or ignored, so I get the chance to correct my typo or detect a copy & paste procedure. | 1 | YES | Problem solved |
| Error the task was impossible to complete using the Accessible portal | 1 | YES | It was a problem in the portal, already solved by FORTH. |
| SoapException in ACCESSIBLE PORTAL. | 1 | YES | It was a problem in the portal, already solved by FORTH. |
| Null Reference Exception in ACCESSIBLE. | 1 | YES | It was a problem in the portal, already solved by FORTH. |
| There wasn't any deadlock, but I couldn't get the results due to a "Error reading the WCAG2" on the standalone | 1 | YES | It was a problem in the portal, already solved by FORTH. |
| Windows 7 jdk1.6.0_26, reports generation failed. | 1 | YES | Problem solved |
| The response time has to be improved. | 1 | YES | Quick assessment options were introduced by FORTH. |
| It's necessary to improve the quality of the reports. | 1 | YES | The report generation module used by MobileWaaT was addressed by CERTH/ITI, within the scope of Waat. |
| Portal slower due to project creation overhead. This may be an advantage for consecutive tests | 1 | YES | Quick assessment options were introduced by FORTH. |
| Standalone version always shows line number -1; score is not transparent in both versions. | 2 | YES | Problem solved |
| The initial settings are not reported on. This is useful for later usage. EARL reporting is differently presented, rather confusing. No colour codes are used, and reporting is hard to follow due to lack of overview. One outcome was "cantTell"… English must be thoroughly checked. | 2 | YES | The report generation module used by MobileWaaT was addressed by CERTH/ITI, within the scope of Waat. |
| New assessments of same url with different settings create a report that overwrites the previous one. | 2 | YES | Problem resolved |
| The PDF´s format is not comfortable to read | 2 | YES | The report generation module used by MobileWaaT was addressed by CERTH/ITI, within the scope of Waat. |
| Mostly ok, but in standalone you have to dig for the code snippet by yourself because of missing line numbers | 2 | YES | Problem resolved |
| I had problems with the validation of url's because they did not start with http://. The error was confusing and it should be improved. | 2 | YES | Problem solved. |
| I'd suggest an information label about how many out of possible tests I selected and for example a very short line up on what disabilities got selected for me upon a person instead of loading for greyed out checkboxes scrolling the whole list. | 3 | YES | This feature is available in the integrated version. |
| PDFs should be able to link the guideline fail to the source line in its context. | 3 | NO | This is not in the scope to be addressed by the standalone tool. |
| The distinction between errors in MWBP and WCAG2.0 is not clear. | 3 | YES | The improvements on the report generation module do impact in the distinction of both guidelines. |
| The results shown as a pdf file are unfortunately paginated at a huge font size. Since these are vector formated results one could scale or even offer an option to scale as part of the pdf-file content. | 3 | YES | The report generation module used by MobileWaaT was addressed by CERTH/ITI, within the scope of Waat. |
| Please offer a live html view including examples of how to correct a highlighted problem just like today's W3C Validators do. | 3 | NO | This will be considered for the next release. |
| Standalone: right mouse button should be allowed to paste URLs. | 3 | YES | Problem solved. |
| ERROR: A problem occurred by reading the WCAG2. | YES | It was the generic error that should appear in the GUI when something goes wrong with the WCAG2 module (and more probably with the WCAG2 assessment service). We have to know the context to try to reproduce the error. However, we changed the error reporting when there is a connection problem with WCAG 2 techniques. | |
| The selection of AT's is not available. | NO | It could be interesting but is not planned within the scope of the project. | |
| The reporting is not as good as WaaT. It should be improved in order to make it more efficient for developers. The reporting should link directly to the source files where the errors and warning points occur. For example if there is an error in file a.html line 135, when I click on the error the file a.html should be open with the cursor in the line 135. | NO | This is performed in the integrated version. | |
| All tests took nearly the same time because after a while I got an "assessment queue" message that a problem occurred by reading the WCAG2. | NO | Probably there was a temporal unavailability of the service. | |
| I cannot end evaluation (Exception). | NO | Problem related with the previous one. We need to be able to reproduce that error to correct. (more detail needed) | |
| Please offer a subtree of the initial site to analyse. Once "Assess" is pressed it clears my input I was about to add sublevel sites to. The main window is not resizable. Some kind of history would come in handy too | NO | This is not a scheduled functionality of the tool. | |
| Running slow on Win XP with 1GB RAM. Was impossible on 2 machines running Win 7 64bit | YES | The setting was replicated and the tool was executed repeatedly. No slowness was detected even for a Win XP OS with 1GB of RAM. |
Position in the theoretical development process
The MobileWaaT evaluation tests have been implemented according to the defined ACCESSIBLE Harmonized methodology (HAM) which is described in deliverable D3.1 "ACCESSIBLE harmonizes methodology".
Based on the HAM mapping between WCAG, MWBP guidelines and disabilities, the following MobileWaat steps for the selection and application of guidelines aiming Mobile Web Accessibility evaluation for specific disability profiles were considered:
- Step1: Select only those WCAG guidelines that are relevant to the targeted disability type
- Step2: Select only those MWBP guidelines that are relevant to mobile device usage and consider the usage patterns potentially adopted by users with the targeted disability type
- Step3: Adopt the recommendations for the levels of effort defined on the relation between WCAG and MWBP, but only considering the guidelines subsets identified in the first two sets
For the first step, a standard mapping between WCAG and disability type can be used to identify the relevant guidelines. For the second, foremost one should find the usage and configuration patterns that users typically apply to their devices depending on the disability type. Based on that, the relevant of applying each MWBP should be assessed, thus selection the adequate MWBP guidelines. Finally, for the last step, one could start by considering all guidelines of the WCAG subset on the mobile Web accessibility evaluation.
Then, for each one of those guidelines, the mentioned WCAG/MWBP relation can be used to exclude the corresponding guideline of the MWBP set, as long as the corresponding effort level is nothing. Once the subset of WCAG guidelines is exhausted, all MWBP guidelines that were not excluded should be applied for a complete coherent evaluation.
