[important] Input for Step 3: recording page states

Dear Eval TF,

On 21.11.2013 18:26, RichardWarren wrote:
> 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?

Yes we can.

If anyone has an objection to this change, now is the time to raise it.

Best,
   Shadi


> 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)

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