Addendum to Mobile Web Best Practices

3.1 Access Keys

Relevant Delivery Context Capability

Support for access keys, i.e. key presses that provide a short cut to activation of links in a page.

Interpretation of the Best Practice

Typically a "Web site" has common navigation links that apply to most, or all, pages in the site (a menu bar for example). Such navigation links should be associated with access keys and the keys assigned should be the same on all pages. Other frequently accessed links (such as navigation within a page) may also benefit from being associated with an access key.

There is no standard way for a content provider to indicate the availability of access keys to users of the site.

Common techniques are:

• Link decoration (put the access key in brackets next to a link e.g. [1] Home).
• Summary page.
• Listing on a site map.

Note that access keys are not supported by some user agents. Representations targeted at such user agents should not contain link decoration.  

Evaluation Procedure

Where there are elements that would benefit from quick access, particularly navigation links and form controls:

• Verify that access keys are assigned to navigation links present on all pages on the site.
• Verify that access keys are used consistently for the same links.
• Verify that the access keys are numeric, or if not, have been tailored for use on a specific target device.
• Verify that the user can establish which access keys are assigned to links.

3.2 Auto Refresh

Related mobileOK Basic Test

AUTO_REFRESH and REDIRECTION

Evaluation Procedure

Verify that pages that use automatic refresh (e.g. as highlighted by a mobileOK evaluation) contain a link to a non-refreshing version.

3.3 Avoid Free Text

Relevant Delivery Context Capabilities

• Maximum size of a select list.
• Availability of an Alpha-Numeric Keyboard.

Evaluation Procedure

Assess whether free-text input fields:

<input type="text">, <input type="password">, <textarea>

would provide a more usable experience if replaced by a series of radio buttons, checkboxes or a select menu (where the number of choices is limited so as to be appropriate to the capabilities and ergonomics of the device).

Examples

• Replacement of text entry with selection:
  • Selection ZIP/Post codes from a list, perhaps within a limited geographical area or by progressive refinement based on previous selection.
  • Selecting a country from a drop down list, ideally with the most likely choice(s) at the top as well as in the list in their alphabetical position.

• Use of radio buttons for limited choice selections such as (Yes/No) and (Small/Medium/Large).

3.4 Background Image Readability and Color Contrast

Relevant Delivery Context Capabilities

• Screen Contrast
• Color Depth
• Screen quality
• Resolution

Interpretation of the Best Practice

The use of colored, patterned or photographic background images can make text hard to read both because of reduced device screen contrast and because of the context of use, in bright sunlight for example, reducing the perceived contrast.

Evaluation Procedure

Verify that where background images are used contrast ratio between the overlying text and each color used in the background image is sufficient.

Examples

There are also a variety of color contrast measuring tools available online, such as:

• WCAG Technique G18 (provides a formula as well as links to further tools) [WCAG20]
  
• Color Contrast Check
• CSS Analyzer

3.5 Balance

Relevant Delivery Context Capability

Type of scrolling and link navigation

Interpretation of the Best Practice

Different devices provide a number of means of navigating within a page:

• Selection of each link in document order.
• Scrolling independently of links.
• Stylus or Finger Based.

If there is a large number of links in the page, users of devices that can only navigate by successive selection of links will find it difficult to scroll the page and use links that are lower down.

Evaluation Procedure

Assess the number of links in the page. If the representation is targeted at devices that do not support navigation independently of the number of links in the page, verify that the page does not use more than 30 links. Other types of device and special purpose pages may warrant a larger number of links.

3.6 Exploit Device Capabilities

Relevant Delivery Context Capabilities

• Screen Width
• Screen Height
• Color Depth
• Markup Language Support
• Character Encoding Support
• Image Format Support
• CSS Support
• Script and XHR Support

For details see the DDC.

Interpretation of the Best Practice

