RIAM Framework: Overlaps between Mobile and Ac ... - CiteSeerX

HCW— RIAM Technical Report Deliverable 2 (D2), July 2008

S CHOOL OF C OMPUTER S CIENCE

Information Management Group

RIAM Framework: Overlaps between Mobile and Accessible Webs

Yeliz Yesilada, Tianyi Chen and Simon Harper

Human Centred Web Lab School of Computer Science University of Manchester UK

This report first presents a survey of the existing work in both mobile and accessible Webs. It then introduces the RIAM framework and explains the main components which include input which refers to various approaches and devices used to deliver information to the Web, content which is the information that forms Web pages, the code and markup, authoring environment which refers to any application that is used to create or modify content and output refers to the rendering of the Web content by a particular user agent. Detailed information about these components can be found in Deliverable “2.1: RIAM Framework: Content”, “2.2: RIAM Framework: Output” and “2.3: RIAM Framework: Input”.

HCW Human Centred Web

2

RIAM The aim of the RIAM project is to investigate ways in which to integrate, to mutual advantage, research into the Accessible and Mobile World Wide Webs (Web), to develop a common infrastructure, and to validate this infrastructure using existing Web documents and Mobile client simulators. The RIAM web pages may be found at http: //hcw.cs.manchester.ac.uk/research/riam/.

RIAM Reports This report is in the series of HCW RIAM technical reports. Other reports in this series may be found in our data repository, at http://hcw-eprints.cs.man.ac.uk/view/ subjects/riam.html. Reports from other Human Centred Web projects are also available at http://hcw-eprints.cs.manchester.ac.uk/.

Acknowledgements RIAM is funded by the EPSRC, reference: EP/E002218/1.

RIAM Framework: Overlaps between Mobile and Accessible Webs

Contents 1

Introduction

2

Analysis of Current Practice 2.1 Web Accessibility . . . . . . . . . . . . . 2.1.1 Web Content and Accessibility . . 2.1.2 User Agent and Accessibility . . . 2.1.3 Authoring Tool and Accessibility 2.1.4 Tools to Support Accessibility . . 2.1.5 Other Work . . . . . . . . . . . . 2.2 Mobile Web . . . . . . . . . . . . . . . . 2.2.1 Web Content and Mobilility . . . 2.2.2 User Agents . . . . . . . . . . . . 2.2.3 Authoring Tools . . . . . . . . . 2.2.4 Tools to Support Mobile Web . . 2.2.5 Other Work . . . . . . . . . . . .

1

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

2 3 3 5 5 5 6 7 7 8 8 9 10

Overlapping Requirements 3.1 Common Experiences . . . . . . . . . . . . . . 3.1.1 Perceivable . . . . . . . . . . . . . . . 3.1.2 Operable . . . . . . . . . . . . . . . . 3.1.3 Understandable . . . . . . . . . . . . . 3.1.4 Robust . . . . . . . . . . . . . . . . . 3.2 Common Guidelines: WCAG 1.0 & MWBP 1.0 3.2.1 From WCAG 1.0 to MWBP 1.0 . . . . 3.2.2 From MWBP 1.0 to WCAG 1.0 . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

11 11 11 15 17 19 20 20 22

4

RIAM Framework and Methodology 4.1 RIAM Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 29

5

Conclusion

29

6

Associated Files

35

3

Human Centred Web Lab School of Computer Science University of Manchester Kilburn Building Oxford Road Manchester M13 9PL UK tel: +44 161 275 7821 http://hcw.cs.manchester.ac.uk/

. . . . . . . . . . . .

. . . . . . . . . . . .

Corresponding author: Yeliz Yesilada tel: +44 (0) 161 275 6239 [email protected]. uk http://homepages.cs. manchester.ac.uk/∼yesilady

Section 1

1

Introduction

1

Introduction

The Accessible Web aims to help people with disabilities to perceive, understand, navigate, interact, and contribute to the Web [49]. There are millions of people who have disabilities that affect their use of the Web. According to recent surveys, the current state of accessibility on the Web is very poor [4, 28, 41, 51]. Web accessibility depends on several different components of Web development and interaction working together, including Web software (tools), Web developers (people) and content (e.g., type, size, complexity, etc.) [22]. The W3C Web Accessibility Initiative1 recognises these difficulties and provides guidelines for each of these interdependent components: (i) Authoring Tool Accessibility Guidelines (ATAG) which address software used to create Web sites [59]; (ii) Web Content Accessibility Guidelines (WCAG) which address the information in a Web site, including text, images, forms, sounds, and so on [21]; (iii) User Agent Accessibility Guidelines (UAAG) which address Web browsers and media players and relate to assistive technologies [31]. The mobile Web aims to improve the experiences of mobile Web users. Web technologies have become the key enablers for access to the Internet through desktop and notebook computing platforms. Web technologies have the potential to play the same role for Internet access from Mobile devices. Today however, mobile Web access suffers from interoperability and usability problems that make the Web difficult to use for most users [39, 43, 48]. To address these issues, W3Cs “Mobile Web Initiative” (MWI)2 proposes a set of guidelines called Mobile Web Best Practices (MWBP) [52]. As MWBP highlights, the experiences of mobile Web users depend on the types of content involved, capabilities of the devices and access networks used and context in which the content is received by the user. To give some specific examples, compared to desktop display, the screen size of mobile devices is much smaller. Therefore, accessing pages designed for desktop browsers from Mobile devices means that the information conveyed is limited, the navigation is linear and thus time consuming [18]. Similarly, visually disabled 3 Web users who typically access pages with a screen reader4 , have to listen to and follow a linear audio stream which again can be time consuming [5]. Another example is that with Web 2.0 technologies5 , Web pages are becoming more complex and interactive and this presents yet another challenge for disabled people [30]. Similarly, due to small screen size, processing power and the abilities of browsers, mobile Web users also have problems in accessing Web 2.0 pages [35]. As can be seen from these examples that there are a lot of similarities and commonalities – the challenges for designing for the mobile Web are similar to those of designing for the Accessible Web [60, 44]. However, despite these commonalities, there has been very limited work on systematically comparing these two domains. Unfortunately, previous work has only looked at accessibility problems from a single user group perspective such as visually impaired [5], motor impaired [46] or small device users [10]. If designers want to create a page which is accessible by both mobile and disabled users, they have to follow a number of different guidelines and validation tools6 which means it will be time consuming and costly. 1

WAI, http://www.w3.org/WAI/. Mobile Web Initiative (MWI), http://www.w3.org/Mobile/. 3 The term visually disabled refers to both people who have visual impairments and are profoundly blind. 4 Screen readers are assistive technologies used by visually disabled people to access Web pages in audio. 5 Web 2.0 is a phrase coined by O’Reilly Media (http://www.oreillynet.com/), referring to a supposed second-generation of Internet-based services. 6 Web accessibility evaluation tools, http://www.w3.org/WAI/ER/tools/. 2

2

Yeliz Yesilada

Our aim is to investigate ways in which to integrate research into the accessible and mobile Webs and to develop a common infrastructure. To compare and contrast these two domains, we have created a framework which amalgamates all the components that need to be considered to model a neutral Human-Web interaction. This framework consists of four main components: input which refers to various approaches and devices used to deliver information to the Web, content which is the information that forms Web pages, the code and markup, authoring environment which refers to any application that is used to create or modify content and output refers to the rendering of the Web content by a particular user agent. Detailed information about these components can be found in Deliverable “2.1: RIAM Framework: Content”, “2.2: RIAM Framework: Output” and “2.3: RIAM Framework: Input”. This technical report aims to introduce this framework as well as gather and revise best practices and techniques. This technical report presents the groundwork for the rest of the RIAM project.

2

Analysis of Current Practice

There has been extensive research in both mobile Web and accessible Web domains. This section seeks to answer the question: “what exists?”. It aims to gather and revise in both domains to identify the overlaps and differences between these domains. Notable bodies with guidelines, best practice, and techniques to support these fields include organisations such as the W3C, IBM, and Fujitsu. By gathering and summarising relevant research within these fields, we can provide the basis for a possible integration of these two fields. In summary, we undertake a comprehensive survey encompassing the W3C best practice, guidelines, and recommendations within the W3C initiatives related to human computer interaction and the device independence of Web documents. This survey is not only confined to W3C but it includes the work from the internal groups of W3C such as the Web Accessibility Initiative (WAI), Mobile Web Initiative (MWI), and Device Independence Working group (DIWG). Additionally, we also consider work from other institutions and companies such as WebAIM, the Trace Centre, and Fujitsu, along with work by leading researchers in the field, such as Jakob Nielsen. The results from this survey enable us to identify intersections, differences, and un-addressed areas within these guidelines and best practices so that a cohesive framework (WP2) can be created. As it is highlighted by [22], achieving Web Accessibility depends on several components working together. These components include: (i) content: refers to information in a Web page ; (ii) user agent: includes browsers, and assistive technologies; (iii) user: refers to users’ knowledge, experiences, etc. (iv) developer: includes people who creates Web content, could be both professional or non-professionals; (v) authoring tools: refers to applications used to create Web content; and (vi) evaluation tools: includes tools that can be used to evaluate Web pages for accessibility, usability or quality. Therefore, as a field, in order to cover Web accessibility, we have investigated all of these components. We have mainly looked at what has been done related to each of these components. In the following sections, we first investigate the work that has been done in the Web accessibility field and then we investigate the mobile Web domain.

Section 2

2.1


3

Web Accessibility

Web Accessibility refers to the practice of making pages on the Web accessible to all users, especially to those with disabilities [49, 58]. Disabled people usually use assistive technologies7 to access Web pages in alternative forms (e.g, audio, Braille). Although an accessible Web means unprecedented access to information for people with disabilities, recent research suggests that the best practice on accessibility has not yet been achieved. For example, [38, 42] found the accessibility of the high street stores, banks and universities in the UK extremely disappointing. [2] surveyed 20 ‘Flagship’ governmental Web sites in the UK and concluded that 75% needed immediate attention in one area or another. Recently, the Disability Rights Commission (DRC) also conducted an extensive user evaluation whose report [28] concludes that most Web sites (81%) fail to satisfy even basic accessibility requirements. In this section, we survey the work that aims to improve the accessibility of Web pages for disabled people. Based on the work that has been done, we grouped them into four: Web content, user agent, authoring tool and other work which includes conformance logo effort. 2.1.1

Web Content and Accessibility

There are a number of Web content accessibility guidelines, however W3C/WAI guidelines are considered to be more complete and cover most of the guidelines suggested by the others. Although adopting these guidelines in developing a particular application does not guarantee the accessibility of that application, it does insure that the application exhibits a high degree of accessibility. Table 1 shows a summary of the existing guidelines and the following list provides further information about these guidelines: Web Content Accessibility Guidelines 1.0 [21]: is the most complete version of all the guidelines and has been a World Wide Web Consortium (W3C) recommendation since 5-May-1999. However, some of the proposed guidelines in WCAG 1.0 are considered as out-of-date and recently a new version has been released as a recommendation which is called WCAG 2.0 [16, 53]. PAS 78 [29]: is a guide to good practice in commissioning accessible Web sites. This is mainly created to guide designers in adapting and using Web content accessibility guidelines such as WCAG 1.0. US Section 508 [1]: is finalised in December 2000 and developed by the US Access Board based on recommendations from a committee composed of academics, disability advocates and industry representatives. There are also documents that compare Section 508 and WCAG8 . IBM Web Accessibility Checklist [3]: provides a list of checklists that could be used to design accessible Web pages. However it is not as comprehensive as the WCAG guidelines. There are also documents that compare IBM guidelines, WCAG 1.0 and Section 508 guidelines9 . 7

Assistive technology refers to hardware and software designed to facilitate the use of computers by people with disabilities [28]. 8 http://www.jimthatcher.com/sidebyside.htm 9 http://www-03.ibm.com/able/guidelines/web/ibm508wcag.html

4

Yeliz Yesilada

Organisation & Guidelines WAI Guidelines Section 508 Guidelines RNIB Guidelines AFB Guidelines Macromedia and Accessibility Dive into Accessibility IBM guidelines Nova Report BBC WCAG Samurai PAS 78 Flash and PDF Accessibility Accessible Blog Guidelines

Website http://www.w3.org/WAI/ http://www.section508.gov/ http://www.rnib.org.uk/ http://www.afb.org/ http://www.macromedia.com/ http://www.diveintoaccessibility.org/ http://www-306.ibm.com/able/guidelines/ http://www.cerlim.ac.uk/projects/ http://www.bbc.co.uk/guidelines http://www.wcagsamurai.org/ http://www.equalityhumanrights.com/ http://www.adobe.com/accessibility/ http://www.afb.org/

Table 1: Web content accessibility guidelines.

BBC Design Guidelines: is a comprehensive set of accessibility guidelines which is mainly used internally to ensure that the pages that are created within BBC are accessible [32]. Guidelines from Educational Institutes: has also proposed accessibility guidelines (e.g., MIT10 ). These guidelines are mainly simplified and summarised versions of the WCAG 1.0 guidelines. Dive into Accessibility [50] : is a book that presents a number of guidelines to design an accessible page based on different perspectives including by person, by disability, by design principle, by Web browser or by publishing tool. WCAG Samurai11 : is a group of developers that publish mainly extensions to the Web Content Accessibility Guidelines 1.0, who also publish corrections for WCAG 1.0. Guidelines from Disability Organisations: a number of disability organisations also provide design guidelines for accessibility, these tend to be simple, design tips like guidelines. There are also guidelines that focus on a specific document structure such as tables or they focus on specific HTML elements such as table, frame and form. These structures are usually more complex compared to the other simpler constructs such as headings, etc. Table 2 lists a number of Website that include tips, guidelines and best practices to design accessible tables, frames and forms. In summary, all these guidelines are related and they all address common accessibility issues. For RIAM, it is important to analyse these content guidelines and find the minimum set that can be used to make a page accessible to disabled people. Besides these guidelines, a number of studies have been conducted to check the accessibility of Web sites, these reports are listed in Table 3. 10

http://web.mit.edu/atic/www/accessibility/developweb.html

Section 2


Organisation & Guidelines Tables Webaim Usability.com Adobe Jim Thatcher Forms AFB Jim Thatcher Frames WebAim

5

Website http://www.webaim.org/techniques/tables/ http://www.usability.com.au/resources/ http://www.adobe.com/resources/accessibility/dw8/tables.html http://www.jimthatcher.com/webcourse9.htm http://www.afb.org http://www.jimthatcher.com/webcourse8.htm http://www.webaim.org/techniques/frames/

Table 2: Structural Web content accessibility guidelines.

Organisation & Report DRC Web Accessibility Report Beyond ALT Text Nova Report eAccessibility of public sector services in the European Union An Accessibility Analysis Of UK University Entry Points

Reference [28] [25] [26] http://archive.cabinetoffice.gov.uk [42]

Table 3: User studies and evaluation reports.

2.1.2

User Agent and Accessibility

A user agent can be defined as a software that retrieves and renders Web content for users12 . W3C/WAI has a set of guidelines that focus on making user agents accessible, which are called User Agent Accessibility Guidelines (UAAG [31]). This has been a recommendation since 17 December 2002. W3C is the only organisation that focuses on the accessibility of user agents. 2.1.3

Authoring Tool and Accessibility

Authoring tools can enable, encourage, and assist users, mainly authors, in the creation of accessible Web content through prompts, alerts, checking and repair functions, help files and automated tools. W3C again has a set of guidelines that focus on authoring tools which is a recommendation [59]. 2.1.4

Tools to Support Accessibility

There are also a number of tools that support either Web developers to create accessible content or end-users to modify pages to meet their needs. We group these into three: evaluation, repair and transcoding tools. Evaluation tools are used to check the accessibility of Web pages against Web accessibility guidelines but they do not necessary repair the identified accessibility problems. Repair tools, however, they try to fix the identified problems. 12

http://www.w3.org/TR/WAI-USERAGENT/glossary.html#def-user-agent

6

Yeliz Yesilada

Organisation & Report WAVE Cynthiasays Webaim, Hermish Webxact The AIS Accessibility toolbar

Reference http://wave.webaim.org/index.jsp http://www.cynthiasays.com/ http://www.webaim.org/resources/hermish http://webxact.watchfire.com/ http://www.visionaustralia.org.au/ais/toolbar/

Table 4: Some popular accessibility evaluation tools.

