ISSUE-274 Which textsare needed for the Addendum

Hi Manrique,

Thanks for the info. Comments below, with snippage where you had agreed.

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

Good.  I will take care of that when we finalize


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


Ah, I see the misunderstanding.  We are talking about a list that is, by
definition, finite.  
Good example:  Countries - this list is big, may change, but it is
finite
Bad example: Names - This would not make sense to put into a drop-down
as it is, for all intents and purposes, infinite

I'll look at the wording to make this clearer.


> > > 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/mea
ning-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
>


I understand your points, but several of these aspects deal with AAA
accessibility.
Other, such as limiting sentences to 25 words, are editorially not
feasible (we tried stuff like this :-)
I think that goes much beyond what was intended in the BP or in the
addendum.

We left that test at warning level on purpose, because it cannot be
determined clearly if you are clear or not.
Depending on who you talk to the opinion on whether you are being clear
or not will vary.

I would really prefer to leave this as is.

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

That is the purpose of labels.  For example if the label says "First
Name" then it is pretty clear what is needed.
Even more, if it is ambiguous, then the label needs to explain what is
needed.

However, as I said early, semantics cannot be machine determined here,
which is why human is needed.
But, the association can be tested, which is what this test covers.
So I would prefer to leave this as is.

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

That is a good point, but it is up to the author to make sure that the
title of the page is explicit enough for the resource and its purpose.
It still very much a case by case question.
I don't see a need to change this.


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

Yes, you can change that, but you shouldn't.  
For the time being sticking to convention makes the most sense on a
mobile device.
This could be expanded to utilize another contrast test, but then what
about underlining?
By opening the "design" bag you are asking for trouble.  
I think we should leave it as is, but if you have ideas on how to allow
people to be creative yet maintain usability, please suggest it.

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


Yes, we could relax things, but consider the following...since you were
also asking about lighting.

For design reasons I decide I need yellow links.
I never use yellow anywhere else, except for my links.
That would fulfill what you propose, but is not a good example of
usability.

We could add something about contrast, but then I would have to specify
contrast between the link text, the normal text and the background and I
should probably add underlining, just to be sure.
Gets a bit difficult.

Why not simply stick with convention and everybody know what is meant?



-- Kai

Received on Thursday, 18 September 2008 11:38:59 UTC