Re: Tests 4.32 onwards

** 4.32 Suitable
The examples of SUITABLE should perhaps include one of
an outsize page of text. 

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.

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

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



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

Yahoo! For Good helps you make a difference

Received on Wednesday, 9 April 2008 08:48:24 UTC