W3C home > Mailing lists > Public > public-wai-ert@w3.org > June 2007

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

From: Jo Rabin <jrabin@mtld.mobi>
Date: Sun, 24 Jun 2007 10:50:30 +0000
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B43BC5A6@mtldsvr01.DotMobi.local>
To: "Shadi Abou-Zahra" <shadi@w3.org>, <public-bpwg-comments@w3.org>
Cc: <public-wai-ert@w3.org>, "Carlos Iglesias" <carlos.iglesias@fundacionctic.org>




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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:28 GMT