Evaluating Web Accessibility for Specific Mobile Devices Markel Vigo
Amaia Aizpurua
Myriam Arrue
Julio Abascal
University of the Basque Country Informatika Fakultatea 20018 Donostia, Spain +34 943 015113
University of the Basque Country Informatika Fakultatea 20018 Donostia, Spain +34 943 015113
University of the Basque Country Informatika Fakultatea 20018 Donostia, Spain +34 943 015160
University of the Basque Country Informatika Fakultatea 20018 Donostia, Spain +34 943 018067
[email protected]
[email protected]
[email protected]
[email protected]
between mobile web usability recommendations and solutions for users with physical impairments. However, the overlap is not complete since users with physical impairments have a more extreme range of needs and requirements. Despite the overlap incompleteness it is remarked that enhancements for users with motor disabilities would benefit mobile web users. In addition, it is suggested by Mankoff et al. [16] that some solutions for users with motor disabilities in the context of web accessibility could be applied to enhancing interaction methods for navigating the WWW with mobile devices.
ABSTRACT This paper presents a tool for evaluating web accessibility for mobile devices regardless their software, hardware or user agent characteristics. Taking the mobileOK Basic tests by the W3C as a basis, these tests are extended so that device characteristics can be considered in the evaluation process. A sound tool that takes into account these extended tests has been developed. Device features of a given device are retrieved from heterogeneous device description repositories and CC/PP based profiles are automatically generated. Based on these profiles, evaluation queries are dynamically created obtaining device-tailored evaluation reports. Finally, in order to demonstrate the feasibility of the tool, a case study has been conducted concluding that the tool reduces the number of false positives and false negatives.
Generally, web content is developed with desktop computers in mind, and therefore web pages are not adequately displayed on mobile devices. Besides, low text input rate, lack of pointing device or low bandwidth [13] cause a poor user experience while interacting with mobile devices. Harper [11] states that problems that able-bodied users may encounter when accessing to the WWW with mobile devices are similar to those that users with physical, sensorial and cognitive disabilities face in the traditional Web due to the previously mentioned device limitations:
Categories and Subject Descriptors H.1.2 [User/Machine Systems]: Human factors. H.5.2. [User Interfaces]: Evaluation. H.5.4. [Hypertext/Hypermedia]: User issues. K.4.2
Small display size. The limited size of the display results in excessive scrolling which causes disorientation on the user in a similar way that the lack of context disorientates visually impaired users [9]. Furthermore, Jones et al. [12] found out that the performance decreases on small screen devices when performing information retrieval related tasks such as using search engines even if the literature review suggests that reading and comprehension would not diminish.
Low text input rate. Filling out a form or typing a URL with a reduced keyboard can be a tedious task and the error rate increases considerably which entails frustrating browsing sessions. A user with motor disabilities faces an analogous problem when accessing to the WWW with an alternative input device.
Lack of pointing device makes difficult browsing through a web page as the user has no other option than relying on reduced keyboards which significantly slows down the navigation. Thus, there is an information overload and excessive sequencing when reading the information. Visually impaired users find similar barriers when navigation bars and menus are read time and again until they get to the piece of information they are looking for [9].
Low bandwidth. Unaffordable high-speed connection or low speed connection leads users to not to load images in their browsers. If there is no alternative description for a given image there is an information loss that affects the mobile device users in the same way as blind users when accessing a web resource in the WWW.
General Terms Human Factors, Verification.
Keywords Mobile web, web accessibility, device-tailored evaluations.
1.
INTRODUCTION
Problems related to accessing to mobile web content are closely related to web accessibility. As stated by Thatcher et al. [20] developing accessible content can benefit users without disabilities. For instance, environmentally constrained scenarios such as driving a car while a handheld device is displaying information regarding traffic but the driver cannot take a glance at it due to heavy traffic can be considered as accessibility problems. Furthermore, bearing in mind traditional accessibility recommendations such as device independence and consistent navigation principles enhances the quality of interaction with mobile devices. Trewin [21] highlights the existence of an overlap Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. W4A2008 - Technical, April 21-22, 2008, Beijing, China. Co-Located with the 17th International World Wide Web Conference. Copyright 2008 ACM ...$5.00.
65
Colour. If the device has a monochrome display (which is not very frequent) or limited colour support, information conveyed by images can be lost. Colour blind users face similar problems.
No support for mark-up, scripting or data formats. Some assistive technologies such as screen readers cannot handle mark-up or scripting formats although as they evolve their capabilities are increasing in this sense. Similarly, user agents in mobile devices have analogous problems and usually the user cannot access to the information.
Before mobileOK Basic tests were released, EvalAccessMOBILE tool [2] was developed by the Laboratory of HCI for Special Needs at the University of the Basque Country based on a draft of the MWBP 1.0. Mobile Web Best Practices were implemented taking advantage of the flexibility GXML (Guidelines in XML) which is a XML-Schema to specify and define guidelines. GXML was developed with WCAG 1.0 in mind and had been successfully deployed in the accessibility evaluation tool EvalAccess [1]. All of the abovementioned tools do not contemplate device specific evaluation even if MWBP are full of statements in this regard. This is the reason why an evaluation tool that considers the characteristics of specific devices regardless the DDC is presented in this paper. Taking the mobileOK Basic tests as a basis, this tool aims at going beyond these tests in order to perform device-tailored evaluations. Therefore, the tool implements mobileOK Basic tests at least and when device dependent issues are found these tests are extended.
In order to overcome the lack of awareness concerning mobile web and aiming at unifying the criteria about good usability practices for mobile devices, the Mobile Web Best Practices 1.0 (MWBP 1.0) [19] were released in 2006 by the W3C Mobile Web Initiative. MWBP 1.0 are derived from Web Content Accessibility Guidelines 1.0 (WCAG 1.0) [8] but their scope is limited to the guidelines that have an impact on mobile devices. In the context of automatic guideline testing, the mobileOK Basic tests [17] were published in order to meet the W3C mobileOK Basic Conformance. These tests define a subset of best practices in MWBP 1.0 and as it is claimed in their web site, the web content that satisfies mobileOK Basic tests provides a “functional user experience”. Each test is accurately defined so that machineautomatable tests can be unambiguously performed. Moreover, it is the less demanding of two levels of conformance since mobileOK Pro is to define the tests for a richer user experience although to date there is not much information in this regard.
According to Bickmore and Schilit [5] there are four approaches to device-independent access.
MWBP 1.0 and specially the mobileOK Basic tests rely on the socalled Default Delivery Context1 hereafter referred to as DDC. The characteristics of the DDC can be seen in Figure 1. Usable screen width: 120pixels, minimum. Mark-up language support: XHTML Basic 1.1 Character encoding: UTF-8 Image format support: JPEG, GIF Maximum total page weight: 20 KB Colours: 256 minimum Style sheet support: CSS Level 1 Scripting is not supported
Therefore, test cases inferred from mobileOK tests are useless for all the devices that differ from the DDC no matter if they are a brand new mobile phone or a legacy PDA. The objective of this paper is to present an evaluation tool that relies on mobileOK Basic tests but is capable of dealing with any device regardless its characteristics.
Related Work
http://www.w3.org/TR/mobile-bp/#ddc
2
http://validadores.tawdis.net/mobileOK/
3
http://ready.mobi/
4
http://validator.w3.org/mobile/
Multiple-device authoring is similar to device-specific authoring but in this case a range of devices is identified and adaptation process is carried out based on automatic transformations upon user request.
Client-side navigation relies on the capabilities of the user agent to adapt or transform the content.
Automatic re-authoring. A unique web document is transformed taking into account the characteristics of the client device. These transformations are applied in the client, in the server side or in a proxy.
The remainder of the paper is organized as follows. In Section 2, in addition to dealing with the device dependent implications in mobileOK Basic tests, the different components of the tool are described. A case study is carried out in Section 3 in order to illustrate the need of a tool such as the one presented in this paper and finally conclusions are drawn in Section 4.
Several evaluation tools such as TAW mobileOK Basic checker2 by Fundación CTIC and ready.moby3 by mTLD check the mobileOK Basic tests among other features. The W3C Mobile Web Initiative is developing an open-source downloadable checker and to date (March 2008) a beta version can be found as well as its web interface4.
1
Device-specific authoring entails developing web content for a particular device.
The application scope of the proposed tool would be the first approach. According to Garofalakis and Stefanis [10] the first two approaches obtain high quality web documents although its high cost is also remarked by Butler et al. [7]. However, using sound tools such as the one presented in this paper can make this process less daunting. On the other hand, even if our tool can be used in the development process its main purpose is to give accessibility scores for different interaction contexts once it is deployed in a more general evaluation framework defined in Vigo et al. [22].
Figure 1. Characteristics of the Default Delivery Context.
1.1
2.
ARCHITECTURE OF THE SYSTEM
2.1
Source Code Retriever
Web servers are capable of adapting web content to mobile devices. Some of them aim at dynamically adapting web content to the specific features of a mobile device while other just redirect to the ‘mobile version’ of a regular web page no matter which the characteristics of the accessing mobile device are. The rest of the web servers do nothing in this regard even if they can be configured for such task. Assuming that the former case works (dynamic adaptations of content), the last two cases are the ones
66
vocabularies are used as long as they refer to the same concept and type as vocabulary reuse is encouraged in CC/PP.
that can cause most accessibility problems. The ‘mobile version’ approach is not always an acceptable solution as the characteristics of the devices such as the screen size, input mode, format support of mark-up or pictures etc. can make a difference.
Taking the mobileOK Basic tests as a basis, the following list outlines accessibility issues regarding devices as well as the considerations that should be made in order to create a CC/PP based vocabulary. Note that words borrowed from UAProf vocabulary have a prf prefix while our new vocabulary uses the access prefix.
Since the objective of our system is to evaluate the accessibility of the content delivered to a specific device it is necessary to retrieve the content that a server would deliver in such a case. Therefore, the Source Code Retriever changes the content of the HTTP ‘User-Agent’ header with the information related to the device model, browser and middleware of the device etc. In Figure 2 can be observed the value of the ‘User-Agent’ HTTP header for the Nokia 6600 cell phone. Nokia6600/1.0 SymbianOS/6.1 Profile/MIDP-2.0
CHARACTER_ENCODING_SUPPORT assumes that if UTF-8 format is not used a checker should produce an error. prf:CcppAccept-Charset word will capture the list of accepted charset by a given device.
CONTENT_FORMAT_SUPPORT, IMAGE_MAPS and LINK_TARGET_FORMAT take for granted that just JPG and GIF picture files can be used. access:picformatSupport captures in a list all the supported formats.
LINK_TARGET_FORMAT checks whether linked resources such as XHTML and CSS are supported. Thus access:cssSuport and access:xhtmlSuport are used in such a case.
NO_FRAMES test produces an error if a frame is found. prf:FramesCapable conveys the capability of a browser to render frames.
OBJECTS_OR_SCRIPT test assumes that scripts and applets are not supported. prf:JavaScriptEnabled and prf:JavaAppletEnabled contain information in this regard.
POP_UPS test produces an error without considering if a browser has multi window support (access:mwSupport).
TABLES_ALTERNATIVES warns the developer if tables are found. prf:TablesCapable word is used to ascertain whether a browser handles tables.
Figure 2. Content of the ‘User-Agent’ HTTP header for the Nokia 6600 cell phone. As a result, the desktop computer simulates the behaviour of a device accessing to the WWW when requesting a resource and it is obtained the web content that a determined mobile device would retrieve.
2.2
Device Information Retriever
The MWBP document contains a lot of references to device features. For instance, the best practice related to tables5 states the following: “Do not use tables unless the device is known to support them”. Since the objective is to adapt web content to the delivery context of a given device or perform device-tailored evaluations it is necessary to know its characteristics beforehand. There are several solutions to address this problem. Some of them are supported by the industry while other are open-source projects. 6
CC/PP [14] is a RDF based framework aiming at describing device capabilities and user preferences in order to tailor content to a given delivery context. A CC/PP profile provides the structure to define components (hardware or software platform, user agent) and their respective attributes, e.g.: screen size, operative system name or browser support for XHTML tables. However these last properties/terms are not specified by CC/PP and should be defined by developers in the context of the CC/PP framework. In this sense the Open Mobile Alliance7 (OMA) proposed the UAProf8 profiles which extend the CC/PP framework by adding new terms in order to gain expressiveness. UAProf is supported by the mobile industry and has become a defacto standard.
2.2.1
2.2.2
Extending mobileOK Basic Tests
This section discusses how we can address the evaluation of web pages for specific devices extending the mobileOK Basic tests. Each test is analyzed in order to find its implications for device characteristics. If a concept that describes a device feature has to be captured, the concept is modelled extending CC/PP with new words in a new vocabulary. If available, words from existing
5
http://www.w3.org/TR/mobile-bp/#TABLES_SUPPORT
6
http://www.w3.org/RDF/
7
http://www.openmobilealliance.org/
8
http://www.openmobilealliance.org/tech/profiles/UAPROF/
Dealing with Device Descriptions
WURFL9, which stands for Wireless Universal Resource File, is an open-source project aiming at collecting in one large XML file the characteristics of mobile devices so that developers can have a source of information about the capabilities of devices when developing their web applications. Several utilities have been launched in the context of WURFL demonstrating its usefulness: automatic mobile web generators, image renderers, database connectors etc. As it is stated in their web site, WURFL is more widely adopted by the community than UAProf profiles are. On the other hand, it should be noted that there are also several commercial device databases. Since the WURFL file can be updated by any contributor there is no guarantee that the content in the file is correct. In addition, UAProf files also contain several inconsistencies even if the profiles are supposedly created by manufacturers. The fact that file format is different and follow different semantics (RDF vs. XML) makes difficult the interoperability between the different sources of information even if both approaches have data overlaps. In other words, both may describe the same devices but since they are expressed using a different syntax and format, dealing with them is not straightforward. Moreover, it can happen
9
ccppschema-20021212#
67
http://wurfl.sourceforge.net/
false false true JPG "US-ASCII" "Windows-1252" "UTF-16be" "UTF-8" "ISO-8859-1" false false true
Figure 3. CC/PP profile corresponding to a Blackberry 7520 device, automatically created by the Device Information Retriever.
Table 1. Device characteristics (column 1) and their location in the device description repositories (columns 3 and 4) and the vocabulary word that captures the characteristics (column 2)
that the same description for a device is more complete in one system than in another.
Concept
Therefore the Device Information Retriever deals with the heterogeneity and different levels of completeness of the profiles. It gets the model name of a given device as an input and queries both UAProf profiles and the WURFL file to obtain the necessary information to perform device-tailored evaluations. Table 1 shows the device features needed in order to satisfy device-tailored mobileOK Basic tests, the word used in the vocabulary to refer to a feature and which information sources (WURFL or UAProf) can these features be retrieved from. Sometimes the information can be directly retrieved while other times inference is required. Since UAProf profiles are RDF-based, Jena has been chosen for manipulating such profiles. Jena is a semantic web framework useful to perform SPARQL [18] queries and process RDF documents, among others and makes easy the access to RDF resources. Information from the WURFL file can be retrieved quite straightforwardly using the API that the WURFL project provides.
10
Yes
Yes
CSS support
access:cssSupport
Yes
No
supported pictures access:picFormatSupport format
Yes
Yes
accepted charsets
prf:CcppAccept-Charset
No
Yes
access:pntSupport
Yes
No
prf:FramesCapable
No
Yes
No
Yes
prf:JavaAppletEnabled
No
Yes
access:mwSupport
No
No
prf:TablesCapable
Yes
Yes
JavaScript support prf:JavaScriptEnabled Java Applet support multi-window support tables support in browser
Once the required data are retrieved, a CC/PP compliant file is automatically created. An example of this file for a Blackberry 7520 can be found in Figure 3. As can be observed the CC/PP profile contains the fields defined in Section 2.2.1 with their respective values. The information in the profile will be used by the Guidelines Instantiator to fill in the slots of the incomplete mobileOK Basic tests.
WURFL UAProf
access:xhtmlSupport
pointing device support frames support in browser
10
Vocabulary word
XHTML support
2.3
Guidelines Instantiator
In recent years numerous guideline sets such as usability guidelines for elderly users [15] and e-learning accessibility guidelines [4] have been published among others. These guidelines sets are quite heterogeneous as they focus on accessibility issues regarding to end-users (elderly, visually impaired etc.), access device or application types such as elearning environments. When GXML was developed it was not foreseen the release of these guideline sets and the different
http://jena.sourceforge.net/
68
abstraction levels of each set made difficult framing them using GXML. Therefore the Uniform Guidelines Language (UGL) was developed [3], a XML-Schema based language which is capable of expressing numerous guideline sets such as the previously mentioned ones. Since it is more expressive and flexible than GXML, the guideline coverage increases significantly. Using UGL, a developer is able to implement guideline sets no matter how generic or specific guidelines are. Tests in mobileOK Basic have been implemented following the UGL grammar. UGL was previously extended to handle references to RDF-based vocabularies [22] since one of the main tasks of the Guidelines Instantiator (GI) is to complete missing specifications in guidelines with concrete values from the CC/PP profile.
Excerpt of the CC/PP profile false Excerpt of the UGL definition auto error [ ] OBJECT check attribute ismap
The system presented in this paper is able to evaluate any device no matter what its features are, and these features are not known until the time of the evaluation. This requires the introduction of slots into guidelines definitions so that elements in the guidelines can represent any value. Since the value of the slot will be found in the CC/PP profile, the same names are being used in the profile and in UGL. Using the same vocabulary has one big advantage: guidelines in UGL and CC/PP files can “talk” in the same language and therefore their interoperability is enhanced. In this vein, the name of the variable in the guideline is matched with the field names in the CC/PP file.
XQuery statement let $tmp:=web_doc.xml//OBJECT[@ismap] return if(not([ ]))then for $i in $tmp return {$i/@line, $i/name()}
Figure 4. One test case for the [IMAGE_MAPS] test. Excerpt of the CC/PP profile JPG BMP GIF
Thereupon, the GI automatically infers XQuery [6] sentences from mobileOK Basic tests in for evaluation purposes. XQuery is a query language for XML documents that extends XPath while versatility is enhanced. To sum up, the process of filling in slots in mobileOK Basic tests from CC/PP profiles to the automatic creation of XQuery sentences is carried out as follows by the Guidelines Instantiator:
Excerpt of the UGL definition auto error [ ] [ ] [ ] INPUT check attribute src value
1. The slots in the mobileOK Basic tests are filled in by matching the fields in the CC/PP profile that have the same name. 2. Only when step 1 is completed the GI automatically can infer XQuery sentences for each test case in mobileOK Basic tests. The GI will yield a set of XQuery sentences to be applied against a XHTML document. Two test cases are described in order to illustrate how the GI works:
IMAGE_MAPS: according to the Default Delivery Context (DDC) a mobile device does not have to have a pointing device. Therefore, server-side image maps are not allowed. This test is extended by checking if the current device has a pointing device. In such a case this test would not result in an error.
XQuery statement let $tmp:= web_doc.xml//INPUT [@type='image' and not(fn:ends-with(@src,'[ ]'))] return for $i in $tmp return {$i/@line, $i/name()}
CONTENT_FORMAT_SUPPORT: the DDC only contemplates the usage of JPG and GIF format for pictures. If a web document contains any other common format such as PNG, SVG, etc. the mobileOK Basic test should yield an error. This test case is extended by checking if the device supports any of the formats in a web page without making any previous assumption.
Figure 5. One test case for the [CONTENT_FORMAT_SUPPORT] test.
2.4
Evaluation Engine
The evaluation engine obtains the XHTML source code of the web document which is going to be evaluated and the dynamically created set of XQuery sentences. Using Saxon11, a powerful XQuery and XSLT processor the evaluation stage becomes straightforward. XQuery sentences are directly applied against the XHTML document. As XQuery sentences also specify how the reporting has to be performed, results are encapsulated in
Figure 4 and Figure 5 illustrate the aforementioned test cases respectively. The first row contains an excerpt of a CC/PP profile that is matched with the fields in UGL in the second row. Once the UGL definition is complete the XQuery sentence can be automatically created. Note that some excerpts related to the evaluation logic are omitted in the UGL excerpts in order to enhance readability.
11
69
http://saxon.sourceforge.net/
a XML-based evaluation report so that data in reports can be exploited by external applications.
Sony Ericsson P990 (D3). Table 2 shows the features of the devices regarding the device dependencies on the mobileOK Basic tests.
2.5
Table 2. Characteristics of three different mobile devices
Putting all together
Figure 6 depicts the previously described components, the relationships among them and how is the information flow.
Figure 6. Architecture of the system.
3.
Upper-left of or orange box. The Source Code Retriever obtains the XHTML code of a given resource in the WWW. It simulates the access of a determined mobile device in case adapted web content is delivered by the web server.
Vocabulary word
D1
D2
D3
access: xhtmlSupport access: cssSupport access: picFormatSupport
yes
yes
yes
yes
no
yes
GIF, WBMP
GIF, JPEG, PNG, WBMP
BMP, ICO, GIF, JPEG, PNG, SVG+XML, TIFF, WBMP, X-BMP, X-EPOC-MGM, X-WMF
prf: CcppAccept-Charset
US-ASCII, ISO-8859, UTF-8, ISO-10646UCS-2
US-ASCII, ISO-8859-1, UTF-8, ISO-10646UCS-2
US-ASCII, ISO-8859-1, ISO-8859-2, ISO-8859-4, ISO-8859-5, ISO-8859-7, ISO-8859-9, ISO-10646-UCS2, KOI8-R, csKOI8R, UTF-8, UTF-16
access: pntSupport prf: FramesCapable prf: JavaScriptEnabled prf: JavaAppletEnabled
no
no
no
no
no
yes
no
no
yes
no
no
no
prf:TablesCapable
yes
yes
yes
Since data in Table 2 are retrieved from either UAProf or WURFL profiles, some inconsistencies might be found with regard to actual data. In addition it should be noted that none of the profile repositories contain information about multiple window support. Thus, access:mwSupport word cannot still be used in device profiles.
Upper-right or blue box. The Device Information Retriever obtains information regarding software, hardware or user agent features from heterogeneous device description sources. The information required to extend the mobileOK Basis tests is put together in a CC/PP file which is used to fill in the slots in the mobileOK Basic tests implemented following the specifications of UGL. The Guidelines Instantiator automatically creates a set of XQuery sentences inferred from the dynamically created UGL-based mobileOK Basic tests.
Table 3 contains the evaluation results of several web pages, no matter which device has been used as just the DDC has been considered. The first column corresponds to the URL of the web page while the following columns contain the number of warning and failures found. It should be noted that warnings and failures are the issues that mobileOK Basic tests can raise. Table 3. Evaluation results for the DDC
Bottom or green box. The XHTML source of the web resource is evaluated against the generated XQuery sentences. As a result device-tailored reports are obtained. Since reports are XML based, other components can exploit the data to collect statistics, to keep track of the accessibility level or to automatically calculate accessibility scores.
item
CASE STUDY
In order to demonstrate the feasibility of the tool a case study has been carried out using three different mobile devices. Several web pages developed with mobile devices in mind have been evaluated against these specific devices which have been chosen according to their features with regard to the DDC: a device that has fewer features than the DDC (a Nokia 3590 mobile phone, D1), a SAMSUMG-SGH-E100 (D2) which is quite similar to the DDC and a device endowed with better support than the DDC, a
URL
1
www.google.com
3
1
2
www.youtube.com
2
1
3 www.flickr.com
3
1
4
3
6
www.amazon.com
5 www.gmail.com
5
4
6
www.facebook.com
6
1
7
m.yahoo.com
5
1
8 m.twitter.com
7
1
140
288
9 www.wikipedia.org
70
D1, D2, D3 warning failure
When accessing to a URL that ranges from 1 to 6 in the table above, the browser is redirected to the mobile version of the web page while in the case of web pages 7 and 8 there is no redirection and the URL of the mobile web has to be typed. As it is very common accessing to web pages with no mobile web version, URL number 9 has been chosen to analyze its behaviour. At first sight, the most striking difference consists in the low number of issues that mobile versions of web pages have in contrast with URL number 9. Mobile web pages are simpler and have less content than traditional ones but still fail in best practices such as: providing the right image format, specifying the size of an image, style issues, scripts usage and poorly coded forms.
D1 D2 D3 warning failure warning failure warning failure
1 www.google.com
3
1
3
1
3
1
2 www.youtube.com
1
1
1
2
1
1
3 www.flickr.com
3
1
3
2
3
1
4 www.amazon.com
3
7
3
6
3
6 4
5 www.gmail.com
1
4
5
4
1
6 www.facebook.com
6
1
6
0
6
0
7 m.yahoo.com
5
1
5
1
5
1
8 m.twitter.com
5
1
7
1
5
1
9 www.wikipedia.org
74
289
118
240
51
239
Guidelines are instantiated on-the-fly and XQuery sentences are dynamically generated.
Device-tailored evaluation reports are obtained as a result of applying XQuery sentences against the XHTML file.
Even if the mobile web development is not the main purpose of the tool it can be useful in determined scenarios. As far as the capabilities that constraint the access to web content, some devices share these features. It would be quite useful for the developer to know which set of devices can adopt the same solution in case they are developing a multi-device solution. Once mobileOK Pro tests are released it will be quite straightforward to extend our tool due to its modularity. It is foreseen that new vocabulary words will be added to the CC/PP profile and new mobileOK Pro test have to be defined in UGL However, the generation of XQuery sentences remains the same.
Even if it was foreseen that D1 would obtain worse results than D2, it is not the case in URLs 5 and 8 due to CSS support. Looking carefully at results, it can be concluded that image, CSS and script support makes the difference among different devices while forms coding issues remain the same as they are not device dependent.
It is remarked that the W3C standards and recommendations such as MWBP 1.0, CC/PP or XQuery and the availability of open source resources have been of great help throughout the challenging development process of the tool.
Results show that the tool reduces the number of false positives as the errors assumed for more capable devices are removed. The number of false negatives also decreases as it is not assumed that those legacy devices with fewer capabilities than the DDC have the same capabilities.
5.
ACKNOWLEDGMENTS
Markel Vigo’s work is funded by the Department of Education, Universities and Research of the Basque Government. “The County Council of Gipuzkoa - Gipuzkoako Foru Aldundia” has also supported this project in the context of the AdaptAccess project.
4. CONCLUSIONS AND FUTURE WORK Numerous mobile devices’ characteristics differ from those in the Default Delivery Context (DDC). Therefore, performing evaluations focusing on mobileOK Basic tests can be useless as these tests assume that mobile devices are DDC compliant. The evaluation tool presented in this paper goes beyond this assumption and successfully evaluates accessibility issues regardless the device characteristics. Firstly, mobileOK Basic test have been extended so that other devices’ features can be covered. Secondly a sound tool with the following capabilities has been developed:
The evaluation tool focuses just on mark-up issues and more concretely on XHTML. Even though several tests rely on the content of HTTP headers it is out of the scope the evaluation of such content. In addition, the downloadable version of the W3C checker contains a component to evaluate this kind of issues. Once a stable version is announced it will be possible to plug this component in our tool and use UGL to store the analysis of HTTP headers for a subsequent evaluation.
Table 4. Evaluation results for specific devices URL
The tool deals with heterogeneous device description repositories in order to create a CC/PP profile for a given device.
Preliminary results show that the tool reduces the number of false positives as the errors assumed for newer and more capable devices are removed. The number of false negatives also decreases as it is not assumed that the devices with fewer capabilities than the DDC have the same capabilities and therefore more errors are produced. In addition, web pages developed with mobile devices in mind meet better the MWBP requirements than traditional pages do as they report fewer issues.
Table 4 shows the evaluation results of the same web pages but this time the DDC is not considered. Since the specific features of each device are taken into account results differ. The last three columns refer to warnings and failures produced by the abovementioned devices when evaluating the web pages.
item
6.
REFERENCES
[1] Abascal, J., Arrue, M., Fajardo, I., Garay, N. and Tomás, J. The use of guidelines to automatically verify Web accessibility. Universal Access in the Information Society 3(1), 71-79, Springer, 2004. [2] Arrue, M., Vigo, M. and Abascal, J. Automatic Evaluation of Mobile Web Accessibility. In C. Stephanidis and M. Pieper (Eds.). Universal Access in Ambient Intelligent Environments, UI4All 2006 (Königswinter, Germany, September 27-28, 2006). LNCS 4397, 244-260, Springer, 2007.
Mobile web-adapted XHTML source code is retrieved from a WWW resource.
[3] Arrue M., Vigo M. and Abascal J. Including Heterogeneous Web Accessibility Guidelines in the Development Process.
71
1st Conference on Engineering Interactive Systems, EIS 2007, EHCI, HCSE and DSV -IS 2007 joint conference (Salamanca, Spain, March 22-24, 2007). To be published in LNCS by Springer.
[14] Klyne, G., Reynolds, F., Woodrow, F., Ohto, H., Hjelm, J., Butler, M. and Tran, L. (Eds.) (2004, January 15). Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0. (W3C Recommendation). Available at http://www.w3.org/TR/CCPP-struct-vocab/
[4] Barstow, C., McKell, M., Rothberg, M. and Schmidt, C. (2002, June). IMS Guidelines for Developing Accessible Learning Applications 1.0. http://www.imsglobal.org/accessibility/accessiblevers/index. html
[15] Kurniawan, S. and Zaphiris, P. Research-derived web design guidelines for older people. 8th ACM SIGACCESS Conference on Computers and Accessibility, ASSETS 2005 (Baltimore, MD, USA, October 9-12, 2005). 129-135, ACM Press, 2005.
[5] Bickmore, T.W. and Schilit, B.N. Digestor: deviceindependent access to the World Wide Web. Computer Networks and ISDN Systems 29, 1075-1082, Elsevier, 1997.
[16] Mankoff, J., Dey, A., Batra, U. and Moore, M. Web Accessibility for Low Bandwidth Input. 5th ACM SIGACCESS Conference on Computers and Accessibility, ASSETS 2002 (Edinburgh, United Kingdom, July 8-10, 2002). 17-24, ACM Press, 2002.
[6] Boag, S., Chamberlin, D., Fernández, M.F., Florescu, D., Robie, J. and Siméon, J. (Eds.). (2007, January 23). XQuery 1.0: An XML Query Language (W3C Recommendation). Available at http://www.w3.org/TR/xquery/ [7] Butler, M, Giannetti, F., Gimson, R. and Wiley, T. Device Independence and the Web. IEEE Internet Computing 6(5), 81-86, IEEE Educational Activities Department, 2002.
[17] Owen, S. and Rabin, J. (Eds.) (2007, November 30). W3C mobileOK Basic Tests 1.0. (W3C Candidate Recommendation). Available at http://www.w3.org/TR/mobileOK-basic10-tests/
[8] Chisholm, W., Vanderheiden, G. and Jacobs, I. (Eds.). (1999, May 5). Web Content Accessibility Guidelines 1.0 (W3C Recommendation). Available at http://www.w3.org/TR/WAI-WEBCONTENT/
[18] Prud’hommeaux, E. and Seaborne, A. (Eds.) (2008, January 15). SPARQL Query Language for RDF. (W3C Recommendation). Available at http://www.w3.org/TR/rdfsparql-query/
[9] Correani, F., Leporini, B. and Paternò, F. Supporting Web Usability for Vision Impaired Users. In C. Stary and C. Stephanidis (Eds.). User-Centered Interaction Paradigms for Universal Access in the Information Society, UI4All 2004 (Vienna, Austria, June 28-29, 2004). LNCS 3196, 242–253, Springer, 2004.
[19] Rabin, J. and McCathieNevile, C. (Eds.). (2006, November 2). Mobile Web Best Practices 1.0. (W3C Proposed Recommendation). Available at http://www.w3.org/TR/mobile-bp/ [20] Thatcher, J., Burks, M.R., Heilmann, C., Lawton Henry, S., Kirkpatrick, A., Lauke, P.H., Lawson, B., Regan, B., Rutter, R., Urban, M. and Waddell, C.D. Web Accessibility: Web Standards and Regulatory Compliance. Springer-Verlag, New York, NY, 2006.
[10] Garofalakis, J. and Stefanis, V. Using RSS for effective mobile web browsing. Universal Access in the Information Society 6(3), 249-257, Springer, 2007.
[21] Trewin, S. Physical Usability and the Mobile Web. International Cross-Disciplinary Workshop on Web Accessibility, W4A 2006 (Edinburgh, United Kingdom, May 22-23, 2006). 109-112, ACM Press, 2006.
[11] Harper, S. Mobile Web: Reinventing the Wheel? ACM SIGACCESS Accessibility and Computing 90, 16-18, ACM Press, 2008. [12] Jones, M., Buchanan, G. and Thimbleby, H. Improving web search on small screen devices. Interacting with Computers 15(4), 479-495, 2003
[22] Vigo, M., Kobsa, A., Arrue, M. and Abascal, J. UserTailored Web Accessibility Evaluations. 18th Conference on Hypertext and Hypermedia, HYPERTEXT 2007 (Manchester, United Kingdom, September 10-12, 2007). 95-104, ACM Press, 2007.
[13] Kaikkonen, A. and Roto, V. Navigating in a Mobile XHTML Application. SIGCHI Conference on Human Factors in Computer Systems, CHI 2003 (Ft. Lauderdale, FL, USA, April 5-10, 2003). 329-336, ACM Press, 2003.
72