Unlike the DDC, many real devices support Scripts, XML HTTP requests, DOM Capabilities, Cookies and advanced CSS support. Web sites that are designed to support a variety of different representations might target a particular demographic of users with certain classes of device or simply make significant efforts to give users the best possible experience. Browsing a simple, static Web site on an advanced device may be little more rewarding than attempting to browse one that assumes capabilities that are unavailable on the device used, thereby making the content inaccessible.

There is no simple rule or single evaluation that will determine whether a content provider has exploited device capabilities. There will always be a balance between the cost of providing multiple representations versus the benefit of doing so. For this reason, we do not provide a formal evaluation procedure to test this aspect of Best Practice except to say that any evaluation necessarily requires the Web site to be accessed from a variety of different devices with different capabilities. However, we do offer some examples of the kind of informal evaluation that may be possible, depending on what type of content is being offered.

Examples

• Where links lead to content that may not work on less-capable devices, e.g. links to video, the user should be warned. Such warnings should not appear when the content is delivered to a target device known to support  the feature (see also 3.8 Suitable, Limited and Clarity, below).
• The representation should not be unnecessarily limited to 120 pixels wide for devices that have wider screens.
• JavaScript should be used for form validation on devices that support it as this can reduce network traffic and latency.
• In forms, scripting may be used to adjust the content or state of a controls based on the input already supplied.
• Enhancements, such as JavaScript and advanced CSS, must fail gracefully  - i.e. where such features are used, the lack of support on less sophisticated devices must not prevent access or limit functionality.

3.7 Central Meaning

Interpretation of the Best Practice

When accessing a page on a mobile device, the primary content should be visible. This means that the well-established layout for desktop devices, with navigation along the top and/or side of the page, is usually inappropriate.

Evaluation Procedure

Verify that the main content of the web page is visible without scrolling. This is usually content that is unique to the page and does not repeat across several pages

3.8 Suitable, Limited and Clarity

Interpretation of the Best Practice

Informational content should be provided in a manner suitable for access on mobile, i.e. with an eye to quick assimilation by the user, rather than in a verbose style.

Evaluation Procedure

• Verify that informational content is characterized by a brief writing style using features such as headings and lists.
• Verify that a user can see skip through the content if so desired to reach the particular information they seek.
• Verify that any more detailed information that is provided comes after the introductory paragraph(s).
• Verify that the text is generally written in short sentences without unnecessary sub-clauses.
• Verify that unfamiliar terms are not used (except technical terms relevant to the subject matter).

Examples

• News stories are typically 'front-loaded' with key information (who, what, why, when) provided in the headline and in the opening sentences.
• Event information should be in the form Venue: village hall; time: 6pm; Refreshments available; rather than the more verbose: "The meeting will begin at 6pm in the village hall where refreshments will be available."
• Non-mechanical gardening implements are referred to as a spade.
• For English language pages, the Gunning Fog test can give an indication of complexity. A level of roughly 7 or 8 would be ideal.
• Otherwise unsuitable content may be suitable in a controlled environment, perhaps with logon for entry. This might be relevant, for example, for the retrieval of large medical scans on mobile devices.

3.9 Content Format Preferred

Related mobileOK Basic Test

CONTENT FORMAT SUPPORT

Interpretation of the Best Practice

If a device supports one format better than another, it is preferable to deliver content in the better-supported format if possible.

Evaluation Procedure

• Request the content simulating a device with a preference for a particular format.
• Repeat the request simulating a device that has a preference for a different format.
• Verify that the appropriate alternative format has been delivered in both cases.

Examples

• PNG images may display better than GIF.
• Support for Shift-JIS character encoding may be better than for UTF-8.

3.10 Control Labeling and Control Position

Interpretation of the Best Practice

It is dangerous to assume that the same layout will be presented to all users of mobile devices. It is important therefore to ensure that <input> elements are correctly labeled so that the association between <label> and <input> element is retained even if the layout is changed.

For a detailed description of labels and form controls, the reader may also refer to Techniques for WCAG 2.0 [TWCAG], specifically to section H44: Using label elements to associate text labels with form controls from some examples have been.

Evaluation Procedure

