Note to BPWG:
None
Limitations of this test:
There are many different ways to aid data input, with no one 'right' way.
However, leaving it entirely up to the user to enter the data freehand
without any attempt to offer pre-selection or pre-filling of the input field
by automated means, where avilable, is readily detectable as 'the wrong
way.'
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
If there are one or more free text input fields:
Could they be converted into any of:
- a select field,
- radio buttons with no more than x values,
- radio buttons for the most likely entries plus a free text option for
'other' values
- check boxes with no more than y values?
If these techniques are avilable, but not implemented: [FAIL].
If the techniques above are not avilable and if data has been entered
previously, if the previously-entered data is not used to pre-fill the input
field: [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:
This test does extend to users with visual impairment. The Web Content
Accessibility Quick
Reference offers more advice on this topic.
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.
Pseudo code:
Where there is a background image, if perceiving content in the foreground
is not easy under normal daylight conditions: [FAIL]
Examples:
- Pink is easily lost on this
background
- Yellow is practically not legible
on this background
- But this is much better
Open issues:
Should we include a reference to the WCAG 2.0 techniques?
If so, did Alan choose the right one?
Note to BPWG:
None
Limitations of this test:
This test is highly dependent on context. Some content, such as site maps,
online encyclopedias and other reference materials may warrant a high link
density. As the scrolling action on many mobile devices selects each link in
turn, however, including a lot of links on a single page can easily create an
unsatisfactory user experience.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
Unless the primary purpose of the content is navigation, such as a site
map, or the user could readily want to persue links to further resources in
an unpredictable manner:
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. However, it is usually possible to detect presentation that is
artificially constrained by the limited and largely hypothetical Default
Delivery Context. Unlike the DDC, many real devices support scripting, XML
HTTP requests, DOM capabilities, cookies and CSS including media queries.
Furthermore most current devices have screens well in excess of 120 pixels
wide
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
If the presentation of the content is artificially limited by the
capabilities of the DDC and if the presentation is similarly limited on more
capable devices: [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.
- Again, in forms, scripting may be used to adjust the presentation or
state of a control based on the input(s) already supplied.
Open issues:
This is a can of worms, but it is important to counteract the “working
down to the DDC” issue
Note to BPWG:
None
Limitations of this test:
There are subtle differences between these two Best Practices. Central
Meaning is concerned with the physical layout of the page, ensuring that
desktop-style navigation does not dominate whilst Limited is concerned with
presenting information in a manner that reflects the likely real world
situation of the audience - on the move with limited time and attention span,
perhaps in an environment where there are many forces competing for the
user's attention. Despite these differences, it is convenient to test
conformance with these two Best Practices together.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
- If it is not possible to determine what the main focus of a web page is
without scrolling: [FAIL]
- If simple facts that can readily be presented using bullet points and
headings are instead presented as lengthy prose: [FAIL]
Examples:
None
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.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
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.
Limitations of this test:
This test cannot be failed, because alternate formats may not be
available.
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
The follow is not very explanatory and needs some
wordsmithing.
How would one determine a "change" in the quality headers, which denote
preference of a content format?
Or did we mean if they are different, as in 0.1 - 0.9 over a variety of
formats?
If the quality factors of the accept headers are changed and the content
which is delivered does not reflect that change [WARN]
Examples:
A change in preference between GIF and JPEG, character encoding or markup
for a given device, should be reflected accordingly.
Open issues:
None
Note to BPWG:
This test is machine testable
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
- If there are form elements and no label elements [FAIL]
- If the for attribute is not defined and the content of the label
element is not a form control [FAIL]
- If the for attribute is present but does not correspond to the id
attribute of a form control [FAIL]
Examples:
None
Open issues:
- Confirm that point 1 is really valid.
- 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?
Note to BPWG:
None
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.
- The DDC supports only CSS 1
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
- 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:
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.
Pseudo code:
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. An 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.
Pseudo code:
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:
None
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.
Pseudo code:
Provoke a server-side error.
- For example: Request a URL known not to correspond to any endpoint on
the site.
- [others]
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.
Pseudo code:
- 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]
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.
Pseudo code:
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.
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.
Pseudo code:
- 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
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
- Is there basic navigation on the page before the other content? If not
[FAIL].
- Does all the navigation detected in [1] fit on a single line (in DDC)?
If not [FAIL].
- Is a some of the main content visible without scrolling (sufficient to
get an idea of the rest of the content)? If not [FAIL]
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.
Pseudo code:
- 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 pseudo code 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.
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.
Differences to mobileOK Basic Tests:
This test covers the meaning of textual alternatives. The mobileOK Basic
test only covers the presence or absence of the alt attribute, not its
value.
Pseudo code:
If content does not meet Basic Test NON_TEXT_ALTERNATIVES, [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
- 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.
Pseudo code:
If the document cannot be viewed properly without objects or scripts
active or present [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.
Pseudo code:
- If there is no apparent justification for exceeding 3 screen sizes in
length [FAIL]
- If the pages displayed are so short that multiple requests are needed
to display the full information and their combined length does not exceed
three screens [FAIL]
Examples:
None
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
Pseudo code:
- Does the title meaningfully describe the page content? If not
[FAIL]
- Is the title too long to display on a screen matching the Default
Delivery Context? [WARN]
Examples:
None
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 the
existing mobileOK Basic Tests.
Pseudo code:
- If the preselection for all form elements is useful. If not [FAIL]
- If no preselection exists and could meaningfully be added [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.
Pseudo code:
Is the usage of horizontal scrolling justified? 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.
Pseudo code:
- Document structure must be represented using proper structural markup
rather than formatting effects. If not [FAIL]
- Where structural markup is used it should be used in accordance with
the specification, i.e. elements should be properly nested according to
their level. If not [FAIL]
- If structural markup is being used improperly, e.g. for formatting
effect [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.
Pseudo code:
- Are style sheets optimized? If not [FAIL]
- Are the style sheets utilized properly? If not [FAIL]
- Is a given style sheet appropriate in its size for the given content,
keeping in mind chaching and loading effects? If not [FAIL]
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.
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
If content is unreadable or unintelligible with stylesheets disabled
[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.
Pseudo code:
Examine content to determine if, given the subject matter, it is
appropriate in a mobile context. If not [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 downloads of Windows XP - FAIL
- a full size x-ray image for in-field access by EMTs – 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.
Pseudo code:
Is the tab order of links, form controls and objects disorganized,
illogical or confusing? If not [FAIL]
Examples:
None
Open issues:
None
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
In addition to the mobileOK Basic Tests, this test checks usage for
layout.
Pseudo code:
If tables are used in a fashion that could be achieved using CSS [FAIL]
Examples:
An image or text which are spaced and positioned with the aid of a table
Open issues:
CSS currently is itself deficient in that it does not support grid layout
that auto adjusts vertically
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.
Pseudo code:
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.
Pseudo code:
- 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.
Pseudo code:
- 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 subdomain www? If yes, [FAIL]
Examples:
Entry URIs should not include information such as author, date, title. See
“Cool URIs don’t
change”
Open issues:
It seems that at least the file extension and the subdomain ought to be
machine testable?
Note to BPWG:
None
Limitations of this test:
None
Differences to mobileOK Basic Tests:
This test does not exist in mobileOK Basic Tests.
Pseudo code:
- Excluding hyperlinks, does your site include any other blue or purple
text? If yes, [WARN]
- When viewed on a monocrome screen, is all content still readable? If
no, [FAIL]
- Is color used to represent information? If yes, [FAIL]
Examples:
- Using red text to represent an error
message
- Using blue or purple text within the page
as it makes it harder to distinguish hyperlinks
- Telling the user that important
information is highlighted in yellow
Open issues:
None