Re: Input for Step 3: recording page states

Hi Richard, 

I am not advocating over-using 'common' - the problem is qualifying the page sampling steps (i.e., states should be included) so that testers are remonden to look aut for and include states while keeping down repetition and redundancy. I do not yet have a good solution myself.

As to the defition of states that you point to ("Each such web page state is considered as an individual web page in the context of this methodology"),
I can't remember when that was included. I personally think it is not a good idea and shudder to think of the implications. A typical page today often has a number of additional states, say, a pull-down manu, a tabbed section, and a lightbox. Do we seriously want to inflate the number of pages in our sample by creating one page each for each page state that we want to include? It would then be necessary to reference the base page and include the action to call up the particular state ain any case. That gets very combersome and confusing. Much better to register states covered (and actions how to call them up) on the base page that becomes part of the sample!

Best,
Detlev


> 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

Received on Thursday, 21 November 2013 14:30:35 UTC