1. Verify that there are <label> elements, if user-visible <input> elements are used.
2. Verify that
   • either the for attribute of the <label> element is present and corresponds to the id attribute of a form control.
   • or that the <label> element contains the form control for which it is a label.
   • doing both of these is also acceptable.
3. Verify that the label describes the purpose of the form control.
4. Verify that labels and <input> elements are visually associated with and without CSS support.

Examples

• A label which requests a person's name but is associated with a birth date field presented as drop down boxes, fails step 3.
  • Bad example: <label>Your name <input type="date"/></label>
• The for attribute and corresponding id are meaningless except that they must match:
  • Good example: <label for="firstname">First name:</label><input type="text" name="firstname" id="firstname" />

3.11 Cookies

Relevant Delivery Context Capabilities 

Device can accept cookies and the network is transparent to cookies

Evaluation Procedure

1. Identify the main functionality of the site that is important for the user and may rely on state.
2. Evaluate the functionality with cookies enabled.
3. Disable support for cookies. Evaluate the functionality and compare with that evaluated in 2.

Examples

A site that requires a user to login might store that login in a cookie to save the user typing in their credentials each time they visit. If cookies are unavailable, an acceptable degradation would mean that the user was prompted for a login each time they visited that page, but would browse the site without further logins from then on. A poor (and unacceptable) cookie-less degradation would render a site useless by always checking for a non-existent cookie and so not letting the user past the login page.

3.12 Error Messages

Evaluation Procedure

1. Provoke a server-side error. For example: request a URL known not to correspond to any endpoint on the site.
2. Examine the content of the error page.
   It should:
   

• Explain in non-technical language the error which has occurred.
• Be suitable for the DDC, at a minimum, (i.e. it must comply with all other tests).
• Provide at least one of the following links: site home page, back, reload.
• Be in the language the user was reading on the site when the error occurred.

3.13 Fonts, Style Sheets Use and Style Sheets Support

Relevant Delivery Context Capabilities

• Style sheets support
• Font availability
• Font size
• Font effects

Interpretation of the Best Practices

Although the overwhelming majority of devices have support for CSS, such support is not uniform. CSS is designed to control presentation but it should not be used to convey meaning - that is the job of the markup.

Evaluation Procedure

• Verify that content is readable and intelligible with style sheets disabled.
• Assess the difference between the appearance of the content with CSS enabled and disabled and verify that this does not alter the meaning.
• Verify that structural markup is used such as <strong>, <em> and <q> (rather than <b> or <i> which, although HTML tags instead of CSS, are presentational in nature).

3.14 Graphics for Spacing

Interpretation of the Best Practice

The correct way to control presentation on a Web page is to use CSS. Using graphics to achieve positioning and spacing effects adds an unnecessary overhead to the page.

Evaluation Procedure

1. Verify that the content complies with GRAPHICS_FOR_SPACING mobileOK Basic Test [MOKTESTS].
2. View all images in a page, for example in a separate list of images, or by outlining them. For XHTML these will usually be included using the <img> element.
3. Ignoring images that are part of the page's graphic design, such as rounded corners, determine whether any of the images do not convey information and are used purely for spacing.

Examples

• A 1 pixel square image used to separate other content is unacceptable.
• A small image with the same color as the surrounding content is unacceptable.
• Using images to indent text, such as the beginning of a paragraph, is unacceptable.

3.15 Link Target ID

Evaluation Procedure

1. Verify that each link in the text is described by attributes as follows:
   • If the target content is in a language different to that of the tested content, it should be correctly marked with the hreflang attribute.
   • If it is in a format other than that of the tested content, it should be correctly described by the type attribute.
   • If it uses a character encoding different to that of the tested content, it should be described by the charset attribute.
2. Verify that the link text (including alternative text for any non-text elements) clearly describes the information obtained when activating the element.
3. Select elements pairwise. Verify that two links with same link text (including alternative text for non-text elements) and same title attribute (if provided) point to the same resource.

(See UWEM 1.0 13.1 for more details)

Examples

