W3C home > Mailing lists > Public > public-wai-evaltf@w3.org > August 2012

Draft for selecting processes in web applications (addition to Step 3.d)

From: Detlev Fischer <detlev.fischer@testkreis.de>
Date: Fri, 17 Aug 2012 10:43:36 +0200
Message-Id: <2AE8BD2B-4FA4-4073-B2EA-7A103343046C@testkreis.de>
To: Eval TF <public-wai-evaltf@w3.org>
Hi everyone,

as promised, I have tried to come up with draft (probably within step  
3.d) for including complete processes.
Feel free to shred this to pieces...


Step 3.d: Include Complete Processes in the Sample

1. For any critical process identified in Step 2.b: Identify Key  
Functionalities of the Website, the *process base page* is included in  
the sample. The process base page is the page that acts as launch pad  
for other states called up when traversing the process.

2. For processes with branches incl. error handling, record the  
*default branch of the process*. The default branch is the simplest  
use case, describing the default way through the process. It assumes  
that there are no user input errors and no selection of additional  
options. For example, in a checkout system, the user would proceed to  
checkout, confirm the default payment option, provide all required  
payment details correctly, and complete the purchase, without changing  
contents of the shopping cart, using a stored user profile, selecting  
alternative options for payment or shipping address, providing  
erroneous input, and so forth.

3. For processes that consequently call up or generate further pages  
(new URIs), add these *derived process pages* to the page sample,  
directly where possible or by specifying the actions on the base page  
of the process that led to it (e.g., "fill out form correctly and  
press "Submit"). The page description should indicate that this  
derived page is part of the same process as the first page, for  
example, through consistent numbering.

4. For each page of the process, the *page process record* should at  
least describe as list all steps / user interactions that lead to  
consequent process states on the same page. Optionally, it can include  
screen shots for these states. Whenever a process calls up a new URI,  
consequent states should enter the page process record of that derived  
process page / URI in the sample.

5. The page process record need only specify additional states to be  
evaluated, i.e., all elements that are added, modified or made visible  
on top of the base page.

6. For processes with branches that are commonly used or entered and  
are critical for the successful completion of the process, register  
*critical alternative branches* of the same process. Branches may  
terminate where they re-enter the default branch of the process, or be  
covered until their completion. For example, adding a new shipping  
address will be registered as a critical alternative branch that leads  
back to the default branch of the process.

Finally, two bits that might be added later in Step 4 "Audit the  
selected sample" to help operationalize checking processes in the  
still rather vague Step 4.a: Check for the Broadest Variety of Use  

* Those parts of the base page that remain unchanged need not be  
evaluated again when evaluating a particular page state.

* When evaluating elements in alternative branches that are found to  
be substantially the same as those already covered in the evaluation  
of another branch, the evaluation may simply record pass/fail and  
clearly refer to the comment made at the other location.

Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Borselstraße 3-7 (im Hof)
22765 Hamburg

Tel   +49 (0)40 439 10 68-3
Mobil +49 (0)1577 170 73 84
Fax   +49 (0)40 439 10 68-5

Beratung, Tests und Schulungen für barrierefreie Websites
Received on Friday, 17 August 2012 08:32:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:21 UTC