Re: Tests 4.32 onwards

Thanks Alan, some comments inline below

Alan Chuter wrote:
> ** 4.32 Suitable
> The examples of SUITABLE should perhaps include one of
> an outsize page of text. 

I agree - but this runs into the problem that Manrique has highlighted - 
that the DDC does not specify a page height, only a page width (120px).

We could say that any image wider than 120px is a FAIL but the X-Ray 
example (and perhaps a map) would work against that.

We could perhaps take an external measurement, something akin to "if the 
amount of text, when rendered in 10pt, fills more than a side of A4 FAIL" ??

> I wonder whether perhaps the limit for this could be
> quantified based on device characteristics like screen
> size, memory, bandwidth etc. Probably not, but it's
> worth considering.


> ** 4.33 Tab Order
> "logical or thematic order" could perhaps say
> something about the designer's intention.

Can you suggest something, I don't think I quite grasp what you mean.

> **4.34 Tables Layout
> I think that when there is an auto test, this should
> be the first step in the test procedure.

Agreed, so we're talking about how it's presented in the text here. The 
"Differences to mobileOK Basic Tests" section says: "In addition to the 
mobileOK Basic Test, this test checks usage for layout." and then we get 
to the MOK Pro test itself: "If tables are used in a fashion that could 
be achieved using CSS [FAIL]"

Not good enough?

> ** 4.36 Testing
> The BP doesn't mention validation. I think you could
> have invalid markup and then use emulators and real
> devices to test in many ways with no problem (without
> stumbling upon the hypothetical problem). So
> validation isn't required here, I think. I really
> strongly suggest that there be no test for this BP.

You're reading the doc - which I didn't change - and not my comments in 
the e-mail. My basic suggestion is that a MOK Pro claim should list the 
devices on which the content was tested, rather than try and prescribe a 
repeatable test for this one.

> --- Phil Archer <> wrote:
>> OK, I've been through my tests and have edited the
>> document Kai sent 
>> this afternoon accordingly (see attached).
>> In addition to the changes in the document, I have
>> made some notes on my 
>> thinking below.
>> Until tomorrow...
>> Phil.
>> 4.32 Suitable - I believe I've cleaned that up a
>> little, basically 
>> setting the bar for a FAIL very high in an attempt
>> to ensure consistency 
>> between evaluators.
>> 4.33 Tab Order
>> Minor edits with some examples added for good
>> measure
>> 4.34 Tables Layout
>> Tidied this up. My worry here is that we're testing
>> a balance between 
>> what is possible using CSS and what is practical in
>> real life. I tried 
>> very hard not to use tables for layout on the fosi
>> homepage - but ended 
>> up using 2 all the same. It wouldn't even pass the
>> Basic test...
>> 4.35 Tables Support
>> The only way I can see to resolve this is to send a
>> request for a page 
>> that contains tables using the UA string of one or
>> more devices known 
>> not to support them. Perhaps the emulator could
>> include this functionality?
>> 4.36 Testing
>> Are we constrained always to give a Pass/Fail/Warn?
>> If not then I 
>> suggest the way to test this is to list the actual
>> devices that were 
>> used (probably by means of a white space separated
>> list of their Device 
>> Description URIs). It's not a test as such, but a
>> way to report that 
>> tests have been carried out, which is what we want
>> people to do with 
>> this one. So the 'Test Procedure' would be:
>> * List the identifiers of the devices on which the
>> content was tested 
>> and rendered as intended
>> * List the devices on which he content was tested on
>> which teh content 
>> was not rendered as intended
>> 4.37 URIs
>> I've removed the example from here - yes, those
>> things are true, but 
>> they don't actually exemplify the tests which seem
>> pretty clear to me as 
>> they are.
>> Also, I've deleted the open issue as I'm not
>> convinced that this is 
>> fully machine testable. I have some experience of
>> this in the ICRA label 
>> generator.
>> Users are asked to enter the homepage URL. When the
>> form is submitted, 
>> the system strips off the www subdomain where I can
>> determine that it is 
>> not important. A simple test is to do a GET on the
>> URI with and without 
>> the www and compare the content. If you get a 4xx
>> message from the 
>> non-www, OK, the www is necessary, but you might get
>> a 3xx or even a 200 
>> and still the content won't match byte for byte as
>> the links and 
>> references within the content might be delivered in
>> a dynamic process. 
>> The text could easily include something as simple as
>> a PHP ?echo 
>> SERVER-NAME parameter which would change depending
>> whether the www were 
>> included or not.
>> As a result I ended up saying that if the content
>> returned from the two 
>> URIs differs by <= 95% - and that's a pretty
>> arbitrary figure. The 
>> manual test is easier in this case!
>> 4.38 Use of color
>> Generally tidied up but no substantial changes.

Received on Wednesday, 9 April 2008 09:21:17 UTC