• Links with only the text "Click here" are unacceptable.
• Multiple links in same page with same text or content but pointing to different things are unacceptable.
• Links from an HTML page to a large video file that does not mention format or size are unacceptable.
• Links to content in a language different to that of the current page are unacceptable.

3.16 Minimize Keystrokes

Relevant Delivery Context Capabilities

Input mode

Evaluation Procedure

This evaluation is covered by AVOID_FREE_TEXT, URIS, CENTRAL_MEANING and PROVIDE_DEFAULTS. [MWBP]

3.17 Navbar

Relevant Delivery Context Capabilities

Screen width

Evaluation Procedure

• Verify that there are basic navigational elements located above the rest of the content.
• Verify that all navigational elements fit on a single line in the DDC.
• Verify that, upon loading the page, enough of the main content is visible without scrolling.

Examples

A navigation bar above the main content consisting of only: Home, Up, Down, Site map & Search, or similarly limited options, would be acceptable.

3.18 Navigation

Evaluation Procedure

1. For all the pages in the sample, examine the navigation mechanisms in the pages. These include inline links, groups of links (for example menus) in different parts of the page.
2. Verify that navigation mechanisms are similar throughout pages of the sample, other than for changes that are necessary within the context of a given page.

Examples

• A well designed site will offer the same navigation menu(s) on all pages with the only changes being in the presentation as it affects ths current page, e.g. the link to the current page may be shown differently or elided. 
• Bad examples include:
  • A site navigation menu that is presented differently on different pages.
  • A site navigation menu that is present on some pages but not on the current page.
  • Inline links on other pages have a descriptive title but on the current page they do not.

3.19 Non-text Alternatives

Evaluation Procedure

Referring to Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20]

• Guideline 1. Provide equivalent alternatives to auditory and visual content.
• Guideline 1.1 Text Alternatives

Non-text elements include images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

Verify that content meets the mobileOK Basic Test NON_TEXT_ALTERNATIVES [MOKTESTS]

• Verify that a text equivalent has been provided for every non-text element that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.
• Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user.

Examples

• Good examples:
  • Null value (alt="") for decorative images such as rounded corners in frame.
  • A text equivalent for an image of an upward arrow that links to a table of contents could be "Return to table of contents".
• Bad examples:
  • An alt value that is the same as the filename.
  • alt=" " (space).
  • No alt attribute.

3.20 Objects or Scripts

Evaluation Procedure

Verify that the document can be viewed or used, with objects or scripts inactive or removed, without any change in the function, or value of the content, of the page.

Examples

From Web Content Accessibility Guidelines 1.0 [WCAG10], Guideline 6, Checkpoint 6.3:

Check that links that trigger scripts work when scripts are turned off or are not supported (e.g., do not use "javascript:" as the link target). If it is not possible to make the page usable without scripts, provide a text equivalent with the NOSCRIPT element, or use a server-side script instead of a client-side script, or provide an alternative accessible page as per checkpoint 11.4. Refer also to guideline 1.

With scripts turned off or when the page is accessed on a device that does not support scripts or objects:

• A given form can still be filled out and submitted.
• Images are displayed and alternative content is shown.

3.21 Page Size Usable

Relevant Delivery Context Capabilities

• Bandwidth
• CPU power
• Screen size

Evaluation Procedure

Verify that a given web page contains contiguous content, which could technically and semantically be separated into individual pages, and exceeds 3 screen sizes in length without page break.

Examples

• A long article that extends over 3 screens full without some type of page break should be broken up into pages.
• Display of navigational information, requiring continuous movement through the map would pass, because additional maps are loaded as needed.

3.22 Page Title

Relevant Delivery Context Capabilities

• Screen width

Evaluation Procedure

• Verify that the title thematically describes the main intent of the page content.
• Verify that the title does not repeat unchanged across more than 3 pages unless a continuous piece of text has been paginated.
• Verify that the title is too long to display on a screen matching the Default Delivery Context.

Examples

• A page with the primary purpose of offering ring tones alongside small textual items should have this reflected in the title.
• A title such as "Main Portal" which is repeated across more than 3 pages would have to have to be adapted on the pages in question.
• Conversely a title of "Uncle Tom's Cabin" in an ebook page, across many pages, would be perfectly acceptable.

