<trevor> https://github.com/w3c/wcag-act/issues/417
WF: everyone got a task
TB: added to the feedback, was mostly done
<Wilco> https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/Rule_Publication_Tracking
<kasper> https://github.com/act-rules/act-rules.github.io/issues/1077
KI: put the feedback in the Community Group GitHub?
WF: in our so that it is all in one place, then notify sender
MJM: will do mine tomorrow
WF: employing similar approach with the Community Group (CG)
... person responsible for submitting a rule to our repo
... they relay any feedback from Task Force TF back to the CG
<Wilco> https://github.com/w3c/wcag-act/pull/425/files
WF: no controversial updates
... agreed to do a CFC last week
... will do it this week
WF: first comment ... from me
... think assumption could be clearer
... not a blocker
KE: identifying language is correct is when you need content
TB: inapplicable before content inserted by JavaScript?
WF: yes
TB: sounds good
WF: suggest raising issue but not blocking
... Kathy also suggests updating assumption
<Wilco> https://www.w3.org/WAI/WCAG21/Techniques/html/H58.html
CP: subcode, like "en-uk" is optional
... only primary code, like "en" is required
... should be reflected in assumption
<Wilco> https://act-rules.github.io/rules/de46e4
CP: example 2 should pass not fail
... yes, this needs to be changed
KI: working on this
TB: my comment is not meant strongly
... not sure how much value it offers
WF: apparently spaces in lang attribute can create issues
... need to include that too
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/1087
WF: send feedback it is too strict?
CP: relates to issue on sub-code?
WF: kind of. wording is imprecise. BCP47 does not talk about "primary code"
SAZ: consistent naming seems useful to avoid confusion
<Wilco> http://github.com/w3c/wcag/
CP: i'm delighted to take this task!
... will raise issue on AG GitHub
WF: some more issues raised on this
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/1130
WF: amount of issues suggest that rule is not a go
KE: we also use H58 in our work
... will changing that impact the other rule?
WF: yes, this affects two rules
KE: do we need to wait for response on these?
WF: don't think so
... nothing really wrong with H58 just imprecise wording
... will only make things clearer
WF: answer to question from Charu is "yes"
... community group between things having an accessible name, and things having a label
... separate things
... there is a different rule for 3.3.2
... should disabled form fields still require accessible name?
SAZ: think still UI component
WF: agree with that
... inactive button is still UI component
TB: inactive input ignored by screen reader?
KE: possibly not behave as form element
TB: needs visible label?
WF: think so too
... but separate issue from 4.1.2
TB: beware of double-reading
KE: disabled form field still a form?
... can't tab to it or interact with it
SAZ: definition for UI component provides "distinct function"
... when inactive, does it provide function?
WF: agree with that argumentation
KI: from ARIA spec, UI components disabled but still perceivable
... enabling may require some other action
MJM: for example, need to complete all input fields before submit button becomes enabled
WF: add to assumption "UI components still such when disabled"?
KE: agree needs to be perceivable
... but not sure it is still a UI component
MJM: still has role and function, just disabled
CP: agree with that
... needs name to be perceivable
WF: ok, needs additional assumption
... concerns with explicit role?
KE: had trouble pulling these into Report Tool
... are inapplicable according to our process