Re: comments on WD-mobileOK-basic10-tests-20061113

Thanks Johannes for your valuable and informed feedback -- we'll
incorporate several changes into the next draft as a result. More
comments follow inline. Let us know what you think of them.

On 11/20/06, Johannes Koch <koch@w3development.de> wrote:
> 2.2 Testing Outcomes
>
> <blockquote>
> Individual rests may result have result of PASS or FAIL. PASS is
> required from all tests in order to claim mobileOK Basic.
>
> In addition to generating a PASS or FAIL tests may also generate a
> number of informative WARNs whose purpose is to alert the tester that in
> some circumstances the content being assessed may contravene Best Practices.
> </blockquote>
>
> If PASS is required for conformance, WARN cannot be just informative (a
> subclass of Pass, but must be a CannotTell in EARL terminology). Some of
> them may imply additional human-verifyable test (e.g. 3.16 script
> element part). Can conformance also be claimed if additional tests are
> performed and result in PASS?

All tests result in PASS or FAIL only, never WARN. The warnings are
intended to be informative only. I think the typographic convention
here is confusing, since all three terms are in all-caps. I believe
warnings should be indicated differently in the tests to avoid
confusion.


> If XHTML MP is allowed, "2.4.2 Style Information" should also include
> the CSS specified in a style attribute. XHTML MP version 1.2 (20050118)
> has a section 8.4 on "Inline Style" using the style attribute.

Agreed, and the group is still discussing whether to mention XHTML MP
in the tests. If so, I agree, the style attribute must be mentioned.


> What about <input type="password" .../>?

It does seem reasonable to specify inputmode on this kind of input
too, though it does reveal a little information about what characters
may be used in the password.

> What does "is empty" mean? No input/@value? No child nodes?

This should be clarified. The test means to require inputmode only
when the input has no pre-filled value. For input elements, this means
a non-empty value attribute. For textarea, this means an empty body
(no child nodes). We'll clarify this.


> If a spacer image is not fully transparent or bigger than 2x2, the test
> passes, which means the requirement GRAPHICS_FOR_SPACING is met. But it
> could still be used for spacing.
>
> This test is not sufficient for testing against the requirement. There
> must be more (human-verifiable?) tests following.
>
> On the other hand, small transparent images are not only used for
> spacing, but also for adding information for text media, like screen
> readers.

Agreed, the basic test presented here does not catch all cases which
go against the best practice. I believe we should work on specifying a
human-verifiable test in mobileOK. We can update Appendix C
accordingly.

You mention that transparent images may be used for screen readers --
what is this application?


> <blockquote>
> If the height or width attribute do not specify a size in pixels, FAIL
> </blockquote>
>
> The values for img/@height and img/@width must be %Length;. This also
> allows for percentage values.

You're right, and this is an interesting issue. While the best
practices typically ask developers to use relative measures, not
absolute measures, in the case of images it is felt that it's
important for the server to determine the right size of an image, in
pixels, so that it may resize the image appropriately on the server
and send the image at exactly the right resolution. Hence it makes
sense to make img elements specify height and width in pixels. There
is still some discussion on this point though.


> 3.10 LINK_TARGET_FORMAT
>
> This test only applies to the a element.
>
> What about form/@action(, link/@href)?

Yes this test should likely include at least some kinds of link element.
Forms are harder to test. Submitting a form may not "work" (retrieve
the usual target page) without certain inputs being filled in. Form
POSTs may also have side effects. Hence there is some reluctance to
specify that form/@action be tested.


> <blockquote>
> Count number of whitespace characters ... outside of a pre, style or
> script element.
> </blockquote>
>
> Add " and outside a comment".

Agreed.


> 3.21 SCROLLING
>
> If the test cannot make sure the subject passes, it should not create a
> PASS but a CANNOT_TELL.

The test itself is limited, and conservative. It will catch obvious
cases where a page must render wider than 120px but not all. But a
page may still PASS the basic conditions outlined in this test, even
if one can imagine a more complete human-testable test (which indeed
should appear in mobileOK).


> <blockquote>
> If the element is empty, or contains an image whose real dimensions are
> 2x2 or less, FAIL
> </blockquote>
>
> Does "contains an image ..." mean "contains as its only child node an
> image ..."?

Yes, we'll clarify.


> B References
>
> The reference XHTML11 should better be called XHTMLBasic11 (could
> otherwise be confused with XHTML 1.1).

Agreed.


Thanks again!

Received on Thursday, 23 November 2006 19:47:00 UTC