3.23 Provide Defaults

Interpretation of the Best Practice

This section only applies to pages that call for user input in a form.

Evaluation Procedure

Submit the form without selecting any item. This will ensure that defaults, such as preselected values, will be used:

• Verify that the response is not an error page.
• Verify that the response is not a page asking the user to fix some data.
• Verify that the response is not the original page.
• If there are <text> or <textarea> elements that include a default value telling the user what to enter, verify that these values do not have to be manually deleted in order for them not to be processed as user input.

Examples

• A country list might preselect the country code of where the page or service is most relevant.
• A ZIP code listing might have the local ZIP code preselected and surrounding ZIP codes at the top of the list.
• A date field might have today's date filled in.

3.24 Scrolling

Relevant Delivery Context Capabilities

• Input mode
• Screen size

Evaluation Procedure

If horizontal scrolling is necessary to view a page, for each element wider than screen size:

• Ensure the element is not decorative.
• Ensure that the element requires the oversize display, i.e. it cannot reasonably be reduced in size or omitted altogether.

Examples

• A map showing an entire trip, information which would be lost upon zoom, is acceptable.
• A X-ray image, intended for a portable medical device where zooming out would loose vital detail of the image is acceptable.

3.25 Structure

Related mobileOK Basic Test

VALID MARK_UP

Interpretation of the Best Practice

The mobileOK test will ensure that markup is valid, however, it does not ensure that markup elements are used correctly, in terms of the semantics of the document, as opposed to being used to achieve presentational effects. 

Evaluation Procedure

• Verify that headers are properly nested according to their level.
• Verify that list elements are used to represent lists (ordered, unordered, or definition lists) and are not used for formatting effects.
• Verify that heading elements (<h1>, <h2> etc.) are used to represent headers and are not used for formatting effects.
• Verify that all information, which is visually is shown as a group of related elements, uses the <list> element in the markup to provide that structure.
• Verify that all information that is shown visually as blocks of text uses separate elements such as <p> or <div> in the markup rather than creating visual separation using multiple <br> line breaks.

3.26 Style Sheets Size

Evaluation Procedure

• Verify that style sheets do not contain more than 25% white space.
• Verify that all style rules are used somewhere in the Web site.

3.27 Tab Order

Evaluation Procedure

Verify that the tab order of links, form controls and objects follows a logical or thematic order.

Examples

• If a user is required to enter their first name, last name, address and contact number, the tab order should not jump, for example, between the first name and the phone number and then back to the last name.
• If a pizza ordering service offers a choice of toppings and bases, the tab order should not jump between those two categories when presenting the user with options.
• If the Submit button, or Submit and Cancel buttons, are not the last item(s) in the form.

3.28 Tables Layout

Relevant Delivery Context Capabilities

Table support

Evaluation Procedure

Verify that tables used solely for layout cannot be replaced by use of CSS.

Examples

An image or text which is spaced and positioned with the aid of a table is not acceptable.

3.29 Tables Support

Relevant Delivery Context Capabilities

Table support

Evaluation Procedure

Verify that the <table> element is not found within the source code if the device does not support tables.

3.30 URIs

Evaluation Procedure

• Verify that the entry domain, including main and subdomain, can be called up with less than 20 multi-tap key presses on the device.
• Ensure that the entry URI does not require a file extension (such as .html) and that the entry URI does not require the www subdomain.

3.31 Use of Color

Evaluation Procedure

• Verify that , excluding hyperlinks, the page does not include any other blue or purple text.
• Check if, when viewed on a monochrome screen, all content is still readable.
• Verify that color is not used as the sole means to represent any item of information.

Examples

• Red text may be used to highlight error messages but the fact that it is an error message should also be conveyed in some other way without color (such as with asterisks or emphasis using the <em> element).
• Telling the user that important information is highlighted in yellow is unacceptable.

See the closely related WCAG Success Criteria for more.