RE: ACTION-837 - Provide explanatory text for the addendum...ISSUE-272 a new name ISSUE-273 for which document? ISSUE-274 which textsare needed?

Hi Manrique,

> Mostly of my points are about the text and "wording" in the 
> tests, and as far as I can remember, the texts weren't 
> discussed after the document was rewritten before Sophia's 
> F2F. Just to remember those that still apply in the latest 
> version of the document:

Answers are in the text.  


> 4.1 Access Keys
> We have "primary navigation links" in the "interpretation" 
> but "navigation links and form controls" in the "procedure". 
> Should it be the same text in both sections?

We can adjust this, but it was never discussed in detail.
Can be done when we finalize the document.


> 4.3 Avoid Free Text
> Take care that a "finite number" can be very big. Perhaps it 
> would be better a "reasonable finite number".

This what discussed at great length.  
We determined that those instances that are big are expected to be so,
which would not be a problem.
Beyond that we cannot think of a number that makes sense, considering
the many potential values.


> 
> 4.4 Background Image Readability
> Perhaps, it would be better adding reference to WCAG 2.0 
> tests instead of Ishihara in the examples.

The goal was to make the test deterministic.  This test does that.


> 4.9 Clarity
> Maybe we could take some 'info' or resources from WCAG2.0 
> effort to make the description "richer".
> References: http://www.w3.org/TR/WCAG20/#understandable

Please make a specific suggestion.  Which "info" are you referring to
specifically? There are many subsections.



> 4.12 Control Labeling
> How can a machine (easily) test that the label does not 
> describe the purpose of the form control?
> Perhaps not so 100% machine testable as "Note to BPWG" says.

The BP requires labelling and correct association.  Semantics cannot be
tested on a maschine basis in this case.


> Open issues: Are empty labels "" acceptable, if the meaning 
> of the field is made clear in some other fashion? 
> Perhaps for search boxes or date entry boxes?

That is indeed listed as an open issue and I believe should remain so.
It prompts a tester to evaluate that point.
Do you have a specific suggestion to close this point?


 
> 4.19 Link Target ID
> In the "Note to BPWG", the "title" attribute could be added 
> to define "ID".

This could be done, but addresses the BP document. 
This is under the responsibility of the group, not the task force.


> 4.22 Navigation
> What is the "sample"? I think it was in the original mobileOK 
> Pro document, but it seems that it has been removed in this 
> document, so the procedure may be not too clear

Are you referring to the Sample Scope?  This links to test scope, which
in turn offers the grouping of resources from POWDER as a potential
mechanism.
As such the sample scope is completely open and does not refer to
anything particular.
Perhaps I misunderstand your point?



> 4.26 Page Title
> I think that second test may conflicts with third example:
> Test: Does the title repeat unchanged across more than 3 
> pages? If yes [FAIL]
> Example: a title of "Uncle Tom's Cabin" in an ebook page, 
> across many pages, would be perfectly acceptable

You left out an important word:  "conversely a title of "Uncle Tom's
Cabin" in an ebook page..."
This means that in such an example it would be expected.



> 4.38 Use of color
> It says: "Excluding hyperlinks, does the page include any 
> other blue or purple text? If yes, [FAIL]"
> Then, I should put the links in blue or purple, shouldn't I?

Correct. Those are the expected colors for links.


> Shouldn't it be better something like:
> Excluding hyperlinks, does the page include any other text 
> with same color than hyperlinks? If yes, [FAIL]

Not necessarily, because the usage of different colors for links in the
first place is not very user friendly as it goes against convention and
thus makes the page less usable.
Especially on a mobile device with suboptimal lighting conditions and
potentially difficult to recognize colors in the first place, this
should not be a best practice.



I hope that clears things up.
Where I ask please do provide the appropriate information and, unless
somebody has problem with it, I am happy to fit it into the document
when I finish it.


-- Kai

Received on Monday, 15 September 2008 07:51:39 UTC