To satisfy the Testing Best Practice, the following
evaluations should be carried out using a range of real
devices as well as, or instead of, emulators. Note that several tests
require certain features of the device or browser to be absent or disabled if
present.
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.
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.
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.
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).
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:
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.
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.
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
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
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.
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
- Verify that there are
<label> elements, if
user-visible <input> elements are used.
- 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.
- Verify that the label describes the purpose of the form control.
- 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" />
Relevant Delivery Context Capabilities
Device can accept cookies and the network is
transparent to cookies
Evaluation Procedure
- Identify the main functionality of the site that is important for the
user and may rely on state.
- Evaluate the functionality with cookies enabled.
- 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.
Evaluation Procedure
- Provoke a server-side error. For example: request a URL known not to
correspond to any endpoint on the site.
- 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.
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).
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
- Verify that the content complies with GRAPHICS_FOR_SPACING
mobileOK Basic Test [MOKTESTS].
- 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.
- 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.
Evaluation Procedure
- 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.
- Verify that the link text (including alternative text for any non-text
elements) clearly describes the information obtained when activating the
element.
- 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.
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.
Evaluation Procedure
- 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.
- 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.
Evaluation Procedure
Referring to Web Content Accessibility Guidelines (WCAG)
2.0 [WCAG20]
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.
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.
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.
Relevant Delivery Context Capabilities
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.
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.
Relevant Delivery Context Capabilities
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.
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.
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.
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.
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.
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.
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.
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.
-
DDRSA
- W3C Device Description Repository Simple API, Jo Rabin, José Manuel
Cantera Fonseca, Rotan Hanrahan, Ignacio Marín, Editors, W3C
Recommendation, 05 December 2008 (see http://www.w3.org/TR/DDR-Simple-API/)
-
DIGLOSS
- Glossary of Terms for Device Independence, Rhys Lewis, W3C Working
Draft 18 January 2005 (see http://www.w3.org/TR/di-gloss/)
-
MOKTESTS
- W3C Mobile OK Basic Tests 1.0, Sean Owen, Jo Rabin, Editors, W3C
Recommendation, 08 December 2008 (see http://www.w3.org/TR/mobileOK-basic10-tests/)
-
MWBP
- W3C Mobile Web Best Practices 1.0, Jo Rabin, Charles McCathieNevile,
Editors, W3C Recommendation, 29 July 2008 (see http://www.w3.org/TR/mobile-bp//)
-
TWCAG
- W3C Techniques for WCAG 2.0, Ben Caldwell, Michael Cooper, Loretta
Guarino Reid, Gregg Vanderheiden, Editors, W3C Working Group Note, 11
December 2008 (see http://www.w3.org/TR/WCAG20-TECHS/)
-
WCAG10
- W3C Web Content Accessibility Guidelines 1.0, Wendy Chisholm, Gregg
Vanderheiden, Ian Jacobs, Editors, W3C Recommendation 5 May 1999 (see http://www.w3.org/TR/WAI-WEBCONTENT/)
-
WCAG20
- W3C Web Content Accessibility Guidelines (WCAG) 2.0, Ben Caldwell,
Michael Cooper, Loretta Guarino Reid, Gregg Vanderheiden, Editors, W3C
Recommendation, 11 December 2008 (see http://www.w3.org/TR/WCAG20/)