ERT WG comments on mobileOK Basic Tests 1.0 LCWD of 25 May, 2007

Dear BPWG,

Please find below ERT WG comments on the latest mobileOK Basic Tests 1.0 
LCWD of 25 May, 2007. The comments are divided into two parts: Part A 
are responses to the BPWG resolutions to the ERT WG comments on the 
previous LCWD version of the document; and Part B are new comments on 
the current LCWD document.

##PART A: ERT WG RESPONSES TO BPWG RESOLUTIONS

COMMENT A.1:
- ERT WG COMMENT:
Section "2.2 Testing outcomes"
The MWBP group have know made clear that warnings are _no_ test outcomes 
but it was also said that the group do not want to specify _which_ 
warning may be generated. In order for the tool developer to create a 
reasonable warning, it would help him to know at least the specific 
purpose why a warning has to be generated.
- BPWG RESOLUTION:
The checker will provide a reference implementation of what the 
warning/error text should be for each warning or error, also linking 
back to appropriate reference material.
- ERT WG RESPONSE:
It's not clear what you mean with "linking back to appropriate reference 
material". What will the appropriate reference material be? Is the 
intention just to link back to the mOK or BP documents as-is? We think 
the point here is not to provide the text of a warning, but to ensure 
that it is clear what the potential problem associated with a warning is.


COMMENT A.2:
- ERT WG COMMENT:
Section "2.3.3 HTTP Response"
"If an HTTP request fails for any reason during a test (network-level 
error, DNS resolution error, non-HTTP response, or server returns an 
HTTP 4xx or 5xx status), the test outcome should be considered FAIL"
You can (and should) evaluate any content received from the server, 
error messages included as they're also content. When the server returns 
4xx or 5xx the result of the test should not fail, because otherwise the 
website as a hole could never be Mobile OK compliant (e.g. you can 
always make a request that will produce an 404 and thus a fail)
- BPWG RESOLUTION:
See http://lists.w3.org/Archives/Member/member-bpwg/2007Feb/0070.html
- ERT WG RESPONSE:
For 300 Multiple Choices [1] a page could be displayed. Apparently this 
depends on client capabilities [2]. It's important to clarify how to 
handle 300 response codes where the page is displayed.
  -[1] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1>
  -[2] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12.2>

COMMENT A.3:
- ERT WG COMMENT:
Section "3.10 MEASURES" reads: "If the value is non-zero and the unit is 
not "em", "ex" or "%", and the property is not a margin, border or 
padding box property (see also 3.20 SCROLLING (partial) ), FAIL"
There are other CSS properties where px values may be allowed as the 
background-position or the outline-width.
- BPWG RESOLUTION:
We agree with the basic point but we will address it in the next phase 
of the Best Practices document instead.
- ERT WG RESPONSE:
We acknowledge the dependency of this test on the wording of the related 
BP. However, we think this is an important issue that needs to be 
addressed in this document before it reaches Recommendation status. As 
currently defined, this test could produce a fail outcome where it 
should be a pass. This could also lead to ambiguity amongst different 
checker tools.


COMMENT A.4:
- ERT WG COMMENT:
Section "3.12 MINIMIZE"
The definition of whitespace characters should be clarified, does it 
include CR (carriage return) for example?
Additionally, it would make sense to consider also CSS in the minimization.
- BPWG RESOLUTION:
We accept the clarification and point to XML definition for white space: 
http://www.w3.org/TR/REC-xml/#sec-common-syn
However, we exclude style regions for the current document but revisit 
for the next Best Practices document.
- ERT WG RESPONSE:
While we think that handling extraneous white space in external CSS 
would be useful at this stage, we recommend to at least add a clear note 
about how it is (not) handled in the current document.