WAI maintains a list of evaluation and repair tools (http://www.w3.org/WAI/ER/ tools/complete). Table 4 lists some example accessibility evaluation tools. As opposed to evaluation and repair tools explained above, transcoding tools usually focus on assisting Web users. By using different techniques, these tools mainly transform pages into another form to meet users’ needs. Depending on what they do and how they work, these transcoding tools can be grouped into the following categories: • Generating Text Only Version: These tools mainly focus on simplifying pages and generating a text only version of pages. Some example tools include BETSIE [47] that can be used to access BBC pages in text only version; Textualise [24] that can be used to generate text only version of Web page; and finally LFT Transcoder [61] can also be used to generate text-only version of Web pages not only for disabled people but also for mobile devices. • Transcoding by User Preferences: These include tools that transcode/adopt pages based on the user preferences. Web Access Gateway is an example tool that collects user preferences and transcodes pages accordingly [11]. • Transcoding by Rules/Heuristics: These kinds of tools use a number of rules or heuristics to transcode Web pages. IBM’s Web Accessibility Tool is such a tool that aims to trancode Web pages for aging users [54]. • Transcoding by External Annotations: There are tools that perform transcoding based on annotations (computer understandable data associated with human understandable data). SWAP [56], IBM’s transcoding tool [57] and DANTE [65] are example tools that transcode pages by using the external annotations. • Transcoding by a Stylesheet: These are tools that transcode pages by stylesheets that are served with Web pages, for example SADIe which is a Semantic Web application that transcode pages using CSS [33]. There are also simulators that simulates how a screen reader renders Web page and there are also similators that show the problems that people with low vision, Dyslexia and Distractability problems experience13 . 2.1.5

Other Work

[37] presents a study that looks at the usage of accessibility logos and statements. The major outcomes are: (i) Not many Web sites use accessibility logos or statements; only 4% 13

http://webaim.org/simulations/

Section 2


7

of e-commerce sites and 12% of financial sites had a logo or a statement or both; (ii) The accessibility of the sites that use logo was very similar to the general sampled assessed by the DRC study; (iii) Sites make exaggerated claims bout their accessibility, with 30% of sites overstating their level of conformance to WCAG. There are a number of logos that Websites can display to show that they are accessible. These include: (i) See it right Logo14 ; (ii) WAI Conformance Logo15 ; (iii) Bobby Approved Logo16 ; and recently EU also has a new schema for delivering a quality mark for Web content accessibility17 . Although, these logos and conformance images can be good for indicating good intentions, displaying these logos does not necessarily mean that a Web page is accessible because: • They can be misleading, passing automated tests does not mean that the page is accessible. For example, an automated tool usually checks whether or not an ALT tag exists but they cannot check the quality of the existing ALT tags; • As it is highlighted by [37] solely responsible for the use of these logos, that means it depends on the honesty of the designers or Web page owners. But as it is highlighted by [37], the sites tend to make exaggerated claims about their accessibility; • The use of logos indicating A, AA or AAA, referring to the WAI priority levels, can be very misleading unless a more detailed explanation is given. • Finally, each conformance logo corresponds to the Web page on which it is displayed and does not apply to the entire site (but as it is indicated by [37], the authors or site owners may think that if a sample of pages passed a particular level of conformance, it means that the Website can display the logo).

2.2

Mobile Web

The Mobile Web aims to improve the experiences of Mobile Web users. Web technologies have become the key enablers for access to the Internet through desktop and notebook computing platforms. Web technologies have the potential to play the same role for Internet access from Mobile devices. Today however, Mobile Web access suffers from interoperability and usability problems that make the Web difficult to use for most users [34]. W3Cs Mobile Web Initiative (MWI) proposes to address these issues through a concerted effort of key players in the Mobile production chain, including authoring tool vendors, content providers, handset manufacturers, browser vendors and Mobile operators. In this section, we aim to give a broad overview of the work that has done to make mobile friendly. 2.2.1

Web Content and Mobilility

Designing Web pages for mobile devices also has similar challenges to designing pages that are accessible. A number of guidelines and best practices are designed to assist designers/developers create pages that are mobile friendly. Table 5 lists a number of organisations 14

http://www.rnib.org.uk http://www.w3.org/WAI/WCAG1A-Conformance 16 http://webxact.watchfire.com/ 17 [http://www.support-eam.org/supporteam/CEN ISSS Workshop.asp 15

8

Yeliz Yesilada

Organisation & Report MWBP dotMobi Switch On! Web Developer Guide Nokia Global Authoring Practices (GAP) UI Mobile Design Guidelines CSS-Discuss Opera Guidelines Taking your Website to Small Screen Mobile Advertising Guidelines AvantGo Guidelines University of Texas Austin Web Credible Usability Guidelines

Reference http://www.w3.org/TR/mobile-bp/ dev.mobi http://sw.nokia.com http://www.passani.it/gap/ http://www.lulu.com/ http://css-discuss.incutio.com/ http://my.opera.com/ http://www.alistapart.com/articles/pocket/ http://mmaglobal.com/mobileadvertising.pdf http://www.avantgo.com http://www.utexas.edu/web/guidelines/mobile.html http://www.webcredible.co.uk

Table 5: Mobile Web Guidelines.

that propose design guidelines for mobile Web. However, as with the other guidelines, W3C has the most complete guidelines called Mobile Web Best Practices [52]. W3C Mobile Web Best Practices group also maintains a Wiki for techniques that can be used to design pages for mobile devices18 . There are also some structural guidelines, that focusing on making some structures accessible to Mobile Web19 . 2.2.2

User Agents

A user agent is defined as a software that retrieves and renders Web content for users. For Mobile Web, it is mainly a browser that can be used to access Web pages from mobile devices. There are a number of mobile browsers available. Here we list these browsers that can be compared against mainstream desktop browsers such as Internet Explorer20 , Firefox 21 and Safari22 . Table 6 lists a number of browsers that are available for mobile devices. For Web accessibility, there are a set of guidelines for designing accessible user agents. However, to our knowledge there is no set of guidelines for designing user agents for mobile devices. However, there are a number of references that look at the limitations and features of these browsers. [62] presents an interesting study that compares how Web pages are displayed and rendered differently on Mobile browsers. 2.2.3

Authoring Tools

There are also a number of authoring tools that support creating Websites for mobile devices. The following list includes some examples: MobiSiteGalore23 is a free mobile website builder developed by Akmin24 . 18

http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro. http://patterns.littlespringsdesign.com/index.php/Main Page 20 http://www.microsoft.com/windows/ie/default.asp. 21 Firefox, http://www.mozilla.com/. 22 http://www.apple.com/safari/ 24 http://www.akmin.com/ 19

Section 2


Organisation & Report Pocket Internet Explorer Opera Mobile Opera Mini Mini Mozilla S60 Browser ThunderHawk AvantGo browser OpenWaver Browser NetFront Eudora-Web WebToGo

9

Reference http://blogs.msdn.com/iemobile/ http://www.opera.com/products/mobile/ http://www.opera.com/products/mobile/ http://www.mozilla.org/projects/minimo/ http://www.s60.com/browser/ http://www.bitstream.com/wireless/ http://www.avantgo.com/frontdoor/index.html http://www.openwave.com/ http://www.jp.access-company.com/ http://www.eudora.com/download/ http://www.webtogo.de/uk/

Table 6: Mobile User Agents.

Organisation & Report MobileReady Report, dotMobi Mobile Web Best Practices Checker W3C HTML Validator TAW MobileOK Basic

Reference http://ready.mobi/launch.jsp?locale=en EN http://validator.w3.org/mobile/W3C http://validator.w3.org/ http://validadores.tawdis.net/mobileok/en/


J2ME - Java Platform, Micro Edition (Java ME)25 Set of Java APIs for the development of mobile applications. Flash Lite26 Macromedia’s Flash retrofitted for mobile phones. 2.2.4

Tools to Support Mobile Web

There are also a number of tools that can be used to evaluate the content for Mobile devices. Some of these tools are listed in Table 8. Transcoding is the process of reformulating the content of a Web page to meet user’s needs. Different techniques are used for transcoding, for example text summarization (generating summaries for complex and long pages), page segmentation (fragmenting pages into a number of smaller and better managebale pages for mobile browsers) and content filtering (removing parts of pages that are not important or removing advertisements). Transcoding Web pages for mobile devices is a common approach and different techniques have been proposed. Some techniques focus on using the link structure, some techniques focus on using the HTML structure of the document, etc. The following list summarises some of these techniques proposed: Digestor [9]: This is one of the early transcoding systems for mobile devices which was a proxy. Power Browser [14]: Power Browser is mainly implemented as a proxy that fetches a page, summarises by using different techniques and then returns this summary to the user. A number of papers published based on this browser and summarisation techniques which are: Accordion summarization for end-game browsing on PDAs

10

Yeliz Yesilada

and cellular phones [13]; Focused Web searching with PDAs[15]; Seeing the whole in parts: text summarization for web browsing on handheld devices[12]; Efficient Web form entry on PDAs[40]. Function-based object model[19]: This paper proposes a new model called Funcationbased Object Model (FOM) that aims to capture the designer’s intention and then transcode pages accordingly. Detecting web page structure [20]: They propose a new browsing paradigm for Web pages where chunks of the Web page are displayed as thumbnail images. Using link analysis [66]: They analyse links to improve layout on mobile devices. They basically use a ranking algorithm similar to Google’s PageRank algorithm to rank the content objects with a Web page which allows the extraction of the important content for mobile devices; Recasting Web-page segmentation [6]: recasting web-page segmentation into an efficient machine learning framework. In Proceedings of the 15th International Conference on World Wide Web (Edinburgh, Scotland, May 23 - 26, 2006). WWW ’06. ACM Press, New York, NY, 33-42. Collapse-to-Zoom [8]: Viewing Web Pages on Small Screen Devices by Interactively Removing Irrelevant Content. Fractal summarization [63]: Fractal summarization for mobile devices to access large documents on the web, Proceedings of the 12th international conference on World Wide Web, p215-224, 2003. Robust web page segmentation [35]: for mobile terminal using content-distances and page layout information. One-column view browsing scheme: This is implemented by Microsoft Pocket IE and Opera Browser. 2.2.5

Other Work

Besides the guidelines, there are also other efforts to make Web content mobile friendly. These include Dot.Mobi, MobileOk Mark, mobile Web simulators, languages and MWI strategy in developing countries. The dotMobi domain27 is aimed at websites designed to be viewed on mobile phones. This means that the designers need to maintain seperate versions of their site. This is an expensive approach. Similarly, same approach was taken for Web accessibility. People started to maintain separate version of their Web sites specifically for Web accessibility. But it soon became clear that that cannot be the best solution: Does this mean, we need .access, .fridge, .pc, .* domain names? The device should be seamless from the design perspective. Dotmobi also has a domain naming guideline28 . 27 28

http://pc.mtld.mobi/ http://pc.mtld.mobi/documents/dotMobi Domain Naming Guidelines 1.0.html

Section 3

Overlapping Requirements

Organisation & Report T-Mobile Web demos Opera Mini Simulator Nokia Mobile Browser Simulator OpenWave Simulator winWAP Smartphone Browser Emulator .mobi Mobile Emulator Balckberry Emulator

11

Reference http://www.t-mobile.co.uk/ http://www.operamini.com/demo/ http://www.forum.nokia.com/info/ http://developer.openwave.com http://www.winwap.com/products 2 3.phpWinWAP http://emulator.mtld.mobi/emulator.php https://www.blackberry.com/Downloads


The MWBP Working Group defines a “mobileOK” trustmark based on existing standards and best practices. A trustmark, in this context, is “a mark or badge that indicates adherence to a set of criteria”. Relevant examples of trustmarks include the Conformance Logos promoted by the W3C’s Web Accessibility Initiative and the TRUSTe seal developed and promoted by TRUSTe. In both of these examples, a visible mark is used to indicate adherence to a set of best practice criteria in a particular domain. There are a number of simulators that show how a Web page is displayed by Mobile Devices which are listed in Table 8. W3C Mobile Web Best Practices (MWBP) recently launched a task force to progress and increase the mobile Web usage in developing countries29 .

3


People with disabilities (using desktop or laptop computers) and people without disabilities who are using mobile devices have similar interaction limitations and they experience similar barriers when interacting with Web sites. There is also significant overlap between the design solutions for both.

3.1

Common Experiences

This section provides examples of barriers to interacting with Web content experienced by people with disabilities and people using mobile devices. Mobile devices vary widely and not all the problems are present on all models. These barriers are grouped under four principles: perceivable, operable, understandable and robust. These principles lay the foundation necessary for anyone to access and use Web content, as described in Understanding the Four Principles of Accessibility section of Introduction to Understanding WCAG 2.0 [17]. Detailed information about these shared experiences can be found in [64]. 3.1.1

Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

29

http://www.w3.org/2006/12/digital divide/public.html

12

Yeliz Yesilada

Information conveyed using color: Information conveyed using color (for example, “required material is shown in red”) with no redundancy. Disabilities Context User perceives color incorrectly or not at all, and so misses or misunderstands information or makes mistakes.

Mobile Context Many screens have limited color palette and color difference is not presented. Device is used in poor lighting (for example, outdoors), so colors are not clearly perceived.

WCAG 1.0

WCAG 2.0

MWBP

2.1, 2.2

1.4.1 Use of Color, 1.3.1 Info and Relationships, 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced).

