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

Hi Sean, hi group

Sean Owen schrieb:
> 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.

Understood and accepted :-)

>> 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.

OK

>> 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.

OK

>> 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

or non-existing

> value attribute. For textarea, this means an empty body
> (no child nodes). We'll clarify this.

OK

>> 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.

I would find it confusing if something fails a test for mobileOK basic, 
but passes a test for mobileOK "sophisticated". The other way round 
would be ok (e.g. the test for SCROLLING).

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

There is a technique to add information which is obvious for users 
equipped with a 2D-rendering visual browser, but also valuable for users 
equipped with a 1D-rendering textual or voice browser or screen reader 
(e.g. skip links, or text "main menu") using a transparent image and 
adding this information in the alt attribute of this image. There are 
other techniques for this purpose (e.g. hiding with CSS) though.

>> <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.

OK

>> 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.

OK

> 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.

I understand that it's more difficult in automatic tesing, yes.

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

OK

>> 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).

OK

>> <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.

OK

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

OK

> Thanks again!

You're welcome.

-- 
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
                          (Thomas Tallis, 40-part motet)

Received on Thursday, 23 November 2006 22:12:51 UTC