Trevor: Wilco asked me to run things today.
Daniel: It was really good to
meet people again. It had been a long time.
... We finished everything related to WAI-ARIA migration from
1.1 to 1.2.
... There was an issue opened whether aria-label triggers
conflict resolution. I think ARIA 1.3 will be addressing
that.
... Helen also raised an important point. Whether we should
write more rules on manual testing.
... This will be discussed on the CG call today.
... There was some text spacing work as well.
Helen: I also agreed to do public relations for the group
Trevor: CFC pretty much only
+1s
... that's going forward
Wilco: All the implementors +1'ed the CFC as well
Wilco: On sequential focus, there's an open PR. I need to resolve the feedback.
Daniel: I'll see what's changed in PR 1925 to avoid conflict
Helen: On iframes, Jean-Yves is working on it.
Daniel: On page title, I merged
1912 this morning.
... We changed the definition, moved something out of the
background
Wilco: I think we can put it out for CFC
Trevor: We have a couple from
Will, I'll meet with him today to work on that
... I have an open PR on automatic changes. I'm waiting for
feedback from Carlos
... I'll probably open a separate PR on changing the
applicability. I think there are ways to simplify
Tom: Still working on Text enhanced contrast
Chris: On CSS transforms. Trevor helped me with a PR. It has been approved, PR 1935
Wilco: I'll merge 1935 then
Trevor: PR 1950, needs reviewers,
updating rules to ARIA 1.2
... lots of link updated, couple entries in the glossary.
... PR 1945, consistency to support and assumptions
wording.
... I went through the assumptions, and I tried to give more
consistent wording.
Daniel: I'll put the italics back.
Helen: For some cognitive impairments, italics are difficult to read.
Trevor: Is there other styling we could use?
Helen: For readability it's probably better to have it plain. Italic suggests it's important to know there are no assumptions.
Daniel: No underscores then
Trevor: 1941, remove outdated
support notes
... 1935, I think this is editorial, it can be merged without
call for review
... 1933: looks like it's approved
... 1931 is approved
... heading is descriptive, there are a couple change
requests.
Helen: His last update was he hadn't had a chance
Trevor: 1925, remove exception
from focus visible. That's the item we took to AG.
... 1917 looks ready, but we'll wait for Kathy to get
back
... 1916, definition for essential text change. I think this PR
may be ready to go. I need to get some approvals.
... Assigned to Wilco, Daniel, Helen
... 1855 from Helen, Jean-Yves is working on that
Wilco: 1742 is getting picked on again by Mark, this was something Chris had assigned.
Trevor: Support on title attributes, sounds like that's finished
Wilco: The ARIA 1.2 priority
issue is getting addressed. No progress on the other two
... The xml:lang issue can be closed as that's getting
deprecated
<dmontalvo> https://www.w3.org/WAI/standards-guidelines/act/rules/afw4f7/proposed/
Trevor: Will commented on text with a 1:1 contrast
Will: Might be out of scope
Wilco: Should be out of scope, because it's not visible
Tom: There was a separate survey
on contrast.
... There was a todo about changing highest possible
contrast
... technically it's correct, but trying to figure out better
wording
Trevor: Do we have a PR?
Tom: Was out for a few weeks, I'm getting caught back up
Trevor: I can put this in, two
birds / one stone
... We still have that todo, but once it's fixed on the second
rule, it should be fixed here too
... On Kathy's comment, adjust the contrast on the letter
"K"
Wilco: I think I put a text-shadow on the text for that
Trevor: I don't think the open
issues need to be addressed
... I wonder if we should put these rules out before secondary
requirements?
... I wonder also if we should check color filters or things on
the OS.
... At least for a while, Chrome wasn't great with windows
contrast mode. It could make things with good contrast into
poor contrast?
... Might not be relevant.
Helen: Not all browsers allow you
high contrast. I think that's beyond this.
... You cannot control what people have on their devices.
Trevor: Agreed, I don't think it
needs to be said in the rule.
... Have we decided we'll go forward with rules like that?
Wilco: I think we can move forward with these rules without secondary requirements. I'm not even sure AGWG will let us use secondary requirements until it's spec'ed out.
Tom: I can be liaison on this.
<trevor> https://github.com/act-rules/act-rules.github.io/issues/1953
Trevor: The next conversation I
wanted to have was on applicability.
... When we proposed writing an update to the format, we'd been
debating allowing subjective applicability.
... There are two ways to go. If we want a subjective
applicability, it changes how we can define states in more
human intuitive ways, but less quantitative.
... If not we have to rely on specs with defined states.
... Defining states, and transitions between states can be
difficult. There are more or less an infinite number of ways
that can happen.
... Back in 2021 we talked about state and decided to look at
CSS pseudo classes. These match an element when they're in a
particular state.
... You can say in CSS, if someone focuses an element, you can
change the style.
... CSS states are for the most part pretty concrete.
... CSS gives us very concrete, very objective definitions. The
problem is that pseudo-classes are constraint. There's a finite
state, if we need things outside this list, we may not be able
to write rules for it.
<Will_c> I have to drop to lead a demo
Trevor: An example of something
that's hard is form validation done by javascript.
... Another thing would be a dropdown menu. Something that
expands / animates. I don't see how to tie the action of
clicking a drop-down with the actual state change.
... I think there are three paths;
1. Continue with CSS states. 2. An extension of that, looking at other specs, for example ARIA.
scribe: 3. Or we open and allow
subjective applicability.
... Things from specs are well defined and objective, but it
can't represent all states.
... The second, we saw with CSS that creating understandable
rules can be difficult. You're using CSS as a proxy of the
element.
... the other option, subjective applicability gives us much
more options on defining states, but makes it difficult to
determine state consistently, and may not be backward
compatibility?
... I want to start thinking about what we can handle with
specs, vs what we can handle with subjective applicability
Wilco: We could also consider input aspects as a way to work around objectivity. We did that with language and with accessibility tree. Those aren't well defined, but we're taking them as input