Re: Expectations...

Hi Alistair,
You are quite right. I think in many cases you wouldn't want to link
expectations in this way. All of the times where I've encountered such a
situation I've opted to use multiple rules and make that "expectation" part
of the applicability instead. One we're updating now is language. First
check that html has a lang, than check that the lang is valid, than check
that the lang matches with what is on the page. Three rules.

The open question is: Are there cases where you wouldn't be breaking things
up. We had one with aria-labelledby, which I think made sense to keep
together in a single rule, but we need more / better examples than that I
think to warrant keeping this in.

Wilco

On Wed, Mar 28, 2018 at 2:21 PM, Alistair Garrison <
alistair.garrison@levelaccess.com> wrote:

> Hi,
>
>
>
> In principle expectations are a good step forward over procedural steps.
> However, the document notes “The task force is looking for feedback about
> whether expectations should be allowed to reference each other, or if each
> must be testable independently of the others.”
>
>
>
> The example, however, contains such a dependency:
>
> …
>
> A rule for labels of HTML input elements may have the following
> expectations:
>
>
>
>    - The test target has an accessible name (as described in Accessible
>    Name and Description: Computation and API Mappings 1.1).
>    - The accessible name describes the purpose of the test target.
>
> …
>
>
>
> The second expectation is dependent on the first.
>
>
>
> To properly split them you’d have to have:
>
>
>
>    - The test target has an accessible name (as described in Accessible
>    Name and Description: Computation and API Mappings 1.1).
>    - Each test target given an accessible name, has an accessible name
>    that describes the purpose of the test target.
>
>
>
> However, continuing, I would suggest you need referencing; but the
> referencing is there to allow each statement to be executed separately; but
> efficiently.
>
>
>
> e.g.
>
>
>
>    - Expectation 1) The test target has an accessible name (as described
>    in Accessible Name and Description: Computation and API Mappings 1.1).
>    - Each test target for which expectation 1 is true, has an accessible
>    name that describes the purpose of the test target.
>
>
>
> Simply - some expectations become applicability statements for other
> expectations.
>
>
>
> All the best,
>
>
>
> Alistair
>
>
>
> ---
>
>
>
> Alistair Garrison
>
> Director of Accessibility Research
>
> Level Access
>
>
>



-- 
*Wilco Fiers*
Senior Accessibility Engineer - Co-facilitator WCAG-ACT - Chair Auto-WCAG