Re: Task testing structure

Hi Shawn

I'm kinda liking aspects of this approach (ACT Rules format for testing
flows), but (of course) I have a critical question: *how do we score
something like this*?

Each site(1) is going to have "critical paths" but few sites will be
sharing the same critical paths. Additionally, some paths or tasks (find
hours of operation) are significantly easier to do then others (update my
emergency contact information on my companies HR intranet), especially if
it pre-supposes that *all* paths start at a site's "homepage" (and/or the
outcome or solution to Success Criterion 2.4.5 Multiple Ways - i.e. a
sitemap page or search results page).

No matter which, it seems to me that testing a critical path needs to start
*somewhere*, and for a scalable and repeatable testing regime, about the
only thing all sites have in common is a 'homepage', which is something
your example already suggests:


   1. Load the pizza restaurant's site
      1. Possible inputs: found via search engine, hit a bookmark link,
      selected from browser's history, etc.
      2. *Main page loads* with focus at the top of the screen

Open question: is this a correct interpretation? Does all critical path
testing need to start from a common starting point?

Additionally, how do we ensure that *all *critical path testing is scoped
by any given site? (the current scoping proposal leaves it to the
site-owner to scope their conformance claims, so leaving out complex or
critical flows that are non-conformant could be easily overcome by simply
leaving those flows out of the testing scope).

JF


(1: site being an euphemism for 'online digital activity or presence' - as
we need to take XR and other emergent tech into account as well)

On Mon, Apr 27, 2020 at 10:28 AM Shawn Lauriat <lauriat@google.com> wrote:

> From an email I sent to some ACT folks a little while ago, where I had
> tried expressing my thoughts on how we could use the same kind of structure
> that ACT has, but as a way of essentially expressing overall scope as a set
> of user journeys for task based testing. Hoping this can help for
> tomorrow's conversation to have an example written out:
>
> For ACT rules, Link has accessible name
> <https://act-rules.github.io/rules/c487ae> applies
> <https://act-rules.github.io/rules/c487ae#applicability> to any HTML
> element with the semantic role
> <https://act-rules.github.io/rules/c487ae#semantic-role> of link that is included
> in the accessibility tree
> <https://act-rules.github.io/rules/c487ae#included-in-the-accessibility-tree>
> . Link in context is <https://act-rules.github.io/rules/5effbb>descriptive
> <https://act-rules.github.io/rules/5effbb> essentially applies to any
> element that passes Link has accessible name
> <https://act-rules.github.io/rules/c487ae>. In other words:
>
>    1. For each thing exposed in the accessibility tree as a link
>       1. Go through Link has accessible name
>       <https://act-rules.github.io/rules/c487ae> steps
>       2. For each link that fails, note result
>       3. For each link that passes
>          1. Go through Link in context is
>          <https://act-rules.github.io/rules/5effbb>descriptive
>          <https://act-rules.github.io/rules/5effbb> steps
>          2. For each link that fails, note result
>
> For tasks, even if simply in Education & Outreach type documentation, we
> could walk people through the process of defining tasks and the steps
> within each task similar to how the ACT Rules Format
> <https://www.w3.org/TR/act-rules-format/> describes composite rules and
> the atomic rules within each composite.
>
> The scope of a pizza restaurant's site could then have the definition of a
> collection of tasks, the level at which they could/would measure overall
> conformance:
>
>    1. Choose what kind of pizza to order from the available options
>    2. Find out the hours of operation
>    3. Find out how to get to the restaurant to dine in
>    4. Contact the restaurant to order delivery
>
> Each task could consist of atomic actions, typically defined by design,
> development, and testing activities. For task 2. Find out the hours of
> operation, that could look like:
>
>    1. Load the pizza restaurant's site
>       1. Possible inputs: found via search engine, hit a bookmark link,
>       selected from browser's history, etc.
>       2. Main page loads with focus at the top of the screen
>    2. Navigate to contact page (composite, describes one possible path)
>       1. Move focus to site navigation menu
>       2. Open navigation menu
>       3. Move focus to "Contact us" link
>       4. Activate link
>    3. Navigate to text containing the hours of operation (composite)
>       1. Find "Hours of operation" section
>       2. Read contents of "Hours of operation" section
>
> Within the steps of each atomic task bit, we could then run through the
> applicability checks for each ACT-type Rule. So Link has accessible name
> <https://act-rules.github.io/rules/c487ae> would apply to all links
> within the path, but not to a random link in the footer that has a label
> that doesn't imply any relation to hours or contact information.
>
> I have thoughts about how each of these could work and how we would define
> applicability of rules and such based on the tasks, but I think it would
> make sense to just start with this higher-level question of whether we
> could (or should) have some kind of structured task definition similar to
> ACT's current structured rule definition.
>
> -Shawn
>


-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com