scribe+ dan_tripp
wilco: will change it to use javascript
carlos: another round of reviews?
wilco: no.
carlos: no 1-weeks, no PRs.
jean-yves: still waiting for
review on 1923, 1994
... been waiting almost a year.
wilco: been doing mostly task
force work.
... have some blocking feedback from AGWG
... (template work)
helen: haven't been working on much lately, sorry
trevor: I have many task force PRs open
<CarlosD> scribe+
<CarlosD> dan_tripp: PR about label in name #2075 needs reviews
wilco: (update from task force):
doing through annual review.
... trevor has been working on subjectivity. a major topic in
rules format 1.1.
... daniel has been streamlining publication process.
... waiting for WG ...
... on hold until WCAG 2.2 is done
... we might be getting a new implementation. oracle. a manual
implementation.
... takes ~ 1.5 months to go through all (approved) rules. ~ 20
rules.
helen: waiting for trevor's
discussion re: subjectivity (re: manual rules)
... waiting for more code examples (dan)
carlos: registration has opened.
early bird closes mid-july.
... standard rate is almost double.
... ACT TF is scheduled for thurs, fri (14, 15 of
september)
wilco: if you're attending only ACT, only remote, you might be able to attend for free.
carlos: also applies to
in-person.
... hybrid event. waiver easier to get if remote.
wilco: looking forward to seeing you all.
carlos: this is about work mostly trevor has been doing. trevor: take the floor.
trevor: sharing my screen.
<trevor_> https://github.com/act-rules/act-rules.github.io/discussions/2046
trevor: first stateful, then
subjectivity.
... we started w/ some instances of stateful rules that we want
to handle.
... first issue: "status messages are announced to user"
... main discussion points: 1) javascript as input aspect.
2) adding subjectivity into applicability
3) introducing "where-after" language. = where we define elements that are initial landing points. when something happens to them, we expect state change to occur, and specify what the state change will be.
trevor: 4) "activation". = some
action on the page. open to better wording.
... 5) "hooks".
... will now go through this example stateful rule.
... (talking through example at
https://github.com/act-rules/act-rules.github.io/discussions/2046
- applicability)
carlos: don't think "appeared" expressed the causal relationship
trevor: fair point.
... that does muddy things up.
wilco: that's a long-standing
problem.
... we'll need to define "appeared" and link it in terms of
time. eg. within 1 second of.
trevor: good point.
... might need to have assumption. i.e. able to follow the
correlation.
... I will add a comment about adding assumptions re:
causation. and/or defining "appeared".
... if it will fix it?
carlos: yes. can't do better than that.
trevor: this rule is relatively
easy. do 1 thing, 1 state change results.
... helen's modal window is more complicated. will take more
work. hope to keep similar format.
... (now discussioning "expecations" at
https://github.com/act-rules/act-rules.github.io/discussions/2046)
... (now discussing passed/failed examples at
https://github.com/act-rules/act-rules.github.io/discussions/2046)
... inclusion of javascript as input aspect: only point of
contention is that you don't need an understanding of JS in
order to be evaluated.
we're back on
wilco restarted it
I re-joined from the link in the email
<Helen> Don't ping him again Wilco!
<Wilco> please
<Helen> +1
<trevor_> +1
+1
trevor: re: javascript as input aspect: personally - b/c it requires the test environment to run JS. in favour of including it. doesn't require /understanding/ the javascript.
jean-yves: reminds me of
discussion of language as input aspect.
... need to understand that language? or recognize it?
manipulate it?
... if you look in repo re: language, you'll find commentary.
it ended up as a common input aspect.
... for some rules you need to understand the language. for
some you don't.
... so we might be able to do something similar w/
javascript.
carlos: in some test subjects, we already rely on javascript.
<Wilco> +1
wilco: linters showed me that we might need an input aspect for external images. maybe iframe loading too.
trevor: sounds like we're mostly
in favour of allowing javascript as an input aspect. that's all
I need.
... re: "where-after" language. big thing: causation between
action and result.
... any other concerns?
jean-yves: IDK if we need to
update rule format to make this clear.
... let's see how it unfolds re: making it explicit vs.
implicit in rule format.
trevor: we could rewrite helen's
focus rules in this "where-after" language.
... fourth topic: using the term "activation".
... does that term seem ok?
carlos: does the origin of the
change in the page need to be taken into account?
... what if the change happened because eg. a timer has
completed?
... will "activation" still accurately describe that?
trevor: fair point.
... passed example 2: has a log. calling this an "activation"
is a stretch.
... will have to think about that.
carlos: maybe we can come up w/ a better term but for now, no objection.
trevor: last topic: whether or
not to include "hooks"
... i.e. to allow tools to get to different states.
... tool says: I want you to get to the next state for me.
jean-yves: not really helping to
implement the rule.
... would call that help to build the report. helping the
vendor.
... important to me. doesn't help the tool implement the rule.
helps the vendor implement the report.
... still in favour. b/c we want more implementation
reports.
... but it's a bit unrelated to the rule.
... makes it hard to understand for the humans reading the
rule.
... this is orthogonal to the stateful rules discussion.
wilco: if we allow ppl to use
these hooks, it'll be semi-automated at best.
... and will we be favouring specific tools?
... was hoping that hooks will be pretty generic.
... (across rules.)
... we'll need to pass information between states.
annoying.
... it's messy.
(scribe mistake: last few lines weren't wilco)
(were trevor, I think)
wilco: if we're writing rules
that require certain interactions to have happened on the page,
if that interaction isn't explicitly in WCAG, then expecting
that from an implementor goes beyond WCAG.
... is it the responsibility of the tester to discover these
states?
jean-yves: if it's about testing
a page in one state: eg. wait for page load - this is
needed.
... for this rule where we need to test in multiple states,
does this become the responsibility of the tester?
... should the tool do state exploration?
wilco: because it's not explicitly in WCAG, seems like more of a pre-condition rather than evaluation of WCAG itself. that's the conversation that people are having right now.
trevor: if (as per example on
github discussion page) we evaluated on second state where
status message has appeared ...
... should eg. kathy as a manual tester need to know how to get
to all the states?
<trevor_> https://github.com/act-rules/act-rules.github.io/discussions/2061
trevor: ^^ discussion on
subjectivity
... if we can narrow down types of subjectivity, we can avoid
people free-form writing subjectivity. please add some mental
horse-power to this discussion.
carlos: would it be useful to have another meeting on subjectivity?
trevor: yes, if you have the time.
This is scribe.perl Revision VERSION of 2020-12-31 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: dan_tripp, Helen, CarlosD, Jean-Yves, giacomo-petri, Wilco, trevor_ Present: dan_tripp, Helen, CarlosD, Jean-Yves, giacomo-petri, Wilco, trevor_ No ScribeNick specified. Guessing ScribeNick: dan_tripp Inferring Scribes: dan_tripp WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]