<Wilco_> clear agenda
<scribe> scribe: adil
WF: have alot of final call this
week
... have never seen that before
... couple of them have been merged
... one week call
... almost there and ready to go, does anyone have thought on
that?
... will be merging week 1 .... remove any example
... PR1357 form control
have one more days
comments from adil on that pull request
scribe: last one conditional
PR1345
... stil have one day to go
... final call 2 weeks
5 new PR
<Wilco_> https://github.com/act-rules/act-rules.github.io/pull/1354#discussion_r452184496
scribe: adil left comment PR
1354
... difference between descriptive and an equalant purpose
WF: will look at it and equalent
is good word for that
... nothing recent in PR1276 device motion based....
... pR1010 inline link in paragraph.... does this need to be
taken from final call?
JYM: Yes
CD: joined the meeting
zakin, take up next
:-D
WF: updated this list this
morning
... splitt up one the table with a separate list awaiting W3C
resolution awaiting
... there are explicit list of things waiting for input from
TF
AJ: aria-* ready for publication
WF: lets go from top to bottom
AJ: Added title to the PR
... linked to the bottom of aria-*
WF: need to approve that PR is
there in the PRE
... open a PR to fix the thing in these tables.
... all table header call have assignd data cells
... PR opened for all of these rules.
... image has non-empty ... need to update.
Jey: required context... implementation issue
WF: let see who can take that
up
... many stuff with respect to W3C
... aria required element
... PR?
AJ: PR1365
WF: ARIA stat or property .. any update?
Jey: Nothing yet.
WF: wanna add some date on that rule AJ?
AJ: reviewed
... happy to change the changes
27 july?
CD: one week final call
WF: will fix that
Jey: one week is enough
WF: need to go final call on
20th
... CD on table header?
CD: waiting for approval
PR1363
WF: adil review that?
AH: sure
WF: oject element has .... need
more
... take the text with min. contrast
... deadline
CD: suggested 3rd august
WF: accepted
... iframe elements have issues to resolve.
... might be ready to W3C, date?
Jey: it's acc. support changes
WF: 27th july?
Jey: Accepted, once it get merged what the process to get it done?
WF: let me know or leave a
comment, I will pick it up
... any thing else
WF: this may be small
discussion
... TF asked for non-interference accessibility requirement
mapping.
... it is a seprate requried with 5 6 SC under it
... if one of these 6 SC in the acces. mapp we should include
this non-intereference in mapping
... is that make sense practically?
... ?
AJ: can you repeat?
<Wilco_> https://www.w3.org/TR/WCAG21/#cc5
WF: if there is rule with 5 6 SC, also should include non-interference requirement
CD: make sense
... it is a WCAG requirement
... Jey what's your opinion?
... we do need to add in rules.
JYM: we already do some of
it
... need to add small changes in SC
... possible nothing as already have target in ARIA1.1
WF: JYM know what to do on it
JYM: the change should be easy to
do with linking it with acc. requirement
... taken that issue
WF: composite rule
implementation
... highlevel problem description
... we don't have not alot of implementation of atomic
rules
that do not map to SC
e.g links that have ... have different atomic rules in it
these things to pass this SC there is composite rule
that you need to pass one of atomic rule
we have implementation of comp. rules but not for the atomic rules.
it may be because that dont belong to SC and don't have confirmity requiremnt
JYM: in alfa we should need to submit the implementation
CD: it's same for QW, we can submit validation data for automic rule
WF: we only have one comp. rule
CD: video rule
WF: to solve this, most of the
test case in the comp. are from atomic rules, that's the right
way to do it.
... because the test cases are same it is possible to figure
out the result/conclusion
... if two rule have the same test cases have different #
create a dificult mappiong
but first thing is who can submit for atomic rule
scribe: we should fix this thing
even if the test case is same but # is gonna different
... complicated
JYM: related to other
thing.
... if we have hash which is unique enough, if we made some
changes to test case you don't need to change the
validation
<Jey> https://github.com/act-rules/act-rules-web/issues/193
WF: Jey and I have the discussion on that
Jey: proposed solution for
that
... moving test cases up and down
... rule id is problem with composite rule
... it is hard to map the implementation from composite to
atomic rule
... if implemented differently the hash will be changed
... requesting input on that
WF: summerise the purposal
Jey: solution given hashes
changes overtime
... when we change the logic how the hashes changes
then we push it to new key
scribe: WF have another opinion with dates.
WF: we could have multi ID
generator algorithm
... the date the rule last updated
... we keep running this issue
... the way we can do it, we can come up with new hasing
solution
... if the rule update we need to get the implementation data
update
... if not we don't need to update the implementation data.
Jey: all we do now npm install
repo.
... we don't have any input dependency on the repo.
JYM: we should have the last
updated date
... it will keep the log
... we already use hash algorithm
... we can reuse it.
JEY: it create another dependency.
WF: how would keeping the
previous ID work?
... if chaning the test case around that we now
JEY: those two generate the same
ID, because ID generated based on rule ID, language and code
inside the rule
... there would be any effect
WF: final thoughts?
JEY: sharing the screen
WF: time shortage
JEY: we can discuss in the issue created in github
WF: we had test data
JEY: it's long conversation and
DM provided the test data
... from that test data the DM provided
... the sequence of navgation is a big issue
... there been long conversation
... there is no concrete decision.
... opened an issue
... waiting for approval
CD: have two approval from SI
Jey: waiting for review other
WF: how do we missed this issue?
Jey: focus navigation
... there was no conversation before the issue open
... JAW was ignoring it
WF: safari is the one critical experience
Jey: Don't test the other
combination, relied on the information provided by DM
... it's like the table rows
WF: what we are doing now is reliing on voiceover
Jey: we have amende the
applicable
... when we wrote it iframe you can tab it navigate it
WF: suggestion or agree with the solution
Jey: disagree because we are
getting back and forth with TF feedback
... when writing the rule we should do the research actually
how it work
WF: agree
... we are the author of this rule
Jey: consider it as learning aspect.
WF: any other thoughts?
AJ: different user work on different browser
WF: JYM will be on vacation
... time goes fast
lets wrap
scribe: final thoughts
CD: good discussion
AJ: like to talk about heading as well
JYM: always interesting
Jey. Happy :-)
This is scribe.perl Revision of Date 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: Carlos, Adil, Jean-Yves, Wilco, Daniel, shadi, Wilco_, Jey Present: Carlos Adil Jean-Yves Wilco Daniel shadi Wilco_ Jey Found Scribe: adil Inferring ScribeNick: adil 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]