use of color and color contrast

Large page or large images: User only sees small areas at a time, is unable to relate different areas of a page, and so becomes disoriented or has to scroll excessively. Additionally, user cannot access picture details because the picture is shrunk. Disabilities Context User with restricted field of vision or using screen magnifier gets only small part of page or image at a time.

Mobile Context Mobile device has small screen (viewport).

WCAG 1.0

WCAG 2.0

MWBP

12.3

1.4.8 Visual Presentation.

page size usable and scrolling.

Multimedia with no captions: User misses auditory information. Disabilities Mobile Con- WCAG 1.0 WCAG 2.0 Context text User who is Mobile users 1.1 and 1.4. 1.2.2 Capdeaf or hard of often in public tions (Prehearing cannot places (trains, recorded), hear. hotel lobbies) 1.2.4 Capturn off sound; tions (Live), or often cannot 1.2.8 Media hear in noisy Alternative places (streets, (Prerenightclubs). corded)

MWBP non textalternatives.

Section 3


13

Audio-only prompts (beeps, buzzes) for important information (warnings, errors): Can’t operate or interact correctly with content, misses prompts, makes mistakes. Disabilities Context User who is deaf or hard of hearing can’t perceive content.

Mobile Context Users often cannot hear in noisy (street, nightclub) or in public places (trains, hotel lobbies).

WCAG 1.0

WCAG 2.0

MWBP

1.1 and 1.4.

1.2.1 Audioonly and Video-only (Prerecorded)

non textalternatives.

Non-text objects (images, sound, video) with no text alternative: User cannot perceive important information or loses information due to lack of alternative. Disabilities Context User who is blind cannot perceive content that include nontext objects. Furthermore, information not available to user whose browser, assistive technology, other user agent doesn’t support object.

Mobile Context User can be billed for download volume so images might be turned off to save costs. Some mobile user agents have limited support for non-text objects so user loses information. Some user agents also shrunk images in size to fit the device’s screen which can make images meaningless.

WCAG 1.0

WCAG 2.0

MWBP

1.1 and 1.4.

1.1.1 Nontext content

non textalternatives, objects or script.

14

Yeliz Yesilada

Text entry: User has difficulty entering text so text is entered incorrectly or mistakes are made. Disabilities Context User with motor disability (for example, partial paralysis, hand tremor, lack of sensitivity, coordination) has difficulty entering information.

Mobile Context Device has small keypad which has limited functionality compared to a full keyboard, or is held in an unsteady hand.

WCAG 1.0

WCAG 2.0

MWBP

3.3 Input Assistance: Help users avoid and correct mistakes.

minimize keystrokes, avoid free text, provide defaults and default input mode.

Content formatted using tables or CSS, and reading order not correct when linearized (for example when CSS or tables not rendered):User cannot understand the content correctly when it’s presented in a linear order. Disabilities Context User who is blind reads content in document tree order.

Mobile Context Meaning of content can be changed because of reformatting or restructuring in adaptation process.

WCAG 1.0

WCAG 2.0

MWBP

5.3, 5.4

1.3.2 Meaningful Sequence

tables layout, Tables nested and tables alternatives

Information conveyed only using CSS (visual formatting): User is unable to access some information encoded in visual formatting or in CSS. Disabilities Context User who is blind doesn’t perceive visual formatting effects.

Mobile Context Often no CSS support or diverging CSS support by mobile browser.

WCAG 1.0

WCAG 2.0

MWBP

6.1

1.3.1 Info and relationship

styles sheets support.

Section 3

3.1.2


15

Operable

User interface components and navigation must be operable. Mouse required for interaction and navigation: User is unable to navigate all content, or wastes time moving through numerous links. Disabilities Context Some users with a motor disability cannot use a mouse. Users who are blind also do not use the mouse.

Mobile Context Device has no mouse, only alphanumeric keypad or joystick.

WCAG 1.0

WCAG 2.0

MWBP

6.3, 6.4, 6.5, 8.1

2.1 Keyboard Accessible.

objects or script.

Scripting required to operate content: User cannot operate the content so loses some information. Disabilities Context User’s assistive technology or browser doesn’t support scripting.

Mobile Context Scripting turned off or not supported.

WCAG 1.0

WCAG 2.0

MWBP

6.3, 6.4, 6.5 and 8.1.

Conformance objects or script. Requirement 4: Only AccessibilitySupported Ways of Using Technologies, Conformance Requirement 5: NonInterference..

16

Yeliz Yesilada

Special plugin required: User can not perceive content or can not operate interface. Disabilities Context Plugin turned off, or not installed, or not compatible with assistive technology. Plugin not operable with preferred input device.

Mobile Context Plugin turned off or not installed; not compatible with input device (for example, requires mouse).

WCAG 1.0

WCAG 2.0

MWBP

11.1.

2.1.1 Keyboard, 2.1.3 Keyboard (No Exception)

objects or script.

Missing or inappropriate page title: User cannot easily scan to get an overview because of missing, inappropriate, or long page title. Disabilities Context User who is blind typically uses a screen reader feature to get a list of the currently open windows, by window title. Therefore, if the page title is long, inappropriate or missing, user cannot perceive the content.

Mobile Context Page title truncated to fit narrow viewport of mobile device.

WCAG 1.0

WCAG 2.0

MWBP

13.2.

2.4.2 Page titled

page title.

Section 3


17

Inconsistency between focus (tab) order and logical document content sequence: User is unable to navigate content in logical sequence, becomes disoriented. Disabilities Context User with (for example) motor disability uses keyboard for navigation not mouse.

Mobile Context Mobile devices may not have a pointing device so the user may have to navigate elements serially.

WCAG 1.0

WCAG 2.0

MWBP

9.4.

2.4.3 Focus order.

tab order.

Non descriptive link label: User cannot determine to follow or not to follow a link because the link label is not descriptive enough. Disabilities Context User can not determine purpose of a link when read out of context. User who is blind often accesses a list of links on a page without the context around them.

3.1.3

Mobile Context User can not determine purpose of link.

WCAG 1.0

WCAG 2.0

MWBP

13.1.

2.4.4 Link Purpose (In Context) and 2.4.4 Link Purpose (Link only).

link target id.

Understandable

Information and the operation of user interface must be understandable.

Long words, long and complex sentences, jargon: User has difficulty understanding information.

18

Disabilities Context Users with some types of cognitive disabilities have difficulty processing information. Users who are deaf and whose native language is sign, have difficulty processing complex written language.

Yeliz Yesilada

Mobile Context Text is displayed in small font, and user is often distracted by ambient conditions (background noise, conversations, moving objects in field of vision).

WCAG 1.0

WCAG 2.0

MWBP

14.1.

3.1.5 Reading level.

suitable and clarity.

Content spawning new windows without warning user: User becomes disoriented among windows; back button doesn’t work. User closes window, not realizing it is last in stack, closing browser instance. Disabilities Context User with low vision, or restricted field of vision, or blindness, or cognitive disabilities doesn’t realize active window is new.

Mobile Context Single window interface. Multiple stacked windows on small screen hide each other.

WCAG 1.0

WCAG 2.0

MWBP

10.1.

3.1.2 On focus, 3.2.2 On input and 3.2.5 Change on request.

pop ups.

Section 3


19

Blinking, moving, scrolling or auto-updating content: User has difficulty reading and comprehending content. Disabilities Context People with reading disabilities, cognitive limitations, and learning disabilities do not have sufficient time to read or comprehend information.

3.1.4

Mobile Context Reduced size of mobile viewport or poor ambient lighting make it difficult to see content. Auto-refreshed pages may also have cost implications if they are left open or put unnoticed into the background.

WCAG 1.0

WCAG 2.0

MWBP

7.4 and 7.5.

2.2.2 Pause, Stop, Hide, 3.2.5 Change on request.

auto refresh.

Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Invalid or unsupported markup: User cannot access the content because browser or adaptation system chokes on markup or rejects or garbles it. Disabilities Context User’s assistive technology or browser cannot handle markup.

Mobile Context Some older mobile browsers do not display content with invalid markup.

WCAG 1.0

WCAG 2.0

MWBP

3.2, 11.1 and 11.2.

4.1.1 Parsing.

valid markup.

20

Yeliz Yesilada

Scripting required to generate content: User cannot access the content so loses some information because scripting is not supported by the user agent. Disabilities Context User’s assistive technology or browser doesn’t support scripting.

3.2

Mobile Context Scripting turned off or not supported.

WCAG 1.0

WCAG 2.0

MWBP

6.3

Understanding objects or script. Guideline 4.1.

Common Guidelines: WCAG 1.0 & MWBP 1.0

This section describes the relationships, overlaps and differences between the Web Content Accessibility Guidelines 1.0 (WCAG) and the Mobile Web Best Practices (MWBP). This analysis is a practice to show that there are overlaps between design guidelines. This analysis does not only show that there are overlaps but it also shows that there are different requirements that need to be considered. In the following two sections we show what needs to be done if either WCAG or MWBP is already completed. First section shows what needs to be done to comply with WCAG 1.0 if the document already complies with MWBP, and the section after that shows what needs to be done to comply with WCAG 1.0 if the document already complies with MWBP. Detailed information can be found in [23]. 3.2.1

From WCAG 1.0 to MWBP 1.0

This section provides guidance on the upgrade path from MWBP 1.0 to accessibility through WCAG 1.0 compliance. For each of the WCAG 1.0 priorities there are three possible levels of effort required, labelled for simplicity with keywords (nothing, something, everything): Nothing: The following list shows the best practices that are covered if content already complies with WCAG 1.0. Therefore, the list mainly shows direct overlaps between accessibility guidelines specified in WCAG 1.0 and best practices specified in MWBP. • Non-Text Alternatives, covered by 1.1 Provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content). • Use of color, covered by 2.1 Ensure that all information conveyed with color is also available without color. . . • Navigation, covered by 13.4 Use navigation mechanisms in a consistent manner. • Pop ups, covered by 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear,. . . • Provide Defaults, covered by 10.4 Until user agents handle empty controls correctly. . . • Redirection, covered by 7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. . .

Section 3


21

• Style Sheets Support, covered by 6.1 Organize documents so they may be read without style sheets. • Tab order, covered by 9.4 Create a logical tab order through links, form controls, and objects. • Auto Refresh, covered by 7.4 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. . . • Clarity, covered by 13.8 Place distinguishing information at the beginning of headings, paragraphs. . . • Control Labelling, covered by 12.4 Associate labels explicitly with their controls • Link Target Id, covered by 13.1 Clearly identify the target of each link. • Measures, covered by 3.4 Use relative rather than absolute units in markup language attribute values. . . • Objects or script, covered by 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. . . • Structure, covered by 3.5 Use header elements to convey document structure. . . • Style Sheets Use, covered by 3.3 Use style sheets to control layout and presentation. • Valid markup, covered by 3.2 Create documents that validate to published formal grammars. • Graphics for spacing, covered by 3.1 When an appropriate markup language exists, use markup. . . Something: The following list shows the best practices that are not completely covered by the accessibility guidelines. However, they still show that there are overlaps between accessibility and mobile Web guidelines. • Color contrast, partially covered by 2.2 Ensure that foreground and background color combinations provide sufficient contrast. . . • Control Position, partially covered by 10.2 Until user agents support explicit associations between labels. . . • Page size usable, partially covered by 12.3 Divide large blocks of information into more manageable groups where natural and appropriate. • Access keys, partially covered by 9.5 Provide keyboard shortcuts to important links. . . • Background Image Readability, partially covered by 2.2 Ensure that foreground and background color combinations provide sufficient contrast. . . • Central Meaning, partially covered by 13.6 Group related links, identify the group (for user agents). . .

22

Yeliz Yesilada

• Fonts, partially covered by 6.1 Organize documents so they may be read without style sheets. • Image maps, possibly covered by 1.2 Provide redundant text links for each active region of a server-side image map, 9.1 Provide client-side image maps instead of server-side image maps and 1.5 Until user agents render text equivalents for clientside image map links, provide redundant text links for each active region of a clientside image map. • Navbar, partially covered by 13.5 Provide navigation bars to highlight and give access to the navigation mechanism. • Page title, possibly covered by 13.2 Provide metadata to add semantic information to pages and sites. . . • Tables alternatives, possibly partially covered by 5.3 Do not use tables for layout unless the table makes sense when linearized. . . • Tables layout, possibly covered by 5.3 Do not use tables for layout unless the table makes sense when linearized. . . Everything: These are the best practices that are not related to the accessibility guidelines. They show the major differences between the requirements for accessibility and the mobile Web: Balance, Avoid free text, Error messages, Default input mode, Scrolling, Testing, Thematic consistency, Uris, Minimize keystrokes, No frames, Tables nested, Tables support, Caching, Capabilities, Character-encoding-support, Character encoding use, Content format preferred, Content format support, Cookies, Deficiencies, External resources, Images resizing, Images specify size, Large-graphics, Limited, Link target format, Minimize, Page size limit, Style sheets size, Suitable. 3.2.2

From MWBP 1.0 to WCAG 1.0

