<ChrisLoiselle> I am set to scribe however may need to step away throughout call due to medical issues, can someone else scribe this week and I'll take next when I'm feeling better?
<scribe> scribe: trevor
<Wilco> https://github.com/act-rules/act-rules.github.io/pulls
wilco: A few new pull requests, please look at them if you can
chris: Getting back into the swing. Will take a look at some open requests
Will_C: Didn't get to update HTML element lang, but did complete the surveys.
Catherine: Need to look at some of the surveys. Want to meet with Kathy to go through the process.
thbrunet: Looked through some of
Wilco's PR. Still looking at iframe rule, need some more
discussion.
... did the survey from last week
kathy: I am liaison for a rule on
visible name that got some comments. A lot of back and forth
right now, mainly comments on extra spacing.
... Might need some agreement from AG on what the rule actually
requires. Did open a PR to update a composite rule on keyboard
trap.
... noticed some delays in updating the Trusted Tester ACT
rules fully tested rules.
trevor: call for review on element, and put more thoughts down on stateful discussion for today.
wilco: Had a few +1s, they were not from task force members, but I think the rule is ready
<Wilco> draft RESOLUTION: Accept Images of text rule as ready for AG
RESOLUTION: Accept Images of text rule as ready for AG
<kathy> https://w3c.github.io/wcag-act/act-rules-format.html#accessibility-requirements-mapping
kathy: Above is the link to the
draft ACT rules update including the secondary requirements.
Includes the last few months of work
... the AG chairs have been notified that we are reviewing an
editors draft.
<kathy> https://github.com/w3c/wcag-act/pull/531
kathy: the PR (link above) is still open, so you can add any comments that
wilco: I think its good for us
all to give it another read, since its likely been awhile. We
have reached out to CG for feedback to see what we get
there
... I will ask them to review it in the CG call today. Once we
are happy with it, we can ask AG if they want to review or wait
for a working draft.
... rules format is a normative document. Editors draft is
something we put out that we change regularly. The working
draft is communicated to the public as ready for review.
... next step would be the first public working draft for this
document. Slightly problem is the current charter doesn't
include a way to put out a working draft. Will be at least May
for the new charter.
<Wilco> https://www.w3.org/2021/Process-20211102/
thbrunet: If we have these working drafts will that affect the implementation reports
wilco: We are already advancing
on what we are planning to put into a working draft. it is
already affecting how we are doing the reporting.
... one of the things we want to do in 1.1 is formalize more
what it means to be consistent.
kathy: When we get to working draft is there any kind of time frame or limit?
wilco: We are supposed to get the
working draft to recommendation by 2025, plenty of time I
think
... think of this as a time box exercise, anything thats done
goes to 1.1, anything else goes to 1.2
wilco: Looks like we have plenty
responses
... q6 question from me for PR, just editorial and has
approvals so it can be merged today
... q7, wilco wondering if they should fail deprecated
properties or is it a separate rule
... when aria 1.2 came out we added an expectation about using
prohibited attributes, should we also add one for deprecated
attributes
... problems with deprecated attributes is that they sort of
never worked.
helen: Is that the same as invalid attributes?
wilco: I think its very much the same
Helen: Then we could just add some fail cases using deprecated attributes
thbrunet: Deprecated definition
doesn't necessarily mean invalid, just means that it will be
invalid eventually
... but it doesn't technically mean they are invalid
wilco: Asked them to deprecate since it doesn't work. The philosophy fo this rule is trying to use things that don't work. In that case a deprecated attribute isn't different from prohibited or not permitted
thbrunet: Should maybe be a qualification that it is part of the spec but in practical terms fails
Helen: Could we add an assumption?
Wilco: I think a note in the background might be easier. If we wanted to do this, would it be a third expectation? Should we split them out?
thbrunet: I would prefer separate, in our tool we might flag some for review and others as fail
Wilco: Should we do the same thing, have prohibited attributes as a separate rule?
Kathy: Our other rule specified 1.2, should we do the same here?
Wilco: Have a link, could change
the link text to ARIA 1.2
... but the ARIA folks actually asked us not to include the
ARIA version.
... we are specifically implementing towards ARIA 1.2. If we
were to move to 1.3 we would need to add more tests
... what I am trying to get at is should expectation 2 be its
own rule
ChrisLoiselle: Put some definitions in chat, for the definition of deprecated vs prohibited. The agents still have to support deprecated until it is no longer valid
<Helen> afk
ChrisLoiselle: would make more sense to separate it out to a new rule
Wilco: Agree, also additionally
think prohibited attributes should be its own rule
... might be good to have more granular ARIA rules. Has a bit
more overhead for maintaining
Will_C: Might have some overhead, but makes these discussions easier.
Wilco: Any disagreements with separating?
thbrunet: So we will have 2 new rules, potentially prohibited and deprecated.
Wilco: Possibly, though just
removing prohibited for this rule
... Proposal is expectation 1 stays and expectation 2 is moved
to its own rule
... this rule checks for known aria attributes that aren't
allowed on the element
... do have some work left on this rule.
kathy: will need to think about the names of the rules to make sure that they are clear.
Wilco: Might be other examples,
such as aria-checked on native checkboxes. So another way in
which aria-attributes may not be allowed.
... think that is it for the surveys.
... two new surveys for next week. There are open issues for
them, we want to get all of the issues and fix them
<kathy> scribe+
https://github.com/act-rules/act-rules.github.io/issues/1953
<kathy> trevor: last time, we looked at 3 rules talking about state
<kathy> ... 1 - link states; nice since we have a distinct list of link states
<kathy> ... 2 - expandable elements; states of expanded or collapsed, applicability would be elements with aria-expanded
<kathy> ... 3 - status messages were a struggle because of applicability, added another comment to issue 1953
https://www.w3.org/WAI/WCAG21/Understanding/status-messages.html
<kathy> ... used Understanding doc for Applicability to list a few common interactive elements with an event handler
<kathy> ... Expectations: activate test target does not trigger a status message, or status messages appear but does not cause state change of context
<kathy> ... then look at new element to have role=alert or aria-live=polite/assertive
<kathy> will: makes sense
<kathy> ... expectation section is good
<kathy> trevor: in Discussion Points of issue 1953, non-semantic HTML elements (divs, spans) are difficult to include
<kathy> will: doesn't 4.1.2 need to be met for 4.1.3 to pass
<kathy> wilco: we have plenty of rules that assume no violation of other requirements
<kathy> chris: some activations show busy and not text
<kathy> trevor: that may be covered separately
<kathy> ... another problem with applicability, some tools put event handlers at top level. Automated tools might have problems
<kathy> ... detecting those
<kathy> wilco: those are solvable. Write applicability to any button or ancestor with those events
<kathy> trevor: it got broader than I was hoping to go
<ChrisLoiselle> great work!
<kathy> chair: wilco