Mobile Web Best Practices 1.0

5.1.1.1 What it means

Many This is a realization of the best practice statements refer to the One Web (see 3.1 One Web ) principle, whereby content provider knowing should be accessible on a significant amount about the characteristics range of the device, the properties devices irrespective of the browser differences in use presentation capabilities and access mechanism. Web sites may paginate their content in various ways corresponding to differences in device characteristics; therefore the transparency navigation structure of the network connection site, and possibly its technical realization, may vary according to the device. For simple sites device class that present an interface which is similar across a broad range of clients the need for such information is diminished when compared with a sophisticated site which has an optimized navigation structure, presents different size images or carries out other adaptations to suit the client. being served. (See also [WebArch] Section 3.5.1 ).

It is unlikely that the content provider, "having taken all reasonable steps", will know nothing at all about the context of the device. However if absolutely nothing is known "a reasonable default experience" A bookmark captured on one device should be provided. The details of the default experience depend upon a number usable on another, different type of factors including, but device even if it does not limited to, yield exactly the geographic region in which same experience. If the service page that was bookmarked is offered and the primary intention of the service (e.g. considering whether not appropriate for the service device that is primarily desktop focused vs. primarily mobile focused). Where the determination of the default experience has resulted in selection of a mobile experience, the default delivery context now using it, an alternative that is suitable should be assumed in creating that presentation. provided.

The content provider URIs may choose, in the interests of "One Web" considerations, be decorated to allow provide session or other information. If a URI is decorated with session information that is no longer current, then the user should be directed to select the experience from broad categories such as mobile or desktop, where these presentations are distinguished a point in the application. 5.1.1.2 How navigation hierarchy that is appropriate to do it There are several techniques by which a content provider can discover information about a client's capabilities: CC/PP, UAPROF, CSS Media Queries, DDWG output, DIWG material. their device, in order to establish appropriate session and other parameters.

5.1.2.1 What it means

While encouraging content providers to be sensitive to the needs of the default delivery context, Default Delivery Context, it is not intended that this results will result in a diminished experience on more capable devices. Specifically it is not the intention to encourage the development of sites that target the default delivery context Default Delivery Context when a better user experience could be attained on more capable devices.

5.1.3.1 What it means

Just as in the desktop browser world, there are browsers that do not respect the intentions of the content provider. There are differences in interpretation between browsers and there are also deficiencies in implementation. By deficient we mean non-support of mandatory features of a relevant standard or recommendation and other bugs or errors in implementation.

Because the software in mobile devices is frequently embedded in the device device, there is no easy way to correct or enhance software it once it is in the field. It is a particular challenge to provide work-arounds for these deficiencies and differences in interpretation. It is recognized that content providers may need to violate specific best practices Best Practices in order to support their intentions on devices that exhibit deficiencies in implementation. If a device is not known to have specific limitations then content providers must comply with best practices. Best Practices.

Just as it is not the intention to recommend a least common denominator approach, it neither is not it the intention to recommend avoidance of avoiding features that exhibit problems on some class of devices.

It is also not the intention to suggest that content providers should restrict their support to certain client device types. Content providers should aim to support as wide a range of client device types as is practical.

5.1.4.1 What it means

Any web Web site should be tested in a range of browsers. Mobile browsers often show markedly different characteristics to desktop browsers. As well as assessing a site's suitability for display in reduced format, content providers are encouraged to test that the features they rely on work in actual devices.

5.1.4.2 How to do it

Many manufacturers provide emulators for their device that can provide a convenient preliminary means of testing. However, in practice, many of the emulators behave in a different way to the devices they emulate. Consequently testing should be carried out in as wide a range of real devices and specific software versions as is practical.

5.2.1.1 What it means

Typing URIs on mobile devices can be difficult, so and it is expected that users will prefer to use alternative methods of obtaining URIs when available - such as following a hyperlink (from an e-mail, SMS or other Web page), WAP Push, 2D bar code, color bar code, RFID tag and Bluetooth. However, typing a URI may in some cases be the only option available. By keeping site entry point URIs short can it is possible to reduce the chance of error and provide a more satisfactory user experience.

5.2.1.2 How to do it

The user When accessing site entry points users should not need have to type enter a filename as part of the default page filename. URI. If possible, configure Web sites so that they can be accessed without having to specify a sub-domain as part of the URI.

Example: Instead of requiring users to type

"http://www.example.org/index.html"

allow

"http://example.org"

and instead of

"www.example.org/example.html"

allow

"example.org/example"

5.2.2.1 What it means

Two or three links should be enough to provide the Provide basic navigation. Navigation navigation, which should be placed on the top of the page. Any other secondary navigational element may be placed at the bottom of the page if really needed. It is important the users should be able to see page content once the page has loaded without scrolling (see 5.3.4 Navigation Bars etc. (Extraneous material) ).

