Re: validity levels

Hi,

There is a use case for 'warnings'. For example (to stay in the realm of 
accessibility) to warn the user that longdesc attribute is one way of 
describing images, but that this feature is not widely supported by user 
agents and it should therefore not be used on its own. There may be also 
other values such as 'conditionally passed' or 'probably failed' that 
give the user more granuality in the validity level.

Having said that, all these values mentioned so far in this discussion 
can be derived from one of the core validity level values ('pass', 
'fail', 'cannotTell', 'notTested'). If someone can think of another 
value that is not in the core vocabulary then please raise this.

As to the 'extended values' which we are currently talking about, there 
have been a couple of proposals to address these. Here are the current 
proposals for discussion:

1. provide the 'extended values' as subclasses of the 'core values' 
within the EARL namespace (thus described in the EARL 1.0 Schema);
2. provide the 'extended values' as subclasses of the 'core values' but 
in a different namespace (to be described in the EARL 1.0 Guide);
3. do nothing and encourage tool developers to create, publish, and 
maintain the RDFS about their subclasses of the 'core values';

Note that, as CarlosI pointed out, the dc:description can also be a 
valuable mechanism for conveying information to the end-user. However, 
these would be text-based messages and not values that tools can pick up 
and work with. This should be therfore in addition to one of the 
subclassing approaches listed above.


Regards,
   Shadi


Carlos A Velasco wrote:
> Hi Paul, Charles, all,
> 
> Paul Walsh, Segala wrote:
>> ...
>>
>> Warnings (in tools) shouldn't exist as they're pretty meaningless to
>> experienced testers and only give inexperienced 'users' the wrong impression
>> about the state of results. It's not a bad idea for EARL to support it as a
>> means of bookmarking stuff.
> 
> Thus for my own understanding (since Shadi wants me to do some
> subclassing here ;-) ), let us say I have a Java compiler report on some
> compilation units: how do I report the compiler warnings? As a subclass
> of cannotTell? I don't think the definition fits at all: code compilers
> *do know* what a warning is. (... and we all know about the Bobby use
> case problem.)
> 
>> Tools that give warnings and hence give users the wrong impression about the
>> compliance of a Web site, are a large part of the problem of inaccessible
>> sites claiming accessibility compliance. An extreme example is the overuse
>> of Bobby to demonstrate compliance with Triple-A. Only the seriously
>> inexperienced would do this. But it happens a lot, allowing Watchfire to
>> have healthy Christmas parties. 
> 
> Maybe their parties are not due to Bobby sales ;-)
> 
> regards,
> carlos
> 

-- 
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 Monday, 23 October 2006 21:29:14 UTC