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

Thanks very much for these detailed and helpful comments.

We'll review them in the group and get back to you.

Jo

> -----Original Message-----
> From: public-bpwg-comments-request@w3.org
[mailto:public-bpwg-comments-
> request@w3.org] On Behalf Of Shadi Abou-Zahra
> Sent: 23 June 2007 14:15
> To: public-bpwg-comments@w3.org
> Cc: public-wai-ert@w3.org; Carlos Iglesias
> Subject: 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 Sunday, 24 June 2007 12:48:10 UTC