5.2.2.2 How to do it

Provide the basic links on a single line. If they do not fit the screen the device will take care of wrapping.

5.2.3.1 What it means

The design should aim to provide a balance between having an excessive a large number of navigation links on a page and the need to navigate multiple links to reach content. Each

Scrolling a page when there are many links on it can be very cumbersome, as the scrolling action on many mobile devices selects each link in turn. On the other hand, each retrieval of a navigation page takes time and adds cost, so the number of links on a page should not be minimized at the expense of adding page retrievals.

Design the service so that links provide a thematically coherent experience when frequently accessed from a device other than the one on which they were captured. 5.2.4.1 What it means This information is easily reached with a realization of the One Web principle, whereby content should be accessible on a range of devices irrespective minimum number of differences in presentation capabilities. Web sites may paginate their content in various ways corresponding page retrievals. Navigation to differences in device characteristics; therefore the navigation structure of the site, and possibly its technical realization, less frequently accessed information may vary according to the device class that is being served. take more retrievals as a result. A bookmark captured on one device should be usable on another different type of device even if it does not yield exactly the same experience. If the page that was bookmarked is not appropriate for the device that guideline is now using it, an alternative that is suitable should be provided. In addition, URIs may be decorated to provide session or other information. 5.2.4.2 How to do users become frustrated if it If takes more than four retrievals to reach their objective. Whether this can be achieved depends on the URI is decorated with session information that is no longer current then nature of the user should be directed to a point site and, in the navigation hierarchy that is appropriate to their device, particular, how items in order menus group together to establish appropriate session and other parameters. provide understandable themes.

5.2.5.1 5.2.4.1 What it means

Using the same navigation mechanisms across a service helps users orient themselves and allows them to identify navigation mechanisms more easily.

Users of devices that do not have pointing devices have to scroll between hyperlinks using the keypad. Intelligent grouping, perhaps optimized through adaptation according to usage patterns, can assist usability.

5.2.5.2 5.2.4.2 How to do it

A "drill-down" method, based on major headings, can often provide an effective means of navigation; because of the linearized arrangement of content, small screen size and lack of pointing device, it is often useful to provide a means to jump entire sections of content.

At each target of the drill down drill-down navigation an "up" link should be provided to allow the user to jump up an entire section.

5.2.5.3 5.2.4.3 References

This relates to WCAG 13.4 .

5.2.6.1 5.2.5.1 What it means

Where there is no pointing device, assigning an access key (keyboard short cut) to a link can provide a convenient way for users to access the link, link and avoid navigating to the link by repeated pressing of the navigation key . key.

Provide the same access key for links that are repeated across pages such as links to the home page.

5.2.6.2 5.2.5.2 What to test

Machine Test: Test for the presence of the accesskey attribute.

Human Test: Verify the presence of the accesskey attribute on links such as the home page.

5.2.6.3 5.2.5.3 References

This relates to WCAG 9.5 .

5.2.7.1 5.2.6.1 What it means

Users of mobile devices may suffer undue delay and cost as a result of following links. It is important to identify where a link leads so users can make an assessment of whether following it will be of interest to them. While it is unlikely that the cost in monetary terms of a particular user following a particular link can be specified, it should be possible to give an idea of the size of the resource [in (in bytes or in an abstract way e.g., way, e.g. large file]. file).

Links to content that is in a different format to the format that of the page the link is on (i.e. content that can only be interpreted by other applications, applications or downloads) should be human signposted, so that users are not lead to download content that their device may not be able to use. However, bear in mind that some devices support the rendering of those formats by other applications once downloaded (e.g. music files). Additionally, users may wish to download content for later transfer to other devices altogether. So even if it is known that the user agent does not support a particular content type, that content should still be made available.

5.2.7.2 5.2.6.2 How to do it

Use clear, concise, descriptive link text to help users decide whether to follow a link. Identify the implications of following a link if the target is notably large and the user might not anticipate this from the context.

For the Default Delivery Context all formats other than XHTML, GIF and JPG should be noted.

5.2.6.3 What to test

