Note to BPWG:
None
Limitations of this test:
None
Interpretation of the Best Practice:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
If the user is asked to fill in a form and if there is a finite number of
possible values that the user could enter and those options are not presented
either as a series of radio buttons, check boxes or a select menu: [FAIL].
Examples:
- Selecting ZIP/Post codes from a list, perhaps within a limited
geographical area of interest or in a sequence of steps where each list
of options is dependent on the previous data entered
- 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
- Having to enter text for words like 'Yes' and 'No' is a clear FAIL.
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests, but it is worth noting
that the DDC does support background images which are part of CSS 1.
Interpretation of the Best Practice
The use of patterned or photographic background images behind text is
discouraged but not prohibited.
Test procedure:
If background images are used, the COLOR CONTRAST test must be passed for
the ratio between the overlying text and each color used in the background
image. Otherwise: [FAIL]
Examples:
- The Ishihara Test for Color Blindness, for example, shows background
and text with patterning and insufficient color contrast.
- The
contrast between this text and its black background color is 5:1
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None.
Interpretation of the Best Practice:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
If the page contains more than 30 links: [FAIL]
Examples:
None
Open issues:
None
Note to BPWG:
None
Limitations of this test:
This test cannot cover all the possible capabilities that might be found
in devices.
Unlike the DDC, many real devices support scripting, XML HTTP requests, DOM
capabilities, cookies and CSS including media queries.
However, it is usually possible to detect a presentation that is artificially
constrained by the limited and largely hypothetical Default Delivery Context.
Interpretation of the Best Practice:
Rather trying to find where device capabilities are not utilized it is
more conclusive to identify those instances where the content is wrongfully
limited on a device more capable than the DDC.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- For each property of the DDC (e.g. screen width), identify some
unadapted, original content that would exceed the value given by that
property of the DDC
- Request content on a device more capable than the DDC for that
particular property
- If content is rendered according to the constraints of the DDC:
[FAIL]
Examples:
- Web sites that offer video streams should not offer such content for
the DDC, however, it should be offered to users of devices that do
support video.
- Presentation should adjust itself to the optimal display for this
device and not be unnecessarily limited to 120 pixels wide.
- 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 presentation or state of a
control based on the input already supplied.
Open issues:
None
Note to BPWG:
None
Limitations of this test:
- Visual-only.
- Does not attempt to evaluate the meaningfulness of the visible content
(would be too subjective).
Interpretation of the Best Practice:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- Determine what is the main content of the page. This is content that is
unique to the page and does not repeat across several pages.
- If none of the main content of the web page is visible without
scrolling: [FAIL]
Examples:
None
Open issues:
None
Note to BPWG:
Advise on the use of the type attribute on links to provide information in
machine-readable format for future user agents.
Limitations of this test:
None
Interpretation of the Best Practice:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- The information contained in the link text must describe (e.g.
contextual information, content type, file size) the content that will be
retrieved. If not, [FAIL].
- Content provided or linked to should be suitable for the mobile
context, unless provided in a controlled environment where its
unsuitability is know a priori.
Examples:
- Content may be suitable in a controlled environment, with logon for
entry, for example for retrieval of large medical scans on mobile
devices.
Open issues:
None
Note to BPWG:
None
Limitations of this test:
This test is subjective and cannot be conclusive. It must therefore remain
at a warning level to be informative.
Interpretation of the Best Practice:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
If the text is, for the context, considered to be unnecessarily complex or
verbose [WARN]
Examples:
- Consider the purpose of the page. If the purpose of the page is to
deliver a specific piece of information, that information should be
readily extracted without excessive scrolling or scanning of text.
- In the English language the Fogg test can give an indication of
complexity. A level of rough 7 or 8 would be ideal. For other languages
this does not apply.
Open issues:
None
Note to BPWG:
This test is machine testable and we are not sure why is it not covered in
the basic tests. The number of alternative formats is small and could be
searched for by issuing subsequent appropriate requests.
Limitations of this test:
None
Interpretation of the Best Practice:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- Determine which alternative formats are available.
- If no alternative formats are available [PASS], otherwise
- Change the quality factors of the accept headers to express a
preference for an available alternative format
- If the content which is delivered does not reflect that change:
[FAIL]
Examples:
Typical changes to preferences such as the following should be reflected
accordingly:
- GIF and JPEG
- Character encoding
- Markup language
Open issues:
None
Note to BPWG:
This test is machine testable
Limitations of this test:
None
Interpretation of the Best Practice:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- If there are user-visible form elements and no label elements:
[FAIL]
- If the
for attribute is not defined and the form control
is not contained within the label element: [FAIL]
- If the
for attribute is present but does not correspond to
the id attribute of a form control: [FAIL]
- If the label does not describe the purpose of the form control:
[FAIL]
Examples:
- A label which requests a persons name but is associated with a birth
date field, fails.
Open issues:
- Are there ever presentational / layout reasons why having a form label
isn't appropriate? e.g. if there's only one form element and the meaning
of that element is given by the context of the page?
- Are empty labels "" acceptable, if the meaning of the field is made
clear in some other fashion?
Note to BPWG:
The BP says labels ashould be positioned �properly� but gives no clue
as to what this means. It should either clarify what is intended or this BP
should be deprecated."
Limitations of this test:
- The aspect of properly aligning with a form control has been limited to
mean �in the vicinity�, as the positioning to the left or below an
input field is not the only way to use them.
Note by Alan Chuter: (first bullet point) The BP says
�Make sure that where the label goes is consistent and close to the
form control so re-flowing or adapting the content intelligently will
always recognize label controls and keep them together.� This means
that the user agent, when �adapting the content intelligently� will
recognise the controls [and label text] and keep them together. If they
are just positioned so they look good visually, the UA (which can't see
them) will not necessarily be able to understand. However, the convention
arose in the first place to make the form visually easier to use, with
the meaningful text label at the left of the screen, perhaps preceded by
a radio button. This makes good sense for the mobile device with its
small viewport, but is not mentioned in the BP. If the controls are not
used consistently (according to convention), then there is no point in
doing the BP. Either we follow the convention or we deprecate the BP.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- If CSS is turned off and labels are not clearly associated with a form
control [FAIL]
- If the label cannot be clearly associated with a form control
[FAIL]
- If the association is only achieved by means of positional CSS
[FAIL]
Examples:
See Gez
Lemon's article on Label Positioning. The examples should be in the BP
document.
I was not able to find any examples that should be included
here. There are discussions shown on the page. Alan, please specify.
Open issues:
None
Note to BPWG:
None
Limitations of this test:
- The tester can not know with certainty all the functionality that may
rely on cookies. It is however possible to apply this check to the main
intent of the page
- The test does not deal with potential alternatives which may be
used.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- Identify the main functionality of the site that is important for the
user and may rely on state. See examples.
- Evaluate the funcionality with cookies supported correctly.
- Disable cookies supported. Evaluate the funcionality and compare with
that evaluated in 2.
- If the content or function cannot be accessed without cookies
[FAIL]
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)
cookieless degradation would render a site useless by always checking for a
non-existent cookie and so not letting the user past the login page.
Open issues:
None
Note to BPWG:
None
Limitations of this test:
This test cannot test all existing deficiencies of devices. Rather the
test limited to the author/provider being aware of common deficiencies and do
something about those. This test is not intended to test pixel perfect
rendering across devices, but rather focuses on usability across devices.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
If there are common deficiencies of devices, which impinge significantly
on usability of the content being offered, measures must be taken to work
around those deficiencies. If not [FAIL]
Examples:
Some devices which render tables badly will wrap columns by default, if
the meaning of the page is dependent on layout which does not render well on
these sorts of devices then an alternative rendering should be used when that
user-agent is detected.
Open issues:
Can we make use of - http://dev.w3.org/2008/mobile-test/doc.html
to identify deficiencies of a device?
Note to BPWG:
An external tester can not know what errors generate error messages, or
what languages are available.
That is not quite true. At least a 404 is easy to produce
and available languages can be inquired.
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
1. Provoke a server-side error.
- For example: Request a URL known not to correspond to any endpoint on
the site.
- Develop further tests to provoke error status
generation
2. Examine the content of the error page. All the following must be true,
if not [FAIL].
It must:
- Explain in non-technical language the error which has occurred.
- Be suitable for the DDC, at a minimum, (ie 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.
Examples:
None
Open issues:
The mechanism by which a context specific error message can be displayed
in not clear. For example, how to display a French error message if the user
was in the French section of the site.
Note to BPWG:
The intent of the BP stated in 5.4.16.1 is that meaning should be conveyed
without relying on font-related styling. However, the "Machine Test" under
5.4.16.2 fails on any presence of any font-related styling (whether it
conveys meaniong or not).
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- Check for presence of font-related styling, by means of the font
element, or the bold, italic or underline elements, or CSS.
- Examine the content with CSS enabled and disabled. If the meaning is
significantly different [FAIL]
- Examine any font-related elements present and the effect they have on
the meaning of the content. If they are used to convey meaning
significantly, [FAIL]
- Check for the presence of the "face" element. If only one
font has been defined [FAIL]
Examples:
- Emphasis expressed using bold or underline.
- Quotes that are indicated by italics rather than enclosed in quotation
marks or quotation markup.
Open issues:
None
Note to BPWG:
None
Limitations of this test:
This test does not rely on a particular graphics format that are being
evaluated.
Differences to mobileOK Basic Tests:
This BP is partially covered by the GRAPHICS_FOR_SPACING
MobileOK basic Test.
Test procedure:
Does the content comply with GRAPHICS_FOR_SPACING
MobileOK Basic Test? If not [FAIL].
View all images in a page, for example in a separate list of images, or by
outlining them. For XHTML these will be included using the <img>
element.
Determine visually whether any of the images do not convey information and
are used for spacing. If they are [FAIL].
Note: Spacer images do not convey useful information. They are normally
very small.
Examples:
Open issues:
Define unambiguously what is and is not a spacer image.
Should this test exclude 1x1px advertising images? I.e those
which send page hit data back to a server for user analysis? These are
commonly used on e-commerce sites and wont be going away anytime soon.
I believe not, because those images are usually not
anchored in the content itself but are pulled from a tracking server.
Note to BPWG:
The abbreviation "ID" included in the handle of the BP, is confusing and
suggests it involves the ID attribute. The test covers the use of hreflang,
type and charset attributes which are not mentioned in the BP.
Limitations of this test:
This test only deals with the descriptive portion of a link
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- Each link in the text is described by attributes as follows. If not,
[FAIL].
- If the target content is in a language different to that of the
tested content, it is correctly marked with hreflang attribute;
- If it is in a format other than that of the tested content, it is
correctly described by the type attribute;
- If it uses a character encoding different to that of the tested
content, it is described by the charset attribute.
- Check that the link text (including alternative text for any non-text
elements) clearly describes the effect of activating the element. If not,
[FAIL]
- Select elements pairwise. Check 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. If not, [FAIL].
(These liberally adapted from UWEM 1.0
13.1).
Examples:
- Link with only the text "Click here."
- Multiple links in same page with same content but pointing to different
things.
- Link from an HTML page to a large video file that does not mention
format or size.
- Link to content in a language different to that of the current
page.
Open issues:
Can contextual information can provide enough explanation for a "click
here" link?
What is meant here is that there are instances were enough
information is provided in the preceeding or surrounding text that a more
detailed link description is not needed
Accessibility evangelists would crucify us if we did not
discourage the use of 'click here' link text.
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
Examples:
Navigation bar consisting of only: Home; Up; Site map; Search...
Open issues:
- How much navigation is admissible?
- Can it be quantified in terms of the number of links and the number of
characters?
Note to BPWG:
There seems to be confusion in the MWBP document. The title refers to
�consistent navigation�. However, the second paragraph discusses
�Intelligent grouping� and the �How to do it� section suggests
providing a drill-down list based on section headings, rather than about
being consistent (it doesn't say use drill-down lists consistently). The
latter is more relevant to [STRUCTURE] than to this BP. What was the intent,
consistent navigation across a site or just good navigation in a page? This
test assumes that consistency is what must be tested.
Limitations of this test:
- Tester must be able to delimit what constitutes the site. This is
assumed to be the pages in the sample scope.
- Test has to define what a navigation mechanism is.
- It tests for consistency, not good navigation design.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test 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.
- If navigation mechanisms are different on different pages of the sample
other than in a way relevant to the difference between the pages, [FAIL].
The word "sample" in the Test procedure was fitted with links
which were non-sensical. Are there samples missing or was some other point
being made?
Examples:
- A site navigation menu is present on all pages and only changes the
presentation of the section and the current page, [PASS]
- A site navigation menu is present on all pages and changes structure
and presentation of the links [FAIL].
- A site navigation menu is present on some pages but is not on the
current page [FAIL].
- A site navigation menu is present on two pages of the sample but in a
different place [FAIL].
- Inline links on other pages have a descriptive title but on the current
page they do not.
Open issues:
More examples needed.
Note to BPWG:
It is not made explicit in
the BPs whether all non-text content is covered or only images included with
the <img> element.
The BP is actually in conflict here. The BP itself says "Provide a text
equivalent for every non-text element.".
Yet in "What to test" it says "Test for presence of alt attribute on images
and text content on objects." and elaborates to make sure that objects are
supported.
This is actually a subset of the BP itself and therefore in conflict.
Conversely, the BP states "every non-text element", which greatly increases
the scope of this test.
Additionally, the BP does give a reference to the WCAG definition of
"non-text element", which is:
Non-text Content [WCAG20] 2001-12-10
See also Normative, Informative
Non-text content includes images, text in raster images, image map regions,
animations (e.g., animated GIFs), applets and programmatic objects, ascii
art, 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.
Therefore it seems sensible to adapt the text given by Web Content
Accessibility Guidelines 1.0 and deal with all the non-text elements
Limitations of this test:
This test deals with images only.
Other non-text content is not mentioned explicitly in the Best Practices and
is beyond the scope of this test. Such content includes horizontal rules,
form controls, audio, video, multimedia elements, embedded objects and
frames.
While not all non-text elements are supported by the DDC, tests should
fokus on the super set of elements provided by markup languages.
Interpretation of the Best Practice:
The original intent of the proposed human test for this BP is linked to
the meaning of alternative text. While alt="this is alternative text"
fulfills the letter of the guideline in terms of usage of the alternative
text it leads such practice ad absurdum. This Test will cover both the
extension to other non-text elements and the meaning of alt text.
Differences to mobileOK Basic Tests:
This test covers the meaning of textual alternatives as well as additional
non-text elements. The mobileOK Basic test only covers the presence or
absence of the alt attribute for images and objects, not its value.
Test procedure:
Referring to http://www.w3.org/TR/WCAG10/#gl-provide-equivalents
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.
If content does not meet Basic Test NON_TEXT_ALTERNATIVES, [FAIL]
- Provide a text equivalent for every non-text element that, when
presented to the user, conveys essentially the same function or purpose
as auditory or visual content. If not [FAIL]
- 'Content is "equivalent" to other content when both fulfill essentially
the same function or purpose upon presentation to the user.' If not
[FAIL]
For XHTML content if any of
the following UWEM 1.0 tests are not met, [FAIL].
- UWEM 1.0 Test 1.1_HTML_01 (note
that this is same as Basic test, included for completeness
- UWEM 1.0 Test 1.1_HTML_02
- UWEM 1.0 Test 1.1_HTML_03
- UWEM 1.0 Test
1.1_HTML_04
Examples:
- Pass: Null value (alt=��) for decorative images such as rounded
corners in frame
- Pass: a text equivalent for an image of an upward arrow that links to a
table of contents could be "Go to table of contents".
- Fail: alt value same as filename
- Fail: alt=� � (space)
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test covers the functionality of documents without objects or
scripts, in addition to the mobileOK Basic Tests.
Test procedure:
If, without objects or scripts active or present, the document cannot be
viewed or used such that the original intent of the web page is fulfilled
[FAIL]
Examples:
From http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts
- Ensure that links that trigger scripts work when scripts are turned off
or 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 not supported or objects not supported
- a given form can still be filled out and submitted
- images are displayed and alternative text is shown
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- If a given web page contains contiguous content, which could techically
and semantically be separated into individual pages, and exceeds 3 screen
sizes in length without page break [FAIL]
Examples:
- a long article that extends over 3 screens full without some type of
page break would have to fail
- display of navigational information, requiring continuous movement
through the map would pass, because additional maps are loaded as
needed
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test covers the meaning of the title, in addition to the existing
mobileOK Basic Tests
Test procedure:
- Does the title thematically describe the main intent of the page
content? If not [FAIL]
- Does the title repeat unchanged across more than 3 pages? If yes
[FAIL]
- Is the title too long to display on a screen matching the Default
Delivery Context [WARN]
Examples:
- a page with the primary purpose of offering ring tones along side 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 fail
- conversely a title of "Uncle Tom's Cabin" in an ebook page, across many
pages, would be perfectly acceptable
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test covers the usefulness of the preselection, in addition to existing
mobileOK Basic Tests .
Test procedure:
- Submit the form without selecting any item (left preselected values):
- If the response is an error page [FAIL]
- If the response is a page asking the user to fix some data
[FAIL]
- If the response is the original page [FAIL]
- If the form contains a text or textarea input element, with a default
value telling what to write there [FAIL]
Examples:
None
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
If testing a webpage with a device, and horizontal scrolling appears. For
each element wider than screen size:
- if it is decorative [FAIL]
- if resizing it to screen size, it could be easily read and/or described
[FAIL]
Examples:
None
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- If headers and list elements aren't properly nested according to their
level [FAIL]
- If lists elements aren't used to represent lists (ordered, unordered,
or definition lists) but formatting effects [FAIL]
- If headers elements aren't used to represent headers but formatting
effects [FAIL]
- If visually some information is shown as a group of related elements,
but there isn't any list element in the markup [FAIL]
- If visually some information is shown as a block of text, but there
isn't any paragraph or blockquote element in the markup [FAIL]
Examples:
None
Open issues:
It is not clear what structural markup is and which elements are included
in this definition.
Note to BPWG:
None
Limitations of this test:
There is no guidance on this parameter and a value was picked
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- If whitespaces are more than 10% of CSS content [WARN]
- If whitespaces are more than 20% of CSS content [FAIL]
- If there are style properties that doesn't aply to the page [WARN]
- If there are at least two CSS properties that could be mixed in a
shorthand property [WARN]
- If there is at least one CSS RGB color property that could be written
shorthand way [WARN]
Examples:
None
Open issues:
- What is an optimized stylesheet?
- It is not clear if there should be some upper limit on style sheet use,
for example as percentage of the total page size and if there should be,
what percentage that should be.
Several tests refer to white space. White space has the same
definition in this document as in XML. For XML 1.0 [XML10] it
is defined in http://www.w3.org/TR/REC-xml/#sec-common-syn
as being:
S ::= (#x20 | #x9 | #xD | #xA)+ i.e. the characters SP,
TAB, CR and LF.
Could this be applied to a CSS?
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
If content is unreadable or unintelligible with stylesheets disabled
[FAIL]
Examples:
None
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
This test is clearly very subjective, therefore the threshhold for a FAIL
is very high. It must be beyond reasonable argument that the presentation of
the content is inapropriate for a mobile context.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
Examine content to determine if,
given the subject matter, it is appropriate in a mobile context. If not
[FAIL]
Examine the content to determine if the presentation is very obviously
inappropriate in a mobile context. If so [FAIL]
Examples:
- a page showing Renaissance paintings in full size - FAIL
- a page showing a listing of Renaissance Paintings with thumb nails -
PASS
- a page offering large downloads of applications that mobile devices do
not support, such as professional image manipulation software, desktop
operating systems etc. - FAIL
- a full size x-ray image for in-field access by medical personnel - PASS
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
Does the tab order of links, form controls and objects follow a logical or
thematic order? If not [FAIL]
Examples:
- If a user is required to enter their first name, last name, address and
contact number, if the tab order jumps between, say, the first name and
the phone number and then back to the last name [FAIL].
- If a pizza ordering service offers a choice of toppings and bases, if
the tab order jumps between those two categories when presenting the user
with options [FAIL]
- If the Submit button, or Sumbit and Cancel buttons, are not the last
item(s) in the form [FAIL]
Open issues:
None
Note to BPWG:
None
Limitations of this test:
As of this writing, CSS is itself deficient in that it does not support a
grid layout that auto adjusts vertically. It must be recognized therefore
that some layouts can currently only be achieved using tables.
Differences to mobileOK Basic Tests:
In addition to the mobileOK
Basic Test, this test checks usage for layout.
Test procedure:
If tables are used in a fashion that could be achieved using CSS [FAIL]
Examples:
- An image or text which is spaced and positioned with the aid of a
table
Open issues:
None
Note to BPWG:
We had originally asked why this test is not included in
basic tests, but the Open Issue below spells it out. How can it be determined
if a device supports tables? Just look it up in UAProf or can the Checker do
something here?
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
If the device does not support tables and the table element is found
within the source code [FAIL]
Examples:
None
Open issues:
Is there a way to programatically determine if a device supports
tables?
Note to BPWG:
This BP gives no information about what is being tested, which calls this
BP into question as being useless.
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- Has this content been tested with emulators? If not [FAIL]
- Has this content been tested with actual devices? If not [FAIL]
I would also offer: Has this content been validated? If not
[FAIL] and Has this content been tested with the Checker? If not [FAIL]
Examples:
None
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- Is the entry Domain, including main and subdomain, less than 20 key
presses on the device? If not [WARN]
- Does the entry URI require a file extension as in .html? If yes,
[FAIL]
- Does the entry URI require the www subdomain? If yes, [FAIL]
Examples:
None
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Test procedure:
- Excluding hyperlinks, does the page include any other blue or purple
text? If yes, [FAIL]
- When viewed on a monocrome screen, is all content still readable? If
not, [FAIL]
- Is color used to represent information? If yes, [FAIL]
Examples:
- Using red text to represent an error
message - PASS
- Using blue or purple text within
the page, other than for hyperlinks - FAIL
- Telling the user that important information
is highlighted in yellow - FAIL
Open issues:
None