COMMENT A.5:
- ERT WG COMMENT:
Section "3.15 OBJECTS_OR_SCRIPT"
"If the value of the href attribute begins with the "javascript:" 
scheme, FAIL"
At least, href attributes with "#" (or any number of '#') value should 
also fail as it's a widely used value. A wider definition which 
discourages any misuse of href values in general would be desirable.
- BPWG RESOLUTION:
We think that there are valid uses for allowing # as the href, such as a 
link to the top of the page.
- ERT WG RESPONSE:
Although being a valid URI, the behaviour of href="#" is not defined. 
Several user agents have the behaviour describe above, but we think this 
shouldn't be considered a good practice and the linking to the top of a 
page should be done using a real (not empty) anchor (fragment ID).


##PART B: NEW ERT WG COMMENTS ON CURRENT DOCUMENT

COMMENT B.1:
- comment nature: [substantial]
- location: All the tests
- current wording: It looks like PASSES and FAILS are defined as "final 
states" that interrupt the algorithm (otherwise all the algorithms will 
always produce a PASS, as it's always the last instruction)
- suggested revision: Tests algorithms should be describe in a way that 
provide messages for every fail or warning
- rationale: If they not do so, then the algorithm would be useless for 
tracking reasons, you can use them to know if something PASS or FAIL, 
but not to know the details.


COMMENT B.2:
- comment nature: [substantial]
- location: All the tests
- current wording: There is no reference to the applicability condition 
or prerequisites (when relevant) in the pseudo-code
- suggested revision: Include this applicability rules in the algorithms 
when relevant
- rationale: Some times could be not clear when to produce a N/A output 
vs. a Pass/Fail one. This is also a good practice for the shake of 
completeness in the algorithm


COMMENT B.3:
- comment nature: [clarification]
- location: 2.3.2 HTTP Request
- current wording: Use the HTTP GET method when making requests.
- suggested revision: Clarify how to proceed while testing GET requests. 
E.g. use only default values
- rationale: It's quite clear now (see related #7 comment) what are the 
reasons to leave POST requests out, nevertheless there's no clear 
indication on how to proceed while testing GET requests.


COMMENT B.4:
- comment nature: [clarification]
- location: 2.3.2 HTTP Request
- current wording: Use Implementations must support URIs with both http 
and https  scheme components.
- suggested revision: Clarify how to proceed with different URI schemes.
- rationale: It's not clear what should be done when you find a 
different URI scheme. Ignore it?

#5 COMMENT
- comment nature: [clarification]
- location: 2.3.3 HTTP Response
- current wording: If the HTTP status indicates redirection (status code 
3xx):
   Do not carry out tests on the response
