Re: Input for Step 3: recording page states

Hi Detlev, 

I welcome your suggestion.  My only comment is that we should refer to the "DOM state", rather than "page state".  Post load it is the DOM state we would need to assess.

All the best 

Alistair

On 21 Nov 2013, at 13:00, RichardWarren wrote:

> Hi Detlev,
>  
> 1) I am concerned about the use of the over-use of the word “common” as in common web pages and common states. In the former use we are defining a set of pages that can be identified from the navigation bar etc. (we even give examples). But “common states” is not so easy to define. It is surely much safer to explore all the different states.
>  
> 2) In the definitions section we already explain the tem "different states"  - http://www.w3.org/WAI/ER/conformance/ED-methodology-20131111#states
> so I wonder if we really need anything else? Could we perhaps simply improve on the definition?
>  
> Regards
> Richard
>  
> -----Original Message-----
> From: Detlev Fischer
> Sent: Thursday, November 21, 2013 10:56 AM
> To: public-wai-evaltf@w3.org ; melledge@yahoo.com
> Subject: Re: Input for Step 3: recording page states
>  
> Hi Michael,
>  
> Sure - I just wonder whether that would sound as if states and processes only need ot be included for 'Common Web Pages'.
> It seems clear that (depending on the complexity of the pages) looking for states should be part of sampling in *all* Steps 3a-3e. Appending 'States and Processes' in each Step title does seem a bit awkward and wordy.
>  
> It might be good to have a general part at the beginning pfo the Sampling section on what to include in sampling (pages, page states, processes) and how to record this information *before* entering the steps...
>  
> Best, Detlev
>  
> --
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
>  
> Mobil +49 (0)1577 170 73 84
> Tel +49 (0)40 439 10 68-3
> Fax +49 (0)40 439 10 68-5
>  
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>  
> Mike Elledge schrieb am 20.11.2013 22:54:
>  
> > 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
>  
>  
> Richard Warren
> Technical Manager
> Website Auditing Limited (Userite)
> http://www.website-accessibility.com