This section provides guidance on the upgrade path from WCAG 1.0 to MWBP 1.0 compliance. For each of the WCAG 1.0 priorities there are three possible levels of effort required, labelled for simplicity with keywords (nothing, something, everything): Nothing: This list shows the WCAG 1.0 checkpoints that are already fully covered by the Mobile Web best practices. These are quite important to show the overlaps. • 1.1 (Priority 1) Provide a text equivalent for every non-text element (e.g., via alt longdesc or in element content), covered by Non-Text alternatives and possibly covered by Image maps. • 2.1 (Priority 1) Ensure that all information conveyed with color is also available without color, for example from context or markup, covered by Use of color. • 6.1 (Priority 1) Organize documents so they may be read without style sheets, covered by Style sheets support and partially covered by Fonts.

Section 3


23

• 6.3 (Priority 1) Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported, covered by Objects or script. • 3.2 (Priority 2) Create documents that validate to published formal grammars, covered by valid markup. • 3.3 (Priority 2) Use style sheets to control layout and presentation, covered by Style Sheets use. • 3.4 (Priority 2) Use relative rather than absolute units in markup language attribute values and style sheet property values, covered by Measures. • 3.5 (Priority 2) Use header elements to convey document structure and use them according to specification, covered by Structure. • 7.5 (Priority 2) Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects, covered by Redicrection. • 10.1 (Priority 2) Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user, covered by Pop ups. • 12.4 (Priority 2) Associate labels explicitly with their controls, covered by Control labelling. • 13.4 (Priority 2) Use navigation mechanisms in a consistent manner, covered by Navigation. • 9.4 (Priority 3) Create a logical tab order through links, form controls, and objects, covered by Tab order. • 9.5 (Priority 3) Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls, covered by Access keys, possibly partially covered by Image maps and possibly partially covered by Minimize keystrokes. • 10.4 (Priority 3) Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas, covered by Provide defaults. • 13.8 (Priority 3) Place distinguishing information at the beginning of headings, paragraphs, lists, etc., covered by clarity. Something: This list shows the WCAG 1.0 checkpoints that are partially covered by the Mobile Web best practices. They require more effort of some kind or a check, to comply with these checkpoints: • 1.2 (Priority 1) Provide redundant text links for each active region of a server-side image map, partially covered by Non-text alternatives and possibly covered by Image maps. • 5.1 (Priority 1) For data tables, identify row and column headers, possibly covered by Tables support and Tables alternatives.

24

Yeliz Yesilada

• 5.2 (Priority 1) For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells, possibly covered by Tables support, Tables nested and Tables alternatives. • 6.2 (Priority 1) Ensure that equivalents for dynamic content are updated when the dynamic content changes, possibly partially covered by objects or script. • 9.1 (Priority 1) Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape, possibly covered by image maps. • 12.1 (Priority 1) Title each frame to facilitate frame identification and navigation, possibly covered by no frames. • 14.1 (Priority 1) Use the clearest and simplest language appropriate for a site’s content, partially covered by clarity. • 2.2 (Priority 2) Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen (for images), partially covered by Color contrast and Background image readability. • 3.1 (Priority 2) When an appropriate markup language exists, use markup rather than images to convey information, possibly partially covered by Non-text alternatives and graphics for spacing. • 5.3 (Priority 2) Do not use tables for layout unless the table makes sense when linearized, possibly covered by tables layout, Tables support and Tables alternatives. • 5.4 (Priority 2) If a table is used for layout, do not use any structural markup for the purpose of visual formatting possibly covered by Tables layout, Tables support and Tables alternatives. • 7.4 (Priority 2) Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages, covered by Auto refresh. • 10.2 (Priority 2) Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned, partially covered by Control position. • 11.1 (Priority 2) Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported, possibly partially covered by Valid markup. • 11.2 (Priority 2) Avoid deprecated features of W3C technologies possibly partially covered by Valid markuo and partially covered by Fonts. • 12.2 (Priority 2) Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone, possibly covered by No Frames.

Section 3


25

• 12.3 (Priority 2) Divide large blocks of information into more manageable groups where natural and appropriate, partially covered by Page size usable. • 13.1 (Priority 2) Clearly identify the target of each link, partially covered by Link target id. • 13.2 (Priority 2) Provide metadata to add semantic information to pages and sites, partially covered by Page title. • 1.5 (Priority 3) Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map, possibly covered by image maps and Non-text alternatives. • 2.2 (Priority 3) Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen (for images), partially covered by Color Contrast • 5.5 (Priority 3) Provide summaries for tables, possibly covered by Tables support and Tables alternatives. • 5.6 (Priority 3) Provide abbreviations for header labels, possibly covered by Tables support and Tables alternatives. • 10.3 (Priority 3) Until user agents (including assistive technologies) render side-byside text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns, possibly partially covered Tables alternatives. • 13.5 (Priority 3) Provide navigation bars to highlight and give access to the navigation mechanism, possibly Navbar. • 13.6 (Priority 3) Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group, possibly Navbar and partially possibly Central meaning. Everything: start from scratch to comply with these checkpoints: • 1.3 (Priority 1) Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. • 1.4 (Priority 1) For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. • 4.1 (Priority 1) Clearly identify changes in the natural language of a document’s text and any text equivalents (e.g., captions). • 7.1 (Priority 1) Until user agents allow users to control flickering, avoid causing the screen to flicker.

26

Yeliz Yesilada

• 8.1 (Priority 1) Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies (priority 1 if functionality is important and not presented elsewhere). • 11.4 (Priority 1) If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. • 3.6 (Priority 2) Mark up lists and list items properly. • 3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation. • 6.4 (Priority 2) For scripts and applets, ensure that event handlers are input deviceindependent. • 6.5 (Priority 2) Ensure that dynamic content is accessible or provide an alternative presentation or page. • 7.2 (Priority 2) Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). • 7.3 (Priority 2) Until user agents allow users to freeze moving content, avoid movement in pages. • 8.1 (Priority 2) Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies (priority 1 if functionality is important and not presented elsewhere). • 9.2 (Priority 2) Ensure that any element that has its own interface can be operated in a device-independent manner. • 9.3 (Priority 2) For scripts, specify logical event handlers rather than device-dependent event handlers. • 13.3 (Priority 2) Provide information about the general layout of a site (e.g., a site map or table of contents). • 4.2 (Priority 3) Specify the expansion of each abbreviation or acronym in a document where it first occurs. • 4.3 (Priority 3) Identify the primary natural language of a document. • 10.5 (Priority 3) Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. • 11.3 (Priority 3) Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)

Section 4

RIAM Framework and Methodology

27

• 13.7 (Priority 3) If search functions are provided, enable different types of searches for different skill levels and preferences. • 13.9 (Priority 3) Provide information about document collections (i.e., documents comprising multiple pages.). • 13.10 (Priority 3) Provide a means to skip over multi-line ASCII art. • 14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. • 14.3 (Priority 3) Create a style of presentation that is consistent across pages.s

4

RIAM Framework and Methodology

As can be seen from the previous section, on closer inspection of these two domains, we observe that there are a lot of similarities and commonalities – the challenges for designing for the mobile Web are similar to those of designing for the Accessible Web [60, 44]. However, despite these commonalities, there has been very limited work on systematically comparing these two domains. Unfortunately, previous work has only looked at accessibility problems from a single user group perspective such as visually impaired [5], motor impaired [46] or small device users [10]. If designers want to create a page which is accessible by both mobile and disabled users, they have to follow a number of different guidelines and validation tools30 which means it will be time consuming and costly.

4.1

RIAM Framework

Our aim is to investigate ways in which to integrate research into the accessible and mobile Webs and to develop a common infrastructure. To compare and contrast these two domains, we have created a framework which amalgamates all the components that need to be considered to model a neutral Human-Web interaction. This framework is illustrated in Figure 1 and consists of the following four main components: 1. Input refers to various approaches and devices used to deliver information to the Web. Although the desktop users usually provide input via standard keyboard and mouse, there is an enormous range of options available to people who cannot use these standard input devices [36]. Similarly, there are many text entry mechanism for small device users based on the phone keypad and novel input devices (e.g., speech commands) [45]. The input part of our framework covers all of these devices and techniques. 2. Content is the information that forms Web sites and Web applications, the code and markup that define the structure, presentation, and interaction, as well as text, images, and sounds that convey information to the end-user [22]. To be more specific, content refers to both HTML/XHTML content of a Web page and presentation encoded with CSS31 which could be in a separate file. 30 31

Web accessibility evaluation tools, http://www.w3.org/WAI/ER/tools/. Cascading Style Sheets (CSS), http://www.w3.org/Style/CSS/.

28

Yeliz Yesilada

Figure 1: The Human-Web-Interaction Framework.

3. Authoring environment refers to any application that developers (professionals or nonprofessionals [7]) use to create or modify Web content [22]. These include WYSIWYG (what-you-is-what-you-get) tools designed to produce Web content, word processor tools, content management tools and tools that are designed for non-professional Web authoring (e.g., iWeb or Google Page Creator or blogging applications) [51]. 4. Output refers to the rendering of the Web content by a particular user agent. User agents are tools used by end-users to view and interact with content including Web browsers, media players, and assistive technologies32 . The RIAM framework also includes the following two supporting components which play an important role in the mobile Web: a) Device and network capabilities refers to the processing capabilities of the client-side device and stands for the communication between a client device and the Web server which can be quite important for the mobile Web. The capabilities include bandwidth, battery, processing power and voice and multimodality features [52] which can have high impact on the mobile Web users’ experience. For example, battery capacity is very constrained in mobile devices and certain activities tend to increase power consumption and shorten battery life. Similarly, basic mobile access often offers lower bandwidth than a fixed desktop connection. b) Context refers to any information that characterises a situation related to the interaction between humans, applications, and the surrounding environment [27]. The parameters defining context can be captured by answering the questions: why, when, where and how the user is going to access a Web page. Some example context parameters include the setting (physical environment) (e.g., a mobile device is used indoor, outdoor, etc.), behavioural environment (gestures of people near by), the task (s) at hand (e.g., walking, 32

Assistive technologies refer to hardware and software designed to facilitate the use of computers by people with impairments [28].

Section 5

Conclusion

29

talking, etc.) which could cause partial attention problem or multi-tasking issues [48, 55]. This framework provides the foundational components of a neutral Human-Web interaction that can be used to compare the mobile Web with the accessible Web. In RIAM project, we aim to cover the four main components.

4.2

Methodology

We first survey existing literature and identify problems experienced by both disabled desktop users and the mobile Web users, along with corresponding solutions. Our survey focuses on six user groups: motor impaired, visually impaired, hearing impaired, cognitive impaired, aging desktop users and small screen device users. The survey indicates intersections and gaps of problems between domains in the literature. Based on the survey, we pick up common problems that are likely to affect both domains but have not been confirmed by any empirical study. Then we repeat the user study that was originally conducted with disabled desktop users and reproduce it with mobile Web users. If the user study confirms the existence of common problems between domains, we can suggest solution migrations in order to address them. As the mobile Web field is relatively new compared with the accessibility field, more solutions can be transferred from the accessibility domain to the mobile Web domain.

5

Conclusion

This report presented a survey of the existing work in both mobile Web and accessible Web. This survey enabled us to identify intersections, deifferences and un-addressed areas within existing guidelines and best practices so that we could devise a cohesive framework. This report then introduces the RIAM framework and explains the different components that the rest of the project focuses on. These components include input which refers to various approaches and devices used to deliver information to the Web, content which is the information that forms Web pages, the code and markup, authoring environment which refers to any application that is used to create or modify content and output refers to the rendering of the Web content by a particular user agent. Detailed information about these components can be found in Deliverable “2.1: RIAM Framework: Content”, “2.2: RIAM Framework: Output” and “2.3: RIAM Framework: Input”.

References [1] Section 508 standards. Access Board of the U.S. Federal Government. http:// www.section508.gov/. [2] A Report Into Key Government Web Sites. Interactive Bureau, UK, 2002. http: //www.iablondon.com/. [3] Ibm web accessibility guidelines. IBM, 2004. http://www-03.ibm.com/ able/guidelines/web/accessweb.html.

30

REFERENCES

[4] eAccessibility of Public Sector Services in the European Union. European union policy survey, UK Government Cabinet Office, November 2005. [5] Chieko Asakawa. What’s the web like if you can’t see it? In W4A ’05, pages 1–8. ACM Press, 2005. [6] Shumeet Baluja. Browsing on small screens: Recasting web-page segmentation into an efficient machine learning framework. In Proceedings of the 15th International Conference on World Wide Web, pages 33–42, 2006. [7] Kynn Bartlett. Accesibility of the blogging revolution. In Technology and Persons with Disabilities Conference (CSUN), 2004. [8] Patrick Baudisch, Xing Xie, Chong Wang, and Wei-Ying Ma. Collapse-to-zoom: Viewing web pages on small screen devices by interactively removing irrelevant content. In 17th Annual ACM Symposium on User Interface Software and Technology (UIST 2004), 2004. [9] T.W. Bickmore and B.N. Schilit. Digestor: Device-independent access to the World Wide Web. In Proceedings of the Sixth International World Wide Web Conference, pages 655–663, 1997. [10] Stephen Brewster. Overcoming the lack of screen space on mobile computers. Personal and Ubiquitous Computing, 6, 2002. [11] S. Brown. The Web Access Gateway. http://www.cus.cam.ac.uk/∼ssb22/ access.html. [12] O. Buyukkokten, H. Garcia-Molina, and A. Paepcke. Proceedings of the tenth international world-wide web conference. In Seeing the Whole in Parts: Text Summarization for Web Browsing on Handheld Devices, 2000. [13] O. Buyukkokten, H.G. Molina, and A. Paepcke. Accordion summarization for endgame browsing on PDAs and cellular phones. In Proceedings of the SIGCHI conference on Human factors in computing systems, pages 213–220. ACM Press, 2001. [14] O. Buyukkokten, H.G. Molina, A. Paepcke, and T. Winograd. Power browser: Efficient web browsing for PDAs. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 430–437. ACM Press, 2000. [15] Orkut Buyukkokten, Hector Garcia-Molina, and Andreas Paepcke. Focused web searching with pdas. Computer Networks, 33(1-6):213–230, 2000. [16] B. Caldwell, M. Cooper, L.G. Reid, and G. Vanderheiden. Web Content Accessibility Guidelines 2.0 (WCAG 2.0). W3C, 2008. http://www.w3.org/TR/WCAG20/. [17] Ben Caldwell, Michael Cooper, Loretta Guarino Reid, and Gregg Vanderheiden. Understanding wcag 2.0. W3C, 2008. http://www.w3.org/TR/ UNDERSTANDING-WCAG20/.

REFERENCES

31

[18] Minhee Chae and Jinwoo Kim. Do size and structure matter to mobile users? an empirical study of the effects of screen size, information structure, and task complexity on user activities with standard web phones. Behaviour and Information Technology, 23(3):165–181, 2004. [19] J. Chen, B. Zhou, J. Shi, H. Zhang, and Q. Wu. Function-based object towards website adaptation. In Proceedings of the Tenth International World Wide Web Conference, Hong Kong, 2001. ACM. [20] Y. Chen, W.Y. Ma, and H.J. Zhang. Detecting web page structure for adaptive viewing on small form factor devices. In Proceedings of the Twelfth International World Wide Web Conference, 2003. [21] Wendy Chisholm, Gregg Vanderheiden, and Ian Jacobs. Web content accessibility guidelines 1.0. W3C, 1999. http://www.w3.org/TR/WAI-WEBCONTENT/. [22] Wendy A. Chisholm and Shawn Lawton Henry. Interdependent components of web accessibility. In W4A ’05: Proceedings of the 2005 International Cross-Disciplinary Workshop on Web Accessibility (W4A), pages 31–37. ACM Press, 2005. [23] Alan Chuter and Yeliz Yesilada. Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG). W3C, 2008. http: //www.w3.org/TR/mwbp-wcag/. [24] Codix. Textualize, 2003. http://codix.net/solutions/products/ textualise/index.html. [25] Kara Pernice Coyne and Jakob Nielsen. Beyond ALT text: Making the web easy to use for users with disabilities. Nielson Norman Group, 2001. [26] Jenny Craven and Peter Brophy. Non-visual access to the digital library: the use of digital library interfaces by blind and visually impaired people, 2003. Library and Information Commission Research Report 145. [27] Anind K. Dey, Gregory D. Abowd, and Daniel Salber. A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Human Computer Interaction, 16(2, 3 & 4):97–166, 2001. [28] Disability Rights Commission (DRC). The web: Access and inclusion for disabled people, 2004. [29] DRC. PAS 78: a guide to good practice in commissioning accessible websites, 2006. [30] Becky Gibson. Enabling an accessible web 2.0. In W4A ’07: Proceedings of the 2007 international cross-disciplinary conference on Web accessibility (W4A), pages 1–6. ACM Press, 2007. [31] Jon Gunderson and Ian Jacobs. User agent accessibility guidelines 1.0. W3C, 1999. http://www.w3.org/TR/WAI-USERAGENT/.

32

REFERENCES