- suggested revision: It's not clear what to do with invalid location 
header values (URIs that are not absolute.
absoluteURI   = scheme ":" ( hier_part | opaque_part )
- rationale: Quite a lot of servers create
    Location: /foo.bar
   instead of
    Location: http://www.example.org/foo.bar


COMMENT B.5:
- comment nature: [editorial]
- location: 2.3.5 CSS Style
- current wording: resources linked by xml-stylesheet  processing 
instructions
- suggested revision: resources linked by xml-stylesheet  processing 
instructions, as defined in 2.3.7 Included Style Sheet Resources"
- rationale: It make sense to reference the normative definition


COMMENT B.6:
- comment nature: [clarification]
- location: 2.3.5, 2.3.6, 2.3.7
- current wording: At 2.3.5 is said that the CSS style must be assemble 
using @import rules among others, and at 2.3.6 this rules are also 
included in the definition of included resources, but at 2.3.7 there in 
no mention to @import while defining included style sheets that are 
taken into account when calculating the page size.
- suggested revision: Include @import rules into the page size calculation
- rationale: If CSS provided by @import rules is going to be analysed 
then it should also be taken into account while calculating the page size.


COMMENT B.7:
- comment nature: [typo]
- location: 2.3.8
- current wording: Note that forms with method _get_ are permissible in 
documents under test, but must not be checked in case posting caused 
unwanted side effects such as the addition of unwanted records to a 
database.
- suggested revision: Note that forms with method _POST_ are permissible 
in documents under test, but must not be checked in case posting caused 
unwanted side effects such as the addition of unwanted records to a 
database.
*rationale: We think it's a typo as currently POST is the method that 
it's not been checked


COMMENT B.8:
- comment nature: [editorial]
- location: 2.3.8
- current wording: Note that forms with method POST are permissible in 
documents under test, but must not be checked in case posting caused 
unwanted side effects such as the addition of unwanted records to a 
database.
- suggested revision: Add a similar note before 2.3.2 HTTP Request
*rationale: We think this clarification should also be done before as 
it's also quite relevant to correctly understand why at 2.3.2 the use of 
GET method is required.


COMMENT B.9:
- comment nature: [clarification]
- location: 2.3.9 Validity
- current wording: "CSS > A resource is considered a valid CSS resource 
if it conforms to the grammar defined in [CSS], Appendix B."
- suggested revision: Include all the properties that are allowed in the 
definition of Valid CSS
- rationale: It's not clear what CSS properties are allowed as, apart 
from those in the CSS1 Recommendation, there are mentions at least to 
@media (3.21) and position (3.20).


COMMENT B.10:
- comment nature: [clarification]
- location: 2.3.10 White space
- current wording: "Several tests refer to white space. White space has 
the same definition in this document as in XML. For XML 1.0 [XML10] it 
is defined in http://www.w3.org/TR/REC-xml/#sec-common-syn as being:
S ::= (#x20 | #x9 | #xD | #xA)+ i.e. the characters SP, TAB, CR and LF"
- suggested revision: Should &nbsp; entities (#xA0) be considered?
- rationale: This entity is frequently used (and abused) and having a 
look at the related test (3.15, 3.17 and maybe 3.12) it makes even more 
sense


COMMENT B.11:
- comment nature: [clarification]
- location: 3.2 CACHING
- current wording: In the following, note that HTTP headers should be 
used rather than meta elements with http-equiv attributes, which are 
commonly not taken into account by proxies. Where both a meta element 
and the corresponding header are found the value of the header must be used.
- suggested revision: Clarify what to do in the absence of HTTP headers, 
should meta elements be used?
- rationale:


COMMENT B.12:
- comment nature: [typo]
- location: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
- current wording: application/xhtml+xml; charset=UTF-8"
- suggested revision: Remove '"'
- rationale:


COMMENT B.13:
- comment nature: [clarification]
- location: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE 
and elsewhere where the message body is not involved (3.6, 3.10, 3.16)
- current wording: For each resource specified by 2.3.6 Included Resources:
    Request the resource
- suggested revision: Would a HEAD instead of GET request be sufficient?
- rationale:


COMMENT B.14:
- comment nature: [clarification]
- location: 3.4 CONTENT_FORMAT_SUPPORT  and VALID_MARKUP
- current wording: If the document is an HTML document
- suggested revision: What is "an HTML document" here? Which 
characteristics are to be checked?
- rationale: Is not clear if there's any algorithm to check whether 
something is an HTML document or not as it's not clear what you should 
look for in absence of an HTML document definition.


COMMENT B.15:
- comment nature: [editorial]
- location: 3.6 EXTERNAL_RESOURCES
- current wording: "Note that if an HTTP request is unsuccessful while 
conducting this test, the result is FAIL"
- suggested revision: Include this condition in the general algorithm
- rationale: It's the only condition that affects to the result and it's 
out of the general algorithm, this way it could be easily leave out


COMMENT B.16:
- comment nature: [clarification]
- location: 3.6 EXTERNAL_RESOURCES
- current wording: "Note that if an HTTP request is unsuccessful while 
conducting this test"
- suggested revision: Clarify what means unsuccessful here
- rationale:


COMMENT B.17:
- comment nature: [typo]
- location: 3.6 EXTERNAL_RESOURCES
- current wording: Count the total number of unique included resources, 
as defined in 2.3.6 Included Resources
- suggested revision: Add '.'
- rationale:


COMMENT B.18:
- comment nature: [clarification]
- location: 3.11 MEASURES
- current wording: "For each property in the CSS Style whose value is a 
numeric measure of length stated together with a unit
If the value is non-zero and the unit is not "em" or "ex"..."
- suggested revision: Why has been % left out? is it not considered an unit?
- rationale: As currently expressed it's not clear what to do with 
percentages


COMMENT B.19:
- comment nature: [clarification]
- location: 3.11 MEASURES
- current wording: "For each property in the CSS Style whose value is a 
numeric measure of length stated together with a unit
If the value is non-zero and the unit is not "em" or "ex"..."
- suggested revision: The current wording could give the impression that 
numeric measures without units are allowed, which in general is not a 
good idea with some exceptions.
- rationale: Although this issue could be already covered by CSS 
validation, redundancy could be helpfull for the shake of
completeness in this test as "mobileOK tests are intentionally expressed 
in an independent way"


COMMENT B.20:
- comment nature: [editorial]
- location: 3.12 MINIMIZE 3.15 OBJECTS_OR_SCRIPT 3.17 PAGE_TITLE
- current wording: "white space"
- suggested revision: Link to the "normative" definition of white space 
at 2.3.10 White Space
- rationale: Once you have a "normative" definition it make sense to 
link to it as it's been done with "Validity"


COMMENT B.21:
- comment nature: [typo]
- location: 3.13 NO_FRAMES
- current wording: "If the document contains a frame, frameset or iframe 
element or object element..."
- suggested revision: "If the document contains a frame, frameset or 
iframe element or _an_ object element..."
- rationale: Apparently there is a missing "an"


COMMENT B.22:
- comment nature: [clarification]
- location: 3.16 PAGE_SIZE_LIMIT
- current wording: If the size of the document's markup exceeds 10 kilobytes
- suggested revision: Does "size of the document's markup" mean "the 
markup document's length"?
- rationale: Although this is the most sensible, it could also mean 
"count only tags" or other things


COMMENT B.23:
- comment nature: [substantial]
- location: 3.18 POP_UPS
- current wording: "If a target attribute is present,..."
- suggested revision: What about JS popups? (window.open)
- rationale: JS popups should be taken into consideration as there are 
already other JS related verifications


COMMENT B.24:
- comment nature: [editorial]
- location: 3.19 PROVIDE_DEFAULTS
- current wording: "If there is no nested option element whose selected 
attribute is set to some value, warn"
- suggested revision: "If there is no nested option element whose 
selected attribute is set to _"selected"_, warn"
- rationale: This is the only valid value for this attribute and it's 
been already included in the next condition of the algorithm


COMMENT B.25:
- comment nature: [substantial]
- location: 3.21 STYLE_SHEETS_USE and 2.3.9 Validity
- current wording: If the CSS Style contains at-rules (other than the 
@media at-rule), properties, or values that are not recognized as being 
valid CSS Level 1 (2.3.9 Validity), warn
...
CSS
     A resource is considered a valid CSS resource if it conforms to the 
grammar defined in [CSS], Appendix B
- suggested revision: The definition of CSS validity should include in 
some way allowed at-rules, properties and values.
- rationale: Test 3.4 fails for content that is not valid CSS with 
validity being defined as conforming to the CSS 1 grammar (syntax).
Test 3.21 seems to use the phrase "valid CSS 1" in a sense that is not 
just grammar conformance.
So right now, CSS 2 that conforms to the CSS 1 grammar passes 3.4, but 
you'll get a lot of warnings, because the grammar does not define 
properties and values (3.21)
Additionally,
    @import "foo.css" handheld;
would fail 3.4 because of the media type, which is not part of the CSS 1 
grammar, while the rule should be considered when collecting the 
"Included Resources" (2.3.6).


COMMENT B.26:
- comment nature: [editorial]
- location: 3.21 STYLE_SHEETS_USE
- current wording: If the CSS Style contains at-rules (other than the 
@media at-rule), properties, or values that are not recognized as being 
valid CSS Level 1 2.3.9 Validity, warn
- suggested revision: Add () around the link "2.3.9 Validity".
- rationale:


Regards,
   Carlos Iglesias and Shadi Abou-Zahra for ERT WG


-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
Chair & Staff Contact for the Evaluation and Repair Tools WG |
World Wide Web Consortium (W3C)           http://www.w3.org/ |
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ |
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ |
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ |
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France |
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |

Received on Saturday, 23 June 2007 22:01:38 UTC