Re: Input for Step 3: recording page states

Hi Detlev, all--

If I understand the issue correctly, it may also make sense to revise Step 3.a. to read: "Step 3.a: Include Common Web Pages, States and Processes for the Website." This would reinforce the need to review compliance of the differing states found within a page.

I hope this is helpful.

Best regards,

Mike





On Wednesday, November 20, 2013 11:43 AM, Detlev Fischer <detlev.fischer@testkreis.de> wrote:
 
Hi everyone,

I had promised in the last telco to contribute a small part that would make it clear to testers sampling pages that in addition to recording URLs (where possible; often not possible in "Step 3.d: Include Complete Processes"), particular states of the page should be recorded for inclusion in testing. 
I think this is different from defining Complete Processes; it refers to toggle states (content accordions), popup states (lightboxes) that may spin out into sequences like browsing several images that do not need to be traversed in any particular order, pulldown menus / megadropdowns, 'stages' which often bring up distinct navigation options) etc.

The conceptual problem in including this aspect is that it should really be taken into account in *each* of the sampling steps as it may apply to any page selected, whether a common page, distinct type, other relevant, or randomly selected. 

One way to handle this is to include the provision under Step 3a and refer to it in steps 3b-3e by referencing 3a, for example, by adding "..including different page states as described in Step 3a".

But maybe there is a better option.

So here is a draft, assuming for now that this provision is added to the first step 3.a:

=============

Step 3.a: Include Common Web Pages of the Website

Methodology Requirement 3.a: Include all common web pages into the selected sample of web pages.

All common web pages<del>, including the common states of these web pages for web applications,</del> are part of the selected sample. These web pages are identified in step Step 2.a: Identify Common Web Pages of the Website. 

Important note: In addition to selecting and identifying the page, different page states should be included in testing. Where present, page states should be recorded for each page sampled by specifying the action needed to call them up. Examples for page states that should be included are:

* Toggle states in tab panels and content accordions that hide/remove and show/insert parts of the content
* Pop-up states such as 'light boxes' or other pseudo windows. These pop-up elements may in themselves contain several states, such as a row of images to be browsed.
* Pseudo dialogues that require some user action, especially in Complete Processes
* Pulldown menus, mega dropdowns, or stage views (large sections of new content) that often insert distinct content and navigation options not present on the default page.

Note that the content revealed in these states is often not present in the DOM at the time of loading the page, but dynamically added and removed via scripting and server calls.


// For Steps 3b-3e, add: "Make sure to including different page states where present as described in Step 3a."

// What can probably be dropped is the part "...including the common states of these web pages for web applications, ..." since the states are more explicitly defined, and do not only appear in web applications: there are all over the place today.

Best,
Detlev

=============

-- 
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Thedestraße 2
22767 Hamburg

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

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites