Expectations...

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

Received on Wednesday, 28 March 2018 12:22:45 UTC