Wilco: Last week we discussed
re-structuring test procedure.
... Worked on alternative proposal.
<Wilco> https://github.com/w3c/wcag-act/issues/152
Kasper: Re-write of part 3. Tried re-write using applicability and expectation.
Kasper - Writing less implementation specific - without using css selectors or xpath selectors.
Kasper - For the expectation - background this rule is procedural. So we tried to write things in terms of expectations.
Kasper - you can use this to model hierarchy...
Kasper - language is kept less technical / implementation specific.
Kasper - so it could be done manually, or coded-up...
Wilco - you have dropped the referencing the results?
Kasper - that is on purpose. Each expectation leads to a pass or a fail. Go through each expectation and determine if it holds.
Kasper - if expectation 1 does not hold, that would be a fail.
Kasper - you could attach a piece of text to that expectation.
<MoeKraft> expectation = a strong belief that something will happen or be the case in the future.
Alistair - what is the benefit of this?
Anne - programmers could read the test?
<MoeKraft> expectation seems very abstract
Kasper - previously, we were writing tests as a set of procedures.
Alistair - Still what is the point. Is it that applicability is being set on the output of other tests.
Wilco - Trying to find a way to move away from the large procedural tests, so that new tests can have their applicability based on input from other tests.
Wilco - what made you ditch the css selector.
Kasper - you can't write the css selector to cover what you need to find.
Kasper - there's loads of stuff you can't locate using css selectors.
Wilco - why the perceivable by wai-aria piece?
Kasper - as this rule requires aria-support.
Anne - we did not want to re-write the language of the test too much...
Wilco - like the expectation bit, but having difficulty with the applicability bit.
Wilco - Change to r3 - uses a css selector... Tried using expectations, but it did not seem like the right word to be describing what we wanted.
Wilco - there's some terminology to consider.
Wilco - Then I borrowed some things from Gherkin.
Wilco - The if, then, else worked ok... but did not do everything.
Wilco - The scenario I wrote was not specific to HTML - just the css selector. The css selector is only there for automatic testing... For manual testing, you'd just want to say find the video on the page.
Wilco - any element which contains a semantic image. It broadens things quite considerably.
Wilco - in r3, if you are using a video or audio element you can automate things easily - if you are using object then it's much harder.
Kasper - just describing what you are looking for in plain english allows you to describe things easily.
Wilco - my concern is by not using precise language in applicability you'll get different results automatically from manually.
Wilco - if you are doing this manually it does not matter if it is a video element or an object element.
Romane - In the current draft, both css and plain-language selectors can be used.
Romane - Role of process to validate a rule, and validate the applicability section.
Romane - aria roles cannot always be written for aria roles.
Romane - BDD approach to rule writing - you said it didn't fit? But, it would be good to hear more?
Wilco - why Gherkin didn't work.
Wilco - Gherkin uses Given, And, When, Then...
Wilco - Struggling with Given...
Wilco - looking at applicability... in terms of Given.
Wilco - looking at r2 in a given, when and then approach gives a procedure - which is what we are not trying to do.
Romane - It describes a scenario. A bit like the expectation idea, but more formalised.
Wilco - you are defining the order in which you are trying to do things.
Romane - in r2 there are dependencies. So there is an order implied there...
Alistair - you need to think about making things as atomic as possible.
Alistair - dependencies will create a difficult to maintain set of rules.
Kasper - Every rule should have a single passing condition.
Kasper - then you aggregate in rule groups.
Wilco - should r2 be 3 rules.
Kasper - you need expectation 3 to determine if an image passes a rule.
Kasper - we need to find a way to specify which are the passing conditions.
Alistair - I think you'll end up with a house-of-cards type structure, which may well be difficult to maintain.
Kasper - I disagree. r2 is stand-alone.
Kasper - I don't see how this is not atomic.
Anne - it is nor dependent on R1 and R2 - it is dependent on expectation 1 and expectation 2.
Wilco - I think this rule can be broken down, but is this a good idea?
Wilco - you could move out certain pieces in the expectations...
Anne - what if R1a gets retired.
Wilco - You could move it out.
Wilco - R2B would be separate from R2A.
Wilco - you move the applicability into each of the rules.
Wilco - fundamental question is - do we need expectation to be separated or not.
Wilco - we'll go back to Kasper's comments on how the structure is in part 3.
Wilco - I think you're right - in pulling things into separate rules it becomes an issue with presentation.
Wilco - if you look at things in isolation things look strange.
Anne - won't that apply to rule groups, so we have to think carefully about how to present different rule groups.
Wilco - these rules might have to be r3a and r3b...
Wilco - all interesting.