Human Test: Check for proper descriptions (and (e.g. no use of "Click here").

Human and Machine Test: Spider the page/web site to find Check for links to non-HTML formats and formats.

Human Test: If present check whether there is information about the format of the target of the link.

5.2.7.3 5.2.6.4 References

This relates to WCAG 11.3 and 13.1 .

5.2.8.1 5.2.7.1 What it means

Image maps allow fast navigation providing the requesting device can support the image involved and providing there is a means of navigating the map satisfactorily. Up, down, left, right, right and enter are available on most mobile devices, even if there is no pointing device is present, and this device. This is usually sufficient to allow navigation of the active regions of client side client-side image maps. maps where they are defined as geometric shapes.

Many mobile devices lack a pointing device and server-side image maps cannot be used on such devices.

5.2.8.2 5.2.7.2 How to do it

If only small images can be displayed, break larger images up into smaller sections and deal with them separately.

If For the Default Delivery Context ,or if a satisfactory image map cannot be displayed, use a list of links with descriptive text instead.

5.2.8.3 5.2.7.3 What to test

IMAGE_MAPS Machine Test: Send a request to the site with a user agent that does not support client-side image maps and check the map element is not present.

5.2.8.4 5.2.7.4 References

This relates to WCAG 1.2 and 9.1 .

5.2.9.1 5.2.8.1 What it means

Each of these activities is likely to cause the user confusion, or add cost and delay to their interaction.

Some mobile devices use a separate window for input; this section does not refer to such windows.

Many mobile devices cannot support more than one window and consequently consequently, attempting to open one will have unpredictable results.

Auto refreshing Auto-refreshing pages are widely recognized as presenting accessibility problems, and in problems. In a mobile environment they may expose the user to undue cost as a result of an auto refreshing such a page being left open, open or put unnoticed into the background. If an auto refreshing auto-refreshing page is demanded by the application application, always provide a means of ceasing the auto refresh and always inform the user that the page will refresh and may expose them to high higher usage costs.

While redirection is a commonly employed mechanism, it must be remembered that redirection usually requires a round-trip to the browser. This adds to delay on slow links, hence redirection should not be used as links; so use a matter maximum of course. one redirect per page and limit the number of pages that are redirected.

5.2.9.2 5.2.8.2 What to test

POP_UPS Machine Test: Look for the target attribute on links.

AUTO_REFRESH Machine Test: Check whether meta http-equiv="refresh" content=" the content="<the same URI " URI>" is used.

AUTO_REFRESH Human Test: If auto refresh auto-refresh is used, check that options are provided to stop any page using auto-refresh.

REDIRECTION Machine Test: Check whether meta http-equiv="refresh" content=" a content="<a different URI " URI>" is used.

5.2.9.3 5.2.8.3 References

This relates to WCAG 7.4, 7.4 ,7.5 and 10.1 .

5.2.9.1 What it means

Each linked resource (images, style sheets and other objects) requires a separate request across the network. This may add significantly to the load time of the page in the mobile context.

5.2.9.2 How to do it

Minimize the number of images on a page and consolidate style information into a single sheet per page (see also 5.4.9 Style Sheets ).

5.2.9.3 What to test

Machine Test: Count the number of linked images, style sheets and other linked items.

Human Test: Review whether a similar effect could be obtained using fewer links.

5.3.1.1 What it means

Users in a mobile context are often looking for specific pieces of information, rather than browsing. Content providers should consider the likely context of use of information, and information and, while providing the option to access all information, should offer appropriate information first.

The general prescription to use clear language is of particular importance in the for mobile context delivery, where brevity and directness are generally more desirable than a discursive style.

Writing content in the traditional journalistic "front loaded" style can assist users determining whether information is of interest to them and allow them to skip it more easily if it is not. Placing distinguishing information at the beginning of headings, paragraphs, lists, etc. can also help the user contextualize when using devices with limited screen area. See also 5.3.4 Navigation Bars etc. (Extraneous material) for a discussion of making sure that the subject matter of the page is near the top.

In many cases the user pays Mobile users often pay for bandwidth in the mobile context, and bandwidth, so offering the user them content that is extraneous to their needs, especially advertising, costs them time and money and contributes to an unsatisfactory experience. In general, the user's consent should be sought before initiating the download of content.

5.3.1.2 What to test

Human Test: Examine content to determine if, given the subject matter, it is appropriate in a mobile content. [NB probably not machine-testable.] context.

5.3.1.3 References

This relates to WCAG 13.8 and 14.1. 14.1 .

5.3.2.1 What it means

If pages are too big they may take an unduly long time to load. In addition, mobile devices typically have restrictions as to on the largest page they can accommodate.

On the other hand, if pages are too short then the user will be required to make multiple requests to read the relevant information. This can lead to an unnecessary delay delay, since each request typically takes a measurable time to complete.

The balance between pagination and scrolling is partly a matter of taste and partly a matter of necessity. Devices with severe memory restrictions can only have small pages delivered to them. Equally some devices offer a poor scrolling experience and a better page retrieval experience.

Some studies [MF] have been carried out in this area to test for user preferences. Some of these indicate that users prefer scrolling to click-throughs and some indicate the contrary. More research is likely to be needed in this area.

5.3.2.2 How to do it

For the Default Delivery Context assume the limits specified in 3.7 Default Delivery Context .

5.3.2.3 What to test

PAGE_SIZE_USABLE Machine Test: Check that Measure the page doesn't total size of the markup for a page; check that it does not exceed the allowable size for the device - 10 KBytes kilobytes for the default delivery context. Default Delivery Context.

Human Test: Check that the page is still usable (e.g. not cut in the middle of a sentence, just before the end of a section, and so on).

PAGE_SIZE_LIMIT Machine Test: Measure the total size of mark-up markup and images for a page; check that it doesn't does not go over the allowed size for the device - 20 KBytes kilobytes for the default delivery context. Default Delivery Context.

5.3.2.3 5.3.2.4 References

This relates to WCAG 12.3 .

5.3.3.1 What it means

The page should lay out so that simple repeated scrolling in the same direction (axis) allows the user to experience all its content. However some content (such as maps and other images) cannot be displayed without secondary scrolling.

If some element on the page requires secondary scrolling it must not cause the remainder of the page to require this. For example, if an object causes subsequent text to lay out with a significant margin to its left, then this text may not be visible once a user has scrolled past the object.

Equally, if the presence of such an object causes text to render beyond the right boundary of the page then the user will be required to scroll to read each line of text.

5.3.3.2 How to do it

If it is not possible to avoid presenting images that are larger than the screen size, then consider providing these images on a separate page with a link back to the main content.

In the Default Delivery Context assume a width of 120 pixels.

5.3.3.3 What to test

SCROLLING Machine Test: Check for width attributes and width style properties wider than the screen size - for the default delivery context, Default Delivery Context, 120 pixels.

Human Test: If it is wider, wider than the screen size, check that the use case warrants it (e.g. maps).

SCROLLING_LIMIT Human Test: Browse URIs within a site with a mobile user agent and observe that on pages with elements that require secondary scrolling, scrolling only those elements require it it, and the rest of the page requires only primary scrolling.

5.3.4.1 What it means

Many Web pages are designed with significant navigational and other elements at the top of or to the side of the page (e.g. Menu Bars, Breadcrumb Trails, Trails and Search Functions). This provides a convenient and well-understood navigational metaphor on large displays. However, on small displays this can result in the navigation appearing instead of the actual content of the page when the page is first retrieved.

Because it is important for the user to gain an idea of the content of the page on initial view, there should be a minimum amount of clutter preceding this - including navigation, decorative images, advertising and other material that is not central to the user's experience of the page. The user should not have to scroll significantly to find the primary content of the page.

See also 5.3.1 Page Content for a discussion of how writing style can help the user identify meaning.

5.3.4.2 How to do it

Menu selections can be placed away from the top of the page with a simple link to the selection at the top of the page. Alternatively, use meta navigation on top of the page with simple text links to major sections of the web Web site.

5.3.4.3 What to test

Human test: Browse URIs within a site with a mobile user agent and observe that the most important/relevant information is conveyed first first.

5.3.4.4 References

This relates to WCAG 13.5 .

5.3.5.1 What it means

The popular mechanism of using a 1 pixel graphic for absolute positioning is does not work on a variety of screens.

Graphics that are larger than necessary, for example by possessing having a higher resolution than is displayable on the device or by having too many colors, waste bandwidth.

5.3.5.2 What to test

GRAPHICS_FOR_SPACING Machine Test: Check for very small and/or transparent graphics.

LARGE_GRAPHICS Machine Test: Check dimensions of graphics.

5.3.6.1 What it means

Mobile devices often do not have good color contrast and are often used in less-than-ideal lighting conditions. Hence information highlighted in color may not be visible to users. If color is used to indicate a feature then that feature should generally also be indicated in a way that is not color dependent. In particular, do not use blue or purple text, as this may be confused with hyperlinks, especially on devices that do not underline links.

5.3.6.2 What to test

USE_OF_COLOR Human Test: Browse the page in a monochrome environment.

COLOR_CONTRAST Human Test: Browse the page under a strong light parallel to the screen.

Machine Test: There are automatic tools to test color contrast.

5.3.6.3 References

This relates to WCAG 2.1 and 2.2 .

5.3.7.1 What it means

Images that are used indiscriminately can lead to content that is hard to view, particularly with the limited contrast often found on mobile devices and in the hostile viewing conditions in which mobile devices are frequently used.

Before using background images, consider carefully your objectives for doing so and try to use alternative techniques to achieve similar objectives. If you use a background image ensure that the content is readable with and without the background image for devices that do not support them.

5.3.7.2 What to test

BACKGROUND_IMAGE_SUPPORT Machine Test: Send a request to Test for the site with presence of a user agent that does not support background images and check the background attribute is not present. image.

BACKGROUND_IMAGE_READABILITY Human Test: Test readability. readability both on devices that support them and devices that do not.

5.4.1.1 What it means

Provide a descriptive title for the page to allow easy identification. Keep the title as short as is possible to reduce page weight weight, and bear in mind that it may be truncated.

Many mobile browsers do not display the title of a page. Where the title is displayed the available space may be limited.

The client may use the page title as the default label for bookmarks. Again Again, space may be limited limited, so use it to help identify the content and not for other purposes.

5.4.1.2 What to test

Machine Test: Test for presence of the title element.

Human Test: Test that the title is descriptive of content.

5.4.2.1 What it means

Many mobile clients do not support frames. In addition, frames are recognized as being generally problematic.

5.4.2.2 What to test

Machine Test: Test for presence of frame related elements - in HTML check for frameset and iframe elements.

5.4.2.3 References

See http://www.w3.org/TR/xframes/#s_intro for a discussion of problems with frames.

5.4.3.1 What it means

It is good practice for all but the simplest documents to indicate their structure through headings and sub-headings. Using structural markup, rather than formatting effects, allows easier adaptation of content where it needs to be divided into several pages pages, as well as potentially facilitating access only to the sections of the document that a user is interested in.

Where headers headings are used they should be used in accordance with the specification, i.e. they should be properly nested according to their level.

Structural markup must not be used solely to create a font effect. effect (see also 5.4.3 Structural Elements ).

5.4.3.2 How to do it

Mark up Markup languages like HMTL contain many constructs to indicate structure.

5.4.4.1 What it means

Tables do not work well on limited size screens and may result in the user having to scroll horizontally to read them. Putting navigational links into tables may result in the user having both to scroll horizontally and vertically to see possible navigational choices.

5.4.4.2 How to do it

The Default Delivery Context does not support tables.

5.4.4.3 What to test

TABLES_SUPPORT Machine Test: Send a request to the site with a user agent that does not support tables and check the table element is not present.

Machine Test: Check that there are no nested tables.

TABLES_LAYOUT Machine Test: Check that no column or row in a table is empty or contains only a 1x1 transparent GIF.

Machine Test: If there is a table element, check to see whether there is rendered content outside the element. If there is not then it is likely that the table is being used for layout.

5.4.4.3 5.4.4.4 References

This relates to WCAG 5.1, 5.2, 5.3, 5.1 ,5.2 ,5.3 ,5.5 and 5.6 .

5.4.5.1 What it means

Downloading images to a mobile client adds to the time to display an image and the cost of displaying the page. Making the page readable in text only text-only mode can help the user assess its usefulness before images arrive.

Many mobile clients do not support embedded objects or script and in many cases it is not possible for users to down load plug-ins to add support. Content must be designed with this in mind.

Even where a device does support scripting, do not use it unless there is no other way of accomplishing your objectives. Scripting increases power consumption and so decreases battery life.

5.4.5.2 How to do it

Design pages as though they were to be displayed on a text-only browser.

Always use features of the markup designed to support alternate rendering such as the longdesc and alt attributes in XHTML.

Use only features from the markup that are known to be supported by the device in question.

Avoid things like CSS image replacement and pictures of words.

If scripting is used, do not use onmouse and onkey triggers, use onclick .

For the Default Delivery Context do not use scripting and do not embed objects.

5.4.5.3 What to test

NON-TEXT_ALTERNATIVES Machine Test: Test for presence of alt attribute on images and text content on objects.

Human Test: Check the relevance of the meaning of the content of alt attributes with their elements. attributes.

OBJECTS_OR_SCRIPT Machine Test: Send a request to Test for the site with presence of object or script elements in content delivered to a user agent device that does not support scripts and check the script element is not present. them.

Machine Human Test: Send a request to the site with a user agent If present, test that does not support objects and check the object element user experience is not present. acceptable.

5.4.5.4 References

This relates to WCAG 1.1, 3.1, 6.2, 6.3, 1.1 ,3.1 ,6.2 ,6.3 ,6.5 and 9.2. 9.2 .

5.4.6.1 What it means

Resizing images at Images such as bitmaps have an intrinsic size. Telling the server and specifying their size browser in markup assists advance what the browser size is avoids it having to flow re-flow the text, page when it receives it. Resizing images at the server reduces the amount of data transferred and the amount of processing the client has to carry out to scale the image.

Note that this recommendation contrasts with 5.4.8 Measures ,which recommends using relative measures where possible.

5.4.6.2 What to test

IMAGES_SPECIFY_SIZE Machine Test: Test for presence of width and height attributes on img elements.

IMAGES_RESIZING Machine Test: Check width and height attributes are equal to image dimensions.

5.4.7.1 What it means

If the page markup is invalid this will result in unpredictable and possibly incomplete presentation.

5.4.7.2 What to test

Machine Test: Validate documents.

5.4.7.3 References

This relates to WCAG 3.2, 3.2 ,11.1 and 11.2. 11.2 .

See http://www.w3.org/QA/Tools/#validators .

5.4.8.1 What it means

Avoiding pixel and absolute measures allows the browser to adapt content to fit the display. An exception to rule is where an image has been specifically sized for a particular display (see 5.4.6 Image Size ). In this case references to the image in markup may specify the exact dimensions of the image in pixels, in order to help the browser to flow the page, page and avoid re-flowing it after the page has been retrieved. Devices may realize the intentions of authors more accurately if margins, borders and padding are specified in pixels.

5.4.8.2 How to do it

Use percentage and other relative measures. measures such as em ,ex ,bolder ,larger and thick .

5.4.8.3 What to test

Machine Test: Send a request to the site with a user agent that supports relative measures correctly and check the values of font-size are not absolute or pixels.

5.4.9.1 What it means

Clients provide several levels of Style information may be contained in an externally linked style sheet or, in HTML, may be contained either in a style element or in a style attribute on specific elements.

Mobile Devices offer varying support for style sheets. Some provide full implementations implementations, including caching of external style sheets. Some sheets; some do not cache external style sheets, and for these devices embedding sheets; some do not support the style information in the delivered page is element; some implementations do not support more efficient than the browser making repeated retrievals for the one style sheet across a site. Some implementations and some do not support style sheets at all.

5.4.9.2 How to do it

It is preferable to share style information between pages, but if the device does not support caching of style sheets then this approach would result in the same style sheet being retrieved for each page. Consequently, in order of preference: if the device caches style sheets, put style information in a single external style sheet (see also 5.2.9 Externally Linked Resources ); if the device supports the style element, use it; otherwise use an external style sheet.

Optimize style information so that only styles that are used are included.

For the Default Delivery Context use an external style sheet.

5.4.9.3 What to test

STYLE_SHEETS_USE Machine Test: Send a request to the site with a user agent that supports CSS and check that style sheets are used and that the page does not use formatting tags (e.g. font). font ).

