Re: Input for Step 3: recording page states

Hi Shadi,

Detlev is right when he says  "Much better to register states covered (and 
actions how to call them up) on the base page that becomes part of the 
sample!".  Treating each "state" as a seperate page would be extremely 
confusing and labour intensive.

So can we change the wording for the definition?

Richard

-----Original Message----- 
From: Shadi Abou-Zahra
Sent: Thursday, November 21, 2013 2:53 PM
To: Detlev Fischer ; public-wai-evaltf@w3.org ; melledge@yahoo.com ; 
richard.warren@userite.com
Subject: Re: Input for Step 3: recording page states

Hi Detlev, all,

Just to say that I principally agree with reminding evaluators about web
page states and tried to implement that in Step 2.c:
  - http://www.w3.org/WAI/ER/conformance/ED-methodology-20131119#step2c

I've also been working on some changes to section 3 but did not get them
in time for today's meeting.

We should, however, discuss the objection to "Each such web page state
is considered as an individual web page in the context of this
methodology" in the definition for "web pages states":
  - http://www.w3.org/WAI/ER/conformance/ED-methodology-20131119#states

Best,
   Shadi


On 21.11.2013 15:30, Detlev Fischer wrote:
> 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
>
>
>

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, W3C/WAI International Program Office
Evaluation and Repair Tools Working Group (ERT WG)
Research and Development Working Group (RDWG)

Richard Warren
Technical Manager
Website Auditing Limited (Userite)
http://www.website-accessibility.com

Received on Thursday, 21 November 2013 17:27:17 UTC