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

Comments below...

El lun, 15-09-2008 a las 09:50 +0200, Scheppe, Kai-Dietrich escribió:
> > 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.
> 

Ok, agree

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

That's true, my point here is about wording, adding "reasonable" to
"finite number" just to point out that there isn't a specific number but
not any "finite number" is possible.

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

You are talking about the "Background Image readability" test, arent't
you? Ok, perhaps it was me that missed a link to [COLOR CONTRAST] test
in the test procedure.

> 
> > 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.
> 
Specific section: Guideline 3.1 Readable: Make text content readable and
understandable
http://www.w3.org/TR/WCAG20/#meaning

Many "mobile" web sites use abbreviations to reduce text on screen, but
they may be difficult to understand. They should/could use abbr and
acronym elements:
http://www.w3.org/TR/2008/WD-UNDERSTANDING-WCAG20-20080430/meaning-located.html

Test example:
For every abbreviation, acronym or initialism in a Web page, if its
expansion or explanation is not provided using abbr or acronym elements
[FAIL]

Resources:
http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H28.html

I would like hearing about ideas/tests coming from this:
http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/G153.html

Example: For every sentence in a Web page:
If is longer than 25 words [FAIL]
If has more than 2 conjuction [FAIL]

Just other ideas about language used in a Web page:
Using language attributes on the html element
http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#H57
Using language attributes to identify changes in the human language
http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#H58

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

I am not sure if I understand you... I mean that "Note to BPWG" says
that "This test is machine testable", but I think that it isn't true
because a machine can't test "If the label describe the purpose of the
form control", or can it?

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

It was more a suggestion, to add "search or date entry boxes" text as
example of "meaning of the field clear in some other fashion". Nothing
else.

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

Ok

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

Sorry, it was my fault, I haven't seen the link.

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

I know we have discussed this before. But, if I want to bookmark two
specific pages, my bookmarks would say "Uncle Tom's Cabin" for both
pages. That's the problem I see with this example, even when I
understand your point.

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

Maybe, but with CSS you can change that. Are we 'promoting' that
designers should use blue/purple 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.

To make a Web page usable, links should be easy to identify but that
doesn't force the designer to use blue color. Of course, "blue is still
the color with the strongest perceived affordance of clickability"[1],
but the main suggestion is "Never show text in your chosen link colors
unless it's a link". Perhaps something like this would work?:

Excluding hyperlinks, does the page include any other text with same
color than hyperlinks? If yes, [FAIL]
Excluding hyperlinks, does the page include any other blue or purple
text? If yes, [WARN]

Just relaxing the constraints, but giving a WARN to those blue/purple
texts.

> 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 don't understand this point and how it is related with [USE OF COLOR]

Thanks and best regards,

[1] http://www.useit.com/alertbox/20040510.html

-- 
José Manrique López de la Fuente <manrique.lopez@fundacionctic.org>
Área de Tecnología Fundación CTIC
Web: http://www.fundacionctic.org
Tel: (+34) 984 29 12 12
Parque Científico Tecnológico de Gijón
Edificio Centros Tecnológicos
Cabueñes s/n
33203 GIJÓN - ASTURIAS - ESPAÑA
#Antes de imprimir este e-mail piense bien si es necesario hacerlo: El
medioambiente es cosa de todos.

Received on Thursday, 18 September 2008 09:05:12 UTC