STYLE_SHEETS_SUPPORT Human Test: Disable style sheets and checks check that the page is still readable.

STYLE_SHEETS_SIZE Machine Test: Check that the elements in a style sheet are used in the pages that reference it.

5.4.9.3 5.4.9.4 References

This relates to WCAG 3.3. 3.3 .

5.4.10.1 What it means

Content which is marked up in languages such as XML can often be made smaller while preserving exactly the same semantics merely by removal of redundant white space (i.e. spaces and new lines).

Marking fonts, colors and other stylistic effects in line, in-line can cause considerably larger page sizes when compared with using logical markup, and use of the HTML class attribute for application of style. style (see also 5.4.9 Style Sheets ).

5.4.10.2 How to do it

While it is not intended that authors should create their content in a single line to remove white space altogether, it is suggested that authors should not contribute to page weight by introducing unnecessary white space. Note that "Pretty Printing", i.e. the "pretty printing" (the formatting of mark-up with programs such as HTML Tidy, markup with indent option set to "yes", indentation) can generate large amounts of white space and hence add to page weight.

If "pretty printing" is an important part of the authoring process process, then try to arrange that redundant white space is stripped when serving a page.

Even though some network proxies strip white space that they think is redundant, not all do so, so it is not best practice to rely upon this behavior. There are other issues relating to network proxies (such as requesting them not to strip relevant white space). Such issues will be addressed in a later phase.

