W3C home > Mailing lists > Public > public-wai-ert-tsdtf@w3.org > January 2008

Re: Primary attribute

From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
Date: Tue, 08 Jan 2008 14:25:52 +0100
Message-Id: <6.2.5.6.2.20080108135416.03f19db0@esat.kuleuven.be>
To: <public-wai-ert-tsdtf@w3.org>

Hi Carlos, All,

At 10:10 8/01/2008, Carlos Iglesias wrote:
>Hi everybody,
>
>During our last teleconference we were 
>discussing about the need or convenience of 
>having a "primary" attribute for the "rule" 
>element. The following is an attempt to summarize the discussion so far.
>
>You can see the TCDL 2.0 description of the 
>attribute at [1], but in brief it specifies 
>whether a rule is "primary" (yes) or not (no), 
>being primary rules those against which the test 
>case is supposed to be evaluated (other rules 
>are supposed to be just informational)
>
>So, the two options that were discussed are:
>
>1 - Allowing just one single (always primary) rule per test sample
>
>PROS
>
>- It could help to simplify test samples and 
>metadata (the primary attribute won't be necessary any more)

After the 11 December telecon, I made the 
"primary" attribute optional; the default value is "yes".


>- This approach follow test cases development 
>best practices as, generally speaking, a good 
>test case should be atomic [2], testing a single 
>feature at a time. (Note that in some cases 
>compound tests are necessary, e.g. a test that 
>check the combination of "border-top-color" and 
>"color" in CSS, but this may not be the case in 
>WCAG as success criterion are intended to be independent)

Test case development best practices are usually 
based on testing technical specifications (simply 
stated: document or file formats). In that 
context, you can test a single feature and it 
does not matter what the effect of other features 
is on the user experience, because you just test 
whether an implementation (say, a browser) 
supports the feature or not. Accessibility 
guidelines are different, because any other 
feature present in the document (and you can't 
create a document with just one feature) may 
affect the user experience. Otherwise, nobody 
would have required that the test samples follow 
best practices. So atomicity is a problematic 
concept here, even if WCAG 2.0 success criteria can be tested independently.
The scope requirement in the checklist for 
content review states that a test sample "must 
not combine several issues in one test", so we 
need to clarify what "issue" means here.


>CONS
>
>- Even with minimal test samples we could find 
>frequently that more than one rule (success 
>criteria) may be applicable. What to do then 
>with those that are not the primary rule?
>
>For example:
>
>If we take sc3.3.1_l1_019 [3] we see that the 
>primary rule here is WCAG2 SC 3.3.1 [4], but 
>there are other potential applicable rules such 
>as WCAG2 SC 3.3.2, 3.3.6 or 1.3.1.
>
>2 - Allowing multiple rules (primary or informational)
>
>PROS
>
>This way we could look for more completeness on 
>test samples, reporting about any related or 
>applicable rule apart from the primary one.
>
>CONS
>
>- In same sense it may be incompatible with the 
>"Clear Scope principle" at the Content Review 
>[5], at least as currently stated.

That depends on how we define "issue".


>- Do we have any use case where this could be a 
>benefit in our context? (Apparently no one of 
>the current submitted test samples has a non-primary rule).

If you have a test sample with multiple files, 
several success criteria can be seen as relevant:
* 2.4.5 Multiple Ways: More than one way is 
available to locate content within a set of Web 
pages where content is not the result of, or a step in, a process. (Level AA)
* 2.4.7 Location: Information about the user's 
location within a set of Web pages is available. (Level AAA)
* 3.2.3 Consistent Navigation: Navigational 
mechanisms that are repeated on multiple Web 
pages within a set of Web pages occur in the same 
relative order each time they are repeated, 
unless a change is initiated by the user. (Level AA)
* 3.2.4 Consistent Identification: Components 
that have the same functionality within a set of 
Web pages are identified consistently. (Level AA)

If you create a test sample for SC 2.4.7, would 
you require that the other SC's are also met? If 
not, that needs to recorded somehow. One way is 
in the purpose: "Only the availability of 
information about the user's location is tested 
here, not skiplinks, the ways in which content 
can be located, or the consistency of navigation elements."
Using <rule> elements with 'primary="no"' would 
be a machine readable alternative (or complement) to this.

(The submitted test samples have only primary 
rules because we chose not to migrate the other rules.)


>- What is the common criterion we all can follow 
>to agree when a rule is primary or not? Will 
>full completeness always be required?

The criterion would be the purpose of the test 
sample. "purpose" and <rule primary="yes" ...> need to be consistent.


>Note also that we have two possible variants within this option:
>
>   A - Allowing just one primary rule and several other informational ones
>   B - Allowing several primary (at least one) and informational rules
>
>I think nobody was in favour of the later, but 
>we can easily see how the complexity would 
>increase (For example, what's the criterion to 
>decide if a rule should be primary or not).

In BenToWeb, we did not restrict ourselves 
beforehand: the intention was to first create 
only test cases with just one primary rule; if we 
had some time left after this, we could also 
create test samples with several primary rules. 
So instead of simply forbidding test samples with 
more than one primary rule, we could just 
treating those as a low priority by saying that 
we will only create test cases with multiple 
primary rules when we have a complete suite of 
test sample with only one primary rule.



>Finally, another related issue is the use of the 
>"complexity" attribute for the "testCase" 
>element [6] whose values are "atomic", if it 
>applies to only one accessibility rule 
>(checkpoint, success criterion...) of any kind 
>of rules set (WCAG 1.0, WCAG 2.0 or Section 
>508), or complex if it applies to multiple 
>accessibility rules from the same set. So, 
>apparently, if we finally decide to follow 
>option 1 (just one single rule) the "complexity" 
>attribute will also turn to unnecessary.

I also made "complexity" optional; the default value is "atomic".


>If we follow option 2 (multiple rules) I'm not 
>sure if this attribute may be necessary, as the 
>number of rule elements may give you the same 
>information (atomic if one or complex if more). 
>Additionally, we should clarify if it takes into 
>account just primary rules or also informational ones.

"Complexity" was meant to refer to the primary 
rules; apparently I forgot to make this explicit. Thanks for cathing that.

Best regards,

Christophe


>I hope this could help to advance on this issue discussion.
>
>[1] - [http://bentoweb.org/refs/TCDL2.0-20071210.html#edef-rule]
>[2] - [http://www.w3.org/QA/WG/2005/01/test-faq#good]
>[3] - [http://www.w3.org/WAI/ER/tests/xhtml/testfiles/sc3.3.1_l1_019.html]
>[4] - [http://www.w3.org/WAI/ER/tests/xhtml/metadata/sc3.3.1_l1_019.xml]
>[5] - [http://www.w3.org/WAI/ER/tests/process#content]
>[6] - [http://bentoweb.org/refs/TCDL2.0-20071210.html#edef-testcase]
>
>Waiting for your thoughts. Regards,
>  CI.
>_________________
>
>Carlos Iglesias
>
>Fundación CTIC
>Parque Científico-Tecnológico de Gijón
>33203 - Gijón, Asturias, España
>
>teléfono: +34 984291212
>fax: +34 984390612
>email: carlos.iglesias@fundacionctic.org
>URL: http://www.fundacionctic.org

---
Please stop inviting me to LinkedIn, Facebook, 
Quechup or other anti-social networks. You may 
have agreed to their "privacy policy", but I haven't.

-- 
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/ 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Tuesday, 8 January 2008 13:26:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:01 UTC