[32] W. Harpe, J. Kingsbury, and J. Hassell. Accessibility study of BBCi: Problems faced by users with disabilities. Technical report, System Concepts Ltd., 2003. [33] Simon Harper and Sean Bechhofer. SADIe: Structural–semantics for accessibility and device independence. ACM Trans. Comput.-Hum. Interact, 14(2), 2007. [34] Simon Harper, Yeliz Yesilada, and Carole Goble. Building the Mobile Web: Rediscovering Accessibility?: W4A - International Cross-Disciplinary Workshop on Web Accessibility Workshop Report - 2006, 2006. [35] Gen Hattori, Keiichiro Hoashi, Kazunori Matsumoto, and Fumiaki Sugaya. Robust web page segmentation for mobile terminal using content-distances and page layout information. In WWW ’07: Proceedings of the 16th international conference on World Wide Web, pages 361–370, New York, NY, USA, 2007. ACM Press. [36] Stephen W. Hawking and Alliance for Technology Access. Computer Resources for People With Disabilities: A Guide to Assistive Technologies, Tools, and Resources for People of All Ages. Hunter House Publisher, fourth edition, 2004. [37] Adam Badani Helen Petrie and Arpna Bhalla. Sex, lies and web accessibility: the use of accessibility logos and statements on e-commerce and financial websites. In Accessible Design in the Digital World Conference 2005, 2005. [38] J. Howell. Get the message online. Royal National Institute of Blind (RNIB), 2000. [39] M. Jones, G. Marsden, N. Mohd-Nasir, K. Boone, and G. Buchanan. Improving Web interaction on small displays. Computer Networks, 31(11–16):1129–1137, 1999. [40] Oliver Kaljuvee, Orkut Buyukkokten, Hector Garcia-Molina, and Andreas Paepcke. Efficient web form entry on pdas. In WWW ’01: Proceedings of the 10th international conference on World Wide Web, pages 663–672, 2001. [41] Shaun K. Kane, Jessie A. Shulman, Timothy J. Shockley, and Richard E. Ladner. A web accessibility report card for top international university web sites. In W4A ’07: Proceedings of the 2007 international cross-disciplinary conference on Web accessibility (W4A), pages 148–156, New York, NY, USA, 2007. ACM Press. [42] Brian Kelly. Webwatch: An accessibility analysis of UK university entry points. Technical report, The University of Bath- Ariadne Issue 33, 2002. http://www. ariadne.ac.uk/issue33/web-watch/. [43] Johan Kildal and Stephen Brewster. Non-visual overviews of complex data sets. In CHI 2006, Montreal, Quebec, Canada, 2006. [44] Aaron Leventhal. Structure benefits all. In W4A: Proceedings of the 2006 international cross-disciplinary workshop on Web accessibility (W4A), pages 33–37, New York, NY, USA, 2006. ACM Press. [45] I. Scott MacKenzie and R. William Soukoreff. Text entry for mobile computing: models and methods, theory and practice. Human-Computer interaction, Volume 17:147– 198, 2002.

REFERENCES

33

[46] Jennifer Mankoff, Anind Dey, Udit Batra, and Melody Moore. Web accessibility for low bandwidth input. Proceedings of the fifth international ACM conference on Assistive technologies, pages 17–24, 2002. [47] W. Myers. BETSIE:BBC Education Text to Speech Internet Enhancer. British Broadcasting Corporation (BBC) Education, 2002. http://www.bbc.co.uk/ education/betsie/. [48] Antti Oulasvirta, Sakari Tamminen, Virpi Roto, and Jaana Kuorelahti. Interaction in 4-second bursts: the fragmented nature of attentional resources in mobile hci. In CHI ’05: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 919–928, New York, NY, USA, 2005. ACM Press. [49] Michael Paciello. Web accessibility for people with disabilities. CMP books, CMP media LLC, 2000. [50] Mark Pilgrim. Dive Into Accessibility: 30 days to a more accessible web site. Online, 2002. [51] Christopher Power and Helen Petrie. Accessibility in non-professional web authoring tools: a missed web 2.0 opportunity? In W4A ’07: Proceedings of the 2007 international cross-disciplinary conference on Web accessibility (W4A), pages 116–119, New York, NY, USA, 2007. ACM Press. [52] Jo Rabin and Charles McCathieNevile. http://www.w3.org/TR/mobile-bp/.

Mobile Web Best Practices 1.0, 2005.

[53] Loretta Guarino Reid and Andi Snow-Weaver. Wcag 2.0: a web accessibility standard for the evolving web. In W4A ’08: Proceedings of the 2008 international crossdisciplinary conference on Web accessibility (W4A), pages 109–115, New York, NY, USA, 2008. ACM. [54] J. Richards and V. Hanson. Web accessibility: A broader view. In WWW2004, pages 72–79. ACM Press, 2004. [55] Virpi Roto and Antti Oulasvirta. Need for non-visual feedback with long response times in mobile hci. In WWW ’05: Special interest tracks and posters of the 14th international conference on World Wide Web, pages 775–781, New York, NY, USA, 2005. ACM Press. [56] L. Seeman. The semantic web, web accessibility, and device independence. In S. Harper, Y. Yesilada, and C. Goble, editors, Proceedings of the international crossdisciplinary workshop on Web accessibility (W4A), pages 67–73, 2004. [57] H. Takagi and C. Asakawa. Transcoding proxy for nonvisual web access. In ASSETS’00, pages 164–171. ACM Press, 2000. [58] Jim Thatcher, Cynthia Waddell, Shawn Henry, Sarah Swierenga, Mark Urban, Michael Burks, Bob Regan, and Paul Bohman. Constructing Accessible Web Sites. Glasshaus, 2002.

34

REFERENCES

[59] Jutta Treviranus, Charles McCathieNevile, Ian Jacobs, and Jan Richards. Authoring tool accessibility guidelines 1.0. W3C, 2000. http://www.w3.org/TR/ ATAG10/. [60] Shari Trewin. Physical usability and the mobile web. In W4A: Proceedings of the 2006 international cross-disciplinary workshop on Web accessibility (W4A), pages 109–112, New York, NY, USA, 2006. ACM Press. [61] UsableNet. LIFT Text Transcoder, 2003. http://www.usablenet.com/. [62] Mark Wilton-Jones. Comparison of http://www.howtocreate.co.uk/operaStuff/devices/.

mobile

web

browsers.

[63] C.C. Yang and F.L. Wang. Fractal summarization for mobile devices to access large documents on the web. In Proceedings of the Twelfth International World Wide Web Conference, 2003. [64] Yeliz Yesilada, Alan Chuter, and Shawn Lawton Henry. Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities. W3C, 2008. http://www.w3.org/WAI/mobile/experiences. [65] Yeliz Yesilada, Robert Stevens, Simon Harper, and Carole Goble. Evaluating DANTE: Semantic transcoding for visually disabled users. ACM Trans. Comput.-Hum. Interact., 14(3):14, 2007. [66] X. Yin and W.S. Lee. Using link analysis to improve layout on mobile devices. In Proceedings of the Thirteenth International World Wide Web Conference, pages 338– 344, 2004.

Section 6

6

Associated Files

35

Associated Files

Please refer to the previous RIAM Deliverables at: http://hcw-eprints.cs.man. ac.uk/view/subjects/riam.html.

RIAM Framework: Overlaps between Mobile and Ac ... - CiteSeerX

RIAM Framework: Overlaps between Mobile and Ac ... - CiteSeerX

Suggest Documents

RIAM Framework: Overlaps between Mobile and Ac ... - CiteSeerX

ECO algorithms for removing overlaps between power ... - CiteSeerX

ECO algorithms for removing overlaps between power ... - CiteSeerX

Overlaps between Human Resources' Strategic ... - Science Direct

Overlaps between Human Resources' Strategic ... - Science Direct

Framework for realizing Mobile and Computer ... - CiteSeerX

Functional overlaps between XLF and the ATM-dependent DNA ...

delineating overlaps in teaching small business ... - CiteSeerX

Comparison between AC and MF-DC resistance spot ... - CiteSeerX

A SOFTWARE FRAMEWORK FOR MOBILE ROBOT ... - CiteSeerX

A Framework for Mobile Collaborative Environments - CiteSeerX

Mobilim: Mobile Learning Management Framework ... - CiteSeerX

delineating overlaps in teaching small business ... - CiteSeerX

Correlation Between AC Core Loss and Surface

S2 Fig. Statistical significance of overlaps between protein ... - PLOS

Two Efficient Techniques to Find Approximate Overlaps between ...

Mobile Peer-to-peer Collaborative Framework and ... - CiteSeerX

Yet Another Framework for Supporting Mobile and ... - CiteSeerX

A Situated Computing Framework for Mobile and ... - CiteSeerX

Yet Another Framework for Supporting Mobile and ... - CiteSeerX

FlashLight: Optical Communication between Mobile ... - CiteSeerX

Mobile Computing Decision Framework

comparison between line conditioners with the ac-ac converter ...

A Comparison Between Two Average Modelling Techniques of AC-AC ...