Use of structural markup (see 5.4.3 Structural Elements ) contributes to minimizing the size of the markup on a page, as does centralizing the style descriptions using CSS. CSS [CSS] .

5.4.10.3 What to test

Machine Test: Count the number of non-significant white space characters in the document.

5.4.11.1 What it means

Transferring content that a client device cannot display wastes users' time and money. Preference A device may be expressed by express a client preference for one format rather than another. formats. In this case it is good practice to respect the client's preference preference, as it may have a fuller implementation of its preferred markup. those formats.

5.4.11.2 How to do it

To determine what formats a device supports, web Web sites may use any combination of device profile information such as the HTTP User-Agent header, HTTP Accept headers and UAProf.

There are problems with using any one approach to the exclusion of the others. Some issues that have been noted by the BPWG in this context are:

• Not all Some devices do not supply accept headers;

• Some devices state that they accept all formats */* when they do not support some common formats and also mis-state their capabilities;

• Some operator gateways supplement the accept headers as they adapt content presented in to include formats that the device does not accept; they adapt;

• User Agent agent headers do not always uniquely identify the device;

• UAProf information may not be available or may be incomplete.

5.4.11.3 What to test

CONTENT_FORMAT_SUPPORT Machine Test: Check MIME types of content with various User-Agent Machine Test: Check MIME types of content with various user agents.

CONTENT_FORMAT_PREFERRED Machine Test: Check MIME types of content with various user agents and check that the preferred format is sent or that the format is compatible with the default delivery context. Default Delivery Context.

5.4.12.1 What it means

As in the previous section, content should not be sent to a device if it can not use it.

5.4.12.2 How to do it

The supported character encodings for a device may be obtained either from a device profile or by examining the value of the HTTP Accept-Charset header sent with a request (see also the section above on determining device characteristics). header.

The character encoding being used in a response may be indicated using the HTTP Content-Type header.

Example:
Content-Type:
text/html;
charset=utf-8

Additionally for XML [XML] documents the character encoding may be indicated in the encoding declaration [XMLENC] declaration, although this will generally be ignored if an HTTP Content-Type header is present.

Example:
<?xml
version="1.0"
encoding="UTF-8"?>

Encoding of the content to a desired character encoding is dependent on the authoring tools being used, web Web server configuration and the server side scripting technology being used (if any). For a discussion of this see [HTTP_CHARSET] [CHARSET1] and [CHARSET2] .

The amount of bandwidth required to transmit content can vary significantly depending on the character encoding used. Text consisting principally of characters from the Latin alphabet will encode more efficiently in UTF-8, whereas text consisting principally of characters from ideographic scripts will encode more efficiently in UTF-16. When choosing a character encoding, consider the efficiency of the available encodings.

All applications should support UTF-8.

5.4.12.3 What to test

Machine Test: Check that the Content-Type HTTP header contains the encoding is declared in some way and that this encoding is supported (may also need to check supported. The content type may be declared in one or more of the following ways: The Content-Type HTTP header, the XML declaration for XML-based content and content, the CSS @charset rules for CSS). CSS, the Content-Type Meta element for HTML content.

5.4.12.4 References

See [XML] Character Encoding in Entities for a discussion of character encoding in XML documents.

5.4.13.1 What it means

It is inevitable that, on occasions, a mobile user will not be successful in accessing the content or information they sought. Providing easy navigation away from the error is particularly important in the mobile arena, where browsers may not have an easy-to-find "back" button, where contextualization is frequently difficult and where re-entry of URIs as a means of error recovery is particularly onerous. difficult.

It is noted that errors due to networking, connection and some kinds of mistyping of URIs are not within the control of the content provider provider, which has no way to influence how such errors are presented to the user. However, where errors are within the control of the content provider the user should be provided with clear information regarding the fault they have experienced. This should help them to understand whether the fault was temporary or permanent, whether they should retry the attempt to access the content, content and how they may be able to escalate the problem.

It should also be possible for the user to escape from the error condition. They should either be able to return to the page they were on prior to the error, or to be able to move onwards to a convenient part of the service from where they can retry or alter the transaction they were attempting.

5.4.13.2 How to do it

It is noted that many web Web servers provide a default error page page, especially in the event of a request for a non-existent page (404) or an internal error (500). Where possible (see [TOMCAT] , [APACHE] and [IIS] ), applications should trap all error conditions by overriding the default pages if necessary, and handle them in a user-friendly, and graceful, way.

Error messages should be provided in the same language as the application that was being used. They should be clear and concise, adhering to the same best practices Best Practices as the rest of the application. They should be provided in a format that the device can handle.

The error message should detail whether the issue is likely to be temporary or permanent, whether the user may be able to solve the issue themselves (for example, by changing input data, data or a handset setting), or whether it is an issue that can be escalated to the content provider or network operator. In the latter case, contact details, such as an SMS address or a support line number, might be appropriate.

The error message should provide one or more of the following navigational constructs:

1. A "back" link to return to the previous page (particularly for devices that do not have an easy to find back button);

2. A "retry" link to attempt the relevant part of the transaction again (note that this may not be equivalent to a page "refresh");

3. A "home" link to allow the user to return to the main part of the application.

The error message can provide an error code to be used for diagnosis of the issue. However, the use of an error code is not a substitute for a human-readable message. While some users may understand "404" to mean "page cannot be found", this must not be assumed to be true for all users.

5.4.13.3 What to test

Enter an extraneous URI, known not to represent an actual resource on the site, and check that a HTTP 404 error response is accompanied by a page whose markup is appropriate for the requesting device, or the default context.

Human Test: Check that the page returned contains an explanation of the error and appropriate corrective actions, without assuming any technical knowledge on the part of the end user.

5.4.14.1 What it means

Cookies are frequently used both to carry out session management management, to identify users and to capture store user preferences. Many mobile devices do not implement cookies or offer only an incomplete implementation. In addition, some gateways strip cookies. cookies and others simulate cookies on behalf of mobile devices.

5.4.14.2 How to do it

Use Test that cookies if they are known to be supported by the device on the device's its current access path. If they are not supported, use URI decoration, decoration for session management, being careful not to exceed the device's maximum length for such strings. Some gateways provide user identification without setting cookies.

5.4.14.3 What to test

Machine Test: Send a request to the site with a user agent Check that does not support an alternative to cookies and check that the Set-Cookie HTTP header is used for session management when they are not present in the response. available.

5.4.15.1 What it means

Since a low Limited bandwidth and a high latency can reduce the usability of a Web site sites on a mobile device, it is most useful to provide enough devices. Using caching information to effectively can reduce the user agent so that it does not need to reload data (e.g. such as style sheets, images) images and pages, thus improving performance and reducing cost of use. It can also prevent the reuse of content where this is not appropriate, for example content that is already available locally. adapted for one device should not be re-used by different devices. User agents and network caches are both affected by caching information.

5.4.15.2 How to do it

The HTTP protocol provides Set expiry times in a well-defined framework for this caching mechanism way that can is appropriate to your application. Consider using Cache-Control: public to allow sharing of pages between devices, Cache-Control: private to allow re-use but only be optimally used if by the delivered content provides enough information (e.g. an ETag header). requesting user agent and Cache-Control: nocache to prevent caching.

The HTTP 1.1 specification [HTTP1.1] and Techniques document [Techniques] contain discussions of caching.

5.4.15.2 5.4.15.3 What to test

Machine Test: Check for the presence of cache headers on the HTTP response.

5.4.15.4 References

Section 13 Caching in HTTP of [HTTP1.1] discusses caching.

5.4.16.1 What it means

Mobile devices often have few fonts and limited support for font sizes and effects (bold, italic etc.) As a result of this, the use of font size, face or effect, for example to highlight an answer or a stressed word, may not achieve the desired effect. See also 5.4.3 Structural Elements .

5.4.16.2 How to do it

For the Default Delivery Context do not use font related styling.

5.4.16.3 What to test

Machine Test: Check for the presence of font related styling in an environment that does not support it.

Human Test: If present, ensure that the author's intentions remain clear.

5.5.1.1 What it means

Given the typical input limitations of a mobile device device, the interface must as far as possible minimize user input. Where possible, use selection lists, radio boxes buttons and other user interface artifacts controls that do not require typing.

Some markup languages allow the specification of an input mode, which is particularly useful in cases where user input is to be restricted, for example to numeric only. It is anticipated that XHTML basic XHTML-Basic [XHTML-Basic] will support this functionality in the future.

5.5.1.2 How to do it

There are a number of techniques available for this this, including:

• Where possible use previous entries as defaults.

• Make it possible to select items using navigation keys and/or numeric input.

5.5.1.3 What to test

AVOID_FREE_TEXT Machine Test: Check whether input type="text" and textarea are used.

Human Test: If one of them is used, check whether it can be replaced by a pre-determined entry.

PROVIDE_DEFAULTS Machine Test: Check if there is a pre-selected value in controls (selected or checked attribute set).

Human Test: If not, check if there could be sensible pre-selection in the context (e.g. most common choice).

DEFAULT_INPUT_MODE Machine Test: Send a request with a user agent known to support the inputmode attribute attribute, and if the response is in a language that supports this attribute, check that it is present on input type="text" and textarea elements.

5.5.1.4 References

This relates to WCAG 10.4 .

5.5.2.1 What it means

It is important that as the user navigates through the page the various fields and objects are presented in a logical order, especially as many of them will not be visible at the same time as the focus item.

5.5.2.2 How to do it

This should normally come from the basic structure of a Use document in a format like HTML. order to control layout and tab order.

5.5.2.3 What to test

Machine Test: Check that there are no input and a tabindex elements use attributes or layout effects that affect the order of presentation.

If there are tabindex attribute. attributes check that all controls have a tab index and that they are used consistently.

Human Test: If not, check whether there are either tabindex attributes or layout effects that might affect the link order matches the needs of presentation, then check that the user. order is usable.

5.5.3.1 What it means

This means use the label element in HTML, or its equivalent in other languages. Make sure that where the label goes is consistent and close to the control so re-flowing or adapting the content intelligently will always recognize label controls and keep them together.

5.5.3.2 What to test

Machine Test: Check if the label element is used in forms.

Human Test: Check whether the labels are properly positioned with regard to the controls.

5.5.3.3 References

This relates to WCAG 10.2 and